1610265 - Use test framework or debug-build assertions to check for accessibility issues in Firefox's own chrome/about: documents

Status: NEW

(Firefox :: Disability Access, task)

Description

[:Gijs (he/him)]

We've occasionally accidentally shipped features with less-than-stellar accessibility support (to put it mildly). Some of these oversights could have been caught with appropriate checks in either test frameworks or inside our own C++ code.

Some examples of what we could check for:

• descriptive (alt) text (or role=presentation) on image element (XUL <image> or HTML <img>)
• text (not just icons) via labels or tooltips or aria-label on buttons or other elements with click/keypress/keydown event listeners
• live foreground/background contrast checks in what we end up rendering (easier than trying to resolve CSS colours "statically", given that foreground/background colours can be set in different places / with variables etc.)

We've done some of this on a case-by-case basis, e.g. I know that we have some checks on the accessibility structure for tabs in Firefox's main window, and IIRC there are some checks for the URL bar autocomplete. However, those are aimed at specific features, and so they don't "catch" new things we do.

Per discussion on slack, integrating with a test framework (like browser-chrome) is likely easier to maintain (in terms of effort for maintenance, as well as for lists of exceptions if this type of tool finds pre-existing problems, or cases where automated checks don't quite get a complete picture of what's going on), but the downside will be that some checks may be trickier to implement (e.g. although you can check whether a specific element has event listeners from JS, it's harder to find all elements in a window with a specific event listener, whereas if we instrumented the addition of event listeners from C++ that'd be less overhead).

A linter would be ideal in terms of the feedback loop, but my understanding is that static linting in this area has not historically been an effective way of detecting problems correctly - though I defer to Jamie as to whether that's perhaps changed in recent years.

Comment 1

[:Gijs (he/him)]

Oh, and one thing that I meant to stick in comment #0 and forgot: we have existing auditing code in the devtools that we could potentially leverage for this purpose if possible - though it's not clear off-hand how practical that would be today.