Could browsers fix more accessibility problems automatically?

Published 04 February 2020 category: thoughts

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:

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:

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 console

Update 26 April 2021: added Quick Highlight Chrome feature

Comments & mentions (141)

Brennan Young 23 Mar 2020 14:01:00

“Link text” and “Link text in context” : Assistive tech often has a feature to abstract links from a page, so that they can be navigated easily, but this is of little use if they consist of dozens of links all called “click here” or indeed “replied”, “likes” and “reposted” (ahem).

In-browser tools could easily display links in a similar form (so that web developers and designers notice the mistake), or even offer to use AI to heuristically expand link text into something meaningful when the context is missing.

Simon Pieters likes this
nic likes this
Steve Lee likes this
Arnout, 3rdEden likes this
Károly Szántai likes this
Chris Heilmann likes this
Oscar likes this
Kilian Valkhof likes this
Giamma likes this
Software accessibility (a11y) likes this
Michelle Barker likes this
Smashing Magazine likes this
Jonathan Dallas likes this
Jens Grochtdreis likes this
Jan Skovgaard likes this
Erik Kroes 🏔 likes this
I. Abiyasa Suhardi likes this
negi4a likes this
Erik Kroes 🏔 likes this
Tatiana Mac likes this
Stephanie Stimac 🔮 Casting Spells likes this
Kyle Pflug likes this
Sketch_House likes this
Michael Spellacy (Spell) likes this
Marcus Gill Greenwood likes this
Sylvain Foucher likes this
shaneeza likes this
Marion Daly likes this
Scott Vinkle likes this
Plant 'CAPTCHA Killer' Daddy 🛡️ likes this
Lucid00 is voting for 1000 years of darkness. likes this
Hidde likes this
hexalys likes this
Alberto Seoane 🧬 ασμ::1 🧬 likes this
Peter Grucza likes this
Bart Simons likes this
Jens Grochtdreis likes this
Llu 🎈 likes this
Manuel Matuzović likes this
Pat Twit likes this
LurkGently likes this
Eric Eggert likes this
Anne Bovelett likes this
Maarten likes this
Manuel Matuzović likes this
Adrián Bolonio likes this
DirkBark likes this
Jan Skovgaard likes this
Stephanie Eckles likes this
swyx likes this
Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦 likes this
Dr. Viviana Menzel 🔴🔴🔴 likes this
Laura Eberly likes this
Bruce Lawson likes this
Cem Kesemen likes this
Eddie Antonio Santos likes this
Sarah Federman likes this
John Liu likes this
Simon R Jones likes this
Mathias Bynens likes this
bertrandkeller likes this
Stefan Krieger likes this
Daniel Schildt likes this
bitttttten likes this
Simon Pieters reposted this
Michael Scharnagl reposted this
Software accessibility (a11y) reposted this
Eric Bailey reposted this
Giamma reposted this
Oscar reposted this
Chris Heilmann reposted this
Halena reposted this
Calum Ryan | reposted this
Gunnar Bittersmann reposted this
SELFHTML reposted this
Michael Spellacy (Spell) reposted this
Marion Daly reposted this
Plant 'CAPTCHA Killer' Daddy 🛡️ reposted this
Kyle Pflug reposted this
GRRR Tech reposted this
Accessabilly reposted this
Manuel Matuzović reposted this
Nicolas Steenhout reposted this
Darren Parlett reposted this
Ioanna Talasli reposted this
Eric Eggert reposted this
🔴 André Jaenisch 🔴 reposted this
Amelia Bellamy-Royds reposted this
Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦 reposted this
Cem Kesemen reposted this
Daniel Schildt reposted this
Steve Lee replied: Postel's law says YES! :)
Marcus Herrmann replied: Indirectly mentioned in the latest @SmashingPod!
Quentin Bellanger replied:
I wish browser makers were more proactive (and developers more conscientious...). #a11y 📙 A good read by @hdv:…
Erik Kroes 🏔 replied: Practical solutions for impracticalities
Roel Van Gils replied: Could browsers fix more #accessibility problems automatically? Yep, and they’re actively working on it. Nice overview by @hdv:…
CSS {IRL} replied: This is a great article by @hdv, it would be awesome to see browsers getting behind this stuff in a big way!
Eric Bailey replied: Great stuff!
Adrian Roselli 🗯 replied:
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.
Adrian Roselli 🗯 replied:
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 replied: thanks Eric!
Hidde replied:
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 🗯 replied:
Yeah, not a criticism of your piece. But I appreciate that you get it.
Deborah Edwards-Onoro replied: 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
nic replied: 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!
Michael Scharnagl replied:
Thanks :-) Did you already got any feedback regarding this from Browser/Devtools people, who could make this happen?
Hidde replied: 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.
Johan Ramon replied:
Could browsers fix more accessibility problems automatically?… #accessibility #a11y
Aaron Gustafson replied:
Could browsers fix more accessibility problems automatically?… @hdv’s proposal from @webwewantfyi
Melanie Sumner replied: 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 replied:

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.

Hidde replied: for users or for website owners?
Adactio Links replied: Could browsers fix more accessibility problems automatically?…
Aaron Gustafson replied:
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 replied: 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 replied: @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 replied: Could browsers fix more accessibility problems automatically?…
Fresh Frontend Links replied: Could browsers fix more accessibility problems automatically?…
Harry Cresswell replied: Today I learned about Firefox Reader View. Thanks to @hdv and his insightful articles.
bert boerland replied:
Could browsers fix more accessibility problems automatically?…
dailydevlinks. replied:
📝 Could browsers fix more accessibility problems automatically? 🔗… #html #css #javascript #webdev #dailydevlinks
jebswebs replied: Fascinating read..."Could browsers fix more accessibility problems automatically?" by Hidde de Vries @hdv #a11y…
Веб-стандарты replied: Могут ли браузеры автоматически исправлять проблемы доступности? Хидде де Врис показывает, в каких случаях и как браузеры могли бы вмешиваться в поведение страницы в интересах пользователей —…
Adam Laki replied: Could browsers fix more accessibility problems automatically? by @hdv…
Sergey replied:
Browsers are doing good job improving #a11y Still #Devs should focus more on it☝️I am going to check our website…
Joulse replied: Could browsers fix more accessibility problems automatically?…
Anders E. Slettebø replied: I agree. Browser should take bigger responsibility in fixing accessibility problems. #a11y…
The Paciello Group replied: Could browsers fix more accessibility problems automatically? @hdv certainly thinks so.… replied: Could browsers fix more accessibility problems automatically?… #accessibility #browsers
Chris Heilmann replied:
👉🏻 “Could browsers fix more accessibility problems automatically?” 🔗…
The A11Y Project replied: "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 replied: 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 replied: I’m sure the list hasn’t changed much over the years.
Henri Helvetica v2.1.0 👩🏾‍🚀 🇭🇹 replied: 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
Hidde replied: 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 replied: So much of this is stuff the browser could yell at you about, or Google could de-rank you for.
Kilian Valkhof replied: Do you want more prominent shouting Eric? I can do more prominent shouting…
Nadhim Orfali replied: 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.
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.