This is a scratch pad to develop Web Technology Accessibility Guidelines, a set of recommendations for the features technical specifications should provide to enable accessibility.

Status

The current draft has been produced by Michael Cooper. It includes general thoughts and a walk-through of WCAG 2.0. It still needs additional content from a walk-through of ATAG 2.0, UAAG 2.0, the JTC-1 User Needs document, and possibly other sources. It also needs to be expanded for applicability to a variety of technologies, from content technologies (the current primary focus) to APIs, protocols, meta-languages, delta technologies, etc. This may result in a variety of conformance or applicability classes.

Draft guidelines are listed as bullet points within a preliminary overall categorization. Organization of this document and specific guidelines are likely to evolve significantly.

Relationship to other documents

@@Explain why we need a separate spec guidelines when we have a bunch of other ones. The accessibility requirements ultimately are the same, but this document explains how technologies can create features that will allow authors or implementers to follow the other guidelines.

• WCAG 2.0
• UAAG 2.0
• ATAG 2.0
• WAI-ARIA 1.0
• JTC 1 User Needs

Introduction

User Needs

@@The document should have an introduction to how user needs of people with disabilities differ from mainstream users. This should include references to authoritative sources, including among others the ISO JTC 1 SWG-A User Needs Summary, WCAG, UAAG, Media Accessibility User Requirements, Mobile Task Force. Ultimately, every guideline should be explicitly related to one or more user needs.

User Needs Analysis

Accessibility support in mainstream user agents

Assistive Technologies

@@The document should explain how people with disabilities use AT, how they differ from mainstream user agents, and special considerations they have for content.

Accessibility APIs

@@Because much accessibility is mediated via AAPIs, the document needs to provide an overview of how they work, the role of the mainstream user agent, and the role of the AT.

Alternative Content

• Provide a way to explicitly mark content as not needing alternative content because it does not perform an important role.
• Provide a way to explicitly indicate when author declined to provide alternative content.
• Provide a way to explicitly indicate that authoring tool is unable to generate or obtain alternative content.
• Provide a way to explicitly associate alternative content with the primary content.
• Allow multiple types and instances of alternative content to be associated with primary content.

Text Alternatives

• Provide a way to define short text alternatives / labels for non-text content.
• Provide a way to define long text alternatives for non-text content.
• Allow text alternatives to be semantically "rich" e.g., with page structure, text style, hyperlinks, etc.

Rich Alternatives

• Provide a way to define non-text alternatives for text content.
• Provide a way to define non-text alternatives for non-text content .

Color

• Allow users to override colors of text and user interface components.
• Provide a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually.
• Provide a feature for users to choose color schemata that work for them.
• Ensure that the foreground and background color of an object can be reported to the user via AT.
• Provide ways to set foreground and background colors separately for all objects.
• Define compositing rules for foreground and background colors well.
• @@similar for patterns, gradients, etc.

Device Independence

• Define a conformance model sufficiently robust that implementations of all types can process content without variations due to different handling of conformance violations.

Universal meaning support

• Provide declarative mechanisms (that have accessibility semantics pre-defined in the spec) to implement technology features whenever possible.
• Define unambiguous ways to express relationships between units of content, such as object nesting, ID referencing, etc.
• Prefer structural semantics to presentational semantics.
• When providing presentational semantics, define ways they can be easily mapped to structural semantics, e.g., to support restyling or meaningful exposure to AAPIs.
• Minimize the need for alternative content by supporting a comprehensive set of authoring use cases. (e.g., don't make authors resort to text in images to get the style they want)

Compatibility with AAPIs

• For every user interface object type, define the "type" of object as a role to AAPIs.
• For every user interface object type, define how authors provide or user agent determines the "accessible name" for AAPIs.
• For user interface objects that can have states, properties, or values, define how authors can set these and how these are exposed to AAPIs.
• When providing imperative mechanisms to implement technology features (e.g., scripts), provide a way for authors to expose accessibility information to AAPIs.
• Provide a way to title Web pages and sections of content.
• Provide a way to clearly indicate the target of a hyperlink and function of a control.
• Provide a way to indicate content language, for the page as a whole and for blocks of content.
• Provide a way for authors to support understanding of abbreviations / acronyms / initialisms, idioms, jargon, etc.
• Provide a mechanism to support correct machine pronunciation of ambiguously spelled terms (e.g., in the phrase "I am content with this content" there are different correct pronunciations of the lexeme "content").

Hardware Interfaces

• Abstract hardware interfaces so various device types can simulate each others' functions.
• Always provide a keyboard interface to interact with content.

User Customization

• Provide ways for display of content to be resized without loss of effective layout.
• Define adaptive layout mechanisms that optimize for different display conditions (screen size, font size, lighting, noise, etc.) well.
• Separate layout semantics from content so users or tools can easily create alternate layouts.
• Provide ways for users to easily select font preferences (size, weight, family, specific typeface, etc.).
• Provide mechanisms for users to easily apply custom display requirements that preserve presentation of meaning without knowledge the idiosyncratic implementation of content.

User Control

Blinking / Flashing

• Define a mechanism to warn users of flashing content.
• Define a mechanism to identify potentially flashing content to user agents so they can suppress it on user preference.
• Define declarative mechanisms for features that could cause blinking or flashing so their parameters can be more easily controlled by user agents than imperative mechanisms.

Automatic actions

• Provide a way for users to prevent time-based content from playing automatically, e.g., as a user agent preference that implementations must provide.
• Provide a way for users to request no interruptions. Note, bona fide emergency interruptions should still be allowed.
• Define that there will be not automatic action leading to a change of context when focus lands on a given element.

Time-based content

• Provide a way for users to pause and stop time-based content.
• Provide a way for users to start or restart time-based content.

Focus

• Any object that can respond to user interaction must be capable of receiving keyboard focus and actuating from keyboard input.
• Common objects defined by the technology should be specified to be focusable by default.
• Provide a means for authors to make objects focusable explicitly.
• Define a complete focus movement model including cycling past the end, recovering from unexpectedly lost focus, etc. so they keyboard focus is always somewhere meaningful and findable.
• Provide sensory and programmatic indication of focus location at all times.
• If allowing authors to restyle focus indicators, provide a mechanism for users to override, particularly to "unhide" focus indicators.

Audiovisual Content

• Provide a mechanism to associate synchronized text tracks with audio or visual tracks (to support captions, subtitles).
• Provide support for at least two audio tracks so volume of foreground and background audio can be set separately.

Extensibility

• When providing extension mechanisms, ensure the tools exist to allow developers to provide the same level of accessibility in extensions that are possible in the root technology. This may involve exposing API methods or other properties that would otherwise not be needed.
• Allow extensions to intersect so accessibility features in one extension can automatically work in others.

Alternate view modalities

• Provide ways for linear (1-dimensional) presentations of content to presented in a different subjective order than graphical (2-dimensional) presentations.
• Provide ways for focus order to adapt to presentation order in order to remain meaningful.
• @@support for haptic and other modalities?

Timing

• Do not create time limitations on user interaction (e.g., actuate a default behavior if the user does not respond within a set window) unless such limitations are intrinsic to the functionality.
• When creating time limitations on user interaction, provide mechanisms for users to be informed in advance of those limitations.
• When creating time limitations on user interaction, provide a way for users to request additional time.
• Provide an interface between content and servers so users can be informed of and request changes to time limitations of the server.

User input

• Provide ways to indicate if user input controls must have input ("required") or not accepting input ("disabled").
• Provide a way to associate information about input validation errors with the specific control(s) with input problems.
• Provide a way for authors to provide context-sensitive help to users, and for users to access this via standard user agent features.