w3c / w3c/webdriver

WebDriver commands to enable and disable full accessibility support in browser

Open
#1,919 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

a11y-tracker enhancement
Dominant language
HTML
Stars
718
Forks
228
PR merge metrics
No merged PRs in 30d

Description

Problem:

There is no cross-browser, cross-platform way to enable accessibility for a browser.

Context:

In order for a browser to work with assistive technologies, the browser must implement various accessibility APIs. Because of the extra computation needed to expose these accessibility APIs for every web page, accessibility support is not enabled by default.

Browsers use a variety of different heuristics to decide whether or not to enable the accessibility support, and these heuristics are not only different between browsers but are also often platform dependent -- for example, testing whether a screen reader is running.

Browsers are also capable of enabling only partial support. For example, the WebDriver commands getComputedRole and getComputedLabel will only enable minimal, platform-independent accessibility support -- it does not enable everything that a screen reader needs to provide access to content. This is true for the "accessibility tree" view in DevTools as well. As a result, we currently lack a single, reliable way to perform complete testing of accessibility implementations for all platforms.

Because there are many levels of accessibility support, I'm going to use the term "full accessibility" to mean that the browser can be operated with a screen reader.

Proposal:

A set of WebDriver endpoints to enable full accessibility within a browser.

Ideally the endpoints would be able to do the following:

  1. Query to see whether or not full accessibility is enabled.
  2. Turn on full accessibility.
  3. Turn off full accessibility.

Possibly:

/session/{session id}/accessibility/status
/session/{session id}/accessibility/enable
/session/{session id}/accessibility/disable
How this API could be used in testing

This API would enable two related but different testing scenarios:

  1. Make it possible to reliably turn on full accessibility support during tests.
    a. This is particularly in test environments where, for example, you won't find a screen reader running.
  2. During the run of a test suite, make it possible to turn on full accessibility support for only a subset of tests without having to restart the browser or slow down non-accessibility related tests
    a. This is particularly critical for running accessibility tests in the Web Platform Test suite.

The ability to turn on accessibility in any test suite that uses WebDriver would also allow for:

  1. Testing differences in performance with accessibility on and off.
  2. Catching crashes that might originate from accessibility support code.

Adding this API would improve testing of a part of the web platform that is absolutely critical for many individuals. Accessibility testing is often far behind the rest of browser testing, and this feature could get us a little closer to creating stable access to the web for assistive technology users.

This solution will also help solve immediate problems with running the new accessibility API tests in the wpt.fyi infrastructure: https://github.com/web-platform-tests/wpt/pull/53733

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the proposal for the three accessibility endpoints and the linked wpt.fyi infrastructure context. No implementation files or tests are identified in the issue. Done means the endpoint semantics and behavior for querying, enabling, and disabling full accessibility are specified clearly enough for cross-browser testing.

Written by the indexing model from the issue text.

Assessment

Domain
accessibility, api, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.