This is a good question. There are some companies that'd like to beg to differ (such as AccessiBe, which is rubbish). This post is not for them. It's for you. They know what they're doing (and not doing).
To start: the web is (generally) accessible by default.
We break it. Me, you, companies, capitalism, you name it - that's what breaks the web from being accessible.
<div> tags with an onClick event when the <button> element is right there, modals that don't trap focus, and other examples are rampant throughout the Internet.
Let's think about this from the angle of how your code is interpreted by the browser and accessibility software:
- Write some HTML.
- Load that HTML into a browser.
- The browser interprets that HTML, and creates an accessibility tree out of it (among rendering it, etc)
- The browser exposes an API that accessibility technology accesses, and a browser interprets the HTML as if it was written to standards.
- If this HTML is not up to spec, such as being used improperly (looking at a
<div>with anonClickevent, for example), the browser cannot infer what exactly that is for. - This affects the accessibility technology, as it can only do with what the browser provides.
- If this HTML is not up to spec, such as being used improperly (looking at a
If we use web technologies improperly, do we expect a browser to somehow perform heuristics to get what we mean? After all, programming is literally telling a computer what to do in a language it understands. If we do not tell it what to do in a way it understands, it will generally take the safest path.
An example of this is correcting for when a closing HTML tag is missing. In older browser days, the standard allowed for certain tags to omit a closing tag and that was valid HTML. That's not the case anymore (except for certain exceptions, like <input>!).
Take this code:
<div>
<span>Hello!
</div>
In any modern browser, the <span> above will be automatically closed in the DOM if you inspect it.
In the source above, there's not even an HTML tag, HEAD tag, or BODY tag, yet Firefox assumes it anyway. The browser can help us in many ways, but it cannot get our intent out of our badly formed code.
Sometimes, the standards aren't all we need
In other instances, we can correctly use all HTML tags and still not make an accessible interface. This is where the nuance comes into play. For example, a modal. By definition, a modal is simply a dialog over top other elements. The user experience dictates that this is treated as a separate "document", and there's no standard way to do this. Modals in general break the way the web was created. A page is a "document", yet a modal is a "document within a document."
If a document is to really behave like a document, then it must be the sole document "in focus." With modals, we generally add a "focus trap" to make sure that users cannot get out of it unwillingly. A bolt-on script will not know this is what you intended.
There are some instances where we need JavaScript in order to make the web accessible. Stephanie Eckles wrote a really good Smashing Magazine article that expands on this.
How does someone's JavaScript know this nuance?
It doesn't. It can't. It won't. And users that need accessible interfaces and experts in the field have said time and time again that it doesn't work.
Don't resort to bolt-on fixes
AccessiBe isn't the first company to do this, but it's making big promises and being slimy in the process. There are others named in the Overlay Fact Sheet - they should all be avoided.
Accessibility is not a bolt-on.
Top comments (11)
Very nice article and so true. For the modal component there is dialog but support isn't great, basically just in blink browsers.
I like using inert which is supported in literally 0 browsers so I have to polyfill it. I do hope it gets supported though. It just makes so much sense.
On a side note when you do code snippets if you include the language you're using you will get syntax highlighting, like this.
Example of actual code.
What's the polyfill?
Plus
disabledand/ortabindex="-1"?I use a JS one from WICG
github.com/WICG/inert
A very interesting article, highlighting just how easy it is for those of us with limited experience of a11y to jump to conclusions about 3rd party products. I thought this link that you shared was very informative too.
I would argue the biggest contributors to bad accessibility are browsers themselves.
We still don't have a
<select>element that style itself even remotely nicely. Let alone looking alike within multiple browsers. This is single-handedly probably the biggest contribution ever to non-accessible website since the dawn of internet.<dialog>is nowhere supported enough yet and if I'm not mistaken, people are already picking out stuff out of the few browser implementations that isn't accessible.There's no such thing as a native menu... Like it's not been what? 20 years we need that component?
Don't start me on date pickers...
Then we have companies like Igalia asking for funding to implement plenty of features in different browsers... Features that should have been implemented by the browser's companies themselves.
Which is infuriating when you think about it, because Microsoft, Google and Apple are 1+ trillion market cap companies!!! Are you telling me they don't have ressources to fix their s***???
I will also point my big fat finger at Safari here, this is the new IE by a long shot. And yet, it's made by the richest company on Earth... They certainly don't need extra funding or Igalia to do their job...
And finally, there is not 1 day without an article asking us, developers, to make our sites accessible...
I think it's high time, we, as developer, get the pitchforks out!
P.S. I'm all for making our sites accessible, I always strive to, but I think there's a mountain of work to be done by the browsers and they're letting us do all the work.
I'd argue that Chrome is the new IE by a long stretch:
-webkit-prefixes in CSS are their fault, and is developers use them for core behaviour rather than progressive enhancement, meaning a lot of websites don't work well on other browsers (Fx & Safari)alert(),confirm(), &prompt()in cross-origin iframes) which cause huge functional and accessibility problems.So much of this reminds me of some of the very same things that Microsoft was doing in the early IE era (4 - 5.5).
You're right.
Accessibility is not some magic you spread on top of your app, or some license you can buy out. A11y is baked on the UX design (correct us of color, contrast, layout, alt text) and in the use of semantically correct components.
A11y's worst enemy is trying to be too smart and reinvent the wheel.
One of the reasons that I cringe every time I hear "the browser is now basically the operating system" is exactly this. That mentality encourages developers to stop thinking about the web like documents, and instead dream of the days when they'll just draw arbitrary pixels to the screen in real time and dynamically decide which will respond to clicks, instead of (as you point out) just using a button.
Interesting stuff, I'd be curious on your experience with accessibility tools as well. We have a Team that does check internally, I implemented something simple use aXe from Deque with Selenium but I know that tool the way we use it barely scratches the surface.
I've been pushing accessibility testing across all levels (dev, QA, content, etc) for the last few years at the company I work at.
At a development level, the built in browser tools are handy for very quick checking, although Chrome's Lighthouse is very basic, it just looks a bit prettier than Fx. Then, there are various plugins available, of which aXe is the best I've found. The pro version has some useful collaboration features which is helpful in a team situation.
The QA team has been integrating aXe and Lighthouse into their automated test suites. They manually test across a variety of browsers and operating systems using different screen readers as well. If you're a bit stuck there with access to devices, I did notice that BrowserStack seems to be implementing screen reader support now too which is a welcome surprise.
Then, we try to get all levels thinking about the issues. So the design/UX process is thinking about things like content, colours, the user journey and ease of access. Developers need to be thinking more about semantic HTML, testing states, and ocassionally putting the mouse/trackpad aside and relying on a keyboard. I've given a few short talks/presentations on various aspects of a11y, and we take things into consideration with code pull requests (at least as far as we can from a pure code POV).
not only do those overlays not help much, they provide almost no protection for accessibility lawsuits so use with caution. If you're not sure where to start, make sure that basic stuff like:
being able to tab through links and sections of your website (in a logical order)
alt attributes for images aren't missing (unless it's a pointless image, like a custom bullet)
aria-labels are implemented
contrast of text is compliant
and whoever mentioned popup date pickers was right...it's a black hole with no way out so be very careful when implementing those. safer to use another method
I'm all for improving web accessibility, I just wish users weren't so litigious. A simple request, followed by a warning, followed by an action is a better way to go. I'm of the opinion that most developers still aren't even aware of how important it is.