This document describes how the Web Content Accessibility Guidelines (WCAG) versions 2.0 [WCAG20], 2.1 [WCAG21], and 2.2 [WCAG22] 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.
Status of This DocumentThis section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.
This is a W3C Group Note on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT). The purpose of this work is to update the previous WCAG2ICT Note's guidance to include changes made in WCAG 2.1 and 2.2. To comment, file an issue in the W3C WCAG2ICT GitHub repository. Create separate GitHub issues for each topic, rather than commenting on multiple topics in a single issue. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-wcag2ict-comments@w3.org (comment archive).
This document was published by the Accessibility Guidelines Working Group as a Group Note using the Note track.
This Group Note is endorsed by the Accessibility Guidelines Working Group, but is not endorsed by W3C itself nor its Members.
The W3C Patent Policy does not carry any licensing requirements or commitments on this document.
This document is governed by the 18 August 2025 W3C Process Document.
Table of ContentsThis 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 could 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 version of WCAG2ICT has been relied upon in regulations and legislation. An example is [etsi-en-301-549] (Europe) as well as other standards that reference or incorporate EN 301 549 (e.g., India, Kenya, Australia). Another example is the U.S. Section 508’s Application of WCAG 2.0 to Non-Web ICT, where WCAG was incorporated by reference into Section 508 as the accessibility standard applicable to non-web documents and which also requires WCAG conformance for non-web software.
These standards looked to WCAG2ICT for detailed direction and guidance on how to apply WCAG non-web technology. The WCAG2ICT guidance also led to a few exceptions where specific success criteria are not required in non-web contexts.
This document provides informative guidance (guidance that is not normative and does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.0, WCAG 2.1, and WCAG 2.2, which are W3C Recommendations). Specifically, this document provides informative guidance on applying WCAG 2.0, 2.1, and 2.2 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.
Note 1
Hereafter, the use of WCAG 2 means all WCAG 2.x versions — 2.0, 2.1, and 2.2.
This document is intended to help clarify how to use WCAG 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 impairments, as well as the accessibility needs of people caused by the effects of aging. Although WCAG 2 addresses some user needs for people with cognitive and learning disabilities, as well as those with mental health-related disabilities, following the WCAG supplement Making Content Usable for People with Cognitive and Learning Disabilities is recommended for non-web ICT in order to address the user needs of these groups. Developers are also encouraged to obtain testing input from people with disabilities who use their applications and content.
Although this document covers a wide range of issues, it is not able to address all the needs of all people with disabilities. Since WCAG 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 as accessible as possible to people with disabilities. The following supporting documents contain helpful information for learning about the user needs, intent, and generalized implementation techniques to support a wider range of people with disabilities:
While WCAG 2 was designed to be technology neutral, it assumes the presence of a “user agent” such as a browser, media player, or assistive technology that is used as a means to access web content. As a result, the application of WCAG 2 to documents and software in non-web contexts necessitates some interpretation in order to determine how the intent of each WCAG 2 success criterion could be met in these different contexts of use. Therefore, the bulk of the WCAG2ICT Task Force's work involved evaluating how each WCAG 2 success criterion would apply in the context of non-web ICT.
The WCAG2ICT Task Force found that the majority of WCAG 2 success criteria can be applied to non-web documents and software with either no or minimal changes. Since many of the Level A and Level 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 increase understanding about applying WCAG success criteria 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 depend upon all pages in the set to share some characteristic or behavior. Since the unit of conformance in WCAG 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 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 non-web software that meet this definition appear to be extremely rare.
Not all success criteria have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. WCAG2ICT has been used in some regulations to determine whether or not to apply certain success criteria. For example, some local standards such as Section 508 in the U.S., and EN 301 549 in Europe, state that WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification do not apply to non-web documents and non-web software. In addition, EN 301 549 states that 2.4.2 Page Titled and 3.1.2 Language of Parts do not apply to non-web software. In contrast, the U.S. Department of Justice regulation, Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities (89 FR 31320, 24 April 2024), directs implementers to utilize the guidance in this document to determine the applicability of success criteria and how to apply the requirements to mobile applications. Since this document does not specifically say which criteria can or should apply, those implementing this document (WCAG2ICT) should consider the applicability of individual success criteria to non-web documents and software.
The glossary terms in WCAG 2 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 includes text quoted from the WCAG 2.2 principles, guidelines, success criteria, and glossary definitions without any changes. The guidance provided by this document for each principle, guideline, success criterion, and definition is preceded by a heading beginning with “Applying…”. This guidance was created by the WCAG2ICT Task Force, then reviewed and approved by the Accessibility Guidelines Working Group.
The following stylistic conventions are used in this document:
<blockquote> elements and visually styled with a gray bar on the left, and immediately follow the heading for the principle, guideline, or success criterion.<ins> elements that are visually styled as green text with a dotted underline.<cite> elements that are 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.<cite> elements that are visually styled as ordinary text with a dark gray underline.The following changes and additions have been made to update the 2013 WCAG2ICT document to incorporate the new features in WCAG 2.1, the new features in WCAG 2.2, and the change to 4.1.1 Parsing listed in the Comparison with WCAG 2.1 section:
Note
WCAG2ICT provides some key glossary terms to address differences between web and non-web contexts and to introduce terms that are nonexistent in WCAG but important to define for a non-web context. “Content” and “user agent” are glossary terms from WCAG 2 that need to be interpreted significantly differently when applied to non-web ICT. The glossary term “web page” in WCAG 2 is replaced with the defined terms “document” and “software”, and both “set of web pages” and “multiple web pages” are replaced with the defined terms “set of documents” and “set of software programs”. The terms introduced by WCAG2ICT are “accessibility services of platform software” because non-web software doesn't leverage the WCAG notion of a user agent, and "closed functionality" which is specific to non-web software. The remaining glossary terms from WCAG 2 are addressed in Chapter 7 Comments on Definitions in WCAG 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:
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.
The term closed functionality, as used in WCAG2ICT, has the meaning below:
a property or characteristic that prevents users from attaching, installing, or using assistive technology
Note 1
To support users with disabilities, ICT with closed functionality might instead provide built-in features that function as assistive technology or use other mechanisms to make the technology accessible.
Example: Examples of technology that may have closed functionality include but are not limited to:
Note 2
Some of these technologies, though closed to some external assistive technologies, often have extensive internal accessibility features that serve as assistive technology that can be used by applications on these devices in the same way assistive technology is used on fully open devices, such as desktop computers. Others are open to some types of assistive technology but not others.
WCAG 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:
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 1
Non-web content occurs in two places; documents and software. When content occurs in a non-web document, a user agent is needed in order to communicate the content's information and sensory experience to the user. When content occurs in non-web software, a separate user agent isn't needed — the software itself performs that function.
Note 2
Content from a third party needs special consideration since sometimes it may be under the control of the author (e.g. contracted and therefore may not be considered 3rd party) and sometimes it is completely out of the control of the author (e.g. email in an email client).
Note 3
For non-web software, content also includes the user interface.
Note 4
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:
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 1
A document always depends upon a user agent to present its content to the user.
Note 2
Letters, spreadsheets, emails, books, pictures, presentations, and movies are examples of documents.
Note 3
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 4
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.
Note 5
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 6
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 platform software, as used in WCAG2ICT, has the meaning below:
Note 1
Platform software may run or host other software, and may isolate them from underlying software or hardware layers.
Note 2
A single software component may have both platform and non-platform aspects.
Example: Examples of platforms are: desktop operating systems; embedded operating systems, including mobile systems; web browsers; plug-ins to web browsers that render a particular media or format; and sets of components that allow other applications to execute, such as applications which support macros or scripting.
This definition is based on the definition of "platform software" found in [ISO_9241-171] and [ISO/IEC_13066-1].
The term set of documents, as used in WCAG2ICT, has the meaning below:
collection of [documents] that share a common purpose; are created by the same author, group or organization; [are published together; and all refer to each other by name or link]
Note 1
Republishing or bundling previously published documents as a collection does not constitute a set of documents.
Note 2
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:
collection of [software programs] that share a common purpose; are created by the same author, group or organization; [and are distributed together and can be launched and used independently from each other, but 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 1
Although "sets of web pages" occur frequently, "sets of software programs" appear to be extremely rare.
Note 2
Redistributing or bundling previously distributed software as a collection does not constitute a set of software programs.
Note 3
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 4
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 5
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 6
If there is any ambiguity whether the group is a set, then the group is not a set.
Note 7
If there is no independent method to launch the software programs (as is common in ICT with closed functionality), those programs would not meet the definition of a “set of software programs”.
Note 8
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, in the WCAG2ICT guidance for the provisions that use the phrase “set of” (success criteria 2.4.1, 2.4.5, 3.2.3, 3.2.4, and 3.2.6), 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:
The term software as used in WCAG2ICT, has the meaning below:
software products, or software aspects of hardware-software products, that have a user interface and do not depend upon a separate user agent to present any of its content
Note 1
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 2
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 3
Because software with a user interface provides a function equivalent to a user agent in addition to content, the application of some WCAG 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 defines user agent as:
any software that retrieves and presents web content for usersExample: 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, 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:
any software that retrieves and presents [documents] for users
Note 1
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 2
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 3
Software that only shows a preview of content, such as a thumbnail or other non-fully functioning presentation, is not providing full user agent functionality.
The term virtual keyboard, as used in WCAG2ICT, has the meaning below:
any software that acts as a keyboard and generates output that is treated by other software as keystrokes from a keyboard
Note
Eye-gaze, morse code, speech, and switches (e.g. sip-and-puff) have all been used by virtual keyboards as input that generates "keystroke" output.
Text applications are a class of software ICT that appeared decades ago, prior to the emergence of the graphical user interface (GUI) and the Web. The interface of a text application is generated using only text characters, and either a hardware terminal or a software terminal application handles the rendering of the text application—similar to how a web user agent handles the rendering of a web application. Text applications only accept text input, though some may also support the use of a mouse or other input devices. More recently, terminal applications that render text applications in the GUI may utilize spoken input through Automated Speech Recognition (ASR). Both GUI and native text environment interfaces also now commonly support word-completion prediction technologies. Command-line applications are a subset of text applications with further specific properties.
Historically, assistive technologies developed alongside text applications, making it possible for text applications to be accessible. Although there are far fewer new text applications being developed compared to new GUI or web applications, text applications remain in use today. In fact, command-line interfaces have seen a resurgence in recent years, especially in popular programming and revision-tracking environments with continued development and greater functionality. In some cases this has precipitated renewed developments in assistive technology support for text applications.
Assistive technology support continues to evolve in today's text applications. Key examples include:
As noted in Appendix B. Background on Text / Command-Line / Terminal Applications and Interfaces, applying WCAG to text / command-line applications involves understanding how text applications are rendered, how text applications have been made accessible via assistive technologies, and how to apply the concepts of “accessibility supported” and “programmatically determined” to text applications.
The sections that follow are organized according to the principles, guidelines, and success criteria from WCAG 2. The text of each success criterion from WCAG 2 is copied as quoted text. Following that, the WCAG2ICT guidance is provided. The WCAG2ICT guidance can be found in the sections where the headings begin with "Applying..." to highlight that this is the content specific to this document. Within these sections custom notes added by WCAG2ICT are marked with the text "ADDED".
Information and user interface components must be presentable to users in ways they can perceive.
In WCAG 2, the Principles are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Principle 1 applies directly as written.
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 1.1 applies directly as written.
(Level A)
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
- Controls, Input
If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
- Time-Based Media
If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
- Test
If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
- Sensory
If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
- CAPTCHA
If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
- Decoration, Formatting, Invisible
If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.1.1.
Note 1 (Added)
CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate.
Provide alternatives for time-based media.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 1.2 applies directly as written.
(Level A)
For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:
- Prerecorded Audio-only
An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.
- Prerecorded Video-only
Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.1.
Note 1 (Added)
The alternative can be provided directly in the non-web document or software – or provided in an alternate version that satisfies the success criterion.
(Level A)
Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.2.
Note (Added)
The WCAG 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, to satisfy 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”.
(Level A)
An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.3.
Note 1 (Added)
The WCAG 2 definition of “audio description” says that “audio description” is “also called ‘video description’ and ‘descriptive narration’”.
Note 2 (Added)
Secondary or alternate audio tracks are commonly used for this purpose.
(Level AA)
Captions are provided for all live audio content in synchronized media.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.4.
Note (Added)
The WCAG 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, to satisfy 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”.
(Level AA)
Audio description is provided for all prerecorded video content in synchronized media.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.5.
Note 1 (Added)
The WCAG 2 definition of “audio description” says that audio description is “also called ‘video description’ and ‘descriptive narration’”.
Note 2 (Added)
Secondary or alternate audio tracks are commonly used for this purpose.
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 1.3 applies directly as written.
(Level A)
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.1.
Note 1 (Added) (for non-web documents)
Where non-web documents contain non-standard structure types (roles), it is best practice to map them to a standard structure type as a fall-back solution for the reader.
Note 2 (Added) (for non-web software)
In non-web software, programmatic determinability is best achieved by using the accessibility services of platform software to enable interoperability between the software and assistive technologies and accessibility features of software.
(Level A)
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.2.
(Level A)
Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.3.
(Level AA)
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
Note
Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4.
Note 1 (Added)
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 does not need to provide support for orientation changes.
(Level AA)
The purpose of each input field collecting information about the user can be programmatically determined when:
- The input field serves a purpose identified in the Input Purposes for user interface components section; and
- The content is implemented using technologies with support for identifying the expected meaning for form input data.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.5.
Note 1 (Added)
Non-web software and non-web document 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 2 (Added)
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 section Input Purposes for User Interface Components that are supported by the technology used.
Make it easier for users to see and hear content including separating foreground from background.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 1.4 applies directly as written.
(Level A)
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Note
This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.1.
(Level A)
If any audio on a web page 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.
Note
Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.2, replacing “on a web page” with “in the non-web document or software”, “whole page” with “whole non-web document or software”, and “on the web page” with “in the non-web document or software”; removing “See Conformance Requirement 5: Non-Interference”; and adjusting Note 1 to avoid the use of the normative term "must".
With these substitutions, it would read:
1.4.2 Audio Control: If any audio [in the 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.
Note 1
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], [it would be necessary for] all content [in the non-web document or software] (whether or not it is used to meet other success criteria) [to] meet this success criterion.
(Level AA)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
- Large Text
Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
- Incidental
Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- Logotypes
Text that is part of a logo or brand name has no contrast requirement.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.3.
(Level AA)
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Non-web software needs to work with platform capabilities where they exist, but when the platform has text resizing that up to 200%, but not all text types scale to 200%, it is unreasonable for all apps on a particular platform to be required to build in their own text resizing. A reasonable expectation would be for non-web software to work with the text sizing features to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language:
Except for captions and images of text, text can be resized without loss of content or functionality and without assistive technology either up to 200 percent or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform.
Note 1 (Added)
It is best practice to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). This applies in particular to embedded fonts.
Note 2 (Added) (for non-web documents)
Content for which there are viewers or editors with a 200 percent zoom feature would automatically satisfy this success criterion when used with such viewers or editors, unless the content will not work with that zoom feature.
Note 4 (Added) (for non-web software)
For non-web software, sometimes the platform provides text scaling to 200% for most, but not all text (e.g. headings, which are naturally large, may not be increased in size to 200%, but other text does increase to 200%). In such cases, authors would only need to support text scaling to the extent provided by user settings in the platform, without losing content or functionality, to satisfy this success criterion.
(Level AA)
If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:
- Customizable
The image of text can be visually customized to the user's requirements;
- Essential
A particular presentation of text is essential to the information being conveyed.
Note
Logotypes (text that is part of a logo or brand name) are considered essential.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.5.
(Level AA)
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Except for parts of the content which require two-dimensional layout for usage or meaning.
Note 1
320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.
Note 2
Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.10, replacing “web content” with “content”.
With this substitution, it would read:
1.4.10 Reflow: Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
Except for parts of the content which require two-dimensional layout for usage or meaning.
Note 1
320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For [content] which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.
Note 2
Examples of content which requires two-dimensional layout are images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.
Note 4 (Added) (for non-web documents)
If a non-web document type and its available user agents do not support reflow, it may not be possible for a document of that type to satisfy this success criterion.
Note 5 (Added) (for non-web software)
The intent section refers to the ability for content to reflow (for vertical scrolling content at a width equivalent to 320 CSS pixels, or for horizontal scrolling content at a height equivalent to 256 CSS pixels) when user agent zooming is used to scale content or when the viewport changes in width. For non-web software, this means that when users scale content, adjust the size of a window, dialog, or other resizable content area, or change the screen resolution, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions; or that the non-web software works with platform features that satisfy this success criterion.
Note 6 (Added) (for non-web software)
Non-web software will have more frequent cases where two-dimensional layout is relied upon for usage or meaning than what occurs on the Web. For example:
Note 7 (Added) (for non-web software)
As written, this success criterion can only be met by non-web software where the underlying user agent or platform software can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.
When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.
When users modify zoom, scaling, and/or display resolution at the platform software level (e.g. Operating System), it impacts the size of all applications and the platform software itself. This can result in improved readability in some applications but unwanted consequences in others.
Note 8 (Added) (for non-web software)
Some non-web software applications provide a mode of operation where reflow is possible, while other modes are unable to reflow. An example is a document authoring tool, which includes both a "print preview mode" (without reflow, for users to view the spatial formatting) and a "drafting view mode" where reflow is supported. Such software would satisfy this success criterion as long as there is no loss of information or functionality in the drafting view.
(Level AA)
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 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.
This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.11, replacing "user agent" with "user agent or other platform software".
With this substitution, it would read:
1.4.11 Non-text Contrast: The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):
Note 1 (Added)
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.
(Level AA)
In content implemented using markup languages that support 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 1
Content is not required to use these text spacing values. The requirement is to ensure that when a user overrides the authored text spacing, content or functionality is not lost.
Note 2
Writing systems for some languages use different text spacing settings, such as paragraph start indent. Authors are encouraged to follow locally available guidance for improving readability and legibility of text in their writing system.
This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12.
Note 1 (Added)
This success criterion only applies to non-web documents and software that are implemented using markup languages and allow the user to modify these text spacing properties.
Note 2 (Added) (for non-web documents)
There are several mechanisms that allow users to modify a document's 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. When such a mechanism is available, the success criterion requires that the content responds appropriately to it.
Note 3 (Added) (for non-web software)
There are several mechanisms that allow users to modify software's text spacing properties of content implemented in markup languages. For example, 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 mean that non-web software needs to implement their own mechanisms to allow users to set text spacing; however, when such a mechanism is available, the success criterion requires that the content responds appropriately to it.
Note 4 (Added) (for non-web software)
"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.
(Level AA)
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 and is not modified by the author.
Note 1
Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML
titleattribute [HTML].Note 2
Custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content covered by this criterion.
Note 3
This criterion applies to content that appears in addition to the triggering component itself. Since hidden components that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content they are not covered by this criterion.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.13, replacing "user agent" with "user agent or other platform software", "browser tooltips" with "tooltips", and "the HTML title attribute" with "user interface object attributes".
With these substitutions, it would read:
1.4.13 Content on Hover or Focus: Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
Exception: The visual presentation of the additional content is controlled by the [user agent or other platform software] and is not modified by the author.
Note 1
Examples of additional content controlled by the [user agent or other platform software] include [tooltips] created through use of [user interface object attributes].
Note 2
Custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content covered by this criterion.
Note 3
This criterion applies to content that appears in addition to the triggering component itself. Since hidden components that are made visible on keyboard focus (such as links used to skip to another part of a page) do not present additional content they are not covered by this criterion.
User interface components and navigation must be operable.
In WCAG 2, the Principles are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Principle 2 applies directly as written.
Make all functionality available from a keyboard.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 2.1 applies directly as written.
(Level A)
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
Note 1
This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
Note 2
This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.1.
Where ICT is or includes non-web software that can be run on a software platform that provides a device-independent keyboard interface service, this applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.1.
Note 1 (Added) (for non-web software)
Keyboard interface does not refer to a physical device but to the service of platform software (e.g. operating system, browser, etc.) that provides the software with keystrokes from any keyboard or keyboard substitute. When the non-web software supports such a device-independent service of the platform software, and the non-web software functionality is made fully operable through the service, then this success criterion would be satisfied.
Note 2 (Added) (for non-web software)
A "device-independent keyboard interface service" refers to the platform service that provides keystrokes to any software running on the platform.
Note 3 (Added) (for non-web software)
Inclusion of an on-screen keyboard can be done as well but does not satisfy this requirement since it does not allow for the use of keyboard alternatives whereas support of input from the device-independent keyboard interface service does.
Note 4 (Added) (for non-web software)
This success criterion does not imply that non-web software always needs to directly support a keyboard or “keyboard interface” if one is not provided by the platform software. But if one is provided, the software needs to make all functionality available through it - unless the exception applies.
Note 5 (Added) (for non-web software)
Nor does this success criterion imply that non-web software always needs to provide its own virtual keyboard. But if it does, then the non-web software still needs to support keyboard input from any keyboard interface provided by the platform software.
(Level A)
If keyboard focus can be moved to a component of the page 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.
Note
Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.2, replacing “page” with “non-web document or software” and “on the web page” with "in the non-web document or software"; removing “See Conformance Requirement 5: Non-Interference”; and adjusting Note 1 to avoid the use of the normative term "must".
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.
Note 1
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], [it would be necessary for] all content [in the non-web document or software] (whether it is used to meet other success criteria or not) [to] meet this success criterion.
Note 2 (Added)
Standard exit methods may vary by platform. For example, on many desktop platforms, the Escape key is a standard method for exiting.
Note 3 (Added) (for non-web software)
This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and this success criterion would be satisfied.
(Level A)
If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:
- Turn off
- A mechanism is available to turn the shortcut off;
- Remap
- A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
- Active only on focus
- The keyboard shortcut for a user interface component is only active when that component has focus.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.4.
Note 1 (Added) (for non-web software)
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.
Provide users enough time to read and use content.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 2.2 applies directly as written.
(Level A)
For each time limit that is set by the content, at least one of the following is true:
- 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.1, replacing “ content” with “non-web document or software”.
With this substitution, it would read:
2.2.1 Timing Adjustable: For each time limit that is set by the [non-web document or software], at least one of the following is true:
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.
(Level A)
For moving, blinking, scrolling, or auto-updating information, all of the following are true:
- 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 1
For requirements related to flickering or flashing content, refer to Guideline 2.3.
Note 2
Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
Note 3
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 4
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.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.2, replacing “page” with “non-web document or software” and “on the web page” with “in the non-web document or software”; removing “See Conformance Requirement 5: Non-Interference” in Note 2 of the success criterion; and adjusting Note 2 to avoid the use of the normative term "must".
With these substitutions, it would read:
2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true:
Note 1
For requirements related to flickering or flashing content, refer to Guideline 2.3.
Note 2
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], [it would be necessary for] all content [in the non-web document or software] (whether it is used to meet other success criteria or not) [to] meet this success criterion.
Note 3
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 4
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 5 (Added)
While the success criterion uses the term “information”, the WCAG 2 Intent from Understanding Success Criterion 2.2.2 makes it clear that this is to be applied to all content. Any content, even if just decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.
Do not design content in a way that is known to cause seizures or physical reactions.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 2.3 applies directly as written.
(Level A)
Web pages 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.
Note
Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.1, replacing “web pages” with “non-web documents or software” , “page” with “non-web document or software”, and “on the web page” with “in the non-web document or software”; removing “See Conformance Requirement 5: Non-Interference”; and adjusting Note 1 to avoid the use of the normative term "must".
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.
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], [it would be necessary for] all content [in the non-web document or software] (whether it is used to meet other success criteria or not) [to] meet this success criterion.
Provide ways to help users navigate, find content, and determine where they are.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 2.4 applies directly as written.
(Level A)
A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
This applies directly as written and described in Intent from Understanding Success Criterion 2.4.1, replacing “on multiple web pages” with “in multiple non-web documents in a set of non-web documents, or in multiple 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:
2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated [in multiple non-web documents in a set of non-web documents, or in multiple software programs in a set of software programs].
Note 2 (Added)
Individual documents or software programs (not in a set) would automatically satisfy this success criterion because this success criterion applies only to things that appear in a set.
Note 3 (Added)
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 4 (Added) (for non-web software)
Sets of software that meet this definition appear to be extremely rare.
Note 5 (Added) (for non-web software)
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.
(Level A)
Web pages have titles that describe topic or purpose.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.2 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.
Note 2 (Added) (for non-web software)
Although not required by this success criterion, ensuring that individual windows or screens have a title (where that title describes the topic or purpose) addresses the user needs identified in the Understanding Success Criterion 2.4.2 Intent section, and is generally considered a best practice.
(Level A)
If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.3 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)
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
This applies directly as written and as described in Intent from Understanding Success Criterion 2.4.4.
Note 1 (Added) (for non-web software)
In non-web 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.)
(Level AA)
More than one way is available to locate a web page within a set of web pages except where the web page is the result of, or a step in, a process.
This applies directly as written and described in Intent from Understanding Success Criterion 2.4.5, replacing “web page within a set of web pages” with “non-web document within a set of non-web documents, or a set of software programs within a set of software programs” and "the web page" with "the non-web document or software program**.
With these substitutions, this success criterion would read:
2.4.5 Multiple Ways: More than one way is available to locate a [non-web document within a set of non-web documents, or a software program within a set of software programs] except where [the non-web document or software program] is the result of, or a step in, a process.
Note 2 (Added)
The definitions of “set of documents” and “set of software programs” in the Key Terms section 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 3 (Added)
While some users may find it useful to have multiple ways to locate some groups of user interface elements within a non-web document or software program, this is not required by the success criterion (and may pose difficulties in some situations).
Note 4 (Added)
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 satisfying this success criterion—is achieved by the definition of set.
Note 5 (Added) (for non-web software)
Sets of software that meet this definition appear to be extremely rare.
Note 6 (Added) (for non-web software)
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.
(Level AA)
Headings and labels describe topic or purpose.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.6.
Note (Added) (for non-web software)
In non-web 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.
(Level AA)
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.7.
(Level AA)
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Note 1
Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.
Note 2
Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.11.
Make it easier for users to operate functionality through various inputs beyond keyboard.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 2.5 applies directly as written.
(Level A)
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
Note
This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.1, making changes to the notes for non-web documents by replacing “web content” with "content", for non-web software by replacing "web content that interprets" with "non-web software that interprets" and "user agent" with "underlying platform software".
With these substitutions, the notes would read:
Note 1 (for non-web documents)
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 2 (Added) (for non-web documents)
Multipoint and path-based gestures are less common in non-web documents. An example where a non-web document author could add such gestures is an interactive prototype document created in a software design tool.
Note 3 (for non-web software)
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).
Note 4 (Added) (for non-web software)
This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
(Level A)
For functionality that can be operated using a single pointer, at least one of the following is true:
- No Down-Event
- The down-event of the pointer is not used to execute any part of the function;
- Abort or Undo
- Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
- Up Reversal
- The up-event reverses any outcome of the preceding down-event;
- Essential
- Completing the function on the down-event is essential.
Note 1
Functions that emulate a keyboard or numeric keypad key press are considered essential.
Note 2
This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.2, making changes to the notes for non-web documents by replacing “web content” with "content", for non-web software by replacing "web content that interprets" with "non-web software that interprets" and "user agent" with "underlying platform software".
With these substitutions, the notes would read:
Note 1 (for non-web documents)
Functions that emulate a keyboard or numeric keypad key press are considered essential.
Note 2 (for non-web documents)
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 3 (Added) (for non-web documents)
Content that interprets pointer actions and controls which events are used for executing functionality is less common in non-web documents. An example where a non-web document author could add such functionality is an interactive prototype document created in a software design tool.
Note 4 (for non-web software)
Functions that emulate a keyboard or numeric keypad key press are considered essential.
Example (Added): 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 5 (for non-web software)
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).
Note 6 (Added) (for non-web software)
This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
(Level A)
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.
Note
A best practice is to have the text of the label at the start of the name.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.3.
(Level A)
Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:
- Supported Interface
- The motion is used to operate functionality through an accessibility supported interface;
- Essential
- The motion is essential for the function and doing so would invalidate the activity.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.4.
(Level AA)
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
Note
This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.7, replacing "user agent" with "user agent or other platform software" and by making changes to the notes for non-web documents by replacing “web content” with "content", and for non-web software by replacing "web content that interprets" with "non-web software that interprets" and "user agent" with "underlying platform software".
With these substitutions, it would read:
2.5.7 Dragging Movements: All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the [user agent or other platform software] and not modified by the author.
Note 1 (for non-web documents)
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 2 (Added) (for non-web documents)
Dragging movements for operation are less common in non-web documents. An example where a document author could add dragging functionality is an interactive prototype document created in a software design tool.
Note 3 (for non-web software)
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).
Note 4 (Added) (for non-web software)
This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer.
(Level AA)
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:
- Spacing
- Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
- Equivalent
- The function can be achieved through a different control on the same page that meets this criterion;
- Inline
- The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
- User Agent Control
- The size of the target is determined by the user agent and is not modified by the author;
- Essential
- A particular presentation of the target is essential or is legally required for the information being conveyed.
Note 1
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders, color pickers displaying a gradient of colors, or editable areas where you position the cursor.
Note 2
For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.
This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.8, replacing "user agent" with "user agent or other platform software" and "on the same page" with "in the same non-web document or software".
With these substitutions, it would read:
2.5.8 Target Size (Minimum): The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:
Note 1
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders, color pickers displaying a gradient of colors, or editable areas where you position the cursor.
Note 2
For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.
Note 4 (Added) (for non-web documents)
Some non-web document formats are designed for viewing at a wide range of zoom levels provided by the user agent. However, the commonly available user agents for these formats may lack a consistent base zoom level from which to evaluate this criterion. For such documents, evaluate target sizes at a zoom level that aligns with the intended usage of the content.
Information and the operation of the user interface must be understandable.
In WCAG 2, the Principles are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Principle 3 applies directly as written.
Make text content readable and understandable.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 3.1 applies directly as written.
(Level A)
The default human language of each web page can be programmatically determined.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.1 replacing “each web page” with “non-web documents or software”.
With this substitution, it would read:
3.1.1 Language of Page: The default human language of [non-web documents or software] can be programmatically determined.
Note 1 (Added) (for non-web software)
Where software platforms provide a “locale / language” setting, applications that use that setting and render their interface in that “locale / language” would satisfy 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 non-web software would also satisfy 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 satisfy this success criterion in that locale / language.
(Level AA)
The human language of each passage or phrase in the content 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.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.1.2 replacing “content” with “non-web document or software”.
With this substitution, 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.
Note 1 (Added)
Examples of programmatic identification include language metadata or markup. There are some non-web 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 satisfy this success criterion with those technologies.
Note 2 (Added) (for non-web documents)
Inheritance is one common method. For example, where the primary language of a non-web document is programmatically determinable, it can be assumed that all of the text or user interface elements within that document will be using the same language unless it is indicated.
Make web pages appear and operate in predictable ways.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 3.2 applies directly as written, replacing “web pages” with “non-web documents or software”.
With this substitution, it would read:
Guideline 3.2 Predictable: Make [non-web documents or software] appear and operate in predictable ways.
(Level A)
When any user interface component receives focus, it does not initiate a change of context.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.1.
Note (Added)
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.
(Level A)
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.2.2.
(Level AA)
Navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
This applies directly as written and described in Intent from Understanding Success Criterion 3.2.3, replacing "on multiple web pages within a set of web pages" with "in multiple non-web documents within a set of non-web documents, or in multiple non-web software programs within a set of software programs”.
With these substitutions, it would read:
3.2.3 Consistent Navigation: Navigational mechanisms that are repeated [in multiple non-web documents within a set of non-web documents, or in 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 2 (Added)
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.
Note 3 (Added) (for non-web software)
Sets of software that meet this definition appear to be extremely rare.
(Level AA)
Components that have the same functionality within a set of web pages are identified consistently.
This applies directly as written and described in Intent from Understanding Success Criterion 3.2.4, replacing “set of web pages” with “set of non-web documents or a set of software programs”.
With these substitutions, it would read:
3.2.4 Consistent Identification: Components that have the same functionality within a [set of non-web documents or a set of software programs] are identified consistently.
Note 2 (Added)
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.
Note 3 (Added) (for non-web software)
Sets of software that meet this definition appear to be extremely rare.
(Level A)
If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
Note 1
Help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information.
Note 2
For this success criterion, "the same order relative to other page content" can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).
This applies directly as written and as described in Intent from Understanding Success Criterion 3.2.6, replacing "web page(s)" and "page(s)" with "non-web document(s) or software program(s)", "set of web pages" with "set of non-web documents or set of software programs", "page content" with "content", "on the page" with "in the non-web document or software", "page is serialized" with "non-web document or software content is serialized", "different page" with "different non-web document, software, or web page", and "page variation" with "content layout variation".
With these substitutions, it would read:
3.2.6 Consistent Help: If a [non-web document or software] contains any of the following help mechanisms, and those mechanisms are repeated [in multiple non-web documents or software] within a [set of non-web documents or set of software programs], they occur in the same order relative to other [content], unless a change is initiated by the user:
Note 1
Help mechanisms may be provided directly [in the non-web document or software], or may be provided via a direct link to a [different non-web document, software, or web page] containing the information.
Note 2
For this success criterion, "the same order relative to other [content]" can be thought of as how the content is ordered when the [non-web document or software content is serialized]. The visual position of a help mechanism is likely to be consistent across [non-web documents or software] for the same [content layout variation] (e.g., CSS break-point). The user can initiate a change, such as changing the [non-web document’s or software's] zoom or orientation, which may trigger a different [content layout variation]. This criterion is concerned with relative order across [non-web documents or software] displayed in the same [content layout variation] (e.g., same zoom level and orientation).
Note 4 (Added) (for non-web software)
Sets of software that meet this definition appear to be extremely rare.
Help users avoid and correct mistakes.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used for conformance to WCAG. Guideline 3.3 applies directly as written.
(Level A)
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.1.
(Level A)
Labels or instructions are provided when content requires user input.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.2.
(Level AA)
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.3.
(Level AA)
For web pages 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:
- 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.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.4 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 A)
Information previously entered by or provided to the user that is required to be entered again in the same process is either:
- auto-populated, or
- available for the user to select.
Except when:
- re-entering the information is essential,
- the information is required to ensure the security of the content, or
- previously entered information is no longer valid.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.7.
(Level AA)
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative
- Another authentication method that does not rely on a cognitive function test.
- Mechanism
- A mechanism is available to assist the user in completing the cognitive function test.
- Object Recognition
- The cognitive function test is to recognize objects.
- Personal Content
- The cognitive function test is to identify non-text content the user provided to the website.
Note 1
"Object recognition" and "Personal content" may be represented by images, video, or audio.
Note 2
Examples of mechanisms that satisfy this criterion include:
- support for password entry by password managers to reduce memory need, and
- copy and paste to reduce the cognitive burden of re-typing.
This applies directly as written, and as described in Intent from Understanding Success Criterion 3.3.8, replacing “the website” with “a website, non-web document, or software”.
With this substitution, it would read:
3.3.8 Accessible Authentication (Minimum): A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
Note 1
"Object recognition" and "Personal content" may be represented by images, video, or audio.
Note 2
Examples of mechanisms that satisfy this criterion include:
Note 3 (Added) (for non-web software)
Any passwords used to unlock underlying platform software (running below the non-web software) are out of scope for this requirement since these are not under control of the non-web software’s author.
Note 4 (Added) (for non-web software)
There are cases where non-web software has an authentication process and no alternative or assistance mechanism is feasible, for example when entering a password when starting, powering on / turning on an ICT (device or otherwise). In such situations, it may not be possible for the non-web software to satisfy this success criterion.
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
In WCAG 2, the Principles are provided for framing and understanding the success criteria under them but are not used 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 by a wide variety of [assistive technologies and accessibility features of software].
Maximize compatibility with current and future user agents, including assistive technologies.
In WCAG 2, the Guidelines are provided for framing and understanding the success criteria under them but are not used 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].
(Level A)
In content implemented using markup languages, 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.
Note 1
This success criterion should be considered as always satisfied for any content using HTML or XML.
Note 2
Since this criterion was written, the HTML Living Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs. [HTML]
Although the HTML standard treats some of these cases as non-conforming for authors, it is considered to "allow these features" for the purposes of this success criterion because the specification requires that user agents support handling these cases consistently. In practice, this criterion no longer provides any benefit to people with disabilities in itself.
Issues such as missing roles due to inappropriately nested elements or incorrect states or names due to a duplicate ID are covered by different success criteria and should be reported under those criteria rather than as issues with 4.1.1.
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.1, 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” and replacing the WCAG notes with notes applicable to non-web documents and software.
With this substitution, 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.
Note 1 (Added)
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.
Accessibility issues introduced through poor markup would surface as errors in the programmatic information and would be reported using success criteria that rely on that information, such as 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.
Note 2 (Added)
This success criterion would be satisfied in cases where:
Example (Added): Examples where 4.1.1 Parsing would be satisfied:
Examples of markup that might be separately exposed and available to assistive technologies and to user agents include:
(Obsolete and removed)
Note
This criterion was originally adopted to address problems that assistive technology had directly parsing HTML. Assistive technology no longer has any need to directly parse HTML. Consequently, these problems either no longer exist or are addressed by other criteria. This criterion no longer has utility and is removed.
Note (Added)
WCAG 2.2 has made this success criterion obsolete and removed it as a requirement in the standard. Therefore, the interpretation of this success criterion for non-web documents and software has been removed.
(Level A)
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.
Note
This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.2, replacing “user agents, including assistive technologies", with “assistive technologies and accessibility features of underlying software” and 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 satisfy 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 [assistive technologies and accessibility features of underlying software].
Note 1 (Added) (for non-web documents)
For non-web document formats that support interoperability with assistive technology, standard user interface components often satisfy this success criterion when used according to the general design and accessibility guidance for the document format.
Note 2 (Replaced) (for non-web software)
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 satisfy this success criterion when used according to specification.
Note 3 (Added) (for non-web software)
For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services of 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 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).
(Level AA)
In content implemented using markup languages, 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.
This applies directly as written, and as described in Intent from Understanding Success Criterion 4.1.3.
Note 1 (Added)
For non-web documents and software where status messages 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 other platform software.
This section is non-normative.
This Working Group Note does not introduce any new privacy considerations. However, when implementing WCAG 2 success criteria in the context of non-web ICT, information about a user’s accessibility needs or preferences might be exposed; a user could be harmed by disclosure and misuse of that information. It is best practice to choose implementations that reduce the potential for fingerprinting or other identification and tracking of users, and that the only data collected is data necessary to enable the accessibility features.
This section is non-normative.
This Working Group Note does not introduce any new security considerations. Since any software feature has the potential to compromise security, take care when implementing non-web ICT features added to meet WCAG 2 success criteria.
There are success criteria that can be problematic for developers of ICT with closed functionality. Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), or doing something else to make content compatible with assistive technologies. Where ICT with closed functionality doesn’t support use of assistive technology or the platform does not have an accessibility API, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive technology, would help meet the intent of these success criteria. See also the Comments on Closed Functionality section.
Other success criteria would apply to ICT with closed functionality either if they are partially closed or if they allow for the connection of some types of devices. As an example, Success Criterion 2.1.1 Keyboard would apply to ICT that is closed to screen readers, but have a physical keyboard, a connector for standard keyboards, or allow the installation of alternate keyboards. While these criteria, as written, are not always applicable to ICT with closed functionality, most of them can inform and aid development of built-in features needed to make ICT with closed functionality accessible.
For non-web software on ICT with closed functionality, those who implement this document (WCAG2ICT) should consider the applicability of individual WCAG 2 success criteria on a criterion-by-criterion basis. Alternate accessibility provisions might be needed to cover the user needs addressed by the following success criteria:
Note 1
Contrast requirements for hardware are out of scope for WCAG2ICT (and this success criterion).
Note 2
Photographs (e.g., of a hardware display) are not sufficient for testing that content meets this success criterion. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.
Note 3
Some ICT with closed functionality does not display large chunks of text and only has UI controls. In such cases, two-dimensional scrolling to access the text and UI controls may be considered essential, thus meeting an exception, and the success criterion would be satisfied.
Note 4
Contrast requirements for hardware are out of scope for WCAG2ICT (and this success criterion).
Note 5
Photographs are not sufficient for testing that content meets this success criterion. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.
Note 6
A keypad that provides full access to functionality might be considered a keyboard.
Note 7
If the viewing distance and pixel density of the system are unknown, approximating the reference pixel as described in Applying “CSS pixel” to Non-Web Documents and Software is not possible.
Note 8
For non-web software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for a CSS pixel are dependent on the viewing distance or pixel density of the display.
Note 9
Non-web software on ICT with closed functionality would need equivalent facilitation to provide access to status messages.
The interface of a text application is realized through a server application directing which characters should be placed on the screen, along with either a hardware terminal or a terminal application that displays the characters. The client terminal application for text applications is analogous to a web user agent for web pages. Also, like web applications, text applications may execute primarily on a remote server or execute locally.
Some text applications render like a TeleTYpewriter (TTY); their output is always appended, like an ever-growing file. Such text applications are often called “command-line applications” or occasionally “TTY-applications”, and their output can optionally be redirected to a file for later review. Others explicitly place text into a matrix of fixed width character cells on a screen (sometimes with specific foreground and background colors).
Historically, input to the text application itself is provided exclusively through a keyboard interface, though Automatic Speech Recognition (ASR) based voice input is sometimes now an alternative option - especially on mobile devices.
Strategies for making text applications accessible through assistive technology involve two key tasks: (1) obtaining all of the text displayed in the interface, and (2) performing an analysis on that text to detect screen updates and attempt to discern structural elements.
For example, a text application screen reader might directly access the matrix of character cells in the interface and provide a screen review mechanism for the user to review that matrix of characters (by sending the output to synthetic speech and/or a braille display). Alternately, a text application screen reader might directly consume the output rendered (perhaps by acting as its own terminal application or by analyzing the “TTY” output). A text application screen reader might also attempt to analyze the spacing and layout of the text in the matrix, to provide features such as reading columns of text in a multi-column layout; discerning headers through analysis of line spacing, indentation, and capitalization; and discerning input fields or user interface components by scanning for the use of inverse video, for text appearing in brackets, or for text from the character graphics codepage (ASCII codes greater than ‘0x7F’). Some of this analysis might also be done through the use of filter tools that transform the output of a program (e.g., through reformatting “TTY” output rendered to a file or as direct input to a filter tool).
Similarly, a text application screen magnifier would gain access to the matrix of character cells to magnify them or re-display them in a larger font. It would scan for screen refreshes and updates and then apply heuristics to what had changed in order to decide what sub-matrix of character cells should appear in a magnified view. It would also scan for inverse video and a moving text cursor to track text being input by the user (and might combine the text matrix scanning with scanning of the keyboard input to match user input to what is appearing on the screen).
To apply WCAG to text applications, it is necessary to apply the glossary terms accessibility supported and programmatically determined in the context of how text applications are rendered and the history of assistive technologies that made them accessible.
As noted above, in a text interface the terminal application renders the characters on the screen, just as a web browser typically renders content for a web application. As an example, for success criterion 1.4.4 Resize Text, a text application could achieve 200 percent resizing when the terminal application client that is rendering it has this capability (cf. WCAG 2 Technique G142 Using a technology that has commonly-available user agents that support zoom). Many web pages and web applications use this approach to meet success criterion 1.4.4 Resize Text through no explicit action of their own.
A similar approach could also be used for success criterion 1.4.3 Contrast (minimum) (cf. WCAG 2 Technique G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults): relying on the terminal application client to render the text with sufficient contrast against the background. In fact, many terminal applications allow the user to force all text to share a single user-chosen foreground color (and a single user-chosen background color), overriding the text application's specified colors to meet the user's desires or needs.
Since many assistive technology analysis techniques depend upon discerning the location of the text input cursor, terminal application use of “soft cursors” and “highlight bars” may bypass those analysis techniques and cause failures of success criteria.
Note 1
It is outside of the scope of this document to define WCAG techniques for non-web ICT. These examples are simply illustrations of how WCAG 2 success criteria can be applied to this class of non-web software applications.
The way to think about "accessibility supported" and "programmatically determined" may seem a little different for text applications, but the definitions are unchanged. Unlike the semantic objects of graphical user interfaces and web pages, the output of text-based applications consists of plain text. A terminal emulator acts as the user agent for text-based applications; it might render some content such as escape codes as semantic elements, but otherwise exposes only lines of text to assistive technology. Where assistive technology is able to interpret the text and any semantic objects accurately, the content is "programmatically determinable"—even though no explicit markup was necessarily used to make it so.
Note 2
The terminal application itself is “traditional” non-web software ICT. It is only for the text application that there is a need to take this approach with these glossary terms.
WCAG2ICT Task Force participants are also in the AG working group, but are not repeated here.
Special thanks goes to members of the APA working group that contributed their expertise in document reviews and in updates to the Text / Command-line / Terminal Applications and Interfaces content.
The following people contributed to the development of the 2013 WCAG2ICT Note.
Shadi Abou-Zahra, Bruce Bailey, Judy Brewer, Michael Cooper, Pierce Crowell, Allen Hoffman, Kiran Kaja, Andrew Kirkpatrick, Peter Korn, Alex Li, David MacDonald, Mary Jo Mueller, Loïc Martínez Normand, Mike Pluke, Janina Sajka, Andi Snow-Weaver, Gregg Vanderheiden
This publication has been funded in part with U.S. Federal funds from the Health and Human Services, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services or the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
Work on this publication was part of the WAI-CooP Project, a European Commission (EC) co-funded project, Horizon 2020 Program (101004794).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4