You Can't Opt-Out of Accessibility
95 points by outervale
95 points by outervale
God damn I enjoyed reading this.
There is a look that certain individuals give you when you explain that a slightly different approach would be optimal for accessibility or that some changes are necessary. It’s a sort of sneer. The same thinly veiled look of discontent that one might pull while subtly investigating the dog poo smell originating from the base of their shoe as they arrive at a dinner party.
Always a bit exhilarating when someone puts words to an experience you didn't even know you had in common with them. This look is a thing. I have been a frequent recipient and I sympathise with the sentiment that compassion is the one key thing you can't teach someone in an accessibility workshop.
Something that really frustrates me is that ~2008 we had accessibility for the web pretty well figured out. Semantic HTML, sensible form design, good alt text and thoughtful link text. Then apply a sprinkling of JavaScript for progressive enhancement if you want to smooth out the UX a bit.
Then SPAs happened. I remember having early conversations with developers who were excited about building SPAs and asking them about screen readers... and getting blank stares.
So I assumed the SPA excitement would either die out or we would figure out how to make them accessible and teach everyone to do that.
It's now 2025. Ask your local frontend SPA engineer how they ensure that when clicking a link on a page loads content via fetch() into another area of the page a screen reader user hears about it. Then ask them how they tested that.
(If you get a good answer then amazing, stick with that engineer as a collaborator for as long as you can!)
I only partly agree, yes SPA development had an adverse effect on accessibility, but that could also be attributed to the fact that DX improved significantly around the same time (and also bootcamps happened) so a lot of newcomers were in the field. If accessibility primitives and educational material wasn't there, that could also explain the problem.
On the other hand, do we know for a fact that ~2008 we had accessibility figured out? There were better primitives than using tables for layout, but I'm not completely convinced that this is not nostalgia speaking.
React is not fully blameless here: it added friction to the use of some of the ARIA tags like aria-labelledby because you need to use unique element ids that match up. Nowadays you use the useId() hook and that adds just a little friction, but before that was added this was a bigger annoyance because you couldn't just generate ids inside the components with Math.random() or a global variable with a counter because that would cause crashes when it caused SSR generated HTML to differ from locally generated HTML. Prior to useId(), the solutions for this looked like either passing in element ids (or prefixes) as strings from screens down into the components, or using the context API to pass counters in to all the components in a deterministic way so you wouldn't get SSR mismatch crashes.
Purely anecdotally, I think React did a poor job of discouraging some poor practices like <div onClick={handleClickTheThing}> instead of <button type="button" onClick={handleClickTheThing}>, and <div onClick={() => navigateToRabbitsList()}> instead of <a href="/rabbits/list"> the latter of which would usually have to be spelled something like <Link to="/rabbits/list"> instead. I am just going off what I remember catching in code reviews here.
Honestly the main thing is that in 2008 I felt confident that if somebody reported an accessibility problem with my web apps I knew how to fix it.
Was that no around the hight of flash? Which was pretty awful for any kind of accessibility.
I only skimmed the article, but this part caught my attention:
A common rebuttal I hear is that accessible design is ugly or boring. This is a lie told to excuse poor craftsmanship.
Even if we assume it is not a lie, how is this even an acceptable answer? I'd understand the lack of skills or knowledge in this area of a solo dev. But "it's ugly or boring" is barely an excuse, and a poor one.
One thing that annoys me about accessibility discourse (not in this article) is disproportionate focus on "best practices" that are pointless and distract from important things. In particular the idea that you have to use "semantic" tags to express the subtle shades of meaning between <i>, <em>, <abbr>, <cite>, <mark>, <var>, <b>, <strong>, etc. that look the same by default but screen readers could, in theory but probably not in practice, use to their advantage. I tried doing this properly for a while but I found it such a burdensome waste of time trying to decide whether my styling was an "alternate tone" or "verbal stress" or "certain relevance". Now I just use <i> when I want italics and <b> when I want bold like it's 1997. I do, however, manually test my website in a screen reader, which I think is 100x more impactful than fiddling with those tags.
I remember reading an article from a number of years ago that compared screen readers and found that not a single one did anything to represent any of the <i> <b> <em> <strong> tags.
A separate link I encountered recently has a table of screen reader interactions for any HTML tag. Idk how complete it is, but it’s updated recently and feels like a good baseline to start from
The main advantage of these tags is not accessibility, but flexibility. If one day you decide that you want emphasized text to be yellow rather than italic, it will take just a few lines of CSS.
You can do that either way, it only matters if you want a distinction and would rather encode that with the tag rather than a class or something.
There were several raccoons under the accessibility trenchcoat, the semantic web was one of them. Back in the day it wasn't just pitched as an accessibility feature but also as "something scripts could use to navigate the web".
It's probably not that relevant to accessibility nowadays.
Arguing against a11y is heresy shouted down by those who talk in the priestly cant.
The core scream is that accessibilty is the job of every developer. It is not. A domain expert coding a form should not care. Further down the stack should care. If I do not add convienent keyboard shortcuts, the framework should. If I do not add alt text, then have your image recognizer take a guess. Yes, it may be a complex problem to look at a graph and describe it in words. Yes, software should be able to analyse the visual presentation of a document to provide headers and structure. No, that is not the job of the designer making the code used by over 99% of the people.
The second scream is that accessibilty guidelines work. I knew an alphageek who was losing her eyesight. Each time her eyesight worsened, she had to switch to a new screenreader. There was no single level of accessibility that would work. What we have now are standards so encyclopedic as to be full employment for specialized contractors writing new frameworks for systems legally mandated to provide them.
In all this, the engineers that reach in and add accessiblity to frameworks are still villified. Discussions about fixing the frameworks, browsers, or operating systems to help screen readers are buried under an avalanche of complaints against web page designers and requirements that PhotoShop be more accessible to the vision impaired.
Accessibility has devolved to where most rational developers smile, repeat a platitude, and ignore it.
Arguing against infosec is heresy shouted down by those who talk in the priestly cant.
The core scream is that security is the job of every developer. It is not. A domain expert coding a form should not care. Further down the stack should care. If I do not check if the user is authorized, the framework shoud. If I do not escape user inputs in my SQL, then have your database take a guess. Yes, it may be a complex problem to distinguish benign and malicious code. Yes, software should be able to analyse the content of a request to detect if the program will halt given that input. No, that is not the job of the designer making the code used by over 99% of the people.
The second scream is that security guidelines work. I knew a company that was targeted by a large scale attack. Each time the attackers changed strategy, she had to implement new mitigations. There was no single level of security that would work. What we have now are standards so encyclopedic as to be full employment for specialized contractors performing tests and audits for systems legally mandated to undergo them.
In all this, the engineers that reach in and add security to frameworks are still villified. Discussions about fixing the frameworks, browsers, or operating systems to help antimalware are buried under an avalanche of complaints against software architects and warnings about regex DoS in offline tools.
Security has devolved to where most rational developers smile, repeat a platitude, and ignore it.
(Did you spell accessibility differently each time specifically to stop me from using find-and-replace?)
But you both are only overdoing it like 10%.
The framework absolutely should have a global switch to demand a marker of whether authentication and authorization is needed even for the functions it is not, and it should default to strict. Access to SQL in business logic should be an API that makes it easier to escape than not to. And the framework's default way of updating the content should not be illegible to screen readers, and the framework should probably explicitly demand something like decorative=true (while making it really complicated to add any interactivity in that case) for any creation of img without alt.
But if the framework is so intelligent, it surely will start damaging the developer experience because it will try to do everything by itself instead of allowing the developer to do what they need.
the framework's default way of updating the content should not be illegible to screen readers
The only one I can think of that could do that is HTMX because the whole point of it is swapping parts of the page.
demand something like decorative=true (while making it really complicated to add any interactivity in that case) for any creation of img without alt.
Aside from what I said earlier, that the framework would need to be very intelligent to know when something is purely presentational, the only solution I can suggest right now for your case is the accesibility plugin for eslint
But if the framework is so intelligent, it surely will start damaging the developer experience because it will try to do everything by itself instead of allowing the developer to do what they need.
I am very in favour the overrides, but very explicit and visible ones. You have a chance of making people pay attention while opening an escape hatch lined with red tape all around, but instead we have defaults that are landmines from any point of view.
the framework's default way of updating the content should not be illegible to screen readers
The only one I can think of that could do that is HTMX because the whole point of it is swapping parts of the page.
Current web is doing worse than full-page-replacement HTML forms…
Aside from what I said earlier, that the framework would need to be very intelligent to know when something is purely presentational
I am not asking the framework to know, I am saying that by default when I am adding something I should be asked for an alt or an explicit claim it is purely aesthetical. Framework needs to do a basic OR check.
Every SPA framework ultimately does partial page replacements, htmx is nothing special here. Accessibility guidelines generally apply to all rich interactive webapps to make sure that the screen reader announces what's happening on the page, for example. That's kind of why things like aria-live=polite exist in the first place. They were created long before htmx!
Even if we assume that accessibility concerns are surfaced at wrong level—and that is a big if—does that really justify willful negligence?
Look each one of the billions of people you’re betraying in the face and tell them that they don’t matter enough for you to give them the slightest modicum of dignity or care.
I have worked with many people who would do this. They would couch it in euphemisms of course.
Great article, thank you. I'd recommend getting rid of the sticky top nav blur effect, it makes it confusing to read the article because the words get fade as I scroll down so I found myself often having to scroll back up to re-read and make sure I got everything.
Quite ironic on an article about accessibility.
See, this is what annoys me about accessibility discourse on the internet.
That fade effect does nothing to harm accessibility. It's trivially disabled by switching to reader mode. The whole page formats perfectly in reader mode, and by ignoring any of a number of CSS directives, it can be rendered in any way the user agent chooses. This is a perfectly reasonably accessible site, and in any case where a user can't interact with the site to the best of their ability, it is 100% on the user agent, not the site developer.
Cargo culting stuff like weird CSS blurs as "inaccessible" is just missing the whole point of accessibility.
I hope you're joking. If we scroll up while reading (as normal), the CSS blur fades out the text, making it difficult to read. That's quite literally an accessibility issue. It would literally not be an issue if the nav bar was not sticky, or if it was sticky and opaque so it just blocked the content behind it. Because at least then we know the text is blocked. But fading out the text makes for a confusing experience.
This is a perfectly reasonably accessible site, and in any case where a user can't interact with the site to the best of their ability, it is 100% on the user agent,
Said the developer of pretty much every inaccessible site ever.
I am not joking. Why can the user not just turn on reader mode if they are struggling to read the site? Good reader mode support solves the problem, AND allows the designer to design whatever the hell they think is pretty. It is the best of all worlds.
If reader mode would solve accessibility problems, there would be no need for WCAG recommendations for colour contrast, would there? Reader mode doesn't magically solve accessibility problems. It just shows the <article> tag if found in the page, otherwise does a best-effort search for the main content. If you want to read other stuff on the page, you're out of luck!
I think until accessibility is taught in schools and thus made as evident and obvious as other basic programming concepts, it is unlikely to ever become the norm, regardless of legislation. Without it people will lack the intuition and without intuition it's always gonna feel like a 'chore' to add accessibility, even if it is what enables so many people to do stuff online.
I've been hobby-programming for about 15 years now. I've done my [local A-class equivalents] in programming. I've gotten a Bsc degree in CS&E. And accessibility was never-ever a topic that naturally came up. Hell, the only reason why I know what ARIA tags are is because I was poking around on MDN and found the name mysterious and thus intriguing.
On my own site I try to use sane markup, contrasts that the browser deems AAA, no animations or overly funny business with CSS, and while I sadly don't have alt texts everywhere, I'm at least trying to add them when I can. Reader mode works great with it. But it's a simple static site of text and images. If I were asked to suddenly make our $DAYJOB React webapp accessible, I admit I'd be at a loss where to even start. And that might be partially my fault, but I feel the issue is very much systemic/cultural.
Missing the tag "rant"?
Use the “suggest” button to suggest changes, instead of commenting.
Where's the "suggest" button?
It’s usually between the timestamp and the “flag” button in the gray text below the story title.
The “suggest” button doesn’t appear on stories whose tags or title were already edited after posting. The moderation log shows that this is one such story: it says this story’s tags were “Automatically changed from user suggestions”.
If I remember right, it takes two users to suggest the same title or tag before the change is applied. For this reason, I think it’s sometimes justified to also write a comment about your tag suggestion: it increases the odds that someone else will second your suggestion.
For this reason, I think it’s sometimes justified to also write a comment about your tag suggestion: it increases the odds that someone else will second your suggestion.
I absolutely agree with this. By adding the tag you suggested, and your reasoning, it stands a better chance of getting a second vote and giving the community better information.
The suggest button is supposed to reduce the need for off-topic meta noise in the comments.
When it's there, it very often successfully does that. When one change is applied, it disappears, and sometimes you get comments like the ones you replied to, and then follow-up meta-meta noise like your comment and my reply.
It seems to be removed from articles where the tags have already been edited, such as this one. Look at some different articles and you should see it