This document, “Guidance on Applying WCAG 2.2 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) 2.2 [WCAG22] and its principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).
This document is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the WCAG2ICT Overview.
This 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 technical reports index at https://www.w3.org/TR/.
This is a Technical Report on Applying WCAG 2.2 to Non-Web Information and Communications Technologies (WCAG2ICT). The intent of this work is to update the existing guidance based on new WCAG 2.1 and 2.2 success criteria.
The current draft includes guidance for WCAG 2.1 success criteria. Guidance on WCAG 2.2 success criteria will be added later this year as WCAG 2.2 becomes a W3C Recommendation. The next draft will also address open issues on WCAG 2.0 criteria.
The group is seeking feedback on the following aspects:
The group is already aware of formatting differences in how quoted passages from WCAG are included in comparison to the previous WCAG2ICT Working Group Note.
Currently there are known issues in the quoted content from WCAG and Understanding Intent sections:
The group is currently working on updates to the format, styling, and linking for these passages, and expects to refine these in a future draft.
This document was published by the Accessibility Guidelines Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 03 November 2023 W3C Process Document.
This document is an update to a W3C Working Group Note to incorporate new guidelines, success criteria, and definitions added in WCAG 2.1 and 2.2.
Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT), approved in September 2013, described how WCAG 2.0 could be applied to non-web documents and software. WCAG2ICT was organized to mirror WCAG's sections: Perceivable, Operable, Understandable, and Robust. WCAG2ICT clarified when and how WCAG success criteria should be applied to non-web documents and software. Some were applicable without modification and some were applicable with edits and/or notes. Glossary terms were also reviewed. Level AAA Success Criteria were not addressed in the 2013 WCAG2ICT Working Group Note.
The 2013 WCAG2ICT has been relied upon in regulations and legislation. One example is EN 301 549[^1] (Europe) and other standards that reference or incorporate EN 301 549 (e.g., India, Kenya, Australia). Another example is Section 508 (U.S.) Application of WCAG 2.0 to Non-Web ICT, which looked to WCAG2ICT for detailed direction with providing specific guidance and exceptions to particular criteria from being applied to non-web technology. Section 508 incorporated by reference WCAG as the Accessibility Standard applicable to non-web documents and requires WCAG Conformance for non-web software.
[^1]: EN 301 549 V3.2.1 2.2 Informative references, p. 13 [i26].
This document provides informative guidance (guidance that is not normative and that does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) 2.2 [WCAG22] to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.1 and WCAG 2.2, which are W3C Recommendations). Specifically, this document provides informative guidance on applying WCAG 2.2 Level A and AA success criteria to non-web ICT, specifically to non-web documents and software.
This document is intended to help clarify how to use WCAG 2.2 to make non-web documents and software more accessible to people with disabilities. Addressing accessibility involves addressing the needs of people with auditory, cognitive, neurological, physical, speech, and visual disabilities, and the needs of people with accessibility requirements due to the effects of aging. Although this document covers a wide range of issues, it is not able to address all the needs of all people with disabilities. Because WCAG 2.2 was developed for the Web, addressing accessibility for non-web documents and software may involve requirements and considerations beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-web documents and software are accessible, as much as possible, to people with disabilities.
While WCAG 2.2 was designed to be technology-neutral, it assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Therefore, the application of WCAG 2.2 to documents and software in non-web contexts required some interpretation in order to determine how the intent of each WCAG 2.2 success criterion could be met in these different contexts of use. Therefore, the bulk of the Task Force's work involved evaluating how each WCAG 2.2 success criterion would apply in the context of non-web ICT, if it were applied to non-web ICT.
The Task Force found that the majority of success criteria from WCAG 2.2 can apply to non-web documents and software with either no or minimal changes. Since many of the Level A and AA success criteria do not include any web related terms, they apply directly as written and as described in the “Intent” sections from the Understanding WCAG 2.2 [UNDERSTANDING-WCAG22] resource. Additional notes were provided, as needed, to provide assistance in applying them to non-web documents and software.
When certain Web-specific terms or phrases like “web page(s)” were used in success criteria, those were replaced with non-web terms or phrases like “non-web document(s) and software”. Additional notes were also provided to explain the terminology replacements.
A small number of success criteria are written to apply to “a set of web pages” or “multiple web pages” and require all pages in the set to share some characteristic or behavior. Since the unit of conformance in WCAG 2.2 is a single web page, the task force agreed that the equivalent unit of conformance for non-web documents is a single document. It follows that an equivalent unit of evaluation for a “set of web pages” would be a ”set of documents”. Since it isn't possible to unambiguously carve up non-web software into discrete pieces, a single “web page” was equated to a “software program” and a “set of web pages” was equated to a “set of software programs. Both of these new terms are defined in the Key Terms section of this document. See “set of documents” and “set of software programs” to determine when a group of documents or pieces of software are considered a set.
The glossary terms were also reviewed and most of them applied to non-Web documents and software, as written. Some applied with additional notes or edits (largely related to phrases like “Web page(s)”), and a small number of terms were only used in Level AAA success criteria which are not addressed by the WCAG2ICT Note at this time.
The following are out of scope for this document:
This document includes text quoted from the WCAG 2.2 principles, guidelines, and success criteria, without any changes. It also includes excerpted text from the “Intent” sections of the WCAG 2.2 supporting document Understanding WCAG 2.2 (Public Review Draft) [UNDERSTANDING-WCAG22]. The guidance provided by this document for each 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 AG Working Group.
Additional supporting documents for WCAG 2.2, such as the WCAG 2 Overview, Techniques for WCAG 2.2 [WCAG22-TECHS], and How to Meet WCAG (Quick Reference), remain available for web content, but have not been changed to apply to non-web documents and software.
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 visually styled as bold green text with a dotted underline.
<cite>elements visually styled as ordinary text with a dotted underline, and contain title attributes noting these are WCAG definitions. They turn blue with a yellow background when mouse or keyboard focus is placed over them.
<cite>elements visually styled as ordinary text with a dark gray underline.
The WCAG2ICT Task Force has incorporated all of the new WCAG 2.1 guidelines, criteria and glossary terms. The next draft version will incorporate new WCAG 2.2 criteria and glossary terms as well as address open issues on any of the content in the document.
The following changes and additions have been made to update the 2013 WCAG2ICT document:
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.2 that need to be interpreted significantly differently when applied to non-web ICT. The glossary term “Web page” in WCAG 2.2 is replaced with newly defined terms “document” and “software”, and both “set of web pages” and “multiple web pages” are replaced with the newly defined terms “set of documents” and “set of software programs”. The new terms introduced by WCAG2ICT are “accessibility services of platform software” because non-Web software doesn't leverage the WCAG 2.2 notion of a user agent, and "closed functionality" which is specific to non-web software. The remaining glossary terms from WCAG 2.2 are addressed in Chapter 7 Comments on Definitions in WCAG 2.2 Glossary. Terms defined and used in WCAG2ICT are applicable only to the interpretation of the guidance in this document. The particular definitions should not be interpreted as having applicability to situations beyond the scope of WCAG2ICT. Further information on usage of these terms follows.
The term accessibility services of platform software, as used in WCAG2ICT, has the meaning below:
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
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:
To support users with disabilities, products with closed functionality can instead provide built-in features that function as assistive technology.
Example: Examples of technology with closed functionality include: retail self-checkout machine, automated banking machine (a.k.a. Automated Teller Machine, or ATM), ticket kiosk, calculator, printer, smart TV, set-top box and a computer that is locked down so that users may not adjust settings due to a policy.
WCAG 2.2 defines content as:
information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions
For non-web content it is necessary to view this a bit more broadly. Within WCAG2ICT, the term “content” is used as follows:
information and sensory experience to be communicated to the user by means of , including code or markup that defines the content's structure, presentation, and interactions
Non-web content occurs in two places; documents and software. When content occurs in a document, a user agent is needed in order to communicate the content's information and sensory experience to the user. When content occurs in software, a separate user agent isn't required—the software itself performs that function.
Within WCAG2ICT wherever “content” or “web content” appears in a success criterion it is replaced with “content” using the definition above.
The term document, as used in WCAG2ICT, has the meaning below:
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
A document always requires a user agent to present its content to the user.
Letters, spreadsheets, emails, books, pictures, presentations, and movies are examples of documents.
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.
A collection of files zipped together into an archive, stored within a single virtual hard drive file, or stored in a single "encrypted file system" file, do not constitute a single document. The software that archives/encrypts those files or manages the contents of the virtual hard drive does not function as a user agent for the individually collected files in that collection because that software is not providing a non-fully functioning presentation of that content.
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.
Example: An assembly of files that represented the video, audio, captions and timing files for a movie would be a document.
Counterexample: A binder file used to bind together the various exhibits for a legal case would not be a document.
The term set of documents, as used in WCAG2ICT, has the meaning below:
collection of that share a common purpose, are created by the same author, group or organization
Republishing or bundling previously published documents as a collection does not constitute a set of documents.
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 that share a common purpose, are created by the same author, group or organization
Although "sets of web pages" occur frequently, "sets of software programs" appear to be extremely rare.
Redistributing or bundling previously distributed software as a collection does not constitute a set of software programs.
Consistent does not mean identical. For example, if a list of choices is provided it might not include the name of the current program.
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.
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).
If there is any ambiguity whether the group is a set, then the group is not a set.
If there is no independent method to launch the software programs (as is common in closed products), those programs would not meet the definition of a "set of software programs".
Although the term “software” is used throughout this document because this would apply to stand alone software programs as well as individual software components and the software components in software-hardware combinations, the concept of “set of software programs” would only apply (by definition) to programs that can be launched separately from each other. Therefore, for the provisions that use the phrase “set of” (success criteria 2.4.1, 2.4.5, 3.2.3, and 3.2.4), the phrase “set of software programs” is used.
Example: One example of a set of software programs would be a group of programs that can be launched and used separately but are distributed together and all have a menu that allows users to launch, or switch to, each of the other programs in the group.
Counterexamples: Examples of things that are not sets of software programs:
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 require a separate user agent to present any of its content
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.
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.
Because software with a user interface provides a function equivalent to a user agent in addition to content, the application of some WCAG 2.2 success criteria would be different for content embedded in software versus content in a document, where it is viewed through a separate user agent (e.g. browser, player, viewer, etc.).
WCAG 2.2 defines user agent as:
- user agent
any software that retrieves and presents Web content for users
Example: Web browsers, media players, plug-ins, and other programs—including assistive technologies—that help in retrieving, rendering, and interacting with Web content.
any software that retrieves and presents for users
Software that only displays the content contained within it is not considered to be a user agent. It is just considered to be software.
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.
Software that only shows a preview of content such as a thumbnail or other non-fully functioning presentation is not providing user agent functionality.
As noted in the Introduction, WCAG 2.2 assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Furthermore, many of the success criteria in WCAG 2.2 assume web content will be accessed by ICT that has assistive technologies connected to it, where the assistive technologies present the web content to the people with disabilities in accessible form. ICT products with “closed functionality” do not allow the use of some assistive technologies for all of their functions. In many cases such ICT products also lack a “user agent” or their equivalent. As a result, ICT following these success criteria by themselves will not make information accessible on ICT with closed functionality. Something else needs to be provided or be required in order to make the information addressed in these success criteria accessible. It is outside the WCAG2ICT Task Force Work Statement to say what the additional measures are, but this Note points out which success criteria depend on assistive technologies—and therefore would not work by themselves in products with closed functionality.
Because closed functionality, by definition, does not allow a user to attach assistive technology, WCAG success criteria that assume the presence of assistive technology will not facilitate accessibility as WCAG 2.2 intends. Where assistive technologies cannot be used, other output and input solutions are needed to achieve the intent of these success criteria.
Examples of products with closed functionality include:
See Appendix A: Success Criteria Problematic for Closed Functionality for a list of success criteria for which this is relevant.
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 which 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.
This section is non-normative.
This Working Group Note does not introduce any new privacy considerations. Horizontal Review Groups are encourage to provide further feedback during the Horizontal Review process.
This section is non-normative.
This Working Group Note does not introduce any new security considerations. Horizontal Review Groups are encourage to provide further feedback during the Horizontal Review process.
In the next public draft, the WCAG2ICT Task Force will remove obsolete criteria and add new WCAG 2.2 criteria if any are problematic for Closed Functionality. The Task Force may also make updates to existing WCAG 2.0 content in this section to reflect new insights learned since the 2013 WCAG2ICT Note.
There are Success Criteria that can be problematic for developers of 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. Other Success Criteria would apply to systems 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 systems which are closed to screen readers, but have a physical keyboard or a connector for standard keyboards. While these criteria, as written, are not always applicable to closed functionality, most of them can inform and aid development of built-in features needed to make closed functionality products accessible. For non-web software on closed functionality products, alternate accessibility provisions might be needed to cover the user needs addressed by the following Success Criteria:
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.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.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.
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.
Special thanks goes to members of the APA working group that contributed their expertise to updates in 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 by funds from the following organizations:
The content of this publication does not necessarily reflect the views or policies of the Ford Foundation and/or the European Commission, nor does mention of trade names, commercial products, or organizations imply endorsement by the aforementioned organizations.