Building it in vs. Bolting it on

Making Accessible Specs, and Updates to the accessibility horizontal review process

Matthew Tylee Atkinson, Fredrik Fischer, APA WG and FAST TF

TPAC 2025
Kobe, Japan & online
10–14 November 2025

Overview

Making the horizontal review process more accessible
What can the Accessible Platform Architectures WG do for you?
Rebooting the Framework for Accessibility in the Specification of Technologies (FAST)
We want to hear from you!
- Pain points with the horizontal review process
- What sort of advice would you like to get, how, and when?

Horizontal Review

What is it? Peer review in key areas:
- Accessibility
- Internationalization
- Privacy
- Security
- Architecture

Horizontal Review

Who's it for? Spec or explainer authors
When does it happen? Often too late! Official horizontal review sometimes only comes way after features have shipped.
What does it provide you with?

Requesting a review

Simple! In general: check out How to get horizontal review in the W3C Guidebook

Options on GitHub for requesting review from APA WG

Resources and points of contact…

Next we'll point out some resources (recently updated) and points of contact.

Resources and review stages available to support your specification

Review activities and resource for your spec:
- TAG screener
- FAST
- FAST Checklist
- APA WG review
The Accessibility User Requirements docs from RQTF, and guidance on Making Content Usable from COGA TF, feed into the FAST, FAST Checklist, and APA WG reviews.

Resources and review stages available to support your specification - feedback cycle

This is the same diagram as on the previous slide, but with the addition of feedback lines from your specification, to the APA WG review stage which, in turn, feeds back to: the Accessibility User Requirements from RQTF and Making Content Usable from COGA TF; the FAST, and the FAST Checklist.

TAG Accessibility Screener

Example question (4 of 7):

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.

Yes No N/A

FAST Checklist

Excerpt of the FAST Checklist, showing the start of the section titled "If technology provides features to accept user input", with a couple of checlist items shown under this:

"There is a mechanism to label user input controls in an unambiguous and clear manner."
"Authors can associate extended help information with a control."

The section as a whole has a set of radio buttons to indicate whether it's applicable. Each checlist item has further explanatory text, an optional external reference, e.g. to WCAG, and a set of yes/no radiobuttons to state whether the checklist item has been met.

Digital Accessibility User Requirements

From the Web Accessibility Initiative (WAI) site…

WAI continues to analyze research and document user needs in several areas. The documents below:

provide information to developers on how to make their products more accessible
inform future standards

Cross-disability user requirements for specific technologies, tools, situations

Media Accessibility User Requirements (MAUR): Describes the needs of users with disabilities to be able to consume audio and video media on the web. A MAUR updated Working Draft is in progress. (Learn more from the MAUR blog post.)
Synchronization Accessibility User Requirements (SAUR) for multimedia: Addresses synchronization of captions, sign language interpretation, and descriptions in audio and video media. Media needs to be synchronized to very specific limits in order to be understandable. (SAUR blog)
XR Accessibility User Requirements: Describes user needs in virtual or immersive environments (XR). (XAUR blog)
RTC Accessibility User Requirements (RAUR): Describes user needs for real-time communication (RTC). RTC enables instantaneous applications for video and audio calls, text chat, file exchange, screen sharing, and gaming. (RAUR blog)
Collaboration Tools Accessibility User Requirements: Describes user needs in tools that support for one or more specific collaborative features. These features include real-time editing of content by multiple authors, the use of comments or annotations, and revision control.
Natural Language Interface Accessibility User Requirements (NAUR) Draft: Addresses situations where a user and a system communicate via a natural (human) language. The user provides input as sentences via speech or other input, and the system generates responses as sentences delivered by speech, text, or another modality. (Learn more from the NAUR blog post.)
Framework for Accessible Specification of Technologies (FAST) Editors’ Draft: Advises creators of technical specifications how to ensure their technology meets the needs of users with disabilities.

Disability-specific user requirements and research

Cognitive and learning disabilities
- Cognitive Accessibility User Research
- Cognitive Accessibility Issue Papers
Low vision
- Low Vision Accessibility Research notes
- Accessibility Requirements for People with Low Vision

Making Content Usable for People with Cognitive and Learning Disabilities

This document is for people who make web content (web pages) and web applications. It gives advice on how to make content usable for people with cognitive and learning disabilities. This includes, but is not limited to: cognitive disabilities, learning disabilities (LD), neurodiversity, intellectual disabilities, and specific learning disabilities.

Key deliverable: use cases

Explainers, and Accessibility Considerations Sections

Writing Effective Explainers

Compute Pressure API Accessibility Considerations

The Compute Pressure API is focused on improving the user experience. There are two ways in which applications that build on the API can positively impact accessibility.

Considering users' access needs when making decisions based on information gathered using the API.
Designing and making user interfaces based on information gained from the API with accessibility in mind.

As a consumer of the API, it's important to consider both of these opportunities. Here are some examples:

Decision: In a video conferencing scenario, there may be multiple video streams. The system may determines that it needs to drop certain streams in order to conserve resources. If one of the video streams comes from a sign language interpreter, then that stream must be prioritized over others, so that the user can still understand the conversation. In practice, this could be simply implemented by allowing the user to "pin" a certain stream, and ensuring that that pinned stream is never automatically dropped by the system.
User Interface:
- A simple load-level meter, in which the current usage level bucket is indicated on the screen. This information must be conveyed using more than just color, so that people who cannot perceive color can still perceive the information. A symbol could be used in conjunction with color. Text could also be used in conjunction with both shape and color.
- Some applications may present a notification to the user when some functionality is restricted due to compute pressure. These notifications may take the form of "toast" messages, in which case care must be taken to ensure that people using assistive technologies (including screen readers) can be made aware of the notification, and dismiss it, without unduly interrupting their workflow.

About the FAST

…and ongoing updates

Background

User needs
- e.g. understand the purpose of a UI control
- e.g. understand some instructional text in the UI
Functional needs (or capabilities)
- e.g. color perception deficit
- e.g. short term memory barriers
The intersection of these gives us specific accessibility scenarios to consider, for which the FAST seeks to advise.

However…

Reboot needed

Feedback we have had from spec authors (primarily on the checklist) is that the examples are too abstract and the concepts very high-level…
More concrete framing and examples would be of help.
Further, projects like the excellent Digital Accessibility Framework have been developed to fulfil the need for a general mapping of accessibilty scenarios, across sets of guidelines

So we are rebooting FAST to be more W3C-specific…

Concrete actors

Spec
Author
UA
AT
User

Example

Feature	Spec	Author	UA	AT	User
Alternative content	Allow provision of alternative content	Provide content	Expose content in some way	Render content	Be aware of possible content

We may not be talking about the alt attribute.

Additional actors and considerations

We want to help you promote the accessibility of…

The products and services built on your spec
The authoring tools and processes associated with your spec
The spec document itself

Where's WCAG?

Following WCAG provides a baseline level of accessibility for web content.
Many of the principles are more generally applicable.
But their coverage isn't necessarily even or universal (because we can only recommend what we know works for representative web content).
The AURs provide higher-level, user-focused, domain-specific advice.
FAST seeks to provide a wider gamut of scenarios, and to be helpful when adding new capabilities to the platform.

APA WG's goals

Be available as early as possible.
Help by highlighting use cases you may be unaware of.
Providing technical advice in general, and helping you co-ordinate with other relevant expert groups.
Providing longitudinal tracking of specs' accessibility.
Improving the horizontal review process for all.
- Via suggestions for the existing tooling, and experiments such as new interfaces onto the process.

Group discussion

Pain points with the horizontal review process
What sort of advice would you like to get, how, and when?

Resources

Acknowledgement: thanks to Peter Korn for the "building it in vs. bolting it on" concept.

Join us

If you would like to join the FAST TF, please contact us.