This document is available in an expandable / collapsible alternate version in which the “Intent” sections copied from Understanding WCAG 2.0 are hidden and individually expandable, for easier reading.
Copyright © 2012-2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
AbstractThis document, “Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] 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 intended to become a Working Group Note, and is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the WCAG 2.0 Overview.
Status of This DocumentThis section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is an Editors' Draft being developed by the WCAG2ICT Task Force (“Task Force”) operating under the terms of its Work Statement, and under the coordination and review of the Web Content Accessibility Guidelines Working Group (WCAG WG), which is part of the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). The WCAG2ICT Task Force's work is consistent with the WCAG WG Charter that includes the following under its scope: “Coordinating with other entities adopting and using WCAG 2.0”.
This document includes many excerpts from “Understanding WCAG 2.0,” each of which is prefaced with the words “Intent from…” and which are also visually indicated with a yellow background. Understanding WCAG 2.0 and other WCAG 2.0 supporting documents will continue to focus on web technologies. For comments on Understanding WCAG, please follow the comment instructions in that document.
Please note that WCAG 2.0 itself is a stable web standard. Comments on this document will not affect WCAG 2.0 wording.
Publication as an Editors' Draft does not imply endorsement by the W3C Membership. 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 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. 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.
1. IntroductionThis 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.0 [WCAG20] to non-web information and communications technologies (ICT). This document is a Working Group Note (in contrast to WCAG 2.0, which is a W3C Recommendation and also an International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) standard). Specifically, this document provides informative guidance on applying WCAG 2.0 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.0 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.0 was developed for the Web, addressing accessibility for non-web documents and software may involve provisions 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 far as possible, to people with disabilities.
While WCAG 2.0 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.0 to documents and software in non-web contexts required some interpretation in order to determine how the intent of each WCAG 2.0 success criterion could be met in these different contexts of use. The bulk of the Task Force's work therefore involved evaluating how each WCAG 2.0 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.0 can apply to non-web documents and software with no or only minimal changes. Specifically, of the thirty-eight Level A and AA success criteria, twenty-six did not include any web related terms and apply directly as written and as described in the “Intent” sections from the updated Understanding WCAG 2.0 [UNDERSTANDING-WCAG20]. Thirteen of these twenty-six applied without any additional notes. The other thirteen applied as written but additional notes were also provided for assistance in applying them to either or both non-web documents and software.
Of the remaining twelve success criteria, the Task Force found that eight of them apply as written when replacing certain Web-specific terms or phrases like “web page(s)” with non-web terms or phrases like “non-web document(s) and software” or “for non-web documents and software that use markup languages, in such a way that…” etc. Additional notes were also provided to assist in the application of these.
The remaining four success criteria apply in situations when “a set of web pages”, or “multiple web pages” share some characteristic or behavior. In WCAG 2.0 the “unit of conformance” is the web page. While WCAG2ICT is not a standard, and thus conformance does not apply, it is still useful to look at what a “unit of evaluation” would be for non-web ICT. For non-web documents, WCAG2ICT uses a single document as the “unit of evaluation”, as it is the best analog to a web page. This became the basis for the notion of a “set of documents”, which is used for the remaining four success criteria which in WCAG speak to “sets of web pages”. For non-web software it wasn't possible to unambiguously carve up software into discrete pieces, and so the “unit of evaluation” for non-web software is the software program. This became the basis for the notion of a “set of software programs”, which is used for the remaining four success criteria.
The 83 glossary terms were also reviewed. 51 applied to non-Web documents and software as written. Another 28 applied with additional notes or edits (largely related to phrases like “Web page(s)”), and the remaining 4 terms were only used in Level AAA success criteria which are not addressed by this Note.
1.1. Excluded from ScopeThe following are out of scope for this document:
This document includes excerpted text from WCAG 2.0 principles, guidelines, and success criteria, as quoted from WCAG 2.0 without any changes. It also includes excerpted text from the “Intent” sections of the WCAG 2.0 supporting document Understanding WCAG 2.0 (Public Review Draft) [UNDERSTANDING-WCAG20], as clarified based on input from Task Force discussions and responses to public comments after review and approval by the WCAG Working Group. The guidance provided by this document for each success criteria is preceded by a title beginning “Additional Guidance…”. This guidance was created by the WCAG2ICT Task Force, then reviewed and approved by the WCAG Working Group.
Additional supporting documents for WCAG 2.0, such as the WCAG 2.0 Overview, Techniques for WCAG 2.0 [WCAG20-TECHS], and How to Meet WCAG 2.0: A customizable quick reference, remain available for web content, but have not been changed to apply to non-web documents and software.
1.3. Document ConventionsThe following stylistic conventions are used in this document:
Of the 83 glossary terms used in WCAG 2.0 there are two key glossary terms that need to be interpreted significantly differently when applied to non-web ICT. These are: “content” and “user agent”. Further, the glossary term “Web page” in WCAG 2.0 is replaced with newly defined terms “document” and “software”, and both “set of web pages” and “multiple web pages” are replaced with the newly defined terms “set of documents” and “set of software programs”. Finally, as part of addressing the fact that non-Web software doesn't leverage the WCAG 2.0 notion of a user agent, we introduce the new term “accessibility services of platform software”. The remaining 79 glossary terms from WCAG 2.0 are addressed in Chapter 7 Comments on Definitions in WCAG 2.0 Glossary in Appendix A. 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.
2.1. Accessibility Services of Platform SoftwareThe 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.
WCAG 2.0 defines CONTENT as:
- content (web content)
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: 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 or Intent it should be replaced with “content” using the definition above.
2.3. DocumentThe 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 requires 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 when so collected together. The software that archives/encrypts those files or manages the contents of the virtual hard drive does not function as a user agent for the individually collected files in that collection because that software is not providing a non-fully functioning presentation of that content.
Note 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.
2.4. Set of DocumentsThe term set of documents, as used in WCAG2ICT has the meaning below:
group of documents that are published together, and where the items 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.
One example of a set of documents would be a three-part report where each part is a separate file. At the beginning of each file the table of contents for “navigating” to the other parts is repeated.
2.5. Set of Software ProgramsThe term set of software programs, as used in WCAG2ICT has the meaning below:
group of software programs that are distributed together and that can be launched and used independently from each other, but that are interlinked each with every other one such that users can navigate from one program to another via a consistent method that appears in each member of the set
Note 1: This definition of “set of software programs” is derived from the characteristics of a “set” of web pages, and is used for mapping WCAG success criteria to software. Although such sets occur frequently for web pages, such sets appear to be extremely rare for software.
Note 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 closed products), those programs would not meet the definition of a set of 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, 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
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.0 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.0 defines user agent as follows:
- user agent
any software that retrieves and presents Web content for users
Example: Web browsers, media players, plug-ins, and other programs—including assistive technologies—that help in retrieving, rendering, and interacting with Web content.
For non-web ICT, “user agent” needs to be viewed differently. In WCAG 2.0, 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 user agent functionality.
As noted in the Introduction, WCAG 2.0 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.0 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 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.0 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.
4. Text / Command-line / Terminal Applications and InterfacesText 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 terminal applications which render text applications in the GUI may utilize a mouse or other input devices). Command-line applications are a subset of text applications with further specific properties.
Historically, assistive technologies developed alongside text applications, and several of these use a variety of analysis and scripting techniques to make text applications accessible. Although there are far fewer new text applications being developed compared to new GUI or web applications, text applications remain in use today, and both text applications and the assistive technologies designed for text applications are in active development.
Though this class of applications predates the Web, WCAG can be applied to them. 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.
Appendix A. Success Criteria Problematic for Closed FunctionalityThe following success criteria will be problematic for developers of closed functionality. They either discuss making information available in text (which can be read by assistive technologies) or making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies) or discuss doing something else to make content compatible with assistive technologies. Alternate accessibility provisions that would be needed to address the purpose of these success criteria for the closed functionality aspects of products:
Note 1: Some of the above success criteria would apply to systems with closed functionality if they are partially closed or if they allow for the connection of some types of devices. For instance, Success Criterion 2.1.1 Keyboard would apply to systems which have closed functionality to screen readers but which have a physical keyboard or a connector for standard keyboards.
Note 2: While these guidelines are not suitable for closed functionality as written, they will inform and aid development of built-in accessible alternatives needed with closed functionality.
Appendix B. Background on Text / Command-line / Terminal Applications and Interfaces Appendix B.1. How text interfaces are realizedThe interface of a text application is realized through a text application directing which characters should be placed on the screen, along with either a hardware terminal or a terminal application that displays the characters produced by the text application. 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). Similar to a web application, the text application may execute primarily on a remote server or execute locally, and a local client terminal application handles the visual display (similar to a web user agent). Input to the text application itself is provided exclusively through a keyboard interface.
Appendix B.2. How text applications have been made accessible via assistive technologyStrategies 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 discern structural elements and screen updates.
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). The text application screen reader would also 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, etc. by scanning for the use of inverse video or for text appearing in brackets or 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 too).
Similarly, a text application screen magnifier would gain access to the matrix of character cells in order to magnify them or re-display them in a larger font. It would scan for screen refreshes / updates and 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).
Appendix B.3. Applying WCAG 2.0 to text applicationsTo 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. Thus for example, in 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.0 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.0 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 in order 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: It is outside of the scope of this document to define WCAG techniques for non-web ICT. These examples are simply raised here to illustrate how WCAG 2.0 success criteria can be applied to this older class of applications that pre-date the Web.
The way to think about “accessibility supported” and “programmatically determined” may seem a little different for text applications, but the definitions are unchanged. Because assistive technologies developed analysis techniques to recognize many forms of tabular layout, column headers, and section headings, such recognized layouts are by definition “accessibility supported”. Where assistive technology is able to extract and present that information, it is “programmatically determinable”—even though no explicit markup or API was used to make it so. While such assistive technology analysis techniques are not used for supporting newer technologies, the fact that such previous analysis work was done allows us to apply WCAG 2.0 to text / command-line applications.
Note: 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.
Appendix C. Acknowledgements Appendix C.1. Participants in the WCAG2ICT Task ForceThe following people were active participants in the WCAG2ICT Task Force, which had a primary role in preparation of this document:
The following people were active participants in the Web Content Accessibility Guidelines Working Group, which reviewed materials to ensure consistency with the intent of WCAG 2.0 and provided final approval of the Working Group Note:
This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED-OSE-10-C-0067. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.
Appendix D. ReferencesRetroSearch 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