Another way to organize APCA "General Guidelines"

[front-endian]

Howdy!

On my journey to better understand APCA and teach the designers that I work with about it, I encountered a hurdle. The measurement is great, but the way some documentation is formatted made it harder to use day to day for designers.

The lookup tables you provide are good for dissecting fine grain recommendations for exactly what the minimums are for a given font size when doing an accessibility review, but they are too large/complicated for our designers to use daily. The General Guidelines are great for giving more pragmatic recommendations, but the the way they are organized makes them a bit tricky to use for ordinary design work. Both of these are fantastic resources, but I have been working on other ways to visualize APCA to make referencing requirements faster.

When our designers are doing work, they know what kind of element they are working on (button border, input label, header, etc), and just need a quick way to answer "what Lc value do I need to meet?".

Because the General Guidelines are sorted by Lc values, finding the requirements for a given component can be difficult. To solve this, I tried breaking down all the different types of text/graphics mentioned in the General Guidelines and creating a table to more quickly reference the requirements for a specific type of contrast:

content type	Lc 90	Lc 75	Lc 60	Lc 45	Lc 30	Lc 15	less than Lc 15
Body Text	great readability for large blocks of text 14px or larger	good readability for large blocks of text 18px (14px bold) or larger					effectively invisible
Non-body Text	great readability for short lines of text, buttons, labels, etc, 12px or larger	good readability (need to fill in size limit)	okay readability for non-body text that is at least 24px (16px bold), like labels, buttons, shorter lines of text, etc				effectively invisible
Header Text (Larger Text)	too much contrast for very large text (35px bold)	good readability	okay readability	okay readability for shorter lengths of larger (36px) or heavier (24px bold) fonts, okay for large headers			effectively invisible
Unread Text	great readability, disabled text might be mistake for enabled text	good readability, disabled text might be mistake for enabled text	okay readability	okay readability	acceptable readability for text that doesn't generally need to be read, like disabled inputs where a user doesn't care about the contents, copyright messages, etc		effectively invisible
Graphics	icons understandable, too much contrast for large blocks of color	icons understandable	icons understandable	icons understandable	icons understandable if the features are 4px or larger, okay for mostly solid icons	visible if the features are 6px or larger, usable for things like thick section dividers or some large buttons.	effectively invisible

Some questions:

• Does this table make sense?
• Are there mistakes? Things missing?
• Are there further categories people should consider?
• Can this be simplified?

Once I have a good matrix for types of text/graphics vs contrast levels, I can build it into our documentation and give designers tools to quickly audit their own work with no training. I can also build automated color palettes, so a designer can say what text/background color they want to use, what type of component they are making, and automatically filter our color palette to ones that would give the required readability.

If others are interested I'd be more than happy to open source said tools for use with your design systems.

(Design systems tend to have a limited number of text sizes. Thus it would probably be possible to incorporate the full APCA text size lookup tables into the code. Then you could just input the equivalent font sizes used by the design system and automatically get more accurate answers about readability without designers having to dig through the tables themselves.)

[front-endian]

Apologies for the table getting squished. It the preview window GitHub added horizontal scrolling to give it more space, but it looks like that didn't carry through after I posted it.

[Myndex]

No worries, I was thinking it needs to be a regular html table surrounded by a <div style="overflow: scroll;"> but I just tried and that seems to be a blocked property here... Hmmmm

[Myndex]

Hi Colin @JustColin

So what you need more is a use-case to Lc table? This makes sense. Here is the current use case master list:

APCA use cases

I'm about to go into a meeting, but I will give you a more detailed answer a bit later sorry to cut this short ...

[front-endian]

Thank you! No need to apologize nor rush a reply. (I'm off for the day anyways.)

So what you need more is a use-case to Lc table?

Correct. Ideally with at least 2–3 thresholds: threshold for passable readability ("don't under X"), threshold for great readability ("aim for at or above Y"), and (if it exists) a threshold for too much contrast.

The article you linked to is very helpful. I will review it later this week and see if there any general use cases from our design system and applications that might be missing.

Clarification question: are the guidelines you've listed generated from:

• Looking at the research on different thresholds of perceivability/readability you listed in that article
• Mapping those thresholds to what different use cases require to be legible (example: clearly reading blocks of text requires a higher threshold than just being able to see a thick dividing line between sections)
• Figuring out what Lc value meets that threshold for an average sized piece of content for a given use-case, and what the lower limit in size could be, then referencing the APCA/SAPC tables?

Are there other factors? Is the process different? I have been trying to read and understand all the articles you've posted but it is a lot to go through. (Not that too much information is a bad thing here. 😄 )