Guidance on Applying WCAG 2.2 to Non-Web Information and Communications Technologies (WCAG2ICT)

Abstract

This document, “Guidance on Applying WCAG 2.2 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) 2.2 [WCAG22] and its principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).

This document is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the WCAG2ICT Overview.

This document is an update to a W3C Working Group Note to incorporate new guidelines, success criteria, and definitions added in WCAG 2.1 and 2.2.

Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT), approved in September 2013, described how WCAG 2.0 could be applied to non-web documents and software. WCAG2ICT was organized to mirror WCAG's sections: Perceivable, Operable, Understandable, and Robust. WCAG2ICT clarified when and how WCAG success criteria should be applied to non-web documents and software. Some were applicable without modification and some were applicable with edits and/or notes. Glossary terms were also reviewed. Level AAA Success Criteria were not addressed in the 2013 WCAG2ICT Working Group Note.

The 2013 WCAG2ICT has been relied upon in regulations and legislation. One example is EN 301 549[^1] (Europe) and other standards that reference or incorporate EN 301 549 (e.g., India, Kenya, Australia). Another example is Section 508 (U.S.) Application of WCAG 2.0 to Non-Web ICT, which looked to WCAG2ICT for detailed direction with providing specific guidance and exceptions to particular criteria from being applied to non-web technology. Section 508 incorporated by reference WCAG as the Accessibility Standard applicable to non-web documents and requires WCAG Conformance for non-web software.

[^1]: EN 301 549 V3.2.1 2.2 Informative references, p. 13 [i26].

Editor's note

This section contains a first pass of updates. It will be re-examined once the Task Force has finished analyzing all of the new WCAG criteria to ensure the summarization of applicability of WCAG criteria to non-web documents and software is accurate.

This document provides informative guidance (guidance that is not normative and that does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) 2.2 [WCAG22] to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.1 and WCAG 2.2, which are W3C Recommendations). Specifically, this document provides informative guidance on applying WCAG 2.2 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.

This document is intended to help clarify how to use WCAG 2.2 to make non-web documents and software more accessible to people with disabilities. Addressing accessibility involves addressing the needs of people with auditory, cognitive, neurological, physical, speech, and visual disabilities, and the needs of people with accessibility requirements due to the effects of aging. Although this document covers a wide range of issues, it is not able to address all the needs of all people with disabilities. Because WCAG 2.2 was developed for the Web, addressing accessibility for non-web documents and software may involve requirements and considerations beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-web documents and software are accessible, as much as possible, to people with disabilities.

While WCAG 2.2 was designed to be technology-neutral, it assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Therefore, the application of WCAG 2.2 to documents and software in non-web contexts required some interpretation in order to determine how the intent of each WCAG 2.2 success criterion could be met in these different contexts of use. Therefore, the bulk of the Task Force's work involved evaluating how each WCAG 2.2 success criterion would apply in the context of non-web ICT, if it were applied to non-web ICT.

The Task Force found that the majority of success criteria from WCAG 2.2 can apply to non-web documents and software with either no or minimal changes. Since many of the Level A and AA success criteria do not include any web related terms, they apply directly as written and as described in the “Intent” sections from the Understanding WCAG 2.2 [UNDERSTANDING-WCAG22] resource. Additional notes were provided, as needed, to provide assistance in applying them to non-web documents and software.

When certain Web-specific terms or phrases like “web page(s)” were used in success criteria, those were replaced with non-web terms or phrases like “non-web document(s) and software”. Additional notes were also provided to explain the terminology replacements.

A small number of success criteria are written to apply to “a set of web pages” or “multiple web pages” and require all pages in the set to share some characteristic or behavior. Since the unit of conformance in WCAG 2.2 is a single web page, the task force agreed that the equivalent unit of conformance for non-web documents is a single document. It follows that an equivalent unit of evaluation for a “set of web pages” would be a ”set of documents”. Since it isn't possible to unambiguously carve up non-web software into discrete pieces, a single “web page” was equated to a “software program” and a “set of web pages” was equated to a “set of software programs. Both of these new terms are defined in the Key Terms section of this document. See “set of documents” and “set of software programs” to determine when a group of documents or pieces of software are considered a set.

Note

Sets of software that meet this definition appear to be extremely rare.

The glossary terms were also reviewed and most of them applied to non-Web documents and software, as written. Some applied with additional notes or edits (largely related to phrases like “Web page(s)”), and a small number of terms were only used in Level AAA success criteria which are not addressed by the WCAG2ICT Note at this time.

The following are out of scope for this document:

This document does not seek to determine which WCAG 2.2 provisions (principles, guidelines, or success criteria) should or should not apply to non-web documents and software, but rather how they would apply, if applied.
This document does not propose changes to WCAG 2.2 or its supporting documents; it does not include interpretations for implementing WCAG 2.2 in web technologies. During the development of this document, the WCAG2ICT Task Force did seek clarification on the intent of a number of the success criteria, which led to clarifications in the Understanding WCAG 2.2 document.
This document is not sufficient by itself to ensure accessibility in non-web documents and software. As a web standard, WCAG does not fully cover all accessibility requirements for non-user interface aspects of platforms, user-interface components as individual items, nor closed product software (where there is no Assistive Technology to communicate programmatic information).
This document does not comment on hardware aspects of products, because the basic constructs on which WCAG 2.2 is built do not apply to these.
This document does not provide supporting techniques for implementing WCAG 2.2 in non-web documents and software.
This document is purely an informative Note about non-web ICT, not a standard, so it does not describe how non-web ICT should conform to it.

This document includes text quoted from the WCAG 2.2 principles, guidelines, and success criteria, without any changes. It also includes excerpted text from the “Intent” sections of the WCAG 2.2 supporting document Understanding WCAG 2.2 (Public Review Draft) [UNDERSTANDING-WCAG22]. The guidance provided by this document for each success criterion is preceded by a heading beginning with “Additional Guidance…”. This guidance was created by the WCAG2ICT Task Force, then reviewed and approved by the AG Working Group.

Additional supporting documents for WCAG 2.2, such as the WCAG 2 Overview, Techniques for WCAG 2.2 [WCAG22-TECHS], and How to Meet WCAG (Quick Reference), remain available for web content, but have not been changed to apply to non-web documents and software.

Editor's note

The visual styling and programmatic structure details for calling out content in this section will be updated once the details have been worked out.

The following stylistic conventions are used in this document:

Quotes from WCAG 2.2 and Understanding WCAG 2.2 are in <blockquote> elements and visually styled in slightly smaller text with a gray bar on the left. They are prefaced by a reference to the original source such as “From {reference title} in {document}”.
Additional guidance provided by this document begins with the phrase “Guidance When Applying” and has no special visual styling.
Replacement text that is presented to show how an SC would read as modified by the advice in this document are in <ins> elements visually styled as bold green text.
Notes are slightly inset and begin with the phrase “NOTE”. Each note is in its own inset box styled in pale green with a darker green line on the left side of the box.
References to glossary items from WCAG 2.2 are presented in <cite> elements visually styled as ordinary text with a dotted underline, and contain title attributes noting these are WCAG definitions. They turn blue with a yellow background when mouse or keyboard focus is placed over them.
References to glossary items in this document are presented in <cite> elements visually styled as ordinary text with a dashed underline, and contain title attributes noting these are Task Force definitions. They turn green with a yellow background when mouse or keyboard focus is placed over them. Note that some terms defined in WCAG 2.2 are redefined in WCAG2ICT and links are updated accordingly (except in direct quotes).
Hereafter, the short title “WCAG2ICT” is used to reference this document.

Editor's note

The WCAG2CIT Task Force has begun incorporating new WCAG 2.1 content. This section will be updated as we incorporate new Guidelines, new and changed Success Criteria and term definitions, as well as make updates to other major sections of the document. This will help readers to focus reviews to sections that are ready.

The following changes and additions have been made to update the 2013 WCAG2ICT document:

New Background section to explain the history and known uses of WCAG2ICT
New WCAG 2.1 Success Criteria and Guidelines
New terms
- process, state, status message were added to Glossary Items that Apply to All Technologies
- motion animation, region, and user inactivity were added to Glossary Items Used only in AAA Success Criteria
- down-event
- keyboard shortcut
- up-event
Updated sections
Note
This will eventually list sections with major updates that are ready for review.

There are two key glossary terms from WCAG 2.2 that need to be interpreted significantly differently when applied to non-web ICT. These are: “content” and “user agent”. In addition, the glossary term “Web page” in WCAG 2.2 is replaced with newly defined terms “document” and “software”, and both “set of web pages” and “multiple web pages” are replaced with the newly defined terms “set of documents” and “set of software programs”. Finally, since non-Web software doesn't leverage the WCAG 2.2 notion of a user agent, we introduced the new term “accessibility services of platform software”. The remaining glossary terms from WCAG 2.2 are addressed in Chapter 7 Comments on Definitions in WCAG 2.2 Glossary. Terms defined and used in WCAG2ICT are applicable only to the interpretation of the guidance in this document. The particular definitions should not be interpreted as having applicability to situations beyond the scope of WCAG2ICT. Further information on usage of these terms follows.

The term accessibility services of platform software, as used in WCAG2ICT, has the meaning below:

accessibility services of platform software (as used in WCAG2ICT): services provided by an operating system, user agent, or other platform software that enable non-web documents or software to expose information about the user interface and events to assistive technologies and accessibility features of software

Note

These services are commonly provided in the form of accessibility APIs (application programming interfaces), and they provide two-way communication with assistive technologies, including exposing information about objects and events.

WCAG 2.2 defines content as:

information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions

For non-web content it is necessary to view this a bit more broadly. Within WCAG2ICT, the term “content” is used as follows:

content (non-web content) (as used in WCAG2ICT): information and sensory experience to be communicated to the user by means of [software], including code or markup that defines the content's structure, presentation, and interactions

Note

[Non-web content occurs in two places; documents and software. When content occurs in a document, a user agent is needed in order to communicate the content's information and sensory experience to the user. When content occurs in software, a separate user agent isn't required—the software itself performs that function.]

Within WCAG2ICT wherever “content” or “web content” appears in a success criterion it is replaced with “content” using the definition above.

The term document, as used in WCAG2ICT, has the meaning below:

document (as used in WCAG2ICT): assembly of content, such as a file, set of files, or streamed media that functions as a single item rather than a collection, that is not part of software and that does not include its own user agent

Note

A document always requires a user agent to present its content to the user.

Note

Letters, spreadsheets, emails, books, pictures, presentations, and movies are examples of documents.

Note

Software configuration and storage files such as databases and virus definitions, as well as computer instruction files such as source code, batch/script files, and firmware, are examples of files that function as part of software and thus are not examples of documents. If and where software retrieves “information and sensory experience to be communicated to the user” from such files, it is just another part of the content that occurs in software and is covered by WCAG2ICT like any other parts of the software. Where such files contain one or more embedded documents, the embedded documents remain documents under this definition.

Note

A collection of files zipped together into an archive, stored within a single virtual hard drive file, or stored in a single "encrypted file system" file, do not constitute a single document. The software that archives/encrypts those files or manages the contents of the virtual hard drive does not function as a user agent for the individually collected files in that collection because that software is not providing a non-fully functioning presentation of that content.

Note

Anything that can present its own content without involving a user agent, such as a self playing book, is not a document but is software.

Note

A single document may be composed of multiple files such as the video content, closed caption text, etc. This fact is not usually apparent to the end-user consuming the document / content. This is similar to how a single web page can be composed of content from multiple URIs (e.g. the page text, images, the JavaScript, a CSS file etc.).

Example: An assembly of files that represented the video, audio, captions and timing files for a movie would be a document.

Counterexample: A binder file used to bind together the various exhibits for a legal case would not be a document.

The term set of documents, as used in WCAG2ICT, has the meaning below:

set of documents (non-web) (as used in WCAG2ICT): group of documents that are published together, and where the items all refer to each other by name or link

Note

Republishing or bundling previously published documents as a collection does not constitute a set of documents.

Note

If a set is broken apart, the individual parts are no longer part of a set, and would be evaluated as any other individual document is evaluated.

Example: One example of a set of documents would be a three-part report where each part is a separate file. The table of contents is repeated at the beginning of each file to enable navigation to the other parts.

The term set of software programs, as used in WCAG2ICT, has the meaning below:

set of software programs (as used in WCAG2ICT): group of software programs that are distributed together and that can be launched and used independently from each other, but that are interlinked each with every other one such that users can navigate from one program to another via a consistent method that appears in each member of the set

Note

This definition of “set of software programs” is derived from the characteristics of a “set” of web pages, and is used for mapping WCAG success criteria to software. Although such sets occur frequently for web pages, such sets appear to be extremely rare for software.

Note

Redistributing or bundling previously distributed software as a collection does not constitute a set of software programs.

Note

Consistent does not mean identical. For example, if a list of choices is provided it might not include the name of the current program.

Note

If a member of the set is separated from the set, it is no longer part of a set, and would be evaluated as any other individual software program.

Note

Any software program that is not part of a set, per this definition, would automatically satisfy any success criterion that is specified to apply to “sets of” software (as is true for any success criterion that is scoped to only apply to some other type of content).

Note

If there is any ambiguity whether the group is a set, then the group is not a set.

Note

If there is no independent method to launch the software programs (as is common in closed products), those programs would not meet the definition of a "set of software programs".

Note

Although the term “software” is used throughout this document because this would apply to stand alone software programs as well as individual software components and the software components in software-hardware combinations, the concept of “set of software programs” would only apply (by definition) to programs that can be launched separately from each other. Therefore, for the provisions that use the phrase “set of” (success criteria 2.4.1, 2.4.5, 3.2.3, and 3.2.4), the phrase “set of software programs” is used.

Example: One example of a set of software programs would be a group of programs that can be launched and used separately but are distributed together and all have a menu that allows users to launch, or switch to, each of the other programs in the group.

Counterexamples: Examples of things that are not sets of software programs:

A suite of programs for authoring different types of documents (text, spreadsheets, presentations, etc.) where the programs don't provide an explicit, consistent means to launch, or switch to, each of the other programs in the group.
An office package consisting of multiple programs that launches as a single program that provides multiple functionalities such as writing, spreadsheet, etc., but the only way to navigate between programs is to open a document in one of the programs.
A bundle of software programs that is sold together but the only way to navigate between the programs in the bundle is to use a platform software level menu to navigate between them (and not via a menu provided by each program that allows you to navigate to just the other programs in this bundle).
A group of programs that was a set, but the programs have been moved to separate locations so that their “set” behaviors were disrupted and no longer work. Even though they were a set at one time, because they are no longer installed as a set they no longer are a set and would not need to meet any success criteria that apply to sets of software.

The term software as used in WCAG2ICT, has the meaning below:

software (as used in WCAG2ICT): software products or software aspects of hardware-software products that have a user interface and do not require a separate user agent to present any of its content

Note

For software, the user interface and any other embedded content is covered by these guidelines. The software provides a function equivalent to a user agent for the embedded content.

Note

Software without a user interface does not have content and is not covered by these guidelines. For example, driver software with no user interface would not be covered.

Note

Because software with a user interface provides a function equivalent to a user agent in addition to content, the application of some WCAG 2.2 success criteria would be different for content embedded in software versus content in a document, where it is viewed through a separate user agent (e.g. browser, player, viewer, etc.).

WCAG 2.2 defines user agent as:

user agent

any software that retrieves and presents Web content for users

Example: Web browsers, media players, plug-ins, and other programs—including assistive technologies—that help in retrieving, rendering, and interacting with Web content.

For non-web ICT, “user agent” needs to be viewed differently. In WCAG 2.2, the term “user agent” only refers to retrieval and display of web content. For non-web ICT, the term “user agent” refers to retrieval and display of separate content that is not on the Web, which WCAG2ICT refers to as a “document”. Within WCAG2ICT, the term “user agent” is used as follows:

user agent (as used in WCAG2ICT): any software that retrieves and presents documents for users

Note

Software that only displays the content contained within it is not considered to be a user agent. It is just considered to be software.

Note

An example of software that is not a user agent is a calculator application that doesn't retrieve the calculations from outside the software to present it to a user. In this case, the calculator software is not a user agent, it is simply software with a user interface.

Note

Software that only shows a preview of content such as a thumbnail or other non-fully functioning presentation is not providing user agent functionality.

The sections that follow are organized according to the principles, guidelines, and success criteria from WCAG 2.2. The text of each item from WCAG 2.2 is copied as quoted text. Following that, the WCAG2ICT guidance is provided. Finally, the “Intent” from Understanding WCAG 2.2 is copied as quoted text; the Task Force makes no substitutions or edits in this text. In visual presentations, the WCAG2ICT guidance is set out in a box with a blue bar to the left, to highlight that this is the content specific to this document.

In WCAG 2.2, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 1 applies directly as written.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.1 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.1.1 (also provided below).

Note

CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.

Note

See also the discussion on Closed Functionality.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.2 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.1 (also provided below).

Note

The alternative can be provided directly in the non-web document or software – or provided in an alternate version that meets the success criteria.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.2 (also provided below).

Note

The WCAG 2.2 definition of “captions” notes that “in some countries, captions are called subtitles”. They are also sometimes referred to as “subtitles for the hearing impaired.” Per the definition in WCAG 2.2, to meet this success criterion, whether called captions or subtitles, they would have to provide “synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content” where non-speech information includes “sound effects, music, laughter, speaker identification and location”.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.3 (also provided below).

Note

The WCAG 2.2 definition of “audio description” says that “audio description” is “also called ‘video description’ and ‘descriptive narration’”.

Note

Secondary or alternate audio tracks are commonly used for this purpose.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.4 (also provided below).

Note

The WCAG 2.2 definition of “captions” notes that “In some countries, captions are called subtitles”. They are also sometimes referred to as “subtitles for the hearing impaired.” Per the definition in WCAG 2.2, to meet this success criterion, whether called captions or subtitles, they would have to provide “synchronized visual and / or text alternative for both speech and non-speech audio information needed to understand the media content” where non-speech information includes “sound effects, music, laughter, speaker identification and location”.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.5 (also provided below).

Note

The WCAG 2.2 definition of “audio description” says that audio description is “also called ‘video description’ and ‘descriptive narration’”.

Note

Secondary or alternate audio tracks are commonly used for this purpose.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.3 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.1 (also provided below).

Note

In software, programmatic determinability is best achieved through the use of accessibility services provided by platform software to enable interoperability between software and assistive technologies and accessibility features of software.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.2 (also provided below).

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.3 (also provided below).

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4 (also provided below).

Note

Content that is only used on hardware with a fixed display orientation OR that has no sensor to detect or change the orientation is covered under the essential exception and not required to provide support for orientation changes.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.5 (also provided below).

Note

Non-web software and non-web documents technologies that do not provide attributes that support identifying the expected meaning for the form input data are not in scope for this success criterion.

Note

For non-web software and non-web documents that present input fields, the terms for the input purposes would be the equivalent terms to those listed in the WCAG 2.2 section Input Purposes for User Interface Components that are supported by the technology used.

Note

See also the discussion on Closed Functionality.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 1.4 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.1 (also provided below).

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.2 (also provided below), replacing “on a Web page” with “in a non-web document or software”, “any content” with “any part of a non-web document or software”, “whole page” with “whole document or software”, “on the Web page” with “in the document or software”, and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

1.4.2 Audio Control: If any audio [in a non-web document or software] plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

Note

Since any [part of a non-web document or software] that does not meet this success criterion can interfere with a user's ability to use the [whole document or software], all content [in the document or software] (whether or not it is used to meet other success criteria) must meet this success criterion.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.3 (also provided below).

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.4 (also provided below).

Note

Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom.

Note

The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.5 (also provided below).

Note

See also the discussion on Closed Functionality.

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.11 (also provided below), replacing "user agent" with "user agent or platform software".

With these substitutions, it would read:

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the [user agent or platform software] and not modified by the author;

Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Note

An example of appearance modification by the author is content that sets the visual style of a control, such as a color or border, to differ from the default style for the user agent or platform.

Note

See also the discussion on Closed Functionality.

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 (also provided below) replacing "In content implemented using markup languages" with "For non-web documents or software content implemented using markup languages" and replacing "that support " with "in a way that supports modification of".

With these substitutions, it would read:

[For non-web documents or software] content implemented using markup languages [in a way that supports modification of] the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

Line height (line spacing) to at least 1.5 times the font size;

Spacing following paragraphs to at least 2 times the font size;

Letter spacing (tracking) to at least 0.12 times the font size;

Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Note

"Content implemented using markup languages" includes parts of software that use markup internally to define a user interface. Examples of markup languages that are used internally to define a software user interface include but are not limited to: HTML (e.g., in Electron applications or iOS application Web views), XAML, XML (e.g., in Android application layouts), and XUL.

Note

There are several mechanisms that allow users to modify text spacing properties of content implemented in markup languages. For example, an eBook technology may have an available user agent that allows users to override document text styles, or a software application may provide a "user style sheet" facility to modify the appearance of the software's own user interface. This Success Criterion does not require that documents and software implement their own mechanisms to allow users to set text spacing; however, when such a mechanism is available, the Success Criterion requires that content respond appropriately to it.

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.13 (also provided below), replacing "user agent" with "user agent or platform software", "browser tooltips" with "tooltips", and "the HTML title attribute" with "user interface object attributes".

With these substitutions, it would read:

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

Dismissible A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

Hoverable If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

Persistent The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the [user agent or platform software] and is not modified by the author.

Note

Examples of additional content controlled by the [user agent or platform software] include [tooltips] created through use of [user interface object attributes].

Note
Custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content covered by this criterion.

In WCAG 2.2, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 2 applies directly as written.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.1 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.1 (also provided below).

Note

This does not imply that software must directly support a keyboard or “keyboard interface”. Nor does it imply that software must provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.2 (also provided below), replacing “page” and “Web page” with “non-web document or software” and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the [non-web document or software] using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)

Note

Since any content that does not meet this success criterion can interfere with a user's ability to use the whole [non-web document or software], all content on the [non-web document or software] (whether it is used to meet other success criteria or not) must meet this success criterion.

Note

Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.4 (also provided below).

Note

The WCAG2ICT interpretation is that a long press of a key (2 seconds or more) and other accessibility features provided by the platform do not meet the WCAG definition of a keyboard shortcut. See the keyboard shortcut definition for more details.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.2 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.1 (also provided below), replacing “the content” with “non-web documents or software”.

With this substitution, it would read:

2.2.1 Timing Adjustable: For each time limit that is set by [non-web documents or software], at least one of the following is true: (Level A)

Turn off: The user is allowed to turn off the time limit before encountering it; or
Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or
Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
Essential Exception: The time limit is essential and extending it would invalidate the activity; or
20 Hour Exception: The time limit is longer than 20 hours.

Note

This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.2 (also provided below), replacing “page” and “Web page” with “non-web documents and software” and removing “See Conformance Requirement 5: Non-Interference” in Note 2 of the success criterion.

With this substitution, it would read:

2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)

Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

Note

For requirements related to flickering or flashing content, refer to Guideline 2.3.

Note

Since any content that does not meet this success criterion can interfere with a user's ability to use the whole [non-web documents and software], all content on the [non-web documents and software] (whether it is used to meet other success criteria or not) must meet this success criterion.

Note

Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

Note

An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

Note

While the success criteria uses the term “information”, the WCAG 2.2 Intent section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.3 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.1 (also provided below), replacing “Web pages” with “non-web documents or software” , “the whole page” with “the whole non-web document or software”, “the Web page” with “the non-web document or software”, and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

2.3.1 Three Flashes or Below Threshold: [Non-web documents or software] do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)

Note

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.4 applies directly as written.

This applies directly as written and described in Intent from Understanding Success Criterion 2.4.1 (also provided below), replacing “Web pages” with “non-web documents in a set of non-web documents” or “software programs in a set of software programs” to explicitly state that the multiple documents (or software programs) are part of a set rather than any two documents or pieces of software.

With these substitutions, this success criterion would read:

(for non-web documents)

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple [non-web documents in a set of non-web documents].

(for software programs)

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple [software programs in a set of software programs].

Note

See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.)

Note

Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

Note

Although not required by the success criterion, being able to bypass blocks of content that are repeated within non-web documents or software directly addresses user needs identified in the Intent section for this Success Criterion, and is generally considered best practice.

Note

Many software user interface components have built-in mechanisms to navigate directly to / among them, which also have the effect of skipping over or bypassing blocks of content.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.2 (also provided below) replacing “Web pages” with “non-web documents or software”.

With this substitution, it would read:

2.4.2 Page Titled: [Non-web documents or software] have titles that describe topic or purpose. (Level A)

Note

As described in the WCAG intent (also provided below), the name of a non-web software application or non-web document (e.g. document, media file, etc.) is a sufficient title if it describes the topic or purpose.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.3 (also provided below) replacing “a Web page” with “non-web documents or software”.

With this substitution, it would read:

2.4.3 Focus Order: If [non-web documents or software] can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)

This applies directly as written and as described in Intent from Understanding Success Criterion 2.4.4 (also provided below).

Note

In software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)

This applies directly as written and described in Intent from Understanding Success Criterion 2.4.5 (also provided below), replacing “Web page(s)” with “non-web document(s)” and “software program(s)”.

With these substitutions, this success criterion would read:

(for non-web documents)

2.4.5 Multiple Ways: More than one way is available to locate a [non-web document] within a set of [non-web documents] except where the [non-web document] is the result of, or a step in, a process.

(for software programs)

2.4.5 Multiple Ways: More than one way is available to locate a [software program] within a set of [software programs] except where the [software program] is the result of, or a step in, a process.

Note

See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.)

Note

The definitions of “set of documents” and “set of software programs” in the Key Terms section of the Introduction are predicated on the ability to navigate from each element of the set to each other, and navigation is a type of locating. So the mechanism used to navigate between elements of the set will be one way of locating information in the set. Non-web environments, generally major operating systems with browse and search capabilities, often provide infrastructure and tools that provide mechanisms for locating content in a set of non-web documents or a set of software programs. For example, it may be possible to browse through the files or programs that make up a set, or search within members of the set for the names of other members. A file directory would be the equivalent of a site map for documents in a set, and a search function in a file system would be equivalent to a web search function for web pages. Such facilities may provide additional ways of locating information in the set.

Note

An example of the use of “a software program that is part of process”, that would meet the exception for this Success Criterion, would be one where programs are interlinked but the interlinking depends on program A being used before program B, for validation or to initialize the dataset etc.

Note

While some users may find it useful to have multiple ways to locate some groups of user interface elements within a document or software program, this is not required by the success criterion (and may pose difficulties in some situations).

Note

The definitions of “set of documents” and “set of software programs” in WCAG2ICT require every item in the set to be independently reachable, and so nothing in such a set can be a “step in a process” that can't be reached any other way. The purpose of the exception—that items in a process are exempt from meeting this success criterion—is achieved by the definition of set.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.6 (also provided below).

Note

In software, headings and labels are used to describe sections of content and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.7 (also provided below).

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 2.5 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.1 (also provided below), making changes to the notes for non-web documents by replacing “web content” with "content" and for non-web software by replacing "web content" with "non-web software" and "user agent" with "underlying platform software".

With these substitutions, the notes would read:

(non-web documents)

Note

This requirement applies to [content] that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

Note

Multipoint and path-based gestures are less common in documents. An example where a document author could add such gestures is an interactive prototype document created in a software design tool.

(non-web software)

Note

This requirement applies to [non-web software] that interprets pointer actions (i.e. this does not apply to actions that are required to operate the [underlying platform software] or assistive technology).

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.2 (also provided below), making changes to the notes for non-web documents by replacing “web content” with "content" and for non-web software by replacing "web content" with "non-web software" and "user agent" with "underlying platform software".

With these substitutions, the notes would read:

(for non-web documents)

Note

Functions that emulate a keyboard or numeric keypad key press are considered essential.

Note

This requirement applies to [content] that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

Note

Content that interprets pointer actions and controls which events are used for executing functionality is less common in documents. An example where a document author could add such functionality is an interactive prototype document created in a software design tool.

(for non-web software)

Note

Functions that emulate a keyboard or numeric keypad key press are considered essential. [Examples of essential functionality for non-web software are features for meeting environmental energy usage requirements (like waking a device from sleep, power saver mode, and low power state).]

Note

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3 (also provided below).

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.4 (also provided below).

In WCAG 2.2, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 3 applies directly as written.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 3.1 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.1 (also provided below) replacing “each web page” with non-web documents or software.

With these substitutions, it would read:

3.1.1 Language of Page: The default human language of [non-web documents or software] can be programmatically determined. (Level A)

Note

Where software platforms provide a “locale / language” setting, applications that use that setting and render their interface in that “locale / language” would comply with this success criterion. Applications that do not use the platform “locale / language” setting but instead use an accessibility-supported method for exposing the human language of the software would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform “locale / language” setting may not be able to meet this success criterion in that locale / language.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.2 (also provided below) replacing “content” with “non-web document or software”.

With these substitutions, it would read:

3.1.2 Language of Parts: The human language of each passage or phrase in the [non-web document or software] can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)

Note

There are some software and non-web document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the non-web document or software, and it would not be possible to meet this success criterion with those technologies.

Note

See also the discussion on Closed Functionality.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 3.2 applies directly as written, replacing “web pages” with “non-web documents or software”.

With this substitution, this guideline would read:

Guideline 3.2 Predictable: Make [non-web documents or software] appear and operate in predictable ways.

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.1 (also provided below).

Note

Some compound documents and their user agents are designed to provide significantly different viewing and editing functionality depending upon what portion of the compound document is being interacted with (e.g. a presentation that contains an embedded spreadsheet, where the menus and toolbars of the user agent change depending upon whether the user is interacting with the presentation content, or the embedded spreadsheet content). If the user uses a mechanism other than putting focus on that portion of the compound document with which they mean to interact (e.g. by a menu choice or special keyboard gesture), any resulting change of context wouldn't be subject to this success criterion because it was not caused by a change of focus.

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.2 (also provided below).

This applies directly as written and described in Intent from Understanding Success Criterion 3.2.3 (also provided below), replacing “web pages” with “non-web documents” and “software programs”.

With these substitutions, this success criterion would read:

(for non-web documents)

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple [non-web documents] within a set of [non-web documents] occur in the same relative order each time they are repeated, unless a change is initiated by the user.

(for software programs)

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple [software programs] within a set of [software programs] occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Note

See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.)

Note

Although not required by this success criterion, ensuring that navigation elements have consistent order when repeated within non-web documents or software programs directly addresses user needs identified in the Intent section for this Success Criterion, and is generally considered best practice.

This applies directly as written and described in Intent from Understanding Success Criterion 3.2.4 (also provided below), replacing “web pages” with “non-web documents” and “software programs”.

With these substitutions, this success criterion would read:

(for non-web documents)

3.2.4 Consistent Identification: Components that have the same functionality within a set of [non-web documents] are identified consistently.

(for programs)

3.2.4 Consistent Identification: Components that have the same functionality within a set of [software programs] are identified consistently.

Note

Although not required by this success criterion, ensuring that component identification be consistent when they occur more than once within non-web documents or software programs directly addresses user needs identified in the Intent section for this Success Criterion, and is generally considered best practice.

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 3.3 applies directly as written.

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.1 (also provided below).

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.2 (also provided below).

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.3 (also provided below).

This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.4 (also provided below) replacing “web pages” with “non-web documents or software”.

With this substitution, it would read:

3.3.4 Error Prevention (Legal, Financial, Data): For [non-web documents or software] that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)

Reversible: Submissions are reversible.
Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

Editor's note

This section is to be developed by the WCAG2ICT Task Force.

In WCAG 2.2, the Principles are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Principle 4 applies directly as written replacing “user agents, including assistive technologies” with “assistive technologies and accessibility features of software”.

With this substitution, it would read:

Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of [assistive technologies and accessibility features of software].

In WCAG 2.2, the Guidelines are provided for framing and understanding the success criteria under them but are not required for conformance to WCAG. Guideline 4.1 applies directly as written, replacing “user agents, including assistive technologies” with “assistive technologies and accessibility features of software”.

With this substitution, it would read:

Guideline 4.1 Compatible: Maximize compatibility with current and future [assistive technologies and accessibility features of software].

This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.1 (also provided below), replacing “In content implemented using markup languages” with “For non-web documents or software that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent”.

With these substitutions, it would read:

4.1.1 Parsing: [For non-web documents or software that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent], elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

Note

Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

Note

Markup is not always available to assistive technologies or to user selectable user agents such as browsers. Software sometimes uses markup languages internally for persistence of the software user interface, in ways where the markup is never available to assistive technology (either directly or through a document object model (DOM)), or to a user agent (such as a browser). In such cases, conformance to this provision would have no impact on accessibility as it can have for web content where it is exposed.

Examples of markup that is separately exposed and available to assistive technologies and to user agents include: documents encoded in HTML, ODF, and OOXML. In these examples, the markup can be parsed entirely in two ways: (a) by assistive technologies which may directly open the document, (b) by assistive technologies using DOM APIs of user agents for these document formats.

Examples of markup used internally for persistence of the software user interface that are never exposed to assistive technology include but are not limited to: XUL, GladeXML, and FXML. In these examples assistive technology only interacts with the user interface of generated software.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.2 (also provided below), replacing the note with: “This success criterion is primarily for software developers who develop or use custom user interface components. For example, standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.”.

With this substitution, it would read:

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

Note

[This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.]

Note

For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services provided by platform software. These accessibility services enable interoperability between software user interfaces and both assistive technologies and accessibility features of software in standardized ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could or should be exposed and / or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions).

Note

For document formats that support interoperability with assistive technology, standard user interface components often meet this success criterion when used according to the general design and accessibility guidance for the document format.

Note

See also the discussion on Closed Functionality.

This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3 (also provided below) replacing "In content implemented using markup languages" with "In content implemented using markup languages, or that supports status message notifications".

With this substitution, it would read: In [content implemented using markup languages, or that supports status message notifications], status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Note

For non-web documents and software that are not implemented using markup languages, there is still a user need to have status messages be programmatically exposed so that they can be presented to the user by assistive technologies without receiving focus. This is typically enabled through the use of accessibility services of the user agent or platform software.

Note

See also the discussion on Closed Functionality.

The following is a complete list of definitions from the WCAG 2.2 glossary. Some items apply to all technologies and do not require additional guidance in this document; guidance on the remainder follows.

Editor's note

The new terms used only in Level AAA Success Criteria are now listed in the corresponding section below. When new Success Criteria from WCAG 2.1 and 2.2 get added to this document, any new terms and definitions they introduced will also be added to this document. Any definitions that existed in WCAG 2.0 that have changed since the 2013 WCAG2ICT will be updated soon.

The following glossary items apply to all technologies and do not require further interpretation for non-web Information and Communications Technologies.

abbreviation
alternative to time-based media
ASCII art
audio
audio description
audio-only
blinking
CAPTCHA
captions
correct reading sequence
emergency
essential
extended audio description
flash
functionality
human language
idiom
image of text
informative
jargon
large scale (text)
legal commitments
link purpose
live
lower secondary education level
mechanism
media alternative for text
navigated sequentially
non-text content
normative
on a full-screen window
paused
prerecorded
presentation
primary education level
process
programatically determined link context
pure decoration
real-time event
relationships
relied upon (technologies that are)
same relative order
sign language
sign language interpretation
single pointer
specific sensory experience
state
status message
synchronized media
text
text alternative
used in an unusual or restricted way
user-controllable
video
video-only
visually customized

This document does not provide guidance on applying AAA Success Criteria to non-web ICT, including the following definitions.

blocks of text
context-sensitive help
motion animation
region
section
supplemental content
user inactivity

Additional guidance is provided for the following glossary entries from WCAG 2.2 when applying them to non-web documents and software.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “browsers and other user agents” with “user agents or other software”, replacing “user agents” with “user agents or other software”, replacing “web content technology” with “non-web document or software technology”, adding “or other software extension” after “plug-in”, and replacing all five of the Notes with a single new Note: “Note: The concepts behind the five Notes and in Understanding Accessibility Supported are applicable to web technologies. The same or similar factors are applicable for non-web technologies.”

With these substitutions and addition, it would read:

accessibility supported

supported by users' assistive technologies as well as the accessibility features in [user agents or other software]

To qualify as an accessibility-supported use of a [non-web document or software] technology (or feature of a technology), both 1 and 2 must be satisfied for a [non-web document or software] technology (or feature):

The way that the [non-web document or software technology] is used must be supported by users' assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users' assistive technology in the human language(s) of the content,

AND
The [non-web document or software] technology must have accessibility-supported user agents [or other software] that are available to users. This means that at least one of the following four statements is true:
1. The technology is supported natively in widely-distributed user agents [or other software] that are also accessibility supported (such as HTML and CSS);
  
  OR
2. The technology is supported in a widely-distributed plug-in [or other software extension] that is also accessibility supported;
  
  OR
3. The content is available in a closed environment, such as a university or corporate network, where the user agent [or other software] required by the technology and used by the organization is also accessibility supported;
  
  OR
4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:
  - does not cost a person with a disability any more than a person without a disability and
  - is as easy to find and obtain for a person with a disability as it is for a person without disabilities.

Note

[The concepts behind the five Notes and in Understanding Accessibility Supported are applicable to web technologies. The same or similar factors are applicable for non-web technologies.]

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web page” with “non-web document or software”.

With this substitution, it would read:

ambiguous to users in general: the purpose cannot be determined from the link and all information of the [non-web document or software] presented to the user simultaneously with the link (i.e., readers without disabilities would not know what a link would do until they activated it)

Example: The word guava in the following sentence “One of the notable exports is guava” is a link. The link could lead to a definition of guava, a chart listing the quantity of guava exported or a photograph of people harvesting guava. Until the link is activated, all readers are unsure and the person with a disability is not at any disadvantage.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “acts as a user agent” with “acts stand-alone”, replacing “mainstream user agent[s]” with “mainstream information and communication technologies (ICT)” (later “mainstream ICT[s])”, and replacing “Web content” with “content”.

With these substitutions, it would read:

assistive technology (as used in this document)

hardware and/or software that acts [stand-alone], or along with [mainstream information and communication technologies (ICT)], to provide functionality to meet the requirements of users with disabilities that go beyond those offered by [mainstream ICT]

Note

Functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Note

Assistive technologies often communicate data and messages with [mainstream ICTs] by using and monitoring APIs.

Note

The distinction between [mainstream ICTs] and assistive technologies is not absolute. Many [mainstream ICTs] provide some features to assist individuals with disabilities. The basic difference is that [mainstream ICTs] target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The [mainstream ICT] may provide important functionality to assistive technologies like retrieving [content] from program objects or parsing markup into identifiable bundles.

Example: Assistive technologies that are important in the context of this document include the following:

screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
speech recognition software, which may be used by people who have some physical disabilities;
alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web page” and “page” with “non-web document or content presented by software”.

With this substitution, it would read:

changes of context

major changes in the content of the [non-web document or content presented by software] that, if made without user awareness, can disorient users who are not able to view the entire non-web document or content presented by software] simultaneously

Changes in context include changes of:

user agent;
viewport;
focus;
content that changes the meaning of the [non-web document or content presented by software].

Note

A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).

Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.

Note

A change in the user agent might include bringing up a new window, or might be a significant change in the menus and/or toolbars that are displayed and available for interacting with some portion of the document.

The guidance in this document does not use the term “conformance”.

See the section Comments on Conformance.

The guidance in this document does not use the term “conforming alternate version”.

See the section Comments on Conformance.

See the guidance on content in the Key Terms section.

This applies directly as written and as described in the WCAG 2.2 glossary.

Because relative luminance is defined such that it cannot directly apply to hardware, please note the text in the introduction which reads: “This document does not comment on hardware aspects of products, non-UI aspects of platforms, or the application of WCAG 2.2 for user-interface components as a category, because the basic constructs on which the WCAG 2.2 and / or its conformance are built do not apply to these.”

From the WCAG 2.2 definition for down-event:

This applies directly as written and as described in the WCAG 2.2 glossary. NOTE The down-event may have different names on different platforms. For example ["PointerPressed” or “mousedown”].

This applies directly as written and as described in the WCAG 2.2 glossary.

Note

Because this deals with relative luminance and not luminance, it can only be applied to information on a display, not to hardware sources of light.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web page” with “non-web document or software”.

With this substitution, it would read:

input error

information provided by the user that is not accepted

Note

This includes:

Information that is required by the [non-web document or software] but omitted by the user
Information that is provided by the user but that falls outside the required data format or values

This applies directly as written and as described in the WCAG 2.2 glossary.

Please see the note in the guidance for Success Criterion 2.1.1 that uses this definition and which reads: “This does not imply that software must directly support a keyboard or ‘keyboard interface’. Nor does it imply that software must provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.”

This applies directly as written and as described in the WCAG 2.2 glossary.

Note

A key command issued by a long press of a key (2 seconds or more) and other accessibility features provided by the platform are not considered a keyboard shortcut. Such commands often occur when there are limited keys, or no modifier keys, present on a device.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web Content” with “content” and adding “or by accessibility features of software” after “assistive technology” in Note 1.

With this substitution, it would read:

label

text or other component with a text alternative that is presented to a user to identify a component within [content]

Note

A label is presented to all users whereas the name may be hidden and only exposed by assistive technology [or by accessibility features of software]. In many (but not all) cases the name and the label are the same.

Note

The term label is not limited to the label element in HTML.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web content” with “content” and adding “or by accessibility features of software” after “assistive technology” in Note 1.

With this substitution, it would read:

name

text by which software can identify a component within [content] to the user

Note

The name may be hidden and only exposed by assistive technology [or by accessibility features of software], whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.

Note

This is unrelated to the name attribute in HTML.

Note

“AccessibleName” (or the corresponding term used in different APIs) of the Accessibility API of the platform is an example of such a name.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “user agents, including assistive technologies” with “assistive technologies and accessibility features of software” and adding and “accessibility features of software” after “assistive technology”.

With this substitution, it would read:

programmatically determined (programmatically determinable)

determined by software from author-supplied data provided in a way that different [assistive technologies and accessibility features of software], can extract and present this information to users in different modalities

Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology [and accessibility features of software].

Example 2: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology [and accessibility features of software] via an accessibility API that is supported by commonly available assistive technology [and accessibility features of software].

Note

Software typically enables content to be programmatically determined through the use of accessibility services of platform software. Non-web documents typically enable content to be programmatically determined through the use of accessibility services of the user agent.

With this substitution, it would read:

programmatically set: set by software using methods that are supported by [assistive technologies and accessibility features of software]

Note

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web content” with “content”.

With this substitution, it would read:

relative luminance

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

Note

For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 \* **R** + 0.7152 \* **G** + 0.0722 \* **B** where **R**, **G** and **B** are defined as:

if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

RsRGB = R8bit/255
GsRGB = G8bit/255
BsRGB = B8bit/255

The “^” character is the exponentiation operator. (Formula taken from [sRGB]).

Note

Almost all systems used today to view [content] assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.

Note

If dithering occurs after delivery, then the source color value is used. For colors that are dithered at the source, the average values of the colors that are dithered should be used (average R, average G, and average B).

Note

Tools are available that automatically do the calculations when testing contrast and flash.

Note

A MathML version of the relative luminance definition is available.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web content” with “content”.

With this substitution, it would read:

role: text or number by which software can identify the function of a component within [content]

Example: A number that indicates whether an image functions as a hyperlink, command button, or check box.

Note

“AccessibleRole” (or the corresponding term used in different APIs) of the Accessibility API of the platform is an example of such a role.

This applies directly as written and as described in the WCAG 2.2 glossary, adding a second example (and numbering the first).

With these substitutions, it would read:

same functionality

same result when used

Example [1]:

A submit “search” button on one web page and a “find” button on another web page may both have a field to enter a term and list topics in the Web site related to the term submitted. In this case, they would have the same functionality but would not be labeled consistently.

[Example 2: A ribbon icon that saves the document that looks like an arrow pointing into a folder in one case, and an arrow pointing into a hard drive in another. In this case as well, they would have the same functionality but would not be labeled consistently.]

The guidance in this document does not use the term “satisfies a success criterion”.

See Section 6 Comments on Conformance.

This applies directly as written and as described in the WCAG 2.2 glossary.

Note

For those success criteria that use the term “set of web pages” explicitly or implicitly (2.4.1, 2.4.5, 3.2.3, and 3.2.4) WCAG2ICT provides specific replacement term(s) for “set of Web pages”.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “a Web page” with “non-web documents or software” and replacing “collection of Web pages” with “set of documents or set of software programs”.

With these substitutions, it would read:

structure

The way the parts of [non-web documents or software] are organized in relation to each other; and
The way a [set of documents or set of software programs] is organized

Note

See the guidance on user sets of documents and sets of software programs in the Key Terms section.

Note

“AccessibleRole” (or the corresponding term used in different APIs) of the Accessibility API of the platform is an example of such a role.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “web content” with “non-web document or software”, “user agents” with “user agents or other software”, removing the notes, and replacing the example with “Example: Some common examples of non-web document and software technologies include ODF, OOXML, Java, and C++.”

With these substitutions, it would read:

technology ([non-web document or software]): mechanism for encoding instructions to be rendered, played or executed by [user agents or other software].

Example: Some common examples of [non-web document and software technologies include ODF, OOXML, Java, and C++].

This applies directly as written and as described in the WCAG 2.2 glossary.

Note

The up-event may have different names on different platforms. For example [“PointerReleased” or “mouseup”].

See the guidance on user agent in the Key Terms section.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing the example with “Example: A software program has 2 controls: a text field for entering a file name and a drop down list box for choosing a folder. Each is a user interface component with a name that is settable by the software.”

With this substitution, it would read:

user interface component

a part of the content that is perceived by users as a single control for a distinct function

Note

Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.

Note

User interface components include form elements and links as well as components generated by scripts.

Example: [A software program has 2 controls: a text field for entering a file name and a drop down list box for choosing a folder. Each is a user interface component with a name that is settable by the software.]

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “user agent” with “software”.

With this substitution, it would read:

viewport

object in which the [software] presents content

Note

The [software] presents content through one or more viewports. Viewports include windows, frames, loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport (e.g., nested frames). Interface components created by the [software] such as prompts, menus, and alerts are not viewports.

Note

This definition is based on User Agent Accessibility Guidelines 1.0 Glossary.

This applies directly as written and as described in the WCAG 2.2 glossary.

Note

For those success criteria that use the term “web page”, WCAG2ICT provides specific replacement term(s) for “Web page”.

Guidance on Applying WCAG 2.2 to Non-Web Information and Communications Technologies (WCAG2ICT)

Abstract

Status of This Document

1. Introduction

1.1 Background

1.2 Guidance in this Document

1.3 Excluded from Scope

1.4 Document Overview

1.5 Document Conventions

1.6 Comparison with the 2013 WCAG2ICT Note

2. Key Terms

2.1 Accessibility Services of Platform Software

2.2 Content (on and off the Web)

2.3 Document

2.4 Set of Documents

2.5 Set of Software Programs

2.6 Software

2.7 User Agent

3. Closed Functionality

4. Text / Command-line / Terminal Applications and Interfaces

5. Comments on Conformance

6. Comments by Guideline and Success Criterion

6.1 perceivable

6.1.1 Guidance When Applying Principle 1 to Non-Web Documents and Software

6.1.2 text-alternatives

6.1.2.1 Guidance When Applying Guideline 1.1 to Non-Web Documents and Software

6.1.2.2 non-text-content

6.1.2.2.1 Guidance When Applying Success Criterion 1.1.1 to Non-Web Documents and Software

6.1.3 time-based-media

6.1.3.1 Guidance When Applying Guideline 1.2 to Non-Web Documents and Software

6.1.3.2 audio-only-and-video-only-prerecorded

6.1.3.2.1 Guidance When Applying Success Criterion 1.2.1 to Non-Web Documents and Software

6.1.3.3 captions-prerecorded

6.1.3.3.1 Guidance When Applying Success Criterion 1.2.2 to Non-Web Documents and Software

6.1.3.4 audio-description-or-media-alternative-prerecorded

6.1.3.4.1 Guidance When Applying Success Criterion 1.2.3 to Non-Web Documents and Software

6.1.3.5 captions-live

6.1.3.5.1 Guidance When Applying Success Criterion 1.2.4 to Non-Web Documents and Software

6.1.3.6 audio-description-prerecorded

6.1.3.6.1 Guidance When Applying Success Criterion 1.2.5 to Non-Web Documents and Software

6.1.4 adaptable

6.1.4.1 Guidance When Applying Guideline 1.3 to Non-Web Documents and Software

6.1.4.2 info-and-relationships

6.1.4.2.1 Guidance When Applying Success Criterion 1.3.1 to Non-Web Documents and Software

6.1.4.3 meaningful-sequence

6.1.4.3.1 Guidance When Applying Success Criterion 1.3.2 to Non-Web Documents and Software

6.1.4.4 sensory-characteristics

6.1.4.4.1 Guidance When Applying Success Criterion 1.3.3 to Non-Web Documents and Software

6.1.4.5 orientation

6.1.4.5.1 Guidance When Applying Success Criterion 1.3.4 to Non-Web Documents and Software

6.1.4.6 identify-input-purpose

6.1.4.6.1 Guidance When Applying Success Criterion 1.3.5 to Non-Web Documents and Software

6.1.5 distinguishable

6.1.5.1 Guidance When Applying Guideline 1.4 to Non-Web Documents and Software

6.1.5.2 use-of-color

6.1.5.2.1 Guidance When Applying Success Criterion 1.4.1 to Non-Web Documents and Software

6.1.5.3 audio-control

6.1.5.3.1 Guidance When Applying Success Criterion 1.4.2 to Non-Web Documents and Software

6.1.5.4 contrast-minimum

6.1.5.4.1 Guidance When Applying Success Criterion 1.4.3 to Non-Web Documents and Software

6.1.5.5 resize-text

6.1.5.5.1 Guidance When Applying Success Criterion 1.4.4 to Non-Web Documents and Software

6.1.5.6 images-of-text

6.1.5.6.1 Guidance When Applying Success Criterion 1.4.5 to Non-Web Documents and Software

6.1.5.7 reflow

6.1.5.8 non-text-contrast

6.1.5.8.1 Guidance When Applying Success Criterion 1.4.11 to Non-Web Documents and Software

6.1.5.9 text-spacing

6.1.5.9.1 Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software

6.1.5.10 content-on-hover-or-focus

6.1.5.10.1 Guidance When Applying Success Criterion 1.4.13 to Non-Web Documents and Software

6.2 operable

6.2.1 Guidance When Applying Principle 2 to Non-Web Documents and Software

6.2.2 keyboard-accessible

6.2.2.1 Guidance When Applying Guideline 2.1 to Non-Web Documents and Software

6.2.2.2 keyboard

6.2.2.2.1 Guidance When Applying Success Criterion 2.1.1 to Non-Web Documents and Software

6.2.2.3 no-keyboard-trap

6.2.2.3.1 Guidance When Applying Success Criterion 2.1.2 to Non-Web Documents and Software

6.2.2.4 character-key-shortcuts