Links

The value of component libraries that have accessibility ‘built in’ is both immense and often overstated. Two sides of the same coin: yes they're good, but yes it's also risky to say they are some sort of one size fits all solution. They're a blessing and a curse.

Michael Matthews at A11y Quest explains:

merely using an accessible library or framework doesn’t mean your team has somehow outsourced all its accessibility responsibilities

(From: The Myth of 'Accessible Components and Done' | A11y Quest)

He goes on to say in addition to maybe benefitting from an accessible component library, you need to make informed decisions, test with users and ensure expertise within your team. Amen to that!

Kilian explains that you usually want to avoid autofocus:

there's a place where autofocus shines: On single-purpose pages containing forms.

(From: Starting off right: Where autofocus shines - HTMHell)

Love this new series by Tetralogical, who photographed and chatted with people with disabilities about what they do and how they use the web.

Meet Steve, a photographer from London who is deaf and low vision. He is an ex-civil servant who then went on to do freelance technology journalism and travelled the world.

(From: Meet Steve: a photographer who is deaf and low vision - TetraLogical)

Scott O'Hara shares his thoughts around the ideal way to code spoilers on the web:

I’m just going to tell you what I’d expect from a spoiler component if someone were to build one, or if one were to ever be standardized.

(From: Spoiler Alert: it needs to be accessible | scottohara.me)

Accessibility is easier when you do it earlier, I can't emphasise that enough. In his latest post, Eric posts research that shows how much easier:

Accessibility audits almost always happen after launch, as an afterthought. That means that errors that could have been found in the requirement analysis are 30 times harder to fix2 . This makes accessibility audits seem very inefficient.

(From: The infuriating inefficiency of accessibility audits · Eric Eggert)

Audits aren't useless. They have their place and are essential for monitoring accessibility within large organisations and for governments. Still, for your website or team, finding and fixing issues early is ideal. And it makes those audits easier and quicker too, as they'll need to report less low hanging fruit.

Rahim Abdi of Apple describes an effort to make it possible to test more web platform features for accessibility features:

what if we could regularly test the accessibility behavior of any and all web platform features on the latest browsers in an automated fashion? How much time and effort could this save?

(From: Improving Web Accessibility with Web Platform Tests | WebKit)

Firefox experiments with automatic text alternative text generation, using a local and therefore privacy-preserving (?) machine learning model:

Until recently it’s not been feasible for the browser to infer reasonably high quality alt text for images, without sending potentially sensitive data to a remote server. However, latest developments in AI have enabled this type of image analysis to happen efficiently, even on a CPU.

We are adding a feature within the PDF editor in Firefox Nightly to validate this approach. As we develop it further and learn from the deployment, our goal is to offer it for users who’d like to use it when browsing to help them better understand images which would otherwise be inaccessible.

(From: Experimenting with local alt text generation in Firefox Nightly - Mozilla Hacks - the Web developer blog)

This is good to see as so many websites lack text alternatives and this may be the first of its kind made by a company that didn't take part in large scale user privacy violations.

CSS can lay things out for you automatically, which is cool but could mean reading order and visual order end up not matching. Luckily, Rachel and others at the CSS Working Group are working on a solution, that lets developers choose which order makes most sense:

There’s a proposal however that aims to deal with this, that would let developers indicate to the browser that they want to follow the “visual” flow of items rather than source order. This is currently named reading-order-items, and I recently added a draft of the proposal to the CSS Display Level 4 editor’s draft. The specification deals with reordering both in an automatic sense, but also the reordering you might want to do when placing items on the grid.

(From: Masonry and reading order – Rachel Andrew)

Currently, the Baseline support information does not include whether the feature is supported accessibly:

If you need to understand whether browsers support accessibility features as your own base level set of requirements, for legal or other compliance reasons, then Web Platform Baseline does not represent a baseline.

(From: Baseline Does Not Really Cover Baseline Support — Adrian Roselli)

I support Adrian's call for this to change. We should't assume features to be supported, if there are known accessibility issues in specific browsers or assistive technologies. I previously noted I feel Interop should include accessibility (and there is a separate Interop project for accessibility now, nice). I hope Baseline can meaningfully implement updates to make accessibility support more clear. A disclaimer, as Adrian suggested seems a good first step.

What would that it mean to deem a feature supported accessibly? WCAG's accessibility supported definition is a good start, but the W3C or Accessibility Guidelines Working Group (that makes WCAG) don't say exactly which browsers or assistive technologies a feature needs to work. For users of assistive technologies, ‘it works’ depends both their choice of assistive technology and the browser they use it with. But even if there's no clear cut answer to ‘which browsers or AT’, even the information that there are known bugs and where would tremendously help web developers decide whether to use a feature or not.

Just in time for #GAAD, and in the week where we saw OpenAI share a video of a new feature that integrates the GPT-4o model with BeMyEyes to assist blind people, I want to share the definition of “inspiration porn”:

Inspiration porn is the portrayal of people with disabilities (…) as being inspirational to able-bodied people (…), on the basis of their life circumstances.

(From: Inspiration porn - Wikipedia)

The demo itself was impressive, but I couldn't not notice that OpenAI shared it without captions. It could be that they just forgot. But they clearly didn't forget to upload record, edit, upload and promote the video, so accessibility must have been lower or no priority. And that's likely to be a systemic issue, a bit like some of the other announcement videos that portray assistants as somewhat flirty women.

The term “inspiration porn” has been used in various places, I found the concept particularly well explained in “Against Technoableism” by Ashley Shew and “Handicap” by Anaïs Van Ertvelde. I believe it was originally coined by comedian and journalist Stella Young, see also her TED Talk.

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.