FAST restructure 2021

From Accessible Platform Architectures Working Group

FAST Restructure Overview and work

This page outlines the current work that is taking place to iterate the FAST in the Functional Needs Sub group of the Silver Task Force.

The Framework for Accessible Specification of Technologies (FAST) advises creators of technical specifications how to ensure their technology meets the needs of a user with disabilities. It addresses primarily web content technologies but also relates to any technology that affects web content sent to users, including client-side APIs, transmission protocols, and interchange formats. The idea is that this document can be used by various W3C groups to do horizontal reviews of their specifications to check if that spec can successfully support any given accessibility user need.

This FAST document takes the form of a inventory of user needs, and a draft FAST checklist that is used in horizontal review. The inventory of user needs is designed to be a single set - and from this set of user needs comes requirements that are to be represented as the checklist. This work was an initial draft that needs to be consolidated, refined and updated.

Current work updating FAST user needs

To iterate this work, there is a current updated branch (March 2021) that contains a more consolidated set of user needs. This needs to be reviewed and commented on by the Functional Needs Sub group.

Some questions for the sub-group to consider are:

User Needs structure - Flat or Nested

An open question is how we structure these user needs. There may be:

  • Several hierarchies of user needs
  • Different hierarchies = End user, author, API.

We may break these down in different ways:

  • User needs → Different technology requirements.
  • User needs → Silver Functional Categories → Silver Guidelines → Silver outcomes

An open question is: Do we just have a flat set of user needs? Or do we flat set? Or related sub sets that support their parent.

Structure One: Flat level

Level 1: Flat presentation of user needs:

Level 2: Breaks then into groups of requirements for User groups (human), Application groups: Technology/Spec requirements (FAST) - User agent / API requirements (maybe sibling), authoring tools. If 'technology allows visual rendering etc'.

Level 3: Could be the requirements for each group as we are outlining user needs in FAST (as a sibling to WCAG 3.0)


A pro here is we have one flat level of user needs - but it is potentially huge. Considering that Perceivable, Operable, Understanding and Robust has given us WCAG - we now have ~ 30 + in the 'user-needs-restructure' branch.

Structure Two: Nested level

Level 1 - x : Nested presentation of these core user needs:

Level *: More detailed as needed - if we take this approach the question is how to group them, by technology or disability type?

Level *: Relating these grouped requirements need to relate ultimately: User groups, Application groups: Technology/Spec requirements (FAST) - User agent / API requirements, authoring tools. These would then be addressed by specs such as WCAG 3, User Agents spec, Authoring Requirements, XAUR, RAUR, MAUR etc.

Other questions

  • Q: Is there a need for a new UAAG especially in the context of emerging technologies? It looks like many of the XAUR type user needs are actually UAAG things. This could be restarted under a new gap - if we can see via a gap analysis that UAAG.x is needed.
  • Q: Regarding the process for gap analysis - what should this look like? For example, when we review and can map a user needs to various parts of the technology stack. What does it mean when we can't map or relate a user need to a given technology? Does that mean there is a gap? If we say yes, how do we present that to a group that this is something that the group needs to support, and demonstrates the existence of a feature or requirement that may not exist yet.
  • HTML/CSS we may look at as one technology? What are the advantages of this?
  • Q: When do the combination of particular relevant requirements actually meet the particular user need? What is sufficient?

To do

  • Are there other options for outlining and presenting user needs?
  • If so, we urge group members to refine and model alternatives - come up with a description of the model that works.