A threat model for accessibility on the web

2 hours ago 1

Published on 2 October 2025 + updated on 2 October 2025

Accessibility can fail in far too many ways to count.

It's a hugely complex problem space, existing at the intersection of user experience, specialised technical knowledge, and understanding of the ways specific disabilities and impairments impact the way users are able to interact with software interfaces.

Getting it right to the extent that any particular disabled user is actually able to use a given piece of software has a lot of moving parts: the Web Content Accessibility Guidelines document alone is over 20,000 words. That doesn't even cover the intricacies of making any given UX pattern accessible across multiple browsers, operating systems and assistive technologies.

However, there is one basic, underlying threat to disabled users having a consistently accessible experience when using the web:

The primary threat for accessibility on the web is neglect.

Why is accessibility consistently neglected?

Accessibility is not alone in being a complex, highly specialised field, or even in being neglected.

I think accessibility is unique in the scale of the surface area where problems can arise, compared to the size of the community of practice.

I say “community of practice” specifically, because there is a tendency for non-practitioners to assume the field can be trivially reduced to checklists, or at best a straightforward, late-stage effort to “fix up” any accessibility issues. The unacknowledged assumption seems to be that problems can be addressed with rote, mechanical effort, and thus that accessibility can be relegated to a low-skill profession: performed by those who lack enough talent to succeed in more valuable fields, or undertaken with ease by people with real skill in other areas.

This is as true at the level of web standards as it is at the level of front-end development. (I'll come back to that.)

In reality, just like with every other highly complex speciality, accessibility is a living and constantly evolving field. No individual can possibly understand every single aspect, but practitioners can and do depend on one another to share information, to help one another and the field grow.

The disparity between the size of the problem space and the size of the accessibility community alone would lead to neglect: there simply aren't anywhere near enough people with the relevant expertise compared to the scale of the work required. I think, moreover, that we can trace the reasons for that lack of expertise at an industry level back to more systemic issues, which in turn contribute to neglect in any number of ways.

Neglect in front-end development

A long-time colleague of mine in accessibility, whose accomplishments include developing a hugely popular open source screen reader and being the technical lead for Mozilla's accessibility team, regularly shares on social media examples of accessibility failures he personally encounters as a blind person, and this one nicely illustrates the typical outcome of the standards patterns of neglect:

[...] prices for an online shop that are aria-hidden, with “screen reader text” that is display: none, rendering the prices completely inaccessible to screen reader users.

<del aria-hidden="true"> $899.00 </del> Original price was: $899.00. <ins aria-hidden="true"> $799.00 </ins> Current price is: $799.00.

(.screen-reader-text is CSS display: none)

(I've simplified the HTML from the original example, but the code is semantically the same.)

I can easily imagine that the screen-reader-text class was originally a “visually hidden”-type style, before someone decided to “clean up” the CSS code and reasoned, without checking (and without considering that there might be a good reason for the style to be written that way), that display: none would do the job just as well as all that noise. The extra .screen-reader-text spans were probably originally added, in turn, to mitigate temporarily incomplete accessibility support for <ins> and <del>, and not removed when they were no longer necessary.

The neglect that results in broken outcomes like this plays out in a number of ways.

In front-end departments, you might see a small band of activists putting in overtime to try and convince their management to make any commitment to accessibility at all. Or, a team might spend a sprint or two trying to burn down their backlog of accessibility issues, often following a hard fought for audit - only for regressions to begin to appear immediately afterwards.

Even in the case where accessibility is explicitly staffed, it's not uncommon to see a sole accessibility specialist (or, at best, a team of two or three) given the Sisyphean task of trying to remediate constant accessibility regressions caused by colleagues who consider accessibility someone else's job if they consider it at all. This work is often undertaken on top of trying to educate their colleagues on how to avoid regressions in the first place. These specialists tend to last a handful of years before burning out (or being laid off), taking their hard-won knowledge with them as they leave the role, if not the industry.

Accessibility as a specialty also tends to be under-recognised by technical job ladders. The difficulty is often seriously underestimated precisely because so few engineers actually have a deep understanding of the work involved; being forced to continually play catch-up doesn't lend itself to being able to undertake the type of pro-active work that can demonstrate “technical depth”; and, the impact on revenue tends to be... difficult to discern.

Systemic causes

The latter is, of course, the obvious but sad truth:

Accessibility isn't considered valuable because accessibility doesn't impact short-term profit in any meaningful way.

There's a reason why predatory “accessibility overlay” companies lead with false claims about legal compliance: the real forcing function for accessibility isn't profit, and it certainly isn't the recognition that the needs of disabled people are inherently worthy of attention; it's legal risk. Thanks to decades of work by successive generations of disability activists, many jurisdictions now legislate accessibility requirements, creating (at least at time of writing) a potential legal risk for companies who neglect accessibility.

In practice, however, this risk doesn't really have sharp enough teeth to incentivise companies primarily focused on quarterly revenue to invest in accessibility.

While there have been a number of cathartically satisfying legal wins, and a much greater number of quietly negotiated remediations, most companies recognise that these laws typically require someone impacted by inaccessibility to undertake a lawsuit, potentially paying huge legal costs with no guarantee of success. Success, when it comes, typically consists of a company being forced to remediate accessibility and pay some costs. (Drive-by lawsuits, meanwhile, serve nobody but those weaponising these incredibly hard-won legal protections in bad faith.) A company with a finite budget can quite reasonably decide to take on a presumably small risk of a successful lawsuit rather than investing in accessibility, and a good proportion of the time they'll come out financially ahead.

There is another obvious, horrifying truth behind all of this:

Disabled people are much too often seen as expendable.

This is clearly true when it comes to the faceless systems that govern our lives: money doesn't care about anybody. But it's also true when it comes to so many individuals: individual developers, individual designers, individual product managers, individual web standards experts all make choices which throw disabled people under the bus without a second thought.

Relegating accessibility to a niche is a choice. Waiting until it's too late to consider accessibility is a choice. Not listening to the advice of accessibility specialists is a choice. Blaming disabled people for the effort involved in making websites accessible is a choice.

(I once had a former friend complain to me that her company was being required to remediate an inaccessible internal tool after hiring one disabled employee, at a cost of tens of thousands of $AUD. “Couldn't we just give that money to that person instead and call it a day?”)

Neglect in web standards

I said I'd come back to web standards.

The platform defines what is possible, and what is easy, for front-end developers. Since we can depend on accessibility being neglected in the vast majority of cases, we should aim to design features in ways that make accessibility easier than inaccessibility. Accessibility should be a central concern for those of us working on web standards which touch the user's experience in any way.

Instead, what too often happens is that web standards engineers with very little understanding of accessibility develop and push a design which creates accessibility risks, and then treat pushback from accessibility specialists as a debate, rather than a dialogue. Sometimes these designs ship against the advice (or even without the involvement) of accessibility specialists; sometimes, usually after an exhausting and bruising tug-of-war, the design is quietly dropped.

Here are some of the examples I've seen over my decade-and-a-bit working as a browser engineer:

Flexbox order

Flexbox order, as specced, doesn't affect screen reader or focus order. Firefox shipped an implementation where the feature did impact screen reader and focus order, based on the logic that these things should follow the visual order where possible (in fact, this is a WCAG requirement), but were eventually forced to change their implementation to match the spec and the shipping implementations in Chrome and Safari.

The reason given was that order was for “spatial, not logical reordering”. In the vast majority of cases, this is a distinction without a difference: visual order determines how viewers will encounter content, and authors will choose a visual order for content based on the desired user experience. Even when the visual order is partly arbitrary, as in grid-auto-flow, sighted users' experience is inevitably shaped by the visual order of elements.

A note was added to the spec essentially asking developers not to use it in the most obvious way. Developers continued to use it that way, and the burden of attempting to educate developers on not using that way fell on accessibility specialists.

There are indeed cases where you can use order in a way that doesn't create an inaccessible experience, but they aren't the typical case. You have to “hold it right”, rather than the API making the accessible case the easy one. However, unlike the infamous iPhone 4 antenna issue, developers typically aren't impacted directly by “holding it wrong”: disabled users are. Developers are unlikely to even be aware of the problems their usage of the property may cause.

More than a decade and several more CSS-based content reordering properties later, the CSS Working Group has been undertaking painstaking work to add a mechanism to fix up the usually-inaccessible default created by this choice. This will now require developers to carefully manage three different orders (DOM order, visual order and reading order) in order to create an accessible experience. Since reading order doesn't affect visual order, a likely failure mode when developers even remember to use the new property is that successive additions will cause it to get out of sync, with the non-visual “style” becoming unmaintained and incorrect.

display: contents

display: contents adds a mechanism for removing an element's CSS box, retaining those of its children.

“Having a CSS box” was, up until the moment this feature was conceived, a generally reliable way to determine whether an element was presented to users; an element without a CSS box was typically “non-rendered” and, as such, unable to receive click events, or keyboard focus, or be interacted with or perceived in any way.

For this reason, elements without CSS boxes are removed by default from the tree of content communicated to accessibility APIs. This being the case, and also taking into account content like CSS pseudo-elements which doesn't appear in the DOM tree, two major browser engines had implemented their accessibility tree generation in terms of walking the CSS box tree directly.

display: contents could not work in those browsers as the designers had apparently intended. Elements with display: contents aren't included in the CSS box tree, because they don't have a CSS box. There's no way to find them from a tree which doesn't include them to begin with: at best, the accessibility tree generation code would have to implement error-prone logic to check the DOM object associated with each CSS box, compare its children to the CSS box children and attempt to reinstate missing nodes.

display: contents shipped before anyone involved thought to even check whether elements with a display: contents style would still be included in the accessibility tree. This has been characterised, for years and despite many requests not to, as an implementation error in browsers, rather than a conceptual flaw resulting from incorrect assumptions. The feature was never un-shipped, suggesting that these “bugs” were not considered to be show-stoppers – presumably since they only impacted assistive technology users.

The designers had apparently believed that this would be a helpful accessibility feature since it would allow elements to be included in the DOM which would otherwise need to be omitted so that certain CSS features would work. They did not document this goal (only adding a note to the spec long after the fact), nor did they consult with anyone actually knowledgeable about browser accessibility internals about whether their understanding of how they worked was correct.

Remediating this design flaw required delicate and time-consuming work across two browser engines to change the way the accessibility tree was built, and still only partially addressed the accessibility problems caused by the feature: there are still outstanding issues, particularly with focus.

<std-toast>

<std-toast> was an attempt to (among other things) standardise an element for the “toast” design pattern, which has challenging accessibility requirements, particularly when shipped as a generic stand-alone element rather than as part of a larger UX pattern like a notification system or undo function, which could provide alternative UI to mitigate some of the accessibility issues.

There was a lot of very angry feedback, much of it actually not accessibility related but rather about process issues. Still, the accessibility feedback was fairly swift and pointed. Again, the people designing the feature neither understood accessibility nor had consulted anyone who did while they designed it, instead relegating accessibility to the later stages of their design and assuming it could simply be remediated with a modest effort and without any serious redesign or rethink.

Given the volume of angry feedback (again: mostly not around the accessibility aspects), the proposal was eventually shelved, but not before everyone involved was seriously bruised from the encounter. One tweet from one of the designers of the feature complained about how such a “well researched” proposal had gotten such unfair feedback. However, the research consisted largely of looking at what existing widget libraries had implemented, without pausing to consider that most widget libraries, just like most front-end projects, neglect accessibility. Moreover, no research had been done on how the components were used in practice, nor how accessible they were when used in those ways, nor on what usage modes could be made accessible.

CSS toggles

CSS toggles was another eventually-abandoned proposal. This proposal aimed to generalise the concept of UI being “toggleable”, and make it settable via CSS properties. The intent was that any type of UI which can toggle between two or more states (open/closed, light/dark, italic/normal, etc) could use this concept; regardless of whether the pattern was a switch, a checkbox, a disclosure, or, with an extension to allow an arbitrary number of states, carousels, cycle buttons, and others. Adding a toggle or toggle-trigger property to a CSS rule would make any matching element activatable, where the activation behaviour of the element would be to toggle or set some CSS state.

The proposers, to give them some credit, recognised that authors would be unlikely to do the extra work to apply the relevant ARIA roles, states and properties to make any interactive widgets made using these properties accessible. However, they assumed it would be possible to simply have the browser automatically apply the correct semantics, even going so far as to consider this expected future achievement a selling point of the project.

Multiple engineers, including one accesibility engineer, spent over a year working on the feature. They spent considerable effort trying to figure out how to automatically determine based on heuristics what pattern authors intended to implement. Only after they sought second and third opinions from other accessibility specialists, when they weren't happy to get the feedback that their heuristics did not result in an accessible experience and that it was not reasonable to expect that this kind of automated repair strategy was feasible for such an open-ended problem, did they finally abandon the project.

One of the things that makes me saddest about this story is that this effort effectively stalled progress on a more reasonably scoped proposal to add one or more elements to HTML to represent a tabpanel pattern, which was also doing a better job at listening to feedback from accessibility specialists. And, with that project effectively starved of attention and resources, and with CSS toggles having demonstrated that a CSS-only mechanism for creating interactive UI was technically feasible (even if it was a questionable idea), it paved the way for CSS Carousels.

CSS carousels and interactivity

I came late to the CSS carousels dicussion, and I focused my attention on the interactivity aspect, which alarmed me due to my experience advocating for and implementing the inert attribute in HTML (an effort which, on balance, I think I now regret). I had, and still have, a lot of concerns about interactivity, and the experience of trying to push back on this feature was unfortunately as exhausting and demoralising as it was typical.

This feature allows developers to make parts of the page which are visible to sighted users inert using CSS. By design, as well as making those parts of the page non-interactive, it also causes them to be hidden from accessibility APIs. This is a dangerous enough proposition when it's done using attributes like inert and aria-hidden, and it's already so common to abuse aria-hidden that the ARIA working group have had to keep fine-tuning how “hidden” aria-hidden content is, since authors keep using it in ways which make critical content hidden from accessibility APIs.

I actually do understand the impulse to make this a CSS property. It seems reasonable to want to modify an element's interactivity in the same place where you modify the visual presentation. It could be done well by the minority of developers who take the appropriate care to ensure it always matches up with a visual indication that partially obscured content is not intended to be fully perceivable or interactive. It's possible, with enough effort, to hold it right.

However, the feature's designers neglected to include any mechanism to even encourage developers to use it appropriately. We have seen what developers do with user-select: none and pointer-events: none to prevent interaction with content, and I believe this feature will likely also be used for similar purposes. This is a particular risk given this feature, like those, comes with no visual impact at all. Without a visual impact, the vast majority of developers will assume content remains as perceivable to all users as it is to them. Moreover, it means there is no visual cue to indicate where in the page styles using this property are applying, risking rules applying this property getting out of sync with others which do modify the visual appearance as the code evolves.

I pushed back and proposed alternatives and compromised and proposed alternatives and pushed back and pushed back and pushed back and pushed back and finally gave up; and those were only my attempts to push back. Others also pushed back and pushed back and asked for a pause and pushed back and pushed back and recanted their earlier support and pushed back and asked for a pause and asked for a pause and pushed back.

The proponents of the design repeatedly treated the pushback as a debate, as if those of us pushing back were the ones who didn't understand the issues. As if, once they wrote enough words in response, we would change our minds or at least give up. (They weren't wrong about that, in the end.) They did finally agree to at least not make it an inherited, overrideable property (though not without reiterating that “there are use cases for this”, as if that alone is justification for a dangerous feature), and not allow it to override inert in HTML.

There is no explainer for the interactivity property in isolation; it's only explained as part of the CSS carousels explainer, despite there being no mechanism to limit its use to CSS carousels and despite much of the positive discussion of the feature being about other use cases. The issue discussing it is misleadingly titled “Support setting offscreen content inert”, despite there being no mechanism to limit it to offscreen content.

After I gave up on trying to push back, I got an email from someone I've never met asking why, as an accessibility advocate, I was “against helping authors to build better keyboard navigation experiences”. The author said “it sounded like [I] don't trust authors to use new CSS features correctly or with enough skills”, and asked me to explain myself (yet again) and to provide feedback on a blog post. I didn't respond.

CSS Carousels (including the interactivity property) shipped in Chrome in time for Google I/O, in spite of a host of accessibility issues not even counting the completely unnecessary accessibility foot-gun that is interactivity. There is ongoing cleanup work being undertaken by accessibility specialists to try and mitigate the worst impacts on users of this ill-conceived design, assuming it's too much to hope that it will be un-shipped.

This sucks.

Pushing back like this is miserable. Nobody wants to do this, actually.

Again and again, accessibility as a topic in web standards is treated as simultaneously too trivial for specialists' technical opinions to be given weight, but also too difficult to get right without a specialist volunteering to tackle the tricky details.

Again and again, the discussion quickly devolves into an adversarial debate, as if participants are in a zero sum game instead of what should be a collaboration in service of ultimately shared goals.

Again and again, we are told “developers want this” and “there are use cases” as if developers always have users' needs as their first priority; as if most developers even understand what disabled users need.

Maybe everything isn't hopeless

One recent issue gave me some hope.

OpenUI aims to “establish a standard process for developing high-quality UI controls suitable for addition to the web platform”, and several accessibility specialists regularly participate in developing proposals. This isn't always smooth sailing, but success stories like popover show that careful consideration of accessibility as a goal can produce a design which ends up being useful and popular.

The recent issue which gave me hope was “Navigation vs menu items use case”. This issue captured some confusion around “navigation menus”, which are fairly well understood by accessibility specialists as an anti-pattern.

There was some despair from accessibility specialists, some fairly heated discussion on that issue, and some fairly sobering ignorance of basic accessibility principles demonstrated. But the next meeting which discussed the topic showed that those proposers who weren't accessibility specialists were willing to listen and learn, and take on feedback. A PR was later opened and accepted which added a discussion of the “navigation menu” use case as a distinct case, including a discussion of the accessibility risks.

What can we do differently?

So many exhausting arguments could be avoided by treating the needs of disabled users as a primary, non-negotiable requirement for web features. These needs should be considered at every phase of design, right from inception on; features which don't meet accessiblity requirements should not be shipped. It should not be down to accessibility specialists to monitor repositories and meetings to try and find proposals which carry accessibility risks, and undertake the Sisyphean task of pushing back on proposals which are already considered “mature”.

The second sentence in the very first TAG design principle advises feature designers to “understand and document the user need that the API aims to address.” To unpack some key words there:

understand: “Developers want this” should always be a starting point for discussion. Developers asking for some functionality should prompt curiosity: why are developers asking for this? Do they really want a (metaphorical) faster horse, or do they just want to (metaphorically) spend less of their time travelling? Is the UI developers are trying to build in the interest of all people? In the best and most generous possible interpretation, what user need are developers seeking to fulfil? If the need truly is only developer-facing, what user needs may be impacted by our design choices?
document: Before committing to any design, the user needs must be agreed on and written down. There is no other way to check whether the design is fit for purpose.
user need: This means end user: the same “user” as in “user agent”. This must include disabled users. If you don't know enough about disabled users to understand their needs: find out. Knowing enough about accessibility to know when to seek out specialist guidance, and to understand it when you get it, should be a core competency for standards engineers.

Until we begin the design process of all web features with a genuine effort to understand user needs, and consistently factor in that reality that the needs of disabled users will be for the most part neglected by developers (whether by their own choices, or the choices of their management chain), we will keep failing these users. We will keep shipping features you have to “hold right” in order not to exclude or harm disabled users, and disabled users will continue to be excluded and harmed. We will keep giving accessibility specialists (many of whom are also disabled users) an ever-increasingly impossible task.

Getting this right requires a bit more work up-front, but – just as it is with front-end development – ultimately saves potential years of clean-up work (or having to scrap projects after years of effort), as well as avoiding harming disabled users. It's work that is plainly worth doing, and I wish it was the norm.

Note on terminology: I tend to prefer identity-first language (“disabled person” rather than “person with disability”) when talking about disability. This preference is based on my own values, and discussions I've seen and participated in. However, I don't think there are really any wrong choices out of those two options, and different people have different preferences based on their own experiences, the communities they belong to, and so on.

Read Entire Article