Accessibility (a11y) improvements for visual disabilities and color contrast about skeleton HOT 9 CLOSED

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.

from skeleton.

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.

from skeleton.

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/

from skeleton.

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!

from skeleton.

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!

from skeleton.

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.

from skeleton.

@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.

from skeleton.

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

from skeleton.

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

• #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:

• #598
• #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.

from skeleton.