Could browsers fix more accessibility problems automatically?

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.

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

Comments & mentions (95)

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: hiddedevries.nl/en/blog/2020-0…
Simon Pieters reposted this
Simon Pieters likes this
nic likes this
Steve Lee likes this
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: hiddedevries.nl/en/blog/2020-0…
Michael Scharnagl reposted this
Software accessibility (a11y) reposted this
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 reposted this
Eric Bailey replied: Great stuff!
Giamma reposted this
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
Oscar reposted this
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!
Chris Heilmann reposted this
Michael Scharnagl replied:
Thanks :-) Did you already got any feedback regarding this from Browser/Devtools people, who could make this happen?
Halena reposted this
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? hiddedevries.nl/en/blog/2020-0… #accessibility #a11y
Calum Ryan | calumryan.com reposted this
Aaron Gustafson replied:
Could browsers fix more accessibility problems automatically? hiddedevries.nl/en/blog/2020-0… @hdv’s proposal from @webwewantfyi
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
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?
I. Abiyasa Suhardi likes this
negi4a likes this
Adactio Links replied: Could browsers fix more accessibility problems automatically? hiddedevries.nl/en/blog/2020-0…
Erik Kroes 🏔 likes this
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.
Tatiana Mac likes this
Stephanie Stimac 🔮 Casting Spells likes this
Kyle Pflug likes this
Gunnar Bittersmann reposted this
Sketch_House likes this
SELFHTML reposted this
Michael Spellacy (Spell) reposted this
Michael Spellacy (Spell) likes this
Marcus Gill Greenwood likes this
Sylvain Foucher likes this
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.
shaneeza likes this
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: twitter.com/gregwhitworth/…
Marion Daly reposted this
Plant 'CAPTCHA Killer' Daddy 🛡️ reposted this
Marion Daly likes this
Scott Vinkle likes this
Kyle Pflug reposted this
Plant 'CAPTCHA Killer' Daddy 🛡️ likes this
Lucid00 is voting for 1000 years of darkness. likes this
Alex James replied: Could browsers fix more accessibility problems automatically? hiddedevries.nl/en/blog/2020-0…
MOMIN PASHA MOHAMMED reposted this
MOMIN PASHA MOHAMMED likes this
Hidde likes this
GRRR Tech reposted this
Accessabilly reposted this
hexalys likes this
Alberto Seoane 🧬 ασμ::1 🧬 likes this
Fresh Frontend Links replied: Could browsers fix more accessibility problems automatically? hiddedevries.nl/en/blog/2020-0…
Peter Grucza likes this
Bart Simons likes this
Harry Cresswell replied: Today I learned about Firefox Reader View. Thanks to @hdv and his insightful articles. https://t.co/ldZ9JpYPnm
bert boerland replied:
Could browsers fix more accessibility problems automatically? hiddedevries.nl/en/blog/2020-0…
dailydevlinks. replied:
📝 Could browsers fix more accessibility problems automatically? 🔗 hiddedevries.nl/en/blog/2020-0… #html #css #javascript #webdev #dailydevlinks
jebswebs replied: Fascinating read..."Could browsers fix more accessibility problems automatically?" by Hidde de Vries @hdv #a11y hiddedevries.nl/en/blog/2020-0…
Веб-стандарты replied: Могут ли браузеры автоматически исправлять проблемы доступности? Хидде де Врис показывает, в каких случаях и как браузеры могли бы вмешиваться в поведение страницы в интересах пользователей — hiddedevries.nl/en/blog/2020-0…
Adam Laki replied: Could browsers fix more accessibility problems automatically? by @hdv hiddedevries.nl/en/blog/2020-0…
Sergey replied:
Browsers are doing good job improving #a11y Still #Devs should focus more on it☝️I am going to check our website hiddedevries.nl/en/blog/2020-0…
Joulse replied: Could browsers fix more accessibility problems automatically? hiddedevries.nl/en/blog/2020-0…
Anders E. Slettebø replied: I agree. Browser should take bigger responsibility in fixing accessibility problems. #a11y hiddedevries.nl/en/blog/2020-0…
The Paciello Group replied: Could browsers fix more accessibility problems automatically? @hdv certainly thinks so. hiddedevries.nl/en/blog/2020-0…
Saavutettava.fi replied: Could browsers fix more accessibility problems automatically? hiddedevries.nl/en/blog/2020-0… #accessibility #browsers
Chris Heilmann replied:
👉🏻 “Could browsers fix more accessibility problems automatically?” 🔗 hiddedevries.nl/en/blog/2020-0…
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.

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.