WCAG2ICT Introduction

From WCAG WG

Introduction

This Working Draft 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. This document is intended to become a Working Group Note (in contrast to WCAG 2.0, which is a W3C Recommendation and also an ISO standard.) Specifically, this Working Draft provides informative guidance on applying WCAG 2.0 Level A and AA success criteria to non-Web information and communications technologies (ICT), specifically 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 needs due to ageing. 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 the different context of use. The bulk of the Task Force’s work therefore involved evaluating how each WCAG 2.0 success criteria 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”. Thirteen of these twenty-six applied without any additional notes. 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 nine of them they 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 three success criteria apply in situations when "a set of web pages", or "multiple web pages" share some characteristic or behavior. For these, the task force found that (with substitutions) the success criteria apply to non-web documents fairly straightforwardly. The task force does not yet have guidance for how to apply these three success criteria in a software context.

Excluded from Scope

The following aspects are out of scope for this document:

  • This document does not seek to determine which WCAG 2.0 provisions (principles, guidelines, or success criteria) should or should not apply to non-web ICT, but rather how they would apply, if applied. It does not address level AAA success criteria.
  • This document does not propose changes to WCAG 2.0 itself, nor its supporting documents; and does not include interpretations for implementing WCAG 2.0 in web technologies. During the development of this document, the WCAG2ICT task force did seek clarification on the intent of a number of the success criteria which led to additions to the Understanding WCAG 2.0 document.
  • This document does not address potential gaps in requirements when WCAG 2.0 is used with non-web documents and software; thus, this document is not sufficient by itself to ensure accessibility in non-web documents and software.
  • This document does not comment on hardware aspects of products, non-user interface aspects of platforms, or user-interface components as individual items, because the basic constructs on which WCAG 2.0 is built do not apply to these.
  • This document does not provide supporting techniques for implementing WCAG 2.0 in non-web documents and software.

Document Overview

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 (Editors’ Draft), as clarified based on input from Task Force discussions and responses to public comments after review and approval by the WCAG Working Group. This document also includes new text under “Additional Guidance,” as provided by the WCAG2ICT Task Force, then reviewed and approved by the WCAG Working Group.

Later drafts of this document may include excerpts from the Conformance Section of WCAG 2.0 and Understanding WCAG 2.0, together with “Additional Guidance” from the Task Force following review and approval by the WCAG Working Group; however, this draft does not include any guidance on conformance.

Additional supporting documents for WCAG 2.0, such as the WCAG 2.0 Overview, Techniques for WCAG 2.0, 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.

Understanding Key Terms

< INSERT KEY TERMS SECTION ALREADY APPROVED BY WCAG WG HERE >

Closed Functionality

Interoperability with assistive technology was an underlying assumption in the development of WCAG 2.0. To provide meaningful access to interfaces and information, many of the success criteria require the exposure of content to assistive technologies (programmatically determined) or information be provided in text so that assistive technologies can make it available in an alternative output modality. WCAG 2.0 also assumes that users may use alternative input devices.

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 AT cannot be used, other output and input solutions are needed to achieve the intent of these success criteria.

It is not within the scope of the WCAG2ICT task force, however, to define alternate provisions that are suitable for closed functionality, recommend changes to existing success criteria to accommodate closed functionality, or recommend additional success criteria; but it is useful to point out, in the list below, the WCAG 2.0 guidelines that are intended to support interoperability with attached AT. These success criteria will be problematic for developers of closed functionality:

  • 1.1.1 Non-text Content - Because it requires text or a text alternative
  • 1.2.1 Pre-recorded video - Because it requires a text alternative for time based media
  • 1.2.3 Audio description or Media Alternative - Because it one of the options here is to provide a text alternative
  • 1.2.8 Media Alternative (Pre-recorded) - Because it requires a text alternative for time based media
  • 1.3.1 Info and Relationships - Because it requires information in a programmatically determinable form
  • 1.3.2 Meaningful Sequence - Because it requires information in a programmatically determinable form
  • 1.4.4 Resize Text - Because, according to the intent, the web author's responsibility is is create web pages that do not interfere with user agent zoom features.
  • 1.4.5 Images of Text - Because there is no interoperability with assistive technology, there is no need to impose a requirement on all closed functionality that text displayed on the screen actually be represented internally as text (as defined by WCAG 2.0)
  • 2.1.1 Keyboard - Because it requires operation via a keyboard interface which allows alternative input devices
  • 2.1.3 Keyboard (no exceptions) - Because it requires operation via a keyboard interface which allows alternative input devices
  • 2.4.2 Page Titled - Because, where software is an integral part of hardware that provides a single function, such as a calculator or IP telephone, there is no need for a title.
  • 3.1.1 Language of Page - Because it requires information in a programmatically determinable form
  • 3.1.2 Language of Parts - rBecause it equires information in a programmatically determinable form
  • 3.1.6 Pronunciation - Because, according to the intent, this is to allow screen readers to pronounce text correctly.
  • 3.3.1 Error Identification -Because, while it's important for errors that can be detected to be described to the user, for closed functionality, the error description doesn't have to be provided in text, as defined in WCAG 2.0.
  • 4.1.1 Parsing - Because the intent of 4.1.1 is to provide consistency so that different user agents or assistive technologies will yield the same result.
  • 4.1.2 Name, Role, Value - Because it requires information in a programmatically determinable form

An example of closed functionality is a travel kiosk that provides an audio interface for blind and vision-impaired users as a built-in alternative to the visual interface and tactile keys as an alternative to touch screen operation for both blind users and those who can't operate a touch screen.

Note: 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.


FURTHER IMPROVEMENT SUGGESTIONS

  • Go a little slower in the intros
  • better rationales or intro to rationals
  • possibly re-introduce the purpose (from the status) in the intro
Retrieved from "https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG2ICT_Introduction&oldid=1658"