Links

Live regions have a reputation for being "flaky" and inconsistent. While this can be attributed in part to shortcomings in current implementations, the problem can also be caused by developers misunderstanding how live regions are intended to work.

(From: Why are my live regions not working? - TetraLogical)

Excellent post by Patrick Lauke!

Accessibility standards veteran and axe-core product owner Wilco Fiers explains how he sees EN 301 549 relate to WCAG:

EN 301 549 steadily gained importance. It is often dismissed as “WCAG with a different number slapped on it,” but it is far more than that.

(From: 301,549 ways to improve accessibility: EN 301 549 | Deque)

In the post, he explains the EN is broader than WCAG in various ways:

• it has more requirements, like for browser settings to be respected by websites (11.7 User preferences)
• it applies to more than web content (apps, kiosks), a scope WCAG explicitly doesn't support
• it and derivatives of it apply in more and more places, way beyond the EU (Canada, Japan, Australia)

On the authoring tool requirements bit that Wilco mentioned, I wrote a blog post to summarise our group's thoughts: On authoring tools in EN 301 549.

Donny D'Amato on making a design system component for content that is meant for screenreaders:

there has been one concept that I’ve stuggled to put into this component-driven ecosystem; screenreader only as it has traditionally existed as a class (eg., .sr-only) added to an otherwise benign element

(From: Screenreader only)

This week, once again, someone suggested that “AI” could replace (paraphrasing) normative guidelines (ref: mailing list post of AGWG, the group that produces WCAG).

Eric Eggert explains why this seems unnecessary:

The simple fact is that we already have all the technology to make wide-spread accessibility a reality. Today. We have guidelines that, while not covering 100% of the disability spectrum, cover a lot of the user needs. User needs that fundamentally do not change.

(From: “AI” won’t solve accessibility · Eric Eggert)

I cannot but disagree with Vanderheiden and Nielsen. They suggest (again, paraphrasing) that we can stop making accessibility requirements, because those somehow “failed” (it didn't, WCAG is successful in many ways) and because generative AI exists.

Of course, I'm happy and cautiously optimistic that there are technological advancement. They can meet user needs well, like how LLMs “effectively made any image on the Web accessible to blind people”, as Léonie Watson describes in her thoughtful comment. If people want to use tools meet their needs, great.

But it seems utterly irresponsible to have innovation reduce websites' legal obligations to provide basic accessibility. Especially while there are many unresolved problems with LLMs, like hallucinations (that some say are inevitable), environmental cost, bias, copyright and social issues (including the working conditions of people categorising stuff).

The WebAIM Million 2024 report is out! More errors were detected, but also pages with fewer errors generally got better.

If this inspired you to go fix low hanging fruit in your projects, I previously wrote about ways to fix common accessibility issues, and a part 2 with more issues to fix. Making websites perfectly accessible can be hard, but reducing fruit that is both low-hanging and very common, is not.

The idea of including alt text for images as metadata into image files pops up every now and then.

Eric Bailey explains some of the many reasons why this isn't as good of an idea as it seems:

The largest thing to grapple with is that images are contextual. Choosing to select and share one is a highly intentional act, and oftentimes requires knowing the larger context of how it will be viewed.

(From: Thoughts on embedding alternative text metadata into images – Eric Bailey)

He explains describing images is a human to human thing, not a “problem” that just needs some tech thrown at it. Even if some of the tech can in some ways be helpful and powerful.

Touch screens and buttonless designs on devices have become the norm, not a definition of the ultra-modern any more. Which means, as a blind individual, that finding accessible household appliances has become increasingly challenging.

(From: Devising devices with accessibility in mind)

In Django accessibility in 2023 and beyond, the accessibility team of Python framework Django reflects on their work in the year 2023 and looks to the future. This makes me happy to see, as I'm a bit of a CMS/built-in accessibility nerd (see this intro to CMS accessibility with ATAG and Your CMS is an accessibility assistant). CMS and framework accessibility projects have the potential to increase a lot of accessibility at once: better defaults, better guidance and better output can all lead to a ripple effect. Better admin interfaces can increase how many people can make content for the web, which, again, is great.

Django updated forms in their core, improved the admin UI in lots of ways, updated guidance and automated tooling (including CI/CD). On top, they improved their website and did a bunch of outreach. Great to see it, may more CMSes follow suit (shoutout to WordPress Accessibility Day and Drupal's Accessibility Project).

In Don’t Disable Form Controls, Adrian Roselli explains that, while it sometimes can be ok to disable buttons, it's never ok to disable submit buttons (or any form fields):

Telling authors not to disable submit buttons is too narrow. Authors should not disable any form fields.

Aaron Gustafson:

AI can be used in very constructive, inclusive, and accessible ways; and it can also be used in destructive, exclusive, and harmful ones. And there are a ton of uses somewhere in the mediocre middle as well.

(From: Opportunities for AI in Accessibility – A List Apart)

In this post, Aaron shares some examples of where ‘AI’ could be used to make content more broadly accessible. This is a controversial subject, because there are many automated ‘solutions’ that don't actually remove barriers, so caution is warranted. Such solutions often focus on people who want to comply with accessibility instead of people with disabilities. And accessibility is about people with disabilities, period. Aaron acknowledges this in the post, and calls for including people with disabilities.

What if, he suggests, users could ask specific questions about complex charts? As Aaron acknowledges, hallucinations exist, there could still be a use, especially with more diverse training data. Other examples of where ‘AI’ could remove barriers in his post: voice preservation, voice recognition and text transformation.

I'm still sceptical, because I've seen too many claims from automated tools that don't work that well in practice, but I understand it's worth to at least explore different options, and weigh them against the reality of today's web. For the voice and text tools I am actually somewhat optimistic.

In A Global Design System, Brad Frost makes a case to:

centralize common UI components, reduce so much of this unnecessary duplication, integrate with any web-based tech stack, and create a connected vehicle for delivering front-end best practices to the world’s web experiences.

His proposal explicitly isn't “new HTML features”. We're working on that over at Open UI, and it's fruitful and good, but also hard, because web compatibility is complicated. It's challenging to get accessibility “built-in” in: these web platform features, like a fully customisable select, need to be flexible and styleable enough so that people actually want to use them, but also inflexible enough so that people can't accidentally use them to make something inaccessible. Or maybe “inflexible” isn't the right word… it's a matter of adding “guardrails” to these features: what sort of ARIA relationships and states should apply when? Browsers can't guarantee what developers are trying or going to do.

Anyway, Brad's “global design system“ is not that, it's proposed as a layer on top of HTML, a common library between design systems. That too resonates with me. In fact, it is close to what NL Design System is setting out to do. Different government departments and layers maintain their own design systems, but share a common architecture and reuse themeable components and tests from one another.

Design systems can be a super effective way to propagate a lot of accessibility at once, across many services. Not just as part of components that have good defaults, but also, maybe especially, in written documentation that helps people understand better what to do.

The GOV.UK Design System was updated to add an accessibility section and specific guidance on meeting WCAG 2.2 across the different component pages.