More accessible defaults, please!

category: thoughts

Useful HTML elements like date inputs and <video> could make the web a much better place, if browser accessibility bugs in their implementations were prioritised.

On ‘the web is accessible by default’

I like to claim ‘the web is accessible by default’, a sentence that requires nuance (see below). Yes, the web is accessible by default in many ways. The fact that websites are made of text, structured text in most cases, allows for an amount of accessibility that print never had. We can enlarge it, copy paste it, feed it to translation software, have it read out by screenreaders… this is awesome, and very helpful.

But the web has become more than text, in 2020 it is a lot more than that. Websites and web apps now have videos, complex forms and clickable areas that are usually more than a couple of words to form a link. I would love to tell my clients that they can just use HTML, the language that has accessibility built in. More often, the answer is ‘it depends’, when people ask for solutions.

The components of an accessible web

An accessible web has many components, which all somehow circle around web content. On an accessible web, everyone can create and view web content. That’s the basic premise (and the basic promise). To get there, we need not just accessible content. We also need tools that can create accessible content (like CMSes), web standards that allow for marking up accessible content (like HTML) and tools that can display content accessibly (like browsers). We need developers, authoring tools, web standards and browsers to all play along, if we want the web to be accessible.

The browser part of the accessibility picture can have a huge impact. Last month, I wrote about the potential for browsers to automatically fix accessibility problems, in other words mitigate issues caused by inaccessible content. But what about content that is accessible in principle. but breaks ‘because of browsers’?

What browsers could do

In HTML, the inaccessible parts, Dave Rupert listed a bunch of HTML elements that have known accessibility problems in browsers, like date inputs and <video>. Developers use these elements because they trust the web to be accessible by default, their strategy is to stick close to the standards. That promise is somewhat broken for these specific elements.

In Dave’s article, there is a link with more details for each problem (recommended reading!). It somewhat shocked me to see all these issues in one list, even though I had heard about the majority. Basically, if any of those HTML elements are used, a browser displays the content inaccessibly, despite that the standard defined a thing that could be accessible, and developers implemented a thing that could be accessible.

It’s important for me to note at this point: browsers are complex beasts. Browser engineers are extraordinary people who work very hard to build all sorts of features that generally benefit the web. And, of course, we don’t just need an accessible web. We also need a secure web, a web with user privacy, a web with amazing graphic design capabilities (I love CSS Grid), a web that doesn’t lose market share to app ecosystems, a web that efficiently runs complex JavaScript applications, a web that’s fast, a web that can be a compilation target for Rust and C/C++, et cetera.

I should also clarify that while browsers might be breaking things in these examples, there are also plenty of examples where standards are inconsistent despite heroic efforts, or developers build things that cause nightmares for web compatibility engineers (keeping browsers compatible with the web is hard, explained Mike Taylor at View Source 2016).

So, with the caveats that browsers have many priorities, and that standards and developers can also cause trouble, let’s return to the issue of this post: inaccessible HTML elements in browsers. How can we mitigate these problems? Some of the issues can be addressed by web developers themselves with trivial code. If they have heard of the bug, not all developers will. For other issues, there are third party libraries, like AblePlayer for more accessible video. Again, it’s safe to say only a subset of developers is aware of the issues like those with <video>.

Browser makers are in a unique position to fix all of these particular issues for all, so that people with disabilities need to rely less on the willingness of individual developers to enjoy content. There are bugs filed against the relevant browsers, some of which have been open for over a decade, like the bug for keyboard accessibility for <video> in Firefox.

It would be so good if accessible rendering of HTML elements was prioritised more.

Some developments are happening:

Wrapping up

Yes, there are lots of priorities beyond the rendering of HTML elements in browsers. Yet, I’d like to make the case for browsers to prioritise accessible implementations of HTML elements. If browsers implement these elements with maximum default accessibility, they can make improve a lot of the web platform at once.

As Eric Eggert said on Twitter:

We need a movement to fix the web platform to make those essential building blocks of the web accessible for all.

I’d like to join this movement, please! But really, I hope for browsers to support this movement.

Update 2 March 2020: added link to Form Controls Refresh via Simon Pieters’ tweet

Update 3 March 2020: added link to Jamie Teh’s tweet about updated number input type

Comments & mentions (59)

Eric Eggert reposted this
Sheri Richardson likes this
Eric Eggert likes this
Andy Bell likes this
Dave Rupert reposted this
Abbas Arezoo likes this
Phil Keys likes this
Dave Rupert likes this
Barry Pollard likes this
Erik Kroes 🏔 likes this
Gaël Poupard likes this
Jelmer de Maat likes this
Seán O'Grady likes this
Michelle Barker likes this
Alex James likes this
Marcus Relacion likes this
Nikita Voloboev likes this
JulieG replied: Yes, this! Imagine how much of our time would be freed up for more advanced work if these defaults were accessible!
nic likes this
Christian Cousquer reposted this
Steve Lee likes this
Christian Cousquer likes this
Aaron Peters likes this
Llu 🎈 replied:
De nombreux éléments HTML ne sont pas encore nativement accessibles. Pour <video>, l’issue a plus de 10 ans ! Dans son article, @hdv invite les navigateurs à prioriser les implémentations accessibles de ces éléments. hiddedevries.nl/en/blog/2020-0… #a11y #UAAG
Roel Groeneveld likes this
MelanieB likes this
Ana Rodrigues likes this
Guillaume Deblock replied: More accessible defaults, please! hiddedevries.nl/en/blog/2020-0… #a11y
Tom Hermans 🤘 likes this
Accessabilly likes this
Riccardo Erra likes this
Tim Kraut likes this
Chris Heilmann replied:
👉🏻 “More accessible defaults, please!” 🔗 hiddedevries.nl/en/blog/2020-0…
Marcus Herrmann replied:
"Browser makers are in a unique position to fix all of these particular issues for all, so that people with disabilities need to rely less on the willingness of individual developers to enjoy content." –@hdv in "More accessible defaults, please!" hiddedevries.nl/en/blog/2020-0…
Eric Bailey reposted this
Michael Scharnagl likes this
Alberto Calvo likes this
James Catt reposted this
James Catt likes this
Holger Bartel reposted this
Rob Kendal {{☕}} replied: Accessibility by default on the web > hiddedevries.nl/en/blog/2020-0… #accessibility #html
Rich Holman replied:
As developers we need to push pressure on the browser vendors to make default elements more accessible: hiddedevries.nl/en/blog/2020-0… cc/ @ChromiumDev @FirefoxNightly @MSEdgeDev
Perry Trinier reposted this
Alwar Pillai likes this
St�phanie W. replied:
#Accessibility "More accessible defaults, please!" Browsers still have a lot to do to make some default HTML elements accessible. It's a collective effort! hiddedevries.nl/en/blog/2020-0…
Jonathan Hamilton replied:
"More accessible defaults, please!" 👇👇👇 hiddedevries.nl/en/blog/2020-0…
Deborah Edwards-Onoro replied: "Browser makers are in a unique position to fix all of these particular issues for all, so that people with disabilities need to rely less on the willingness of individual developers to enjoy content." hiddedevries.nl/en/blog/2020-0… #a11y #accessibility
Ann replied: More #accessible defaults, please! hiddedevries.nl/en/blog/2020-0…
New Local Media replied: More accessible defaults, please! hiddedevries.nl/en/blog/2020-0…
The Paciello Group replied:
More accessible defaults, please! by @hdv hiddedevries.nl/en/blog/2020-0… #Accessibility #A11y
Yohan J. Rodríguez replied: #CSS #Automated | More Accessible Defaults, Please! hiddedevries.nl/en/blog/2020-0…
dailydevlinks. replied:
📝 More accessible defaults, please! 🔗 hiddedevries.nl/en/blog/2020-0… #html #css #javascript #webdev #dailydevlinks
Fronteers replied:
More accessible defaults, please! hiddedevries.nl/en/blog/2020-0… @hdv on what can be done about the inaccessible building blocks of the web.
Claire Brotherton replied:
“Websites and web apps now have videos, complex forms and clickable areas that are usually more than a couple of words to form a link. I would love to tell my clients that they can just use HTML, the language that has accessibility built in.” hiddedevries.nl/en/blog/2020-0… via @hdv
Elena replied: More accessible defaults, please! > hiddedevries.nl/en/blog/2020-0…
Joulse replied: More accessible defaults, please! hiddedevries.nl/en/blog/2020-0…
Steve Lee likes this
Abubaker Saeed replied:
More accessible defaults, please! by @hdv #HTML #a11y hiddedevries.nl/en/blog/2020-0…
Myplanet replied: "More accessible defaults please!" YES. hiddedevries.nl/en/blog/2020-0… #Accessibility #AccessibleWeb #WebAccessibility
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.