Could browsers fix more accessibility problems automatically?

Last year, I was lucky to be selected to present at the Web We Want session at View Source in Amsterdam, to argue for something that’s bugged me (and others) for a while: browsers could be more proactive in fixing accessibility issues for end users.

This post is part write-up of that 5 minute talk, part new additions.

Outreach only does so much

The accessibility community produces lots of information about making accessible websites. Especially for folks who want to get the basics right, detailed info is out there. Sources like WAI, The Accessibility Project and MDN Accessibility have information on what to do as designers, developers and content creators.

This is great, but realistically, this guidance is only ever going to reach a subset of website owners. There are always going to be websites that do not include accessibility best practices, for all sorts of reasons. Whether it’s ill will or obliviousness, it impacts people’s ability to use the web effectively.

It would be pretty useful if browsers could give users the power to override the web, so that they can browse it better. They would then be less at the mercy of willing or knowing developers.

Note: I do not want to say browser features can remove the need for us to worry about improving accessibility. Usually, websites can make the best choices about accessibly offering their content. When it comes to responsibility for accessibility, it is the website’s, not the browser’s.

Can browsers fix issues when they find them?

Most web folks will be aware of WCAG 2.1, the internationally embraced web standard that defines what it means for a website to be “accessible”. The sources I mentioned earlier often refer to this document (or earlier versions of it). When we speak of an “accessibility problem”, there’s often a specific success criterion in WCAG that specifies it.

WCAG conformance is largely tested manually, but luckily we can detect some accessibility problems automatically. An interesting project to mention in that regard, is ACT Rules, a Community Group at the W3C. They are mostly people from accessibility testing software vendors, like aXe and SiteImprove, who work on rewriting WCAG as testing rules (paraphrase mine). While doing that, they help harmonise interpretation of the WCAG success criteria, in other words: find agreement about when some web page conforms and when it does not. Guideline interpretation is not trivial, see The Web Accessibility Interpretation Problem by Glenda Sims and Wilco Fiers of Deque.

Interpretation may not be trivial, there are issues that are pretty clear. There are some that we can get true positives for (note, this is a small subset of WCAG; useful, but small). So, if we can automatically find these issues, can we also automatically fix them?

What browsers could do today

There are some issues that browsers could fix automatically today. In my ideal world, when a website has one of those barriers, the user notices nothing, because the browser fixed it proactively. This is not a Get out of jail free card for developers, designers or content people, but more so one for end users, to improve their experience when they encounter inaccesibility.

For lack of a better metaphor, I imagine each of these features to exist as a checkbox within the browser. I’ll gladly admit this is somewhat oversimplified and high level, it is really just to make the point. Browser makers will likely solve these problems most effectively.

During my research, I found that some browsers already fix some of these issues. Yay, go browsers!

Force zoomability

Some users may depend on zoom functionality to read content. With the Apple-invented viewport meta-tag, web developers can disable zooming:

<meta name="viewport" content="user-scalable=no">

This may be useful in some edge cases, like in photo cropping or maps functionality. But often, it prevents what was a useful feature to some users.

Browsers could fix this automatically, for example via some sort of preference that bypasses the developer’s preferences in favour of the user’s.

This fix exists currently, as Apple does ignore the user-scalable directive in the latest versions of iOS (>10), and it seems some Android browsers do, too.

Force readability

Claiming that 95% of the web is text, Oliver Reichenstein once said:

It is only logical to say that a web designer should get good training in the main discipline of shaping written information

(from: Web Design is 95% Typography)

Plenty of websites out there aren’t great at “shaping written information” at all. There may be differences in taste and all, but some design decisions objectively make content illegible to at least a portion of users. Common problems include: light grey text on a white background, typefaces with extremely thin letters as body text and way too many words per line.

Browsers could fix such readability problems automatically, by forcing page content into a lay-out optimised for reading. Examples of browser features that do this:

  • Safari has had a Reader View for a long time, it lets you select fonts and colours and is marketed as allowing for distraction-free reading
  • Firefox Reader View, which will let you make some choices in typography, dark modes and can even speak the page content out loud so that users can listen instead of read
  • Microsoft Edge has Immersive Reader View (previously Reader View), which can, like Firefox, read aloud. It even has grammar tools, that will let you do things like highlight nouns.

Screenshots Examples of reader mode: Safari, Firefox, Edge

Enforce contrast

When there is too little colour contrast in our UIs, they are harder to use for people with low vision and as well as people with color deficiencies. With contrast checkers (like Contrast Ratio), designers can ensure their work meets WCAG criteria like Contrast Minimum and Non-text Contrast. Still, whenever new content gets added, there’s a risk new contrast problems emerge. That text on a photo on the homepage could turn from super readable to hardly readable in a whim.

You might be getting the theme by now… browsers can deal with contrast problems automatically. Why not have a “enforce contrast” setting, that adds a black background to any white text, always?

It turns out, some browsers are already working on this, too! I was unaware when I prepared my talk. The basic idea is to fix contrast for users that use Windows High Contrast Mode (HCM). So, rather than the individual setting I suggested, it ties in with a related and existing preference. Much better!

The details:

  • Microsoft Edge’s solution is a readability backplate that could be behind all text when High Contrast Mode is on. Melanie Richards also mentioned this in her talk Effectively Honoring Visual Preferences at View Source 2019 (also goes into some great other colour-related accessibility features Microsoft are working on)
  • Firefox is also adding a backplate, see bug 153912, which works in HCM and uses theme background color. Firefox used to completely disable background images in HCM, which ensured lots of contrast, but also in losing potentially important context.

Fix focus styles

For many different kinds of users, it is important to see which element they are interacting with. As I wrote in Indicating focus to improve accessibility, focus indicators are an essential part of that.

Some websites remove them, which makes navigation with keyboards and some other input methods nearly impossible. It is a bit like removing the mouse indicator. CSS allows for doing either, but that doesn’t mean we should.

Browsers could fix this automatically! I would welcome a setting that forces a super clear focus indicator. Basically, it would activate a stylesheet like :focus { outline: 10px solid black; } (and probably a white outline for dark backgrounds), and boom, people who need focus indication no are no longer dependent on individual website’s willingness to provide it.

screenshot left: unchecked checkbox force focus indication, screenshot left: checked checkbox force focus indication, large focus outline drawn A simplified example of what “force focus indication” could look like

I am not aware of any browsers that implement this, but believe it could be an effective way to mitigate a common problem.

Update 26 April 2021: From Chrome 86, there is a Quick Highlight functionality that can be turned on in settings://accessibility. It will force focus outlines on any interactive element, even if the website didn’t provide any. The outline disappears after a few seconds.

Autoplay optional

There’s a number of potential accessibility problems with autoplaying content:

Some websites fix this automatically now. Twitter disabled animated PNGs after they had been used to attack users with epilepsy.

Browsers could fix such issues automatically, too… what if they had a setting that would never allow anything to autoplay? It turns out, Firefox has a flag for this. In about:config, you can set image_animation_mode to none, or once if you prefer (via PCMag). For Chromium, there are plugins.

Block navigation

When every page on a website starts with a bunch of navigation and header elements, it can be cumbersome to users of some assistive tech. If you use a system that reads out web pages sequentially, you don’t want to listen to the navigation menu for every page you go to. 2.4.1 Bypass Blocks exists for this reason, and many websites implement it with a “skip link” (e.g. “Skip to content”) that lets users jump to the content they need.

Browsers can determine blocks of repeated content between pages, especially if they are marked up as labeled regions (see: Labeling regions). If a page has one <main> element, browsers could provide navigation to skip to that element.

Wrapping up

In an ideal world, websites ensure their own accessibility, so that they can do it in a way that works with their content and (sometimes) their brand. Website owners have the responsibility to make their stuff accessible, not browsers or other tools.

Yet, when websites ship with accessibility problems, browsers could fix some. They could automatically “fix” zoomability, readability, colour contrast, focus indication, autoplay and block navigation. If they did, users need to rely less on what websites provide them.

See also: my original proposal, and my other proposal on throwing accessibility errors in the consoleUpdate 26 April 2021: added Quick Highlight Chrome feature

Comments, likes & shares (144)

Simon Pieters, nic, Steve Lee, Arnout, 3rdEden, Károly Szántai, Chris Heilmann, Oscar, Kilian Valkhof, Giamma, Software accessibility (a11y), Michelle Barker, Smashing Magazine, Jonathan Dallas, Jens Grochtdreis, Jan Skovgaard, Erik Kroes 🏔, I. Abiyasa Suhardi, negi4a, Erik Kroes 🏔, Tatiana Mac, Stephanie Stimac 🔮 Casting Spells, Kyle Pflug, Sketch_House, Michael Spellacy (Spell), Marcus Gill Greenwood, Sylvain Foucher, shaneeza, Marion Daly, Scott Vinkle, Plant 'CAPTCHA Killer' Daddy 🛡️, Lucid00 is voting for 1000 years of darkness., MOMIN PASHA MOHAMMED, Hidde, hexalys, Alberto Seoane 🧬 ασμ::1 🧬, Peter Grucza, Bart Simons, Jens Grochtdreis, Llu 🎈, Manuel Matuzović, Pat Twit, LurkGently, Eric Eggert, Anne Bovelett, Maarten, Manuel Matuzović, Adrián Bolonio, DirkBark, Jan Skovgaard, Stephanie Eckles, swyx, Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦, Dr. Viviana Menzel 🔴🔴🔴, Laura Eberly, Bruce Lawson, Cem Kesemen, Eddie Antonio Santos, Sarah Federman, John Liu, Simon R Jones, Mathias Bynens, bertrandkeller, Stefan Krieger, Daniel Schildt, bitttttten, Jens Oliver Meiert, Accessabilly and Thomas Steiner liked this

Simon Pieters, Calum Ryan |, Halena, Chris Heilmann, Giamma, Eric Bailey, Software accessibility (a11y), Michael Scharnagl, Oscar, Gunnar Bittersmann, SELFHTML, Michael Spellacy (Spell), Marion Daly, Kyle Pflug, Plant 'CAPTCHA Killer' Daddy 🛡️, MOMIN PASHA MOHAMMED, GRRR Tech, Accessabilly, Darren Parlett, Ioanna Talasli, Nicolas Steenhout, Manuel Matuzović, Eric Eggert, 🔴 André Jaenisch 🔴, Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦, Amelia Bellamy-Royds, Cem Kesemen and Daniel Schildt reposted this

Quentin Bellanger wrote on 4 February 2020:
I wish browser makers were more proactive (and developers more conscientious...). #a11y 📙 A good read by @hdv:…
Marcus Herrmann wrote on 4 February 2020:
Indirectly mentioned in the latest @SmashingPod!
Steve Lee wrote on 4 February 2020:
Postel's law says YES! :)
Roel Van Gils wrote on 4 February 2020:
Could browsers fix more #accessibility problems automatically? Yep, and they’re actively working on it. Nice overview by @hdv:…
nic wrote on 4 February 2020:
Thank you for writing this, it really opened my mind to the possibilities. Here's hoping that some of these ideas will make it in!
Adrian Roselli 🗯 wrote on 4 February 2020:
I have… _opinions_… on this. Zoom is easy; browsers all (AFAIK) already ignore that meta. Contrast concerns me a bit. Focus styles are an easy win. However, I deal with clients daily who decline to fix their code, saying we should file browser/AT bugs.
Eric Bailey wrote on 4 February 2020:
Great stuff!
Hidde wrote on 4 February 2020:
thank you, I hope so too! I was pretty excited to see many already exist in some form, and browsers seem keen to improve more in this area.
Hidde wrote on 4 February 2020:
thanks Eric!
Michael Scharnagl wrote on 4 February 2020:
Thanks :-) Did you already got any feedback regarding this from Browser/Devtools people, who could make this happen?
Adrian Roselli 🗯 wrote on 4 February 2020:
And browser/AT bugs get filed, sometimes flagged as absurd, and sometimes ignored. But developers get to continue to assert this is not their problem, point to their browser/AT bugs, high-five their Scrum master, and continue to build crap.
Hidde wrote on 4 February 2020:
Yea, someone literally suggested that we no longer need to worry about a11y as devs (I was still on stage but unmicced so could not interfere 😱) This is good feedback, I will expand my disclaimer a bit more
Adrian Roselli 🗯 wrote on 4 February 2020:
Yeah, not a criticism of your piece. But I appreciate that you get it.
CSS {IRL} wrote on 4 February 2020:
This is a great article by @hdv, it would be awesome to see browsers getting behind this stuff in a big way!
Deborah Edwards-Onoro wrote on 4 February 2020:
Did you know browsers have options you can use now to fix accessibility issues? I didn't know about all the settings, now I do. #a11y #accessibility
Erik Kroes 🏔 wrote on 4 February 2020:
Practical solutions for impracticalities
Johan Ramon wrote on 4 February 2020:
Could browsers fix more accessibility problems automatically?… #accessibility #a11y
Melanie Sumner wrote on 4 February 2020:
The article says “this is not a get out of jail free card” but I have thought about this for years and I am pretty sure it is.
Jeremy Keith wrote on 4 February 2020:

Some really interesting ideas here from Hidde on how browsers could provide optional settings for users to override developers when it comes to accessibility issues like colour contrast, focus styles, and autoplaying videos.

Aaron Gustafson wrote on 4 February 2020:
Could browsers fix more accessibility problems automatically?… @hdv’s proposal from @webwewantfyi
Hidde wrote on 4 February 2020:
for users or for website owners?
Adactio Links wrote on 4 February 2020:
Could browsers fix more accessibility problems automatically?…
Aaron Gustafson wrote on 4 February 2020:
I agree that's a potential issue, but the sad reality is that not enough devs are paying attention to accessibility issues and they aren't the ones impacted by it, the end users are. But more efforts need to be made to reject code based on failing accessibility review, for sure.
JulieG wrote on 5 February 2020:
Something I've wanted for ages is for browsers to provide standard keyboard shortcuts to any properly marked up regions, or even just <main>. Similar to what's available in screen readers.
Greg Whitworth wrote on 5 February 2020:
@hdv checkout Edge's new focus rect, it's shipped in stable. Here's an old tweet of cookies but it's implemented:…
Alex James wrote on 5 February 2020:
Could browsers fix more accessibility problems automatically?…
Fresh Frontend Links wrote on 5 February 2020:
Could browsers fix more accessibility problems automatically?…
Harry Cresswell wrote on 6 February 2020:
Today I learned about Firefox Reader View. Thanks to @hdv and his insightful articles.
bert boerland wrote on 7 February 2020:
Could browsers fix more accessibility problems automatically?…
dailydevlinks. wrote on 10 February 2020:
📝 Could browsers fix more accessibility problems automatically? 🔗… #html #css #javascript #webdev #dailydevlinks
jebswebs wrote on 11 February 2020:
Fascinating read..."Could browsers fix more accessibility problems automatically?" by Hidde de Vries @hdv #a11y…
Веб-стандарты wrote on 12 February 2020:
Могут ли браузеры автоматически исправлять проблемы доступности? Хидде де Врис показывает, в каких случаях и как браузеры могли бы вмешиваться в поведение страницы в интересах пользователей —…
Adam Laki wrote on 15 February 2020:
Could browsers fix more accessibility problems automatically? by @hdv…
Joulse wrote on 21 February 2020:
Could browsers fix more accessibility problems automatically?…
Anders E. Slettebø wrote on 21 February 2020:
I agree. Browser should take bigger responsibility in fixing accessibility problems. #a11y…
Sergey wrote on 20 February 2020:
Browsers are doing good job improving #a11y Still #Devs should focus more on it☝️I am going to check our website…
The Paciello Group wrote on 27 February 2020:
Could browsers fix more accessibility problems automatically? @hdv certainly thinks so.… wrote on 28 February 2020:
Could browsers fix more accessibility problems automatically?… #accessibility #browsers
Chris Heilmann wrote on 2 March 2020:
👉🏻 “Could browsers fix more accessibility problems automatically?” 🔗…
The A11Y Project wrote on 1 April 2020:
"It would be pretty useful if browsers could give users the power to override the web, so that they can browse it better. They would then be less at the mercy of willing or knowing developers." @hdv…
Access42 wrote on 8 June 2020:
Les navigateurs pourraient-ils corriger automatiquement certains problèmes d’#accessibilité ? @hdv esquisse ce qui pourrait être implémenté dès à présent :… Il insiste sur le fait que cela ne devrait pas dédouaner les devs de leur responsabilité. #a11y
Marc Reppin wrote on 30 April 2021:
I’m sure the list hasn’t changed much over the years.
Hidde wrote on 30 April 2021:
the good news is, these fruits aren't hanging terribly high, these issues are very fixable… bad news, I guess, that many sites still have them. There's work to do! :-)
Eric Bailey wrote on 30 April 2021:
So much of this is stuff the browser could yell at you about, or Google could de-rank you for.
Kilian Valkhof wrote on 30 April 2021:
Do you want more prominent shouting Eric? I can do more prominent shouting…
Henri Helvetica v2.1.0 👩🏾‍🚀 🇭🇹 wrote on 30 April 2021:
wild! I just went looking for the 2021 data early today, but ended up quoting 2020. But seeing the contrast calamities haven't improved in 3 yrs, I'm still up to date. @webaim
Nadhim Orfali wrote on 1 May 2021:
Maybe just me but browsers could just produce a a page error just like if you made a typo or mistake in JS. This then forces the author to correct that mistake. A missing alt is no different to having an undefined variable IMHO.
Yes! Our software could so much more. Fortunately, there seem to be exciting improvements right now—loved @tomayac pointing out the following improvements in @MicrosoftEdge, exactly in this spirit:…