More accessible defaults, please!

Published 2020-03-01 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, likes & shares (63)

Sheri Richardson, Eric Eggert, Andy Bell, Abbas Arezoo, Phil Keys, Dave Rupert, Barry Pollard, Erik Kroes 🏔, Gaël Poupard, Jelmer de Maat, Seán O'Grady, Michelle Barker, Alex James, Marcus Relacion, Nikita Voloboev, nic, Steve Lee, Christian Cousquer, Aaron Peters, Roel Groeneveld, MelanieB, Ana Rodrigues, Tom Hermans 🤘, Accessabilly, Riccardo Erra, Tim Kraut, Michael Scharnagl, Alberto Calvo, James Catt, Alwar Pillai and Steve Lee liked this

Eric Eggert, Dave Rupert, Christian Cousquer, Eric Bailey, James Catt, Holger Bartel and Perry Trinier reposted this

JulieG wrote on 2 March 2020:
Yes, this! Imagine how much of our time would be freed up for more advanced work if these defaults were accessible!
Llu 🎈 wrote on 2 March 2020:
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
Guillaume Deblock wrote on 2 March 2020:
More accessible defaults, please! hiddedevries.nl/en/blog/2020-0… #a11y
Chris Heilmann wrote on 2 March 2020:
👉🏻 “More accessible defaults, please!” 🔗 hiddedevries.nl/en/blog/2020-0…
Marcus Herrmann wrote on 2 March 2020:
"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…
Rob Kendal {{☕}} wrote on 3 March 2020:
Accessibility by default on the web > hiddedevries.nl/en/blog/2020-0… #accessibility #html
Rich Holman wrote on 3 March 2020:
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
St�phanie W. wrote on 3 March 2020:
#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 wrote on 4 March 2020:
"More accessible defaults, please!" 👇👇👇 hiddedevries.nl/en/blog/2020-0…
Deborah Edwards-Onoro wrote on 4 March 2020:
"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 wrote on 4 March 2020:
More #accessible defaults, please! hiddedevries.nl/en/blog/2020-0…
The Paciello Group wrote on 4 March 2020:
More accessible defaults, please! by @hdv hiddedevries.nl/en/blog/2020-0… #Accessibility #A11y
New Local Media wrote on 4 March 2020:
More accessible defaults, please! hiddedevries.nl/en/blog/2020-0…
Yohan J. Rodríguez wrote on 5 March 2020:
#CSS #Automated | More Accessible Defaults, Please! hiddedevries.nl/en/blog/2020-0…
dailydevlinks. wrote on 5 March 2020:
📝 More accessible defaults, please! 🔗 hiddedevries.nl/en/blog/2020-0… #html #css #javascript #webdev #dailydevlinks
Fronteers wrote on 5 March 2020:
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 wrote on 6 March 2020:
“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 wrote on 8 March 2020:
More accessible defaults, please! > hiddedevries.nl/en/blog/2020-0…
Joulse wrote on 9 March 2020:
More accessible defaults, please! hiddedevries.nl/en/blog/2020-0…
Abubaker Saeed wrote on 12 March 2020:
More accessible defaults, please! by @hdv #HTML #a11y hiddedevries.nl/en/blog/2020-0…
Myplanet wrote on 16 March 2020:
"More accessible defaults please!" YES. hiddedevries.nl/en/blog/2020-0… #Accessibility #AccessibleWeb #WebAccessibility
Brian Haferkamp wrote on 24 March 2020:
#accessibility #a11y #HTML hiddedevries.nl/en/blog/2020-0…
CSS Basics wrote on 6 April 2020:
More accessible defaults, please! by @hdv hiddedevries.nl/en/blog/2020-0…
Steve Lee wrote on 5 February 2021:
More accessible defaults, please! @hdv - hiddedevries.nl/en/blog/2020-0…
Harini wrote on 5 May 2021:
@hdv You can learn about Accessibility hiddedevries.nl/en/blog/2020-0…