1.1 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.

Web Technology Accessibility Guidelines 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 WTAG 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.

1.2 Audience

The primary audience of WTAG 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 WTAG.

Secondary audience include creators of higher level accessibility guidelines and other advocates for web accessibility features. Because WTAG 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.

1.3 Scope

Web Technology Accessibility Guidelines 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 WTAG will necessarily overlap and hopefully be compatible with similar guidelines addressing non-web space. Nonetheless, WTAG 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 WTAG.

In spite of these caveats about the scope of WTAG, 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. WTAG will need to reflect this evolution, and future versions may be required to address user needs that are new to the Web.

1.4 Approach

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

• Inventory user needs;
• Identify ways to meet needs;
• Develop technology guidelines.

1.5 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.

3.1 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 design
• Author technical implementation
• User agent accessibility support of standard features
• User agent support of author-implemented accessibility features
• Assistive technology support (including accessibility API mediation)

3.2 Meeting User Needs Table

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.

4.1 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.

4.2 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.

4.3 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.

4.4 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.

4.5 User Control

4.6 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.

4.7 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.

4.8 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.

4.9 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?

4.10 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.

4.11 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.