Accessibility - Contrast

I sometimes forget that transparent colours can solve certain contrast and design issues like the following:

The panel is using a subtle gray (#ddd) to draw a border between its contents and the surrounding page. But when the page background gets closer to #ddd, the design doesn’t work as well.

Using transparency, we can keep the same effect on white backgrounds while ensuring increased contrast on other backgrounds. Here I use a black color set to 0.135 opacity instead: rgba(0, 0, 0, 0.135). This matches #ddd on white backgrounds but automatically appears darker on other backgrounds:

This technique also works well on lightly colored backgrounds. The panel will pick up the underlying colors and display them through the transparent black:

There are many design considerations for making your content more accessible to all. Some things to think about and build into your design workflow include:

• Choose a common font that most users have encountered before.
• The “serif vs. sans-serif debate” is not a huge deal if you choose a common font family or one that has unique characters.
• Avoid specialty display fonts or font families that are not unique (ex. letters or numbers that could mirror each other).
• Your fonts should have a minimum size of 14px (ideally more) and when coded should use relative values.
• Pay attention to color and contrast! Use tools to check the ratio between the text and background and be wary of gray.
• Don’t rely on color alone to signify information (ex. “click on the red button”).
• Clearly define paragraph and letter spacing.
• Do not let the overall width of the content exceed 80 characters (40 characters for logograms).
• Avoid paragraph alignment (such as justified) which creates whitespace within the content.

May 17th is Global Accessibility Awareness Day. See the source link for more. The participate page is a great list of things to test for and be aware of.

The target audience of GAAD is the design, development, usability, and related communities who build, shape, fund and influence technology and its use. While people may be interested in the topic of making technology accessible and usable by persons with disabilities, the reality is that they often do not know how or where to start. Awareness comes first.

Windows users are offered a number of high contrast themes at the operating system level — some light-on-dark like our inverted theme. In addition to supplying our theme switcher feature, it’s important to make sure WHCM is supported as well as possible. Here are some tips:

• Do not use background images as content. Not only will this invert the images in our inverted dark theme, but they’ll be eliminated entirely in most Windows high contrast themes. Provide salient, non-decorative images in <img/> tags with descriptive alt text values
• For inline SVG icons, use the currentColor value for fill and stroke. This way, the icon color will change along with the surrounding text color when the high contrast theme is activated.
• If you need to detect WHCM to make special amendments, you can use the following media query:

Here’s a really straightforward dark theme switcher for light designs. It uses the CSS invert() filter and minimal JavaScript to switch it on and off.

We’ve been working with SVGs a lot recently, which has led our developers down a rabbithole of discovery! Here are some things to consider when it comes to SVGs and accessibility.

[…]

1. <img> tags and SVGs

When SVGs are implemented as <img> tags with an .svg as the source, we’ve encountered a few issues for VoiceOver and TalkBack users. These issues occur when those <img> tags don’t also have an ARIA role=”img” attribute.

[…]

2. <title> tags and SVGs

We often see examples of making SVGs accessible by simply adding a <title> element within the inline <svg>. While this does help in some situations, like a lone SVG icon within a link, adding a <title> element doesn’t make SVGs accessible in all browsing environments.

[…]

For example, when using Firefox and NVDA, a link containing an SVG would be recognized as a link, but the text within the <title> element would not be announced. NVDA announces the path within the href attribute only.

Adding an aria-labelledby attribute to the SVG can help expose the text within the <title> element to the browser’s accessibility API. However, even with this in place, NVDA does not announce the <title> text as we might expect.

Our most recommended approach when it comes to browser support and consistency across screen readers is to add a visually-hidden element as a sibling element to the <svg>. With this implementation, we’ve found that all browser and screen reader combinations tested were able to announce the link with the expected text announcement.

We also recommend adding aria-hidden=”true” to the <svg> element itself. This is to help prevent having any other text that may be embedded within the SVG be announced by screen readers. Then, the only text that should be announced would be the content within that visually-hidden element.

[…]

7. Colour contrast

While not a bug per se, we also see a lot of cases where designers and developers don’t plan for colour contrast issues for SVGs. Since SVGs function just like transparent GIFs in how they are displayed, different page background colors and effects can cause unanticipated issues for low vision users.

For example, a black SVG icon that’s perfectly visible with a white page background is going to be invisible in a Windows High Contrast theme that uses a black background. This is a common use case for users who use High Contrast settings due to light sensitivity or related issues. When you provide a solid background or contrasting border for SVGs, you can help avoid those kinds of problems.