WCAG and accessibility beyond naive misconceptions

Ableism often results from ignorance. As an abled and privileged person, I am "blind" to the challenges that some people face in our society. Role-play and simulation may be small steps towards more empathy.

Influencers like Molly Barnes and Marco Zehe raised my awareness and showed me new aspects and perspectives. I still consider myself quite naive and ignorant. I wear glasses and hearing aids, but I can still read and have a conversation without them.

Summarize WCAG in simple words

Despite the imminent accessibility legislation in Europe (EAA, BFSG, etc.), I struggled to summarize WCAG in simple words. But some others wrote helpful posts, like

• WCAG, but in language I can understand (tempertemper Web Design, 2022)

• Accessible Web Animation: The WCAG on Animation Explained (Val Head for CSS-Tricks, 2020)

• Learn Accessibility (web.dev, updated 2022)

• A Roundup Of WCAG 2.2 Explainers (Smashing Magazine, 2023)

Top portion of Intopia’s the WCAG 2.2 map, as shown in the Smashing Magazine post.

Accessible web development and testing in practice

Ideally, a diverse team of designers and developers collaborating with accessibility and UX experts will have no problems getting their work verified by external auditors and real-user feedback.

In reality, developers are often micro-managed to deliver features according to short-sighted priorities, forced to neglect quality and accessibility. But, like some essential integration tests can be much better than no tests, we should not dismiss accessibility only because we are far from perfection.

We can occasionally use our keyboards to navigate our websites, and we are lucky to have handy tools to detect some kinds of problems automatically. For example, WAVE, axe, and even the indispensable developer tools of our browsers can warn us about insufficient color contrast.

Automated audits tend to neglect

Automated audits tend to ignore interactive aspects like hover states and text selection colors which can also influence a website's readability and user experience.

Focusing a link on my portfolio website when navigating with the keyboard results in the same color combination as hovering with the mouse, but there is an additional outline.

Outlines (sometimes also known as "focus rectangles") can be hard to style using CSS. There is outline-style, outline-color, outline-width, and outline-offset, but there used to be no outline-radius. Developers are often tempted to hide the outline and rely on their custom styles instead without being sure if that works in a high-contrast environment.

Standards, controversies, and challenges

Color contrast might not matter to people using screen readers. But even "blind" does not necessarily mean that one doesn't see anything. The concept of being "temporarily abled" has been criticized, but I think it can help "abled" people overcome an initial naive ignorance.

Some people might struggle when there are too many semantic elements, like subheadings, announced as such by screen readers. But it is agreed that it is best practice to use them. There is no alternative to WCAG, which has become the international standard for ensuring that websites are accessible and inclusive, at least to some degree.

However, some professional accessibility auditors' strict stance about WCAG requirements has made several web designers avoid the topic of accessible standards altogether, fearing that they might lose even more artistic freedom than they already did due to privacy concerns and search engine optimization.

How can we still be creative and publish beautiful websites, and why don't browsers and frontend frameworks support designers and developers better already?

Provide readable color contrast without rejecting pastel color combinations

I like colorful websites with animation and interactivity, but how can we make them accessible when we can't trust user preference media queries, like those about preferred reduced animation?

There are surprisingly few answers on StackOverflow:

• WCAG 2.1 - high contrast toggle button (asked in 2019)
• How to provide an accessible high-contrast alternative to a pastel color scheme? (asked in 2022)

My DEV post about that topic didn't get many reactions yet, either.

How to provide an accessible high contrast alternative to a pastel color scheme? 🎨

Ingo Steinke, web developer ・ Jun 8 '22

#css #ux #webdev #a11y

We could start with a high-contrast theme and fade that to a softer version when we are sure it does not violate user preferences. We could try to make the topmost part of the website ("above the fold") and the top navigation rich in contrast so that users won't notice the transition.

Understanding prefers-contrast

But the contrast feature query is still tricky, as high-contrast system settings might override our CSS or parts of it. Or, as Kilian Valkhof said, "I no longer understand prefers-contrast":

The prefers-contrast media query indicates whether someone prefers more or less contrast within the boundaries of your sites design. At least, that’s what I thought it meant, and it’s also how macOS seems to implement it with their ‘increase contrast’ accessibility feature. This is in contrast to the forced-colors media query, which overwrites all your styles. [...]

While macOS sees prefers-contrast as a discrete thing, the spec (and Windows) intricately links it to forced-colors. [...] What on earth do spec makers expect website builders to do with prefers-contrast? If forced-colors already overwrites all the colors, what contrast is there left for us to change?

Can we expect users to adjust their accessibility preferences?

Dark mode had been a trend in the developer community for years. Still, it hasn't been easy to consistently implement system vs. application preferences, even more so with user-generated data in content management systems or on GitHub. Adding contrast settings, font sizes, zoom, and preferences about motion and transparency, and there is a multitude of possible individual settings combinations even on in the same browser on the same machine.

I started writing a post about accessibility preferences on different devices and operating systems about a year ago, but I found developing practical examples and recommendations quite challenging. And if your're not using a testing device but your primary work laptop or personal smartphone, will you still be able to use it daily without missing important information?

Hopefully, there are many must-read resources that I have missed so far. I'm looking forward to your comments and upvotes. Meanwhile, I will proceed with my own research and networking to overcome the accessibility misconceptions that I probably still have.