Accessibility (a11y) improvements for visual disabilities and color contrast

[endigo9740]

The current release of Skeleton provides support for tab focus, keyboard shortcuts, semantic elements, and of course implements changes to support the ARAI spec per each component.

That said, we still have several items to address in regards to a11y support. The the next major update should include further refinement and support for visual impairments. This includes but is not limited to:

• Support for color blindness
• Support for low visibility or visual impaired users
• Improve color contrast support - note this may involve introducing new and dedicated themes

We should consider making suggestions for tools dedicated to testing. These can include:

• axe DevTools
• Web Disability Simulator

Finally, this will be a bit less of a concrete fix, as color values are completely in control of the users generating the theme. We may want to make considerations for improving a11y support for our theme, or creating separate/dedicated themes specifically built with a11y in mind. Likewise we should update documentation or provide recommendations for a11y (ex: "be mindful of color contrast radio when overriding color values", etc)

Update

Great find for a11y color generation and testing here:
https://stephaniewalter.design/blog/color-accessibility-tools-resources-to-design-inclusive-products/

Dark Theme recommendations:
https://twitter.com/vitalyf/status/1564607043406815233

Leonardo:
https://leonardocolor.io/

[endigo9740]

I've completed some tests regarding visual a11y. In short, it's not really about what color values are used, so much as how high the contrast ratio is. For our themes, the biggest offender is typically text on top of a primary or accent color.

Take this example, generated with https://huewind.jordantwells.com/

Note there's not a particular swatch level (ex: 500) that the overlapping text flips from white to black or vice versa. Rather this is handled per shade and varies per each column. This will be hard handle programmatically and would require an insane effort to test every possible theme and component combination.

Instead, I propose we approach these challenges from a different angle. See below.

1.

We improve our global and component default styles as much as possible. Aiming to better accommodate for contrast. Take our global paragraph style for example, the contrast is way too low, but can be easily fixed:

main p { @apply text-base text-surface-500 dark:text-surface-400; }

Should be:

main p { @apply text-base text-black/80 dark:text-white/80; }

Results before vs after:

This provides a much better contrast ratio out of the box for both light and dark modes. Though obviously users can choose to customize further if they wish. Perhaps even going for full 100% opacity.

2.

We may need to recommend that if a11y is a focus, you should pin your design to use only light or dark, not toggle between both. The variance between the two modes means there's too many variables to keep up with. Plus focusing one mode makes it easier to define and override the default values. For example, if we only used dark mode for the Skeleton theme, we could use the following to improve button contrast:

.button { @apply !bg-primary-400 !text-black; }

Results before vs after:

However, we should look to review each component and ensure it's possible to target styles in a global manner. The style above would affect ALL buttons, whether filled or outlined, which is not very visually appealing.

Something like .button-primary-filled or .button-ghost would suffice. This could be added programmatically as well.

3.

Finally, we should provide at least one theme and set of stylesheets purpose-built for a11y. This could be our reference for best practices. Per this, most a11y-focused themes I've seen to to use high contrasting black/white theme with subtle color highlights for interactive elements (ex: buttons).

Here's a very monotone example:
https://labinator.com/wordpress-marketplace/lat-demo/

The ARIA APG site is also a great example:
https://www.w3.org/WAI/ARIA/apg/patterns/

[endigo9740]

I'd recommend we handle this after the built-in themes and modular stylesheet PR is merged to dev. This will make this process MUCH easier!

[endigo9740]

Note that the new proposed Button Refactor opens the door to handling button visual a11y by allowing for easier global overrides of styling:

#216

This takes us one step closer to supporting this!

[endigo9740]

Note that we've also updated the default typography to improve color contrast ratios. So a bit more progress here! One of the last big steps will be providing a11y friendly theme options, which we should try to include in the next release.

[ryceg]

It's worth noting that the @prefers-contrast media query (:contrast-more in Tailwind) has support for both less and more, and might be a good option for making things more a11y friendly.

[endigo9740]

@ryceg Really great info to know! Thanks!

I am still relatively new to the a11y side of things, but trying to learn and improve. Any other tips are absolutely welcome, visual or otherwise.

[ryceg]

We can use the formula listed on WCAG and test whether colours meet accessibility guidelines, and generate complementary "high contrast" colours. We'd also be able to provide users with this information while they're generating themes, which would be very helpful. I won't have time to dig into this just yet, so don't assign it to me in case someone else wants to have a crack at it, but I figured I'd at least put that idea out there so it's visible.

[endigo9740]

https://twitter.com/vitalyf/status/1580017289868771328

[endigo9740]

With the following update going live tomorrow, I'm feeling confident in our visual a11y:

• Improve the Design Token system #553

This doesn't meant things are perfect or 100% accessible, but rather that we're meeting the standards and quality expected when this ticket was created way back in August. I do expect we'll see additional updates and improvements as part of these tickets:

• Theme System Overhaul #598
• Animation and Design Improvements #374

Likewise another dedicated a11y audit will be recommended prior to the v1.0 launch.

But for now, this ticket has served it's purpose.