Framework for Accessible Specification of Technologies (FAST) advises creators of technical specifications how to ensure their technology meets the needs of 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. Specifications that implement these guidelines make it possible for content authors and user agents to render the content in an accessible manner to people with a wide range of abilities.

This document is accompanied by a checklist which is more complete and usable for groups evaluating technologies at this time.

Introduction

Checklist

This document is accompanied by a checklist which is more complete and usable for groups evaluating technologies at this time.

Goals

Numerous guidelines exist for creating and supporting content that is accessible to people with disabilities, on and off the Web. When these guidelines are supported in the entire web ecosystem, content creators can author accessible content, and expect the accessibility features to be made available by user agents, including assistive technologies when needed. Authoring tools support creation of accessible content, and accessibility features survive transmission to different systems or conversion of content to different formats.

Nearly all of these accessibility features depend on support in some form from the technology in which content is encoded, transmitted, and sometimes transformed. But there is not yet a set of well-documented guidance for such technologies. Instead, requirements are inferred from authoring and user agent guidelines. This makes it complicated for technology creators to ensure they have met the full set of needs. Review from accessibility specialists is limited by bandwidth and expertise, so does not fully address that problem. As a result, varying technologies provide various levels of support with varying levels of compatibility with other technologies. These issues at the core layers of Web technology impact the progress that can be made from support of higher-level guidelines.

Framework for Accessible Specification of Technologies aims to fill this gap. It is intended to be a single, well-considered set of guidelines addressing specifically the features technologies need to provide to support accessible. These guidelines relate to the requirements of other guidelines but should not be confused with them. The goal of FAST is to provide a single source of guidelines for Web technology accessibility. They relate to other guidelines and documentation to provide additional information and rationale for the requirement, but are intended to be a self-sufficient set of guidelines that technology creators can follow.

Audience

The primary audience of FAST is creators of Web technologies. Most of the guidelines relate to content and presentation technologies like HTML, CSS, SVG, PDF, audio/video formats, etc. Some guidelines also address data formats, interchange formats, transmission protocols, etc., usually aimed at ensuring these technologies preserve the accessibility features of content impacted by these technologies. Because of this broad set of relevant technologies, all Web technology creators are considered part of the audience for FAST.

Secondary audience include creators of higher level accessibility guidelines and other advocates for web accessibility features. Because FAST has a strong grounding in user needs, researchers and advocates who identify the accessibility requirements of web users with disabilities are also an important audience.

Scope

Framework for Accessible Specification of Technologies is a product of the World Wide Web Consortium and as such targets only the accessibility requirements of web technologies. Many of the user needs are the same for web use and non-web use, so FAST will necessarily overlap and hopefully be compatible with similar guidelines addressing non-web space. Nonetheless, FAST is not designed to be used for non-web technologies and there could be key differences. Furthermore, there are user needs that exist outside the web that do not impact the web, and those needs are completely unaddressed by FAST.

In spite of these caveats about the scope of FAST, this scope will evolve as the Web does. More and more technologies are becoming part of the Web, and bringing user needs to the Web along with them. For instance, strictly hardware accessibility issues may be non-web requirements, but the Web of Things brings many of these issues closer to the Web than in the past. FAST will need to reflect this evolution, and future versions may be required to address user needs that are new to the Web.

Approach

The goal of FAST is to help ensure that web technologies meet the needs of users with disabilities. To do this, the work involves three stages:

Inventory functional and user needs

The first step in the development of these guidelines is to inventory known functional and user needs. Many user needs affecting web content accessibility are well known and documented in multiple places. These needs are collected and related to each other in order to arrive at a single set of known needs. Sources examined in the development of these guidelines include:

Note the goal of this exercise is not to supplant other good work in this field. The aim is to assemble disparate sources if knowledge about user needs in one place, to facilitate analysis. This work is likely to spin off from the core work of developing FAST. If another organization creates a sufficiently rich collection of documented user needs it will be possible to use that resource rather than reinvent the work in W3C.

In the course of exploring how to apply user needs to accessibility guidance, we have identified two intersecting categories of needs: [[[#functional-needs]]] and [[[#user-needs]]].

Functional needs

A functional need is a statement that describes a specific gap in one’s [=ability=], or a specific mismatch between ability and the designed environment or context. An intersectional functional need results from an individual having more than one functional need simultaneously in a given context.

A functional ability is a notional measure of a person’s abilities that may need technological support or augmentation to be able to complete a particular task.

The intent is to express the need in a contextual model, as opposed to a lack of ability in a medical model. This is similar to the ICF (International Classification of Functioning – a biopsychosocial model), “outcomes of interactions between health conditions (diseases, disorders and injuries) and contextual factors”, focusing on the interactions. 

User needs

A user need is a high level accessibility characteristic of content and/or a user interface that is necessary for users to complete an objective.

In this model, user needs are not accessibility specific. User needs are generic requirements of content for its features to be usable by humans.

Matrix of functional and user needs

In order for people to access content, for every [=user need=] inherent in the content, there must be a way to meet an individual’s [=functional needs=]. User needs and functional needs intersect into a matrix of potential affordances required for content. These requirements comprise the set of expected outcomes that should be addressed in this and other web accessibility guidance.

Todo: put in snapshot of matrix or something.

Identify ways to meet needs

The second stage in development of the guidelines is to identify ways these needs can be met. There are three high-level ways user needs can be met:

  • technology features;
  • author implementation;
  • user agent support.

These are not mutually exclusive categories. A given user need could be met by more than one of these categories, but the ability of a given category to meet a user need implies the need for guidelines targeting that category. In policy setting and evaluation there may be a preference hierarchy for how best to meet needs, e.g., user agent support of standard features is preferred, but author technical override is needed if user agent support is lacking.

Some needs can be met with present technology only via one of these routes. Other needs can be met by more than one route, and for content to be accessible it is only required that one of the available routes be implemented. Many needs, however, require more than one route to be implemented together for the need to be met. The most common example is that a technology provides a feature, the author uses that feature in the content, and the user agent makes the result available to the user.

All of these ways of meeting user needs are identfied, along with their relationships to each other. Once these approaches are identified, the result is separate lists of requirements for content technologies, authors, and user agents. The relationship among the routes may play a role in prioritization of guidelines, since needs that can only be met by one route may be more important to meet by that route, than needs that could be met by other means as well.

Develop technology guidelines

From the above analyses, it should also be easy to see where content technology features are required to make it possible to meet user needs. For example:

  • If the author must implement something, the technology must provide a feature for the author to implement.
  • If the user need is met by design, the technology must provide suitably rich design capabilities.
  • If the user need is met by user agents, the technology must provide a sufficiently rich definition of the object for user agents to implement.

Not all technologies will address all ways of meeting user needs. For instance, CSS is primarily design-oriented, and HTML is somewhat semantics-oriented. The technology requirements may need conformance profiles or some other way of guiding technology developers seeking to follow them. It may not be easy to state in a general prescriptive way whether a given technology should, for instance, provide a richer design capability to meet a user need or should instead rely on better semantics for assistive technology-oriented content alternatives. A good structure of the technology requirements should help make it clear that some method of meeting a given user need is important. Horizontal review may continue to be important in guiding technology developers through the possibilities.

The set of approaches to meeting user needs that affects technology features becomes the base information for the Framework for Accessible Specification of Technologies. (The other two routes, while important to the analysis, are not directly relevant to FAST but may inform other work.) These approaches are prioritized, organized, and translated into guidelines-type language to become the Framework for Accessible Specification of Technologies.

With the above analyses done, it should be easy to see how current guidelines address which user needs. In turn it should be easy to see where current guidelines to not meet user needs, that in theory should be able to be met by activities within the remit of that set of guidelines. This should be important input into WAI 3.0 / WAI 2020 planning.

Explanation of User Needs

Identify user needs that we plan to provide guidance on meeting. These should describe the needs of humans as they currently exist (i.e., without significant evolution or cyborgization from early 21st century norms), and therefore is as era-independent as possible with current knowledge. The focus is on the needs of people with disabilities, but because that is sometimes a relative / contextual condition, a significant proportion of mainstream needs will also be identified.

At least two levels of needs may be identified. The first is truly generic needs, requirements users have to access and use content such as perceive and understand it, and should be stable over time. The second layer is needs specific to technologies of the day, such as ability to understand and operate controls. This layer may be understood as an implementation of the generic needs, so may not be classed as user needs in the end. Regardless of its classification, it will be an important component of understanding the space. This level of needs evolves as technology and design patterns do, so needs to be maintainable separately from the generic needs.

Evolution of user needs

Where user needs are suspected but known, related work may expand the inventory through research when feasible. Therefore the set of documented user needs will evolve over time. A given set of guidelines including FAST, however, can only address needs that were known at the time of development of the guidelines.

Assumptions

  • User is accessing Web content on hardware / OS / AT combination that supports their needs. This may not always be true for shared device / public kiosk situations, but that issue is out of scope.

Applicability of Needs

  • Content
  • Controls (buttons, fields, etc.)
  • Input indicators (mouse, keyboard cursors)
  • Signals (non-actionable state indicators)
  • Alerts (dialogs, alarms, etc.)

Functional Needs

Safety

Use without physical harm or risk (to self or others within a physical environment)

Sensory

Vision and Visual

Use without vision
Use as blind (born without vision)
Use with blindness (acquired blindness during lifetime)
Use with limited vision
Use with limited central vision
Use with limited peripheral vision
Use with limited interocular acuity or monocular input
Use without color perception
Use with limited color perception
Use with limited depth perception
Use with limited orientation or spatial tracking
Use with photosensitivity (too much or too little)

Hearing and Auditory

Use without hearing
Use as Deaf (born with congenital deafness and/or to a deaf family)
Use as deaf (acquired deafness during lifetime after a language was learned)
Use with limited hearing
Use with limited auditory processing (speech)
Use with sensorineural hearing loss (limited frequency range) related to age or Presbycusis (gradual loss over time)

Sensory Intersections

Use without vision and hearing
Use without vision from birth then without hearing as acquired
 
Use without hearing from birth then without vision as acquired
 
Use with vestibular issues
Use without spatial auditory awareness or perception (needs diegetic sound)

Physical

Mobility

Use without mobility
Use with limited mobility
Use with limited ambulation
Use with temporary or partial paralysis
Use with limited reach or range

Motor

Use without hands
Use without multiple touchpoint gesture
Use with limited strength
Use without fine point control
Use without physical tracking speed
Use with tremors

Physical and Sensory Intersections

Use with limited kinaesthetic perception (orientation, position, weight distribution, movement)
Use with limited tactile perception, sensory processing, or touch pressure sensitivity
Use with chronic pain impacting input or interaction modality, speed and/or frequency
Use without vision and a motor disability
Use without hearing and a motor disability

Speech

Use without vocalization
Use with limited vocalization or volume

Cognitive

Attention

Use with limited ability to focus attention
 
Use with limited ability to direct attention
Use with limited ability to shift attention
 

Language and Communication

Use with limited ability to comprehend spoken language 
Use without ability to read 
Use with limited ability to recognize written language
Use with limited ability to comprehend written language 
Use without ability to write 
Use with limited ability to correctly write (or type) words and use punctuation
Use without understanding symbols
Use without understanding metaphors, idioms, euphemisms, or specific dialect of culture or location

Learning

Use with limited understanding of math and numeric concepts
Use with limited compositional skill (simultaneous thinking and input)
Use with limited coordination skill (motoric skills, visual-spatial organizational memory, and social)

Memory

Use with limited short-term or working memory 
Use with limited medium or long-term memory
Use with limited sensory memory
Visual
Visual-spatial
Auditory

Executive

Use with limited planning, organization, sequencing, and execution ability
Use with limited emotional control and self monitoring
Use with limited judgment

Mental Health

Use with debilitating sensitivity to negative emotional stimuli

Cognitive and Sensory Intersections

Use with interocular transfer of visual memory (retrieval based on limited acuity in a single eye)
Use with limited phonological or phonemic awareness

Independence

Independence

Use without autonomy or agency
Use without privacy

The purpose of identifying independence as a functional need is for individuals where independence cannot be achieved. Example: a person who has suffered a stroke, is conscious and aware but otherwise incapable of interacting with technology may need to log into a system or record a decision or authorize an agent to record a decision in their presence. In this case, they lack autonomy and privacy, but a method could be provided to verify the individual consent and the agent authority.

User Needs

Perceivable

Provide consistent content 

(static / fixed)

Users can perceive
Content 
Controls

(roles, states and properties)

Structure
Purpose
Input Values

Reveal changed content

Users can perceive changes to
Content
Controls

(roles, states and properties)

Purpose
Input Values

Operable

Provide consistent interactions

Users can operate
Content
Controls

(roles, states and properties)

Navigation
Users can navigate
Structure

(document and application)

Allow adjustable content

Users can adjust
Duration requirements
Content orientation
Orientation in space

Understandable

Make appearance understandable

Users can understand
Content
Controls
Structure
Navigation
Changed content
Purpose
Relationships

Provide help and instructions

Users get instructions for
Content
Interaction
Support for modalities
Personalization options
Processes
Users get help through
Moderated (form) input
Alert awareness

Make position and orientation clear

Users can identify their position in
Content
Context
A process
A space
Users can orientate themselves in
Immersive environments
Augmented environments

Make discoverable

Users can discover
Content
Context
Customization options

Personalization

Customization

Users can customize or request
Content
Context
Functionality / settings
Users get customized (via platform)
Content
Context
Functionality
Users can control
Time-sensitive content
Time-sensitive tasks
Time-based media

(including dynamic values, EQ, volume)

Preferences

Users personalization preferences
Are allowed
Are honored by content authors
Are not compromised by security
Do not compromise privacy
Users can, device independently
Interact
Input data
Route and control output

Deceptive Patterns

Distractions and Interruptions

Users attention can be
Focussed
Directed
Shifted

No Harm

Users are not harmed
Neurologically
Emotionally

Meeting User Needs

This is a preliminary draft to document how user needs are met in various ways.

For each [=expected outcome=], ways to meet it are proposed for:

Other categories may be included later. Many user needs can be met in more than one way. The mechanism to meet user needs in one of the above areas may require support from one or more of the other areas.

Ways to Meet User Needs

User needs need to be analyzed for how they can be met. The following ways of meeting needs are currently understood:

Author Implementation

User Agent Features

Accessibility Support in Mainstream User Agents
Assistive Technology
Accessibility APIs

Meeting User Needs Table

This version of the resource is primarily to show the structure, not yet a comprehensive documentation of how user needs can be met.

The table below shows how two of the user needs identified above might be met by technology features, author implementation, and user agent support. Each row of the table shows a related set of approaches, in which the approach in column depends on successful implementation of the approaches in the other columns for that row. For instance, many author features depend on support from the technology as well as exposure from the user agents. Some approaches to meeting user needs do not require support from others, which is reflected by rows with blank columns. For instance, it is possible for a user agent to meet certain needs with no particular support provided by the technology or author. This layout is preliminary and a more expressive layout is sought.

User Need Technology Content Author User Agent
Text Alternatives Provide a mechanism for author to create text alternatives and associate with content Create text alternative content and associate with primary content using features of the content technology Expose text alternatives provided by the author
Define parseable and semantically rich content encoding that supports automated creation of text alternatives Encode content using a content technology that is sufficiently rich that machines can create useful automated text alternatives Create automated text alternative content based on the semantics of the primary content
Color Contrast Provide color definition features that allow authors to set colors to meet requirements Use only colors that meet luminosity contrast guidelines
Provide color definition features that allow users to override author-set colors Provide a feature for users to override author colors
Provide color definition semantics that allow colors of common object types to be globally remapped easily Use semantically defined color mappings to allow user global preferences to be easily applied Support semantically defined color mappings to allow users to define global preferences that are easily applied across a range of content
Provide a feature to allow users to define their own color preferences
Provide a feature to allow users to request "high contrast" mode
Provide a "high contrast" mode that overrides author colors

Framework for Accessible Specification of Technologies

The content below is initial draft content intended to show how guidelines aimed at web technology developers might look. It has not yet been related to the user needs and ways of meeting them outlined above. It serves as initial brainstorming to help demonstrate viability of this set of guidelines.

This section needs to be updated to reflect the functional and user needs matrix.

Acknowledgments

The following people contributed to the development of this document.

Participants active in the development of this document

  1. Jake Abma (Invited Expert)
  2. Joshue O Connor (Invited Expert)
  3. Michael Cooper (W3C/MIT)
  4. Charles Hall (Invited Expert)
  5. Todd Libby (Invited Expert)