Search engine indexes like Google, Yandex, and Bing now favor mobile-friendly sites. This has encouraged many sites to invest in mobile-friendliness. If we overlook toxic developments like Google AMP and Yandex Turbo pages, this is an example of search engines creating incentives to improve the state of the Web. Smaller indexes like Teclis and Marginalia create different incentives: they penalize tracking and toxic forms of SEO.
I wonder how this could apply to accessibility. Currently, Google rewards the use of alt-text and penalizes small text, small tap-targets, bad link text, and missing language metadata. Rewarding alt-text has created perverse incentives to be overly descriptive, but on the whole these incentives have been helpful. Can we do better?
For starters: on searches with many results, search engines could stick to keywords that show up in both the DOM and significant landmarks of the accessible tree. They could gently penalize easily-detectable accessibility issues such as missing labels, landmarks, or heading-levels. Search engines that use these heuristics should develop or endorse tools to detect issues using the same logic. Automated tools only detect a tiny fraction of issues; saying “we plan to roll out more accessibility checks in the future” could get people to do more than merely meet current checks.
I also think it’s worth exposing some metadata in search results to describe fixable issues. Something as simple as “This result has detectable accessibility issues: missing landmarks” with a “more info” link could go a long way.
A quick search turned [AInspector] up as an example of scoring
I use AInspector regularly (and actually endorse AInspector alongside other tools), but its underlying OpenA11y evaluation library is not up to this task. It has many false positives and no knowledge of ARIA extension modules (e.g. DPUB-ARIA).
An accessibility score would influence which link I clicked on.
The problem: Site A is designed with accessibility for humans in mind; Site B is designed with automated accessibility checkers in mind. Site A might score worse even if it’s more accessible.
Accessibility-related ranking factors therefore need to be extremely conservative since they will create incentives to conform. They need to stick to absolutely critical issues that any human a11y practitioner would notice. Moreover: a false positive will encourage sites to cater to a flawed metric. We can’t replace a human auditor who understands that tools make mistakes.
Public documentation on ranking factors will be necessary, at least for the ranking factors that exist to incentivize better pages. For example, if Mojeek detects missing heading levels, documentation on what this looks like and how to fix it needs to be prominent. Otherwise, the ranking factor can’t really incentivize any good behavior.
This also has to scale to a fast-growing index of billions of pages. Right now, Mojeek does not even run JS; beyond trivial things like a viewport tag, these checks might require something like a headless browser.
(PS: Google and Bing use Chromium for their Core Web Vitals and mobile-friendly tests, which incentives optimizing for Chrome; something else for an alternative engine would be nice!)
Google’s really simple checks (viewport tag, link text, tap target size, mobile and desktop versions have the same content) are a great start. A small subset of the tests run by axe-core and/or IBM Equal Access Checker could follow.
It seems like the underlying issue is that there is no way to access credible, documented accessibility errors written by humans.
Would accessible Web development benefit from an online database of documented accessibility errors? There, submissions could be reviewed and accepted or rejected. And part of each database entry would include an attached discussion where users and developers could discuss changes.
For example, the following page demonstrates a problem with the headings for nytimes.com This could be the type of feedback accepted.
And, would a score published by the database then be useful input for ranking algorithms? The score could be based on the number of open issues per site: