Home‎ > ‎

- Introduction to WCAG2ICT Application Note



***************NOTICE************************************************ 
                                                                                                       
  This work space is being phased out and is no longer kept        
  updated with the latest task force agreements. Please refer to  
  the most recent WCAG2ICT public draft at                                 
  http://www.w3.org/TR/wcag2ict/                                                  
                                                                                                       
************************************************************************* 



PROPOSAL FROM ANDI: Editorial suggestions for referencing "this document" and the task force are highlighted in yellow below and summarized as follows:

  • WCAG2ICT Task Force should always be spelled out; i.e. don't use WCAG2ICT TF. Task Force should always have initial CAPS. 
  • In the introduction, use "this document". After that, use WCAG2ICT to avoid confusion with our guidance on "documents"
  • Add a bullet to Document Conventions explaining that hereafter, WCAG2ICT will be used to reference this document


                                                                                                                               .
               <NEW TEXT TO SEND OUT FOR PUBLIC DRAFT #3                         .
                                                                                                                               .

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 International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) 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 requirements due to 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”. 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. 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 four 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.
  • 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 clarifications in the Understanding WCAG 2.0 document.
  • Because this document deals with applying WCAG, which is a standard for content accessibility, to ICT it does not deal with such things as closed products and requirements for non-user interface aspects of platforms, nor individual components. As such, 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, hereafter referred to as WCAG2ICT, 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. The guidance provided by the WCAG2ICT 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.  

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. Later drafts may include "Additional Guidance" on level AAA success criteria.

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

Document Conventions

The following stylistic conventions are used in this document:

  • Quotes from WCAG 2.0 and Understanding WCAG 2.0 are in <blockquote> elements and visually styled as pale yellow inset boxes in slightly smaller text. They are prefaced by a reference to the original source such as “From {reference title} in {document}”.
  • Additional guidance provided by this document is visually styled in pale blue boxes labeled by a heading having a dark blue background.
  • Quotes from WCAG 2.0 that are presented as modified by the advice in this document have the modifications in <ins> elements visually styled as bold red text with dotted underlines.
  • Notes are slightly inset and begin with the phrase “Note:”. If there are multiple notes for a specific item, they are numbered, e.g., “Note 1:”, etc.
  • References to glossary items, both in WCAG 2.0 and in this document, are presented in <cite> elements visually styled as ordinary text with a dotted underline.
  • Hereafter, the short title "WCAG2ICT" is used to reference this document. 

















                                                                                                                               .
               <NEW TEXT TO SENT OUT FOR REVIEW #2                                     .
                                                                                                                               .

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 OverviewTechniques 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

There are several terms used throughout WCAG 2.0 that need to be interpreted differently when applied to non-Web ICT. These include: Web page, content, user agent, assistive-technology support, accessibility supported, and programmatically determined.

In addition, several terms are used within this draft document that are not part of WCAG 2.0. These terms include: non-web content and software (as used in this document).

Further information on usage of these terms follows.

Content (on and off the web)

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 we need to view this a bit more broadly. Within our document, we use the term content as follows:
content (non-Web content)
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 does that.

Within WCAG2ICT wherever CONTENT or WEB CONTENT appears in a success criterion or INTENT it should be replaced with CONTENT using the "definition" above.

The terms Document and Software as used in WCAG2ICT, have the meanings below:

Document (as used in WCAG2ICT)
assembly of content, such as a file, set of files, or streamed media that is not part of software and that does not include its own user agent


Note 1. Documents always require 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. 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 4. 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.).


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

Note 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 verses content in a document, where it is viewed through a separate user agent (e.g. browser, player, viewer, etc.).

User Agent


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 this differentlyIn 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:

user agent
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.

Closed Functionality (updated per November 20th TF meeting)

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.  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 of the taskforce work statement to say what the additional measures are,  but we can point out which success criteria depend on assistive technologies - and therefore would not work by themselves in products with closed functionality. 

Examples of products with closed functionality include:

  • an ebook or ebook reader program that allows assistive technologies to access all of the user interface controls of the ebook program  (open functionality) but does not allow the assistive technologies to access the actual content of book (closed functionality).
  • an operating system that requires the user to provide log in credentials before it allows any assistive technologies to be loaded.  The log-in portion would be closed functionality. 
  • 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. 

The following success criteria depend on assistive technologies to make information accessible.  They either discuss making information available in text (which can be read by assistive technologies) or making it "programmatically determinable" (readable by assistive technologies) or discuss doing something else to make content compatible with assistive technologies.   Alternate accessibility provisions would be needed that would address the purpose of these success criteria for the closed functionality aspects of products. 

  • 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 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  - bacause 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 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), given that there is no interoperability with assistive technology
  • 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  - because it requires 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

Note: Some of the above success criteria would apply to systems with closed functionality if they are partially closed or if the allow for the connection of some types of devices. For instance, 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: 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.













The introduction is now being worked on by several teams and individuals. 

The following links take you to a separate page discussing each section.  

When consensus is reached they will all be brought back here.











Include this in the introduction section when discussing content and user agent.

What differentiates non-embedded content from software is this: non-embedded content needs a user agent (e.g. browser or player) in order to be viewed and/or interacted with.  This user agent assumes some of the responsibility for making the non-embedded content accessible.  There is a grey area where non-embedded content may blur into software.  If there is any doubt, then treat the subject material as software

<   POST JULY 27TH PUBLIC DRAFT CONSENSUS ITEMS ARE ABOVE  >.   
 <  POST JULY 27TH PROPOSALS ARE BELOW>


Proposal #4 (new proposal from Peter & Gregg based on WCAG WG feedback to the TF on 6Dec12 relating to SC1.4.4's presence in Appendix A)

New/changed text appears in red; removed text with strike-through

========================

<<FROM Section 3 Closed Functionality>>

Closed 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 of the taskforce work statement to say what the additional measures are,  but we can point 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.


...

----------------------

<<From Appendix A Success Criteria Problematic for Closed Functionality>>

The 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 would be needed that would address the purpose of these success criteria for the closed functionality aspects of products.

  • ...
  • 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. - while the success criterion notes that text should be resized up to 200 percent without assistive technology, there is also the assumption of a user agent rendering the text, which has the ability to re-layout the content and scroll the content (and potentially also to resize the content itself).  This may not be the case for some ICT with closed functionality.  We note that one of the advisory techniques for 1.4.4 is "Providing large fonts by default", which may address the underlying needs of users with low vision in closed ICT - particularly in cases where only one or a few words are being displayed and already fill the entire screen, 200% enlargement may not be possible or helpful.



Proposal #5 (new proposal from Peter & Gregg based on WCAG WG feedback to the TF on 6Dec12 relating to defining "set of documents" in Key Terms)

New/changed text appears in red; removed text with strike-through

========================

<<From Key Terms in the Introduction>>

Key Terms

There are several terms used throughout WCAG 2.0 that need to be interpreted differently when applied to non-Web ICT. These include: “content”, and “user agent”. Further, the 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 term "set of documents / multiple documents".

Further information on usage of these terms follows.

...

set of documents / multiple documents (as used in WCAG2ICT)

group of documents that are published together, and where the items all refer to each other by name or link.

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

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

...


<<From SC 2.4.1>

Additional guidance when applying Success Criterion 2.4.1 to Electronic Documents and Software Aspects of Products:

For Documents:

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “Web pages” with “ documents in a set of non-web documents and assuming that “set” means a group of items 1) that are published together, and 2) where the items all refer to each other by name or link

With these substitutions, it would read:

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

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 documents. 

One example of a set documents would be a 3 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. Each table of contents might have additional navigation mechanisms for the particular chapter in which it is included, but the items that are repeated in all of the chapters (i.e. the navigation mechanisms to the other chapters) would be in the same order relative to each other.

For Software: 

The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 2.4.1.



<<From SC 2.4.5>

Additional guidance when applying Success Criterion 2.4.5 to Electronic Documents and Software Aspects of Products:

For Documents:

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “Web pages” with “non-web documents” and assuming that “set” means a group of items 1) that are published together, and 2) where the items all refer to each other by name or link.

With these substitutions, it would read:

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

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 documents.

Note 31: Authors should assume that an infrastructure exists to allow a user to locate documents in the set; for example, by selecting links within a member of the set, browsing through the files that make up the set, or by searching within members of the set for the names of the other members.

Note 42: A file directory would be the equivalent of a site map for documents in that it provides a link to each of the documents in the set of documents. The directory also acts as the HOME for the set.

Note 53: A search function in a file system (that finds documents) would be equivalent to a Web search function for Web pages.

Note 64Authors can assume that the non-Web documents will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary.

One example of a set documents would be a 3-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. Each table of contents might have additional navigation mechanisms for the particular chapter in which it is included, but the items that are repeated in all of the chapters (i.e. the navigation mechanisms to the other chapters) would be in the same order relative to each other.

For Software: 

The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 2.4.5.


<<From SC 3.2.3>

Additional guidance when applying Success Criterion 3.2.3 to Electronic Documents and Software Aspects of Products:

For Documents:

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “Web pages” with “non-web documents” and assuming that “set” means a group of items 1) that are published together, and 2) where the items all refer to each other by name or link.

With these substitutions, it would read:

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

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 documents. 

One example of a set documents would be a 3 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. Each table of contents might have additional navigation mechanisms for the particular chapter in which it is included, but the items that are repeated in all of the chapters (i.e. the navigation mechanisms to the other chapters) would be in the same order relative to each other.

For Software: 

The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 3.2.3.

Proposal #6 (as edited in the TF meeting December 11th) 

New/changed text appears in red; removed text with strike-through as compared with what WCAG2ICT approved previously.

========================

<<From Key Terms in the Introduction>>

Key Terms

There are several terms used throughout WCAG 2.0 that need to be interpreted differently when applied to non-Web ICT. These include: “content”, and “user agent”. Further, the 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 term "set of documents".

Further information on usage of these terms follows.

...

set of non-web documents (as used in WCAG2ICT)

group of documents that are published together, and where the items all refer to each other by name or link.

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

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

...


<<From SC 2.4.1>

Additional guidance when applying Success Criterion 2.4.1 to Electronic Documents and Software Aspects of Products:

For Documents:

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “Web pages” with “ documents within a set of non-web documents” and assuming that “set” means a group of items 1) that are published together, and 2) where the items all refer to each other by name or link

With these substitutions, it would read:

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

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 documents.  

One example of a set documents would be a 3 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. Each table of contents might have additional navigation mechanisms for the particular chapter in which it is included, but the items that are repeated in all of the chapters (i.e. the navigation mechanisms to the other chapters) would be in the same order relative to each other.

For Software: 

The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 2.4.1.



<<From SC 2.4.5>

Additional guidance when applying Success Criterion 2.4.5 to Electronic Documents and Software Aspects of Products:

For Documents:

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “Web page” with “non-web document” and "set of Web pages" with "set of non-web documents"  and assuming that “set” means a group of items 1) that are published together, and 2) where the items all refer to each other by name or link.

With these substitutions, it 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 except where the document is the result of, or a step in, a process.

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 documents.

Note 31Authors should assume that an infrastructure exists to allow a user to locate documents in the set; for example, by selecting links within a member of the set, browsing through the files that make up the set, or by searching within members of the set for the names of the other members.

Note 42A file directory would be the equivalent of a site map for documents in that it provides a link to each of the documents in the set of documents. The directory also acts as the HOME for the set.

Note 53A search function in a file system (that finds documents) would be equivalent to a Web search function for Web pages.

Note 64Authors can assume that the non-Web documents will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary.

One example of a set documents would be a 3-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. Each table of contents might have additional navigation mechanisms for the particular chapter in which it is included, but the items that are repeated in all of the chapters (i.e. the navigation mechanisms to the other chapters) would be in the same order relative to each other.

For Software: 

The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 2.4.5.


<<From SC 3.2.3>

Additional guidance when applying Success Criterion 3.2.3 to Electronic Documents and Software Aspects of Products:

For Documents:

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “multiple Web pages” with “non-web multiple documents” and "set of Web pages" with "set of non-web documents" and assuming that “set” means a group of items 1) that are published together, and 2) where the items all refer to each other by name or link.

With these substitutions, it would read:

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

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 documents. 

One example of a set documents would be a 3 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. Each table of contents might have additional navigation mechanisms for the particular chapter in which it is included, but the items that are repeated in all of the chapters (i.e. the navigation mechanisms to the other chapters) would be in the same order relative to each other.

For Software: 

The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 3.2.3.





Proposal #7 (agreed by WCAG2ICT on 11Dec12, in reaction to WCAG WG feedback to the TF on 6Dec12 relating to SC1.4.4's presence in Appendix A)

New/changed text appears in red; removed text with strike-through as compared with what WCAG2ICT approved previously.

========================

<<FROM Section 3 Closed Functionality>>

Closed 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 of the taskforce work statement to say what the additional measures are,  but we can point 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.


...

----------------------

<<From Appendix A Success Criteria Problematic for Closed Functionality>>

The 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 would be needed that would address the purpose of these success criteria for the closed functionality aspects of products.

  • ...
  • 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. - while the success criterion notes that text should be resized up to 200 percent without assistive technology, it also makes the assumption that a user agent is rendering the text. This provides solution strategies that would not be present for some types of closed ICT (e.g. using the zoom or text enlargement features in a browser, the ability of a browser to re-layout the text and scroll it).  We note that one of the advisory techniques for 1.4.4 is "Providing large fonts by default", which may address the underlying needs of users with low vision in closed ICT - particularly in cases where only a small number of words are being displayed in a font that is much larger than 200% of a typical web page. Where this large text fills the entire screen, 200% enlargement may not be possible or helpful.



Proposal #8 (fallback text agreed by WCAG2ICT on 11Dec12, in reaction to WCAG WG feedback to the TF on 6Dec12 relating to SC1.4.4's presence in Appendix A - assuming that WCAG WG doesn't approve proposal #7 with SC 1.4.4 in the list)

New/changed text appears in red; removed text with strike-through as compared with what WCAG2ICT approved previously.

========================

<<FROM Section 3 Closed Functionality>>

Closed 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 of the taskforce work statement to say what the additional measures are,  but we can point 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.


...

----------------------

<<From Appendix A Success Criteria Problematic for Closed Functionality>>

The 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 would be needed that would address the purpose of these success criteria for the closed functionality aspects of products.

  • ...
  • 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.

Note 3: WCAG has not yet resolved whether 1.4.4 Resize Text belongs on this list of Success Criteria Problematic for Closed Functionality



                                                                                                                                   .
               <TEXT AS SENT OUT FOR REVIEW ON  JULY 27TH                             .
                                                                                                                                   .

1. Introduction

This draft document provides informative guidance (guidance that is neither normative nor requirement-setting) with regard to the interpretation and application of the Web Content Accessibility Guidelines (WCAG) 2.0 to non-Web Information and Communications Technologies (ICT).

This draft document is intended to help clarify how to use WCAG 2.0 to make non-Web ICT more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities, including the changing abilities of people due to aging. Although the informative guidance in this draft document covers a wide range of issues, it is not able to address the needs of people with all types, degrees, and combinations of disability. Authors are encouraged to seek relevant advice about current best practices to ensure that non-Web ICT is accessible, as far as possible, to this community.

This draft document has been developed by the WCAG2ICT Task Force under the coordination and review of the Web Content Accessibility Guidelines Working Group (WCAG WG), which is part of the Web Accessibility Initiative (WAI) Technical Activity of the World Wide Web Consortium (W3C). The 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 draft document is available for public review and comment according to the information in the Status section.

Document Overview

The organization of this document parallels the organization of WCAG 2.0 in that it includes principles, guidelines, success criteria, and a conformance section. It also includes explanatory material paralleling the WCAG 2.0 supporting document Understanding WCAG 2.0 (Editors Draft). However, while WCAG 2.0 applies normatively to web content, the contents of this document apply only informatively to non-Web ICT. Additional supporting materials for WCAG 2.0, that may or may not be relevant to non-Web ICT, are available from or linked from the WCAG 2.0 Overview.

While WCAG 2.0 was designed to be technology-neutral, it does for example assume the presence of a user agent. The application of WCAG 2.0 in non-Web ICT contexts therefore requires some interpretation in order to remain consistent with the intent of each WCAG 2.0 Success Criterion and the different context of use. This document does not address gaps in requirements that could potentially materialize when WCAG 2.0 is used with non-Web ICT; it is therefore important to note that WCAG 2.0 may not be sufficient by itself to ensure accessibility in non-Web ICT. Also, this document does not provide supporting techniques for implementing WCAG 2.0 in non-Web ICT.

This draft document focuses on non-web ICT, specifically non-web electronic documents and software aspects of products. It may address how individual WCAG 2.0 A, AA, and AAA success criteria, the principles and the guidelines would apply to non-Web ICT, and what WCAG 2.0 Conformance would mean in this context.

This document does not seek to determine what WCAG 2.0 provisions should or should not apply to non-Web ICT, nor does it propose changes to WCAG 2.0 or its supporting techniques or interpretations for implementing WCAG 2.0 in Web technologies.

This document does not comment on hardware aspects of products, non-UI aspects of platforms, or the application of WCAG 2.0 for user-interface components as a category, because the basic constructs on which the WCAG 2.0 and/or its conformance are built do not apply to these.

Understanding Key Terms

There are several terms used throughout WCAG 2.0 that may need to be interpreted differently when applied to non-Web ICT. These include: Web page, content, user agent, assistive technology support, accessibility supported, and programmatically determined. Once available, a discussion of these terms will be included, pointing to the glossary for the definitions.

In addition, several terms are used within this draft document that are not part of WCAG 2.0. These terms include: non-Web software aspects of products, non-Web software, non-Web electronic documents. Once available, a discussion of the final list of terms used will be included, pointing to the glossary for the definitions.

Editors' note: Several places use essentially the same terms with slightly different wording. These will be reconciled to be the same wording where they mean the same thing in the next draft. Specifically these include variants of "software aspects of products", "Software User Interfaces", "electronic documents"/"interactive documents", and others.

2. Comments by Guideline and Success Criterion

The sections that follow are organized according to the principles, guidelines, and success criteria from WCAG 2.0. The text of the item from WCAG 2.0 is copied as quoted text. Following that, the "intent" from Understanding WCAG 2.0 is copied as quoted text. Finally, the guidance of this document is provided. In visual presentations this is set out in a box with a blue bar to the left, to highlight that this is the content specific to this document.



                                                                                                                                   .
         </ END OF 
TEXT AS SENT OUT FOR REVIEW ON  JULY 27TH    >            .
                                                                                                                                   .




Introduction to Applying WCAG 2.0 to non-Web Information and Communications Technologies

This draft document provides informative guidance (guidance that is neither normative nor requirement-setting) with regard to the interpretation and application of the Web Content Accessibility Guidelines (WCAG) 2.0 to non-Web Information and Communications Technologies (ICT).

This draft document is intended to help 
clarify how to use WCAG 2.0 to make non-Web ICT more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities, including the changing abilities of people due to aging. Although the informative guidance in this draft document covers a wide range of issues, it is not able to address the needs of people with all types, degrees, and combinations of disability. Authors are encouraged to seek relevant advice about current best practices to ensure that non-Web ICT is accessible, as far as possible, to this community.

 

This draft document has been developed by theWCAG2ICT Task Force under the coordination and review of the Web Content Accessibility Guidelines Working Group (WCAG WG), which is part of the Web Accessibility Initiative (WAI) Technical Activity of the World Wide Web Consortium (W3C). The 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 draft document is available for public review and comment according to the information in the Status section. 

Document Overview

The organization of this document parallels the organization of WCAG 2.0 in that it includes principles, guidelines, success criteria, and a conformance section. It also includes explanatory material paralleling the WCAG 2.0 supporting document Understanding WCAG 2.0 (Editors Draft). However, while WCAG 2.0 applies normatively to web content, the contents of this document apply only informatively to non-Web ICT. Additional supporting materials for WCAG 2.0, that may or may not be relevant to non-Web ICT, are available from or linked from the WCAG 2.0 Overview.

 

While WCAG 2.0 was designed to be technology-neutral, it does for example assume the presence of a user agent. The application of WCAG 2.0 in non-Web ICT contexts therefore requires some interpretation in order to remain consistent with the intent of each WCAG 2.0 Success Criterion and the different context of use. This document does not address gaps in requirements that could potentially materialize when WCAG 2.0 is used with non-Web ICT; it is therefore important to note that WCAG 2.0 may not be sufficient by itself to ensure accessibility in non-Web ICT. Also, this document does not provide supporting techniques for implementing WCAG 2.0 in non-Web ICT.

This draft document focuses on non-web ICT, specifically non-web electronic documents and software aspects of products. It may address how individual WCAG 2.0 A, AA, and AAA success criteria, the principles and the guidelines would apply to non-Web ICT, and what WCAG 2.0 Conformance would mean in this context.

This document does not seek to determine what WCAG 2.0 provisions should or should not apply to non-Web ICT. Nor does it propose changes to WCAG 2.0 or its supporting techniques or interpretations for implementing WCAG 2.0 in Web technologies.

This document does not comment on hardware aspects of products, non-UI aspects of platforms, or the application of WCAG 2.0 for user-interface components as a category, because the basic constructs on which the WCAG 2.0 and/or its conformance are built do not apply to these.

Understanding Key Terms

There are several terms used throughout WCAG 2.0 that may need to be interpreted differently when applied to non-Web ICT. These include:
@@ [Web page, content, user agent, assistive technology support, accessibility supported, and programmatically determined.] [Once available, a discussion of these terms will be included, pointing to the glossary for the definitions].

In addition, several terms are used within this draft document that are not part of WCAG 2.0. These terms include:
@@[non-Web software aspects of products, non-Web software, non-Web electronic documents] [Once available, a discussion of the final list of terms used will be included, pointing to the glossary for the definitions.]

Editor note: Several places use essentially the same terms with slightly different wording. These will be reconciled to be the same wording where they mean the same thing in the next draft. Specifically these include variants of "software aspects of products", "Software User Interfaces", "electronic documents"/"interactive documents", and others.



                                                                                                                                   .
</ END OF TASK FORCE CONSENSUS CONTENT FOR APPLICATION NOTE >.
              (only EDITORS should make edits above this line.                                      .
     -- and then only after text is approved by consensus by the Task force.              .
                                                                                                                                   .

Two items from one of the commenters (WCAG survey) 


1) Suggest adding text similar to that below to the end of paragraph #2

There are many international standards that focus on or include specific accessibility support for file formats, general software concerns, telecommunication, and other electronic technologies that may be of help in that endeavor.

And a variation that came up during the discussion:  There are many guidelines, application notes, and standards that focus on or include specific accessibility support for file formats, general software concerns, telecommunication, and other electronic technologies that may be of help in that endeavor.


2)  Next, under "Document Overview"

paragraph #2 begins by stating that WCAG 2.0 was designed to be "technology neutral". This sounds, in this content, as if is is being asserted that WCAG 2.0 was always intended to apply to all kinds of ICT. WCAG 2.0, however, in it's definition for "technology", states that "Note 1: As used in these guidelines "Web Technology" and the word "technology" (when used alone) both refer to Web Content Technologies." Therefore, I would have to read all of WCAG 2.0 as intending to apply to only Web Content Technologies, because that it what the definitions tell me. Now in this document, the Task Force is asserting that it was intended to apply to other technology? I'm confused. I don't think you can have it both ways. Either your definition in WCAG 2.0 is incorrect, or your assertion that WCAG 2.0 was intended to be technology neutral, without qualification, is misleading.

<         CONSENSUS WAS REACHED ON THIS ITEM.   
 Place any "Post-Consensus"  notes, including notes from public, ABOVE THIS NOTICE / >



<    Start of feedback from WCAG on this item >

Ok with the following edits:
This draft document is intended to help make non-Web ICT more accessible to people with disabilities." -> "This draft document is intended to help clarify how to use WCAG 2.0 to make non-Web ICT more accessible to people with disabilities."

"what WCAG 2.0 Conformance means" -> "what WCAG 2.0 Conformance would mean"

<    END of feedback from WCAG on this item >





PROPOSED CONTENT FOR INTRODUCTION  -- STILL A WORK IN PROCESS -- NO CONSENSUS ON THIS CONTENT (ONLY WHAT IS ABOVE THE  "  </END OF TASK FORCE CONSENSUS CONTENT FOR APPLICATION NOTE>" MARKER ABOVE

Proposal #1 (Judy Brewer) ========================

Introduction to Applying WCAG 2.0 to non-Web Information and Communications Technologies

This draft document provides informative guidance (guidance that is neither normative nor requirement-setting) with regard to the interpretation and application of the Web Content Accessibility Guidelines (WCAG) 2.0 to non-Web Information and Communications Technologies (ICT). It is intended to help organizations that wish to use a single, well-established set of guidelines and principles – WCAG 2.0 – across ICT that they develop, procure, and/or assess for accessibility.

 

This draft document is intended to help make non-Web ICT more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities, including changing abilities of people due to aging. Although the informative guidance in this draft document covers a wide range of issues, it is not able to address the needs of people with all types, degrees, and combinations of disability. Authors are encouraged to seek relevant advice about current best practices to ensure that non-Web ICT is accessible, as far as possible, to this community.

 

This draft document has been developed by the WCAG2ICT Task Force under the coordination and review of the Web Content Accessibility Guidelines Working Group (WCAG WG), which is part of the Web Accessibility Initiative (WAI) Technical Activity of the World Wide Web Consortium (W3C). The 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 draft document is available for public review and comment according to the information in the Status section.

 

Document Overview

 

The organization of this document parallels the organization of WCAG 2.0 in that it includes principles, guidelines, success criteria, and a conformance section. It also includes and links to explanatory material paralleling the WCAG 2.0 supporting document Understanding WCAG 2.0. However, while WCAG 2.0 applies normatively to web content, all of the contents of this document apply only informatively to non-Web ICT. Additional supporting materials for WCAG 2.0, that may or may not be relevant to non-Web ICT, are available from or linked from the WCAG 2.0 Overview.

 

This draft document focuses on non-web ICT, specifically non-web electronic documents and software aspects of products. It may address how individual WCAG 2.0 A, AA, and AAA success criteria, the principles and the guidelines would apply to non-Web ICT, and what WCAG 2.0 Conformance means in this context.

 

This document does not seek to determine what WCAG 2.0 provisions should or should not apply to non-Web ICT, nor to address potential gaps in provisions that potentially should apply to non-Web ICT. It does not propose changes to WCAG 2.0 nor its supporting techniques or interpretations for implementing WCAG 2.0 in Web technologies.This document does not comment on hardware aspects of productsnon-UI aspects of platforms, or the application of WCAG 2.0 to user-interface components as a category, because the basic constructs on which the WCAG 2.0 and/or its conformance are built do not apply to these.  

Understanding Key Terms

There are several terms used throughout WCAG 2.0 that may need to be interpreted differently when applied to non-Web ICT. These include:

@@ [Web page, content, user agent, assistive technology support, accessibility supported, and programmatically determined.] [Once available, a discussion of these terms will be included, pointing to the glossary for the definitions].

In addition, several terms are used within this draft document that are not part of WCAG 2.0. These terms include:

@@[non-Web software aspects of products,non-Web software, non-Web electronic documents] [Once available, a discussion of the final list of terms used will be included, pointing to the glossary for the definitions.]

 

 

Proposal #2 for Editors Notes (Peter Korn) ========================

[Proposal is to include the bulletted list of "to-do" items of pending editorial tasks as an Editor's Note to appear in this front section, perhaps as part of "Document Overview]

Editor's Note: Carry out the following editorial tasks:

  • Modify all variants of "software aspects of products" in SCs x, y, z so that they are written in the same way
  • Modify all variants of "Software User Interfaces" in SCs x, y, z so that they are written in the same way
  • Modify all variants of "electronic documents"/"interactive documents" in SCs x, y, z so that they are written in the same way
  • [if we use "top-level-frame" in more than one SC] Modify all variants of "top-level-frame" in SCs x, y, z so that they are written in the same way

[Note: I don't think the style sheet allows bulletted lists in Editor note sections]

Editor note: Several places use essentially the same terms with slightly different wording.  These will be reconciled to be the same wording where they mean the same thing.  Specifically these include:
    V
ariants of "software aspects of products" in SCs x, y, z
    V
ariants of "Software User Interfaces" in SCs x, y, z
    Variants of "electronic documents"/"interactive documents" in SCs x, y, z
    [if we use "top-level-frame" more than one place, then Variants of "top-level-frame" in SCsx, y, z]




Proposal #3 for  Gregg reformatting of Editors Notes to proper form ========================

[Proposal is to include the bulletted list of "to-do" items of pending editorial tasks as an Editor's Note to appear in this front section, perhaps as part of "Document Overview]

<Peter, the editors note should be addressed to the reviewers - not the editors>

How about this

Editor's Note: In reading the document and commenting on this document the following things should be kept in mind:

  • The following terms appear in different success criteria in slightly different ways.  In the next draft they will be reviewed and made consistent. 
    • Software
    • Software aspects of products
    • Software user interfaces
    • Electronic documents/interactive documents
    • <Add any other terms that we use that are not here>
  • We will also be defining any terms that are not already defined in WCAG


Previous Proposals (Various) ===========================

Introduction to Applying WCAG 2.0 to non-Web Information and Communications Technologies


This document is intended to help organizations that wish to use a single, well-established set of guidelines and principles – WCAG 2.0 – across all of the ICT that they develop, procure, and/or assess for accessibility. It is consistent with the WCAG WG charter which includes the following under its scope: "Coordinating with other entities adopting and using WCAG 2.0."

This document does not comment on hardwarenon-UI aspects of platforms,or the application of WCAG 2.0 to user-interface components as a category, because the basic constructs on which the Web Content Accessibility Guidelines (WCAG) and/or its conformance are built do not apply to these.   

  • Hardware aspects of a product are not commented on because many (not all but many) of the guidelines are based on the assumption that the information is presented electronically and/or controlled via electronic devices (e.g. keyboard, mouse, etc.) and this is not true for the hardware aspects of a product; information can be printed on the device, and controls can be mechanical and electrical.  The UI-software and electronic display aspects of these same products (e.g. a kiosk) would be covered. 
  • This document does not deal with non-user interface aspects of platforms (like platform architecture or services)  but does apply to 'user-interface aspects of platforms", as described below.  
  • Finally, the conformance model for WCAG is based a web page or set of web pages.  It is therefore not possible for individual user-interface components to conform to WCAG just as it is not possible for a section of a web page to conform to WCAG..

Instead the document focuses on 
  • documents  and 
  • User interface contexts in software including both stand alone software and the software aspects hardware products.

Some of the success criteria may or may not be individually applicable or adapted to apply to ICT in general outside of Electronic Documents and Software aspects of products.  This document however focuses on the application of the guidelines to non-web based Electronic Documents and user interface contexts within stand alone software or software aspects of hardware products. 


Introduction to WCAG 2.0  (Quoted from the WCAG 2.0 introduction)

"Web Content Accessibility Guidelines (WCAG)2.0 was developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.0 is designed to apply broadly to different Web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation."

"WCAG 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general."

"Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community."

Introduction to applying WCAG 2.0 to ICT

WCAG 2.0 was developed within the context of web technologies, and while [most of ? - (to be determined)] the principles, guidelines, and success criteria can be applied directly to non-Web ICT, some assistance is helpful in understanding how the intent of the guidelines, success criteria, and conformance would be applied to non-web content. 

As noted above, WCAG 2.0 is not sufficient to address all of the accessibility aspects of even of web content.  Similarly, WCAG provisions will not be sufficient to meet all of the accessibility aspects of non-web ICT.   In addition, non-web ICT presents some aspects that were covered in other ways for web content (such as those covered by user agents).  So while WCAG 2.0 may be used to cover some aspects of accessibility in a uniform fashion across web and non-web content, it should not be viewed as obviating the need for any other guidelines.  

Understanding Key Terms

In applying WCAG 2.0 to ICT there several terms that are used throughout WCAG (because it was referring to Web Content specifically) that would need to be interpreted differently when applying the WCAG 2.0 provisions to non-web electronic documents, software or ICT in general. It is helpful to start by reviewing the comments on these terms before looking at each provision individually.   They are Web page (or Page)   (and Set of web pages),  Content, and  User Agent


< Here are some of the key terms we need to discuss here.  But they are cross cutting to the discussion will be in the Cross cutting Issues section >

  1. "Web Page"  (or Page)
  2. "Content"   

  3.  "User Agent"

  4. Assistive Technology Support
    • accessibility supported
    • assistive technology
    • programmatically determined
< the above are discussed in   Interpretation of Web Terms (Web Page, etc) >

Definition of "Electronic Documents" and "Software Aspects of Products" in this application note.

Much of this document will focus on describing how WCAG 2.0 should be interpreted when applying it to non-web based Electronic Documents and Software Aspects of Products. 
It is important therefore to understand what we mean by these two terms in this context.

< The discussion of what goes here is in   "Non-Web Softwr" & "NW Elect Docs" >

Key term to define here --   "user interface context

<END OF PROPOSED CONTENT FOR INTRODUCTION>



DISCUSSION POINTS, OPINIONS, ISSUES, NOTES etc. 


Something that might be useful in writing the intro

From issue 2671

It is not clear exactly what change you are suggesting to address this question of interoperability. Part of the effort of this committee is to create language that allows rules to be harmonized internationally, but also harmonized across content types. For example if a document is distributed off of the web but also posted to the web it would be much better for authors if they didn’t have to follow different sets of rules. Also if interactivity or a game-like activity is added to an educational document, it would be helpful if it didn't suddenly become subject to a completely different set of rules.

Due to the scope of the committee’s work, we must simply provide clarity about applying the more general principles in the guidelines and success criteria to non-web ICT. Specific techniques will have to be developed outside of this group, as were developed in support of the original Section 508. 

As for conformance, testing for conformance is definitely not an easy task as many accessibility principles require manual checking by humans rather than automated verification. No matter which accessibility standards are applied (ISO, WCAG, etc.) there will always be an issue with the amount of manual verification that must be done and the cost/burden to complete it. Tools could be developed to make conformance checking easier, but there will always be a manual aspect to the verification. 






Issue #1:  Should we also call out specific types of software that this work doesn't expressly apply to (e.g. authoring tools, for which a mapping of ATAG to non-web ICT might be a different, and analogous effort).


 From M376 -   Draft EN "European accessibility requirements for public procurement of ICT products and services"


    For Electronic Documents 
    · The WCAG 2.0 terms shown in the "WCAG 2.0 terms" column of Table 1 shall be taken to mean the same as the corresponding terms shown in the "Electronic content and documents terms" column of Table 1. Table1: The interpretation of WCAG 2.0 terms when used in the context of electronic documents and content
  • WCAG 2.0 terms

    Electronic content and documents terms

    component

    user interface element

    web page, page

    document

    For Software





EDITORS NOTE:  
For Reference, here is the Introduction to Understanding WCAG 2.0.