I want inaccessibility promoted in the browser user interface

[WebWeWantBot]

---

title: I want inaccessibility promoted in the browser user interface
date: 2021-02-16T15:55:51.634Z
submitter: Martin Mengele
number: 602beb07fd31b048ed2bf035
tags: [ ]
discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/
status: [ discussing || in-progress || complete ]
related:

• title:
  url:
  type: [ article || explainer || draft || spec || note || discussion ]

---

Some browser vendors show insecure connections in the address bar, e.g. when a website only supports HTTP protocol.

The same could be done with HTML documents in the browser, that are inaccessible. Basic accessibility like color contrasts, missing alternative text and missing keyboard support can be detected automatically. Browser vendors could make this basic inaccessibility visible (machine readable!) to all users.

Background: HTML is fault tolerant. Anyone with a text editor can create an HTML document and publish it to the web. Which is a brillant thing that we want to keep! But many HTML authors (even educated devs) have never heard of accessibility. As we don't want HTML itself to break or throw errors, we might want the browser to help the author make the document accessible and guide him here.

It would create some positive and subtle pressure on authors to make their documents accessible for all.

---

If posted, this will appear at https://webwewant.fyi/wants/602beb07fd31b048ed2bf035/

[aarongustafson]

@accessabilly This looks like a dupe of https://webwewant.fyi/wants/11/

Is there anything you’d add?

[accessabilly]

Hi Aaron, No, it's not a duplicate. My idea is a new approach. I want to promote inaccessibility of an HTML document, just like an insecure connection is promoted: In the address bar of the browser. Detailed information can be kept in the dev tools to fix the issues. But the initial indicator of inaccessibility would be in the address bar. Why? Because web accessibility has an awareness problem. Dev tools is mostly for developers. "Regular" website users won't see them. In the address bar, many people (like website operators, clients, authors, editors etc.) could see possible inaccessibility of a page. And this would create a subtle pressure to fiy those problems. If you want to know more about my idea, check my article on that: https://accessabilly.com/inaccessibility-warnings-in-the-browser/

[accessabilly]

...and btw: what became of my other submission? For context: "I want to accessibly trigger a browsers loading behaviour in an SPA" I answered you on March 2nd 2020. I'm just curious...

[aarongustafson]

and btw: what became of my other submission?

I totally lost track of that email in my inbox (which is part of the reason we’ve moved to GitHub now 😅). I’ll start a new Want issue to discuss that one here. I have your email reply.

[aarongustafson]

The other one is tracked at #294.

[carmacleod]

This is an interesting idea - accessibility definitely needs promotion.

I wouldn't want to say "this page is accessible" - not ever, with an automated tool. There are too many things they can't test.

However, something like "there are machine detectable accessibility issues on this page" might be ok.

I would also worry about is false positives, which could cause developers to bend over backwards to try to work around a "problem" that isn't a problem... just to make the "inaccessible" icon go away. It would really matter what tool or criteria are being used for testing/verification. For example, axe-core currently has "only" 10 open issues for false positives, but it also has 151 closed issues... so even though it is supposed to have a very low number of false positives, it is not zero.

[accessabilly]

Yes, false positives are a core issue in my raw idea. I have no answer yet.

[accessabilly]

I'm sure we should not show any indicators when no automatic errors are found because this would create a possible sense of false security.

But always compare with insecure connections indicators: it's the same problem there. A site running on https is not safe or free from security issues.

[accessabilly]

@aarongustafson still consider this a duplicate?

[myasonik]

For the false positives issue, continuing on the axe-core thread, one way to mitigate it would be to disable any newer rules.

Even, being super conservative about it, a handful of handpicked rules could be a good starting place to get the ball rolling.

[aarongustafson]

@accessabilly Browsers highlight insecure connections because users’ security is at risk. While accessibility issues are a major problem, doing something like this risks confusing many users who have no idea what that’s all about. The folks who need to know about it, as you say, are developers and they should be able to get the warnings and take action on them. Visibility in DevTools is increasing. In addition to DevTools, the Reporting API might be a place where accessibility errors could be filed; we could look into that as a request if you want.

[accessabilly]

Well, I get your point. But the awareness thing is more important to me and I don't think anything that goes on in the DevTools raises any awareness. Because it's not only developers that should have awareness here: it's product owners, authors, editors, website owners, web dev customers, basically anybody interacting with a website.
I agree, that doing this in the same way like for insecure URLs might be confusing to some. But this was my first idea. I assume that there are better solutions because confusion also depends on the design or UI it is attached to. Maybe there could be a more subtle design solution. But it should be as conspicuous as possible but as little confusing as necessary.