Accessibility Screener

This document is intended to be used in the context of the TAG Design Review process.

This checklist is a quick mechanism to assess whether or not your proposed design may need specific accessibility treatment whilst it's still in the early stages of development. These are the areas that may have the largest effect on accessibility. Those questions where you answer "YES" generally need a documented strategy for managing accessibility. If you don't know how to develop that strategy, you can ask us for help. Even if you are an expert or have received expert help, review can still find gaps, so consider asking us for help.

Note that this checklist doesn't constitute an accessibility review, only a way to determine whether specific consideration of accessibility might be required at the early stages of development.

The results of the screener will be filed as a new GitHub issue in your spec's repository, which you can link from your design review request. The Accessible Platform Architectures WG will be tagged on the screener results, so they are aware of upcoming changes to the web platform, and can prepare for future horizontal review.

Document or spec being reviewed
GitHub repository of the document or spec being reviewed

Format: https://github.com/org/repo

Does the design being proposed add any new visual user interface, either to the web or user agent?

For example:

  • a new type of UI element
  • a new mechanism for drawing custom user interfaces
  • a requirement for some user agent UI

Why? Visible interface components must be carefully designed to ensure they are flexible enough to work in a wide range of contexts, for example, when users require extremely large fonts or access the web using assistive technologies such as screen readers.

Follow-up: time-limited UI
If you answered YES to question 1, is the interface only available for a given amount of time?

For example:

  • a notification that disappears

Why? There are a range of reasons why a time-limited visual interface may cause problems for users; for example, screen reader users may not be aware that the interface is available (or else struggle with too many interruptions), or users may not be able to reach the interface in time to interact with it before it disappears.

Does the design being proposed add anything audible to the user interface?

For example:

  • a notification sound
  • a speech-based interface
  • an audio stream (alone or with other timed media)

Why? Audio cues may not always be accessible to users due to disability or because the use of audio is not appropriate for them. Depending on the purpose of the audio, it may be appropriate to provide mechanisms to provide alternative forms for the same information, to provide a redundant visual cue, or allow configuration options.

Does the spec define a protocol that conveys any data meant to be presented to a human?

For example:

  • a transport mechanism for media, such as images, video, or user strings, which may benefit from including an alternative representation as part of the payload

Why? Any given media type in isolation (for example, speech) may be inaccessible or inappropriate for a certain subset of users, so authors should be able to provide alternative forms.

Does the specification change how user input is interpreted at an API level?

For example:

  • a new type of input event
  • a change to an existing mechanism for handling user input (e.g., focus)

Why? For users of assistive technology, user input is often done by the assistive tool. This requires the tool to be able to determine the type of input needed and, when it is needed, to present an appropriate affordance to the user.

Does the specification concern user input, potentially constrained to a specific device or modality?

For example:

  • an API limited to a particular device such as a gamepad, touch screen, or pen
  • a requirement for a user to perform a specific type of interaction in order to enable some aspect of the API (e.g., user activation-dependent)

Why? Specific devices may have unique accessibility considerations, and limiting technology to a particular device may unnecessarily exclude users if a more general design could be created instead.

Follow-up: authoring advice
If you answered YES to any of the above questions, does the specification provide authoring advice?

For example:

  • example code
  • guidance on best practices

Why? Authoring advice should be given in a way that allows authors to write content that is accessible to users and take advantage of relevant features in the API.

Note: You will be able to review it before submitting it.