Challenges & Proposals for Remaining 4 SCs



***************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/                                                  
                                                                                                       
************************************************************************* 


====  Update to SC 2.4.5: new Note 5 =====

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web page(s)” with "non-web document(s)" and "software program(s)

With these substitutions, this success criterion would read:
(due to the length or number of the substituted phrases for four success criteria including this one, the substitutions for documents and software are shown separately to make them easier to 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 non-web document is the result of, or a step in, a process.  
-  More than one way is available to locate a software program within a set of software programs except where the software program is the result of, or a step in, a process.   

Note 1: See  “set of documents  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)   

Note 2: The definitions of "set of documents" and "set of software programs" in the Key Terms section are predicated on the ability to navigate from each element of the set to each other, and navigation is a type of locating. So the mechanism used to navigate between elements of the set will be one way of locating information in the set.  Non-web environments, generally major operating systems with browse and search capabilities, often provide infrastructure and tools that provide mechanisms for locating content in a set of non-web documents or a set of software programs. For example, it may be possible to browse through the files or programs that make up a set, or search within members of the set for the names of other members. A file directory would be the equivalent of a site map for documents in a set, and a search function in a file system would be equivalent to a web search function for web pages. Such facilities may provide additional ways of locating information in the set.      

Note 3: An example of the use of 'a software program that is part of process', that would meet the exception for this SC, would be one where programs are interlinked but the interlinking depends on program A being used before program B, for validation or to initialize the dataset etc.  

Note 4: While some users may find it useful to have multiple ways to locate some groups of user interface elements within a document or software program, this is not required by the success criterion (and may pose difficulties in some situations).

Note 5: The definitions of "set of documents" and "set of software" in WCAG2ICT require every item in the set to be independently reachable, and so nothing in such a set can be a "step in a process" that can't be reached any other way.  The purpose of the exception - that items in a process are exempt from meeting this success criterion- is achieved by the definition of set.

-- RESOLVED 24May13
-- APPROVED BY WCAG WG 4June13
--> NEEDS TO BE INCORPORATED BY MICHAEL INTO WCAG2ICT
MC: Note 5 is now incorporated into WCAG2ICT 2.4.5































====  CLEAN COPY OF 
PROPOSAL  22   FROM WCAG -- with only editorial changes from editor - pre-approved by Task Force

NOTE: Underlined text indicates an important link.

Pending editorial changes that need to be approved by all editors are highlighted in yellow.


Definition  of Set of Software: 

Set of software

The term Set of software, as used in WCAG2ICT has the meaning below:

set of software programs: (as used in WCAG2ICT)     

group of software programs that are distributed together and that can be launched and be 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 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" 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:

  • A suite of applications for authoring different types of documents (text, spreadsheets, presentations, etc.) but that don't provide an explicit, consistent means to launch, or switch to, each of the other programs in the group. 
  • An office package consisting of multiple programs that launches as a single program that provides multiple functionalities such as writing, spreadsheet, etc., but the only way to navigate between programs open a document in one of the programs.
  • A bundle of software is sold together but the only way to navigate between them is to use a platform software level menu to navigate between programs (not a menu provided by each program that allows you to do just the other programs this set).
  • A group of programs that was a set but the programs have been moved to separate locations so that their "set" behaviors were disrupted and no longer work. Even though they were set at one time, because they are no longer installed as a set they no longer are a set and would not need to meet any success criteria that apply to sets of software.
Added to WCAG2ICT. ID is keyterms_set-of-software

2.4.1 - Bypass Blocks   ============
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

 Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “multiple web pages” with "multiple non-web documents in a set of non-web documentsor  "multiple software programs in a set of software programs to explicitly state that the multiple documents (or software programs) are part of a set rather than any two documents or pieces of software

With these substitutions, this success criterion would read: 
(due to the length or number of the substituted phrases for four success criteria including this one, the substitutions for documents and software are shown separately to make them easier to read)

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

Note 1: See  “set of documents”  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)       

Note 2: Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

Note 3:  Although not required by the success criterion, being able to bypass blocks of content that are repeated within non-web documents or software directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.

Note 4: Many software user interface components have built-in mechanisms to navigate directly to/among them, which also have the effect of skipping over or bypassing blocks of content.

Added to WCAG2ICT. Note struck the "multiple" from the change description, as it was repeated in each change and therefore not part of the change.

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web page(s)” with "non-web document(s)" and "software program(s)

With these substitutions, this success criterion would read:
(due to the length or number of the substituted phrases for four success criteria including this one, the substitutions for documents and software are shown separately to make them easier to 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 non-web document is the result of, or a step in, a process.  
-  More than one way is available to locate a software program within a set of software programs except where the software program is the result of, or a step in, a process.   

Note 1: See  “set of documents  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)   

Note 2: The definitions of "set of documents" and "set of software programs" in the Key Terms section are predicated on the ability to navigate from each element of the set to each other, and navigation is a type of locating. So the mechanism used to navigate between elements of the set will be one way of locating information in the set.  Non-web environments, generally major operating systems with browse and search capabilities, often provide infrastructure and tools that provide mechanisms for locating content in a set of non-web documents or a set of software programs. For example, it may be possible to browse through the files or programs that make up a set, or search within members of the set for the names of other members. A file directory would be the equivalent of a site map for documents in a set, and a search function in a file system would be equivalent to a web search function for web pages. Such facilities may provide additional ways of locating information in the set.      

Note 3: An example of the use of 'a software program that is part of process', that would meet the exception for this SC, would be one where programs are interlinked but the interlinking depends on program A being used before program B, for validation or to initialize the dataset etc.  

Note 4: While some users may find it useful to have multiple ways to locate some groups of user interface elements within a document or software program, this is not required by the success criterion (and may pose difficulties in some situations).

Added to WCAG2ICT.


PART 4)

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

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" and "software programs” 

With these substitutions, this success criterion would read:
(due to the length or number of the substituted phrases for four success criteria including this one, the substitutions for documents and software are shown separately to make them easier to read)

3.2.3 Consistent Navigation:
- Navigational mechanisms that are repeated on multiple non-web 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." 
Navigational mechanisms that are repeated on multiple software programs within a set of software programs occur in the same relative order each time they are repeated, unless a change is initiated by the user." 

Note 1: See  “set of documents”  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or software programs is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)      

Note 2:   Although not required by the success criterion, ensuring that navigation elements have consistent order when repeated  within non-web documents or software programs directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.

Added to WCAG2ICT.


PART 5)

3.2.4: Consistent Identification (Level AA) ===
Components that have the same functionality within a set of Web pages are identified consistently

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" "software programs” 

With these substitutions, this success criterion would read:
(due to the length or number of the substituted phrases for four success criteria including this one, the substitutions for documents and software are shown separately to make them easier to read)

3.2.4 Consistent Identification:  

- Components that have the same functionality within a set of non-web documents are identified consistently.     
Components that have the same functionality within a set of software programs  are identified consistently       

Note 1: See  “set of documents”  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or software programs is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)     

Note 2:  Although not required by the success criterion, ensuring that component identification be consistent when they occur more than once within non-web documents or software programs directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.

Added to WCAG2ICT.

CHANGE TO BE MADE TO THE "INTENT" OF 3.2.4 IN UNDERSTANDING WCAG 2.0 

"If there are 2 components on a web page that both have the same functionality as a component on another page in a set of web pages, then all 3 must be consistent. Hence the 2 on the same page will be consistent. 

While it is desirable and best practice always to be consistent within a single web page, 3.2.4 only addresses consistency within a set of web pages where something is repeated on more than one page in the set." 


MC: Not clear on the nature of the edit, is this added text or edits to existing text, and if so which part? Not added to WCAG2ICT yet.




====  END OF CLEAN COPY     ====  (all else below is scratch work)



















































































====  PROPOSAL  22  (Proposal 21 with WCAG WG EDITS FROM SURVEY)     ====

The WCAG WG has approved all of the text proposed by WCAG2ICT Taskforce with a few editorial comments.  These are shown in Red with yellow 
highlight below. Briefly the are

  1. WCAG2ICT text sometimes used "Set of software" and sometimes used "Set of software programs".  WCAG WG felt it should be consistent unless we meant them to mean different things.  The edits made them consistent by making them all "set of software programs".  We (the task force) are free to make them all "set of software",  "set of software programs" or "set of software (programs)" as we wish though. 
  2. A few editorial changes  
    • Non-examples changed to Counterexamples
    • removing double "have's" from "have navigation elements have" by changing it to "ensure that navigation elements have"
    • Some tense and grammar fixes
  3. Adding a phrase to the  "With these substitutions" sentences for the "set of " provisions where we split the substitution sentences into two sentences to explain why. 
  4. adding a note 3 to 2.4.5 to provide an example of software programs that would constitute a process so that the exception language was not be removed from 2.4.5.
The most significant was a consolidation of 5 notes in 2.4.5 that it was felt were hard to understand into one note that it was felt was easier to follow and combined the ideas from the other 5 notes.  Please read this over carefully in advance to see if any important aspect of the 5 notes was not captured in the new note.

GV: Suggest a new note on the Def of Set of Software

Note 8:  Although "software" is used throughout this document because this would apply to stand alone software products as well as the software components in software-hardware products, the concept of 'Set of software" would only apply (by definition) to products that can be launched separately from each other.  For the "set of" provision therefore  "set of software products" is used.       [ or "set of software (products)" or whatever else we use ]


WCAG EDITS in RED with HIGHLIGHT

Definition  of Set of Software: 

set of software programs: (as used in WCAG2ICT)     

group of software programs that are distributed together and that can be launched and be 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 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" 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:

    • A suite of applications for authoring different types of documents (text, spreadsheets, presentations, etc.) but that don't provide an explicit, consistent means to launch, or switch to, each of the other programs in the group. 
    • An office package consisting of multiple programs that launches as a single program that provides multiple functionalities such as writing, spreadsheet, etc., but the only way to navigate between programs open a document in one of the programs.
    • A bundle of software is sold together but the only way to navigate between them is to use a platform software level menu to navigate between programs (not a menu provided by each program that allows you to do just the other programs this set).
    • A group of programs that was a set but the programs have been moved to separate locations so that their "set" behaviors were disrupted and no longer work. Even though they were set at one time, because they are no longer installed as a set they no longer are a set and would not need to meet any success criteria that apply to sets of software.


2.4.1 - Bypass Blocks   ============
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

 Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “multiple web pages” with "multiple non-web documents in a set of non-web documentsor  "multiple software programs in a set of software programs to explicitly state that the multiple documents (or software programs) are part of a set rather than any two documents or pieces of software

With these substitutions (shown separately for the provisions that involve the phrase "set of", to make the substitutions easier to read), this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or pieces of software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)        <BE SURE BOLD TEXT IS A LINK HERE> 

Note 2: Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

Note 3:  Although not required by the success criterion, being able to bypass blocks of content that are repeated within non-web documents or software directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.

Note 4: Many software user interface components have built-in mechanisms to navigate directly to/among them, which also have the effect of skipping over or bypassing blocks of content.

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web page(s)” with "non-web document(s)" and "software program(s)

With these substitutions (shown separately for the provisions that involve the phrase "set of", to make them easier to read), this success criterion would read:

2.4.5 Multiple Ways:  
 More than one way is available to locate a non-web document within a set of non-web documents  except where the non-web document is the result of, or a step in, a process.<BE SURE UNDERLINED TEXT IS A LINK>
-  More than one way is available to locate a software program within a set of software programs except where the software program is the result of, or a step in, a process.   <BE SURE UNDERLINED TEXT IS A LINK>

Note 1: See  “set of documents  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)    <BE SURE UNDERLINED TEXT IS A LINK> 

NOTE 2: The definitions of "set of documents" and "set of software" in the Key Terms section are predicated on the ability to navigate from each element of the set to each other, and navigation is a type of locating. So the mechanism used to navigate between elements of the set will be one way of locating information in the set.  Non-web environment, generally major operating systems with browse and search capabilities, often provide infrastructure and tools that provide mechanisms for locating content in a set of non-web documents or a set of software programs. For example, it may be possible to browse through the files or programs that make up a set, or search within members of the set for the names of other members. A file directory would be the equivalent of a site map for documents in a set, and a search function in a file system would be equivalent to a web search function for web pages. Such facilities may provide additional ways of locating information in the set.      <BE SURE UNDERLINED TEXT IS A LINK> 

NOTE 2: Authors should assume that an infrastructure exists to allow a user to locate non-web documents or software 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 3: A file directory would be the equivalent of a site map for documents in that it provides a link to each of the items  in the set of non-web documents or software. The directory also acts as the HOME for the set.

NOTE 4: A search function in a file system (that finds non-web documents or software) would be equivalent to a web search function for web pages.

NOTE 5: The definitions of "set of documents" and "set of software programs" in the Key Terms section are predicated on the ability to navigate from each element of the set to each other, and navigation is a type of locating. Where authors are able to assume that an infrastructure exists such as the one described in Note 2, authors would automatically have multiple ways for locating anything that is within a "set of documents" or "set of software programs".     <BE SURE UNDERLINED TEXT IS A LINK>

NOTE 6: Authors can assume that the non-web documents or software will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary

NOTE 3: An example of the use of 'a software program that is part of process', that would meet the exception for this SC, would be one where programs are interlinked but the interlinking depends on program A being used before program B, for validation or to initialize the dataset etc.  

NOTE 4While some users may find it useful to have multiple ways to locate some groups of user interface elements within a document or software program, this is not required by the success criterion (and may pose difficulties in some situations).



PART 4)

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

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" and "software programs” 

With these substitutions (shown separately for the provisions that involve the phrase "set of", to make them easier to read), this success criterion would read:

3.2.3 Consistent Navigation: 

- Navigational mechanisms that are repeated on multiple non-web 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."  <BE SURE UNDERLINED TEXT IS A LINK>
Navigational mechanisms that are repeated on multiple software programs within a set of software programs occur in the same relative order each time they are repeated, unless a change is initiated by the user." <BE SURE UNDERLINED TEXT IS A LINK>

Note 1: See  “set of documents”  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or software programs is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)        <BE SURE UNDERLINED TEXT IS A LINK HERE> 

Note 2:   Although not required by the success criterion, ensuring that navigation elements have consistent order when repeated  within non-web documents or software programs directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.


PART 5)

3.2.4: Consistent Identification (Level AA) ===
Components that have the same functionality within a set of Web pages are identified consistently

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" "software programs” 

With these substitutions (shown separately for the provisions that involve the phrase "set of", to make them easier to read), this success criterion would read:

3.2.4 Consistent Identification:  

- Components that have the same functionality within a set of non-web documents are identified consistently.      <BE SURE UNDERLINED TEXT IS A LINK HERE>
Components that have the same functionality within a set of software programs  are identified consistently        <BE SURE UNDERLINED TEXT IS A LINK HERE> 

Note 1: See  “set of documents”  and "set of software programs" in Key Terms section of Introduction to determine when a group of documents or software programs is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)      <BE SURE UNDERLINED TEXT IS A LINK HERE> 

Note 2:  Although not required by the success criterion, ensuring that component identification be consistent when they occur more than once within non-web documents or software programs directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.

REQUEST TO  WCAG TO CLARIFY THE INTENT OF 3.2.4

Does this success criteria require only that components that have the same functionality on different pages in a set of web pages be consistent?  Or does it require components that are repeated both across and within a web page in a set of web pages be consistent?   

THE WCAG WG will be adding this text to the INTENT of 3.2.4

If there are 2 components on a web page that both have the same functionality as a component on another page in a set of web pages, then all 3 must be consistent. Hence the 2 on the same page will be consistent. 

While it is desirable and best practice always to be consistent within a single web page, 3.2.4 only addresses consistency within a set of web pages where something is repeated on more than one page in the set." 




















====  PROPOSAL  21  (with EDITS per Feb 8th meeting)     ====


Definition  of Software: 

set of software: (as used in WCAG2ICT)     {revised at WCAG2ICT meeting Feb 8th }  

group of software programs that are distributed together and that can be launched and be 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" 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.

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 that is not part of a set, per this definition, would automatically satisfy any success criterion that 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 programs (as is common in closed products), those programs would not meet the definition of a set of programs.


EXAMPLE: One example of a set of software 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. 

NON-EXAMPLES:  Examples of things that are not sets of software:

    • A suite of applications for authoring different types of documents (text, spreadsheets, presentations, etc.) but that don't provide an explicit, consistent means to launch, or switch to, each of the other programs in the group. 
    • An office package consisting of multiple programs that launches as a single program that provides multiple functionality such as writing, spreadsheet, etc., but the only way to navigate between programs open a document in one of the programs.
    • A bundle of software is sold together but the only way to navigate between them is to use a platform software level menu to navigate between programs (not a menu provided by each program that allows you to do just the other programs this set).
    • A group of programs that was a set but the programs have been moved to separate locations so that their "set" behaviors were disrupted and no longer work. Even though they were set at one time, because they are no longer installed as a set they no longer are a set and would not need to meet any success criteria that apply to sets of software.


2.4.1 - Bypass Blocks   ============
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

 Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “multiple web pages” with "multiple non-web documents in a set of non-web documentsor  "multiple software programs in a set of software programs to explicitly state that the multiple documents (or software) are part of a set rather than any two documents or pieces of software

With these substitutions, this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)        <BE SURE BOLD TEXT IS A LINK HERE> 

Note 2: Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

Note 3:  Although not required by the success criterion, being able to bypass blocks of content that are repeated within non-web documents or software directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.

Note 4: Many software user interface components have built-in mechanisms to navigate directly to/among them, which also have the effect of skipping over or bypassing blocks of content.

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web page(s)” with "non-web document(s)" and "software program(s)

 With these substitutions, this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)        <BE SURE BOLD TEXT IS A LINK HERE> 

NOTE 2: Authors should assume that an infrastructure exists to allow a user to locate non-web documents or software 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 3: A file directory would be the equivalent of a site map for documents in that it provides a link to each of the items  in the set of non-web documents or software. The directory also acts as the HOME for the set.

NOTE 4: A search function in a file system (that finds non-web documents or software) would be equivalent to a web search function for web pages.

NOTE 5: The definitions of "set of documents" and "set of software" in the Key Terms section are predicated on the ability to navigate from each element of the set to each other, and navigation is a type of locating. Where authors are able to assume that an infrastructure exists such as the one described in Note 2, authors would automatically have multiple ways for locating anything that is within a "set of documents" or "set of software".      <BE SURE BOLD TEXT IS A LINK HERE> 

NOTE 6: Authors can assume that the non-web documents or software will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary

NOTE 7: While some users may find it useful to have multiple ways to locate some groups of user interface elements within a document or software program, this is not required by the success criterion (and may pose difficulties in some situations).


PART 4)

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

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" and "software programs” 

With these substitutions, this success criterion would read:

3.2.3 Consistent Navigation: 
- Navigational mechanisms that are repeated on multiple 
non-web 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."
Navigational mechanisms that are repeated on multiple software programs within a set of software programs occur in the same relative order each time they are repeated, unless a change is initiated by the user."

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)        <BE SURE BOLD TEXT IS A LINK HERE> 

Note 2:   Although not required by the success criterion, having navigation elements have consistent order when repeated  within non-web documents or software  directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.


PART 5)

3.2.4: Consistent Identification (Level AA) ===
Components that have the same functionality within a set of Web pages are identified consistently

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" "software programs” 

With these substitutions, this success criterion would read:

3.2.4 Consistent Identification:  
- Components that have the same functionality within a set of non-web documents are identified consistently.
Components that have the same functionality within a set of software programs  are identified consistently

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)       <BE SURE BOLD TEXT IS A LINK HERE> 

Note 2:  Although not required by the success criterion, having component identification be consistent when they occur more than once within non-web documents or software  directly addresses user needs identified in INTENT for this SC, and is generally considered best practice.

REQUEST TO  WCAG TO CLARIFY THE INTENT OF 3.2.4

Does this success criteria require only that components that have the same functionality on different pages in a set of web pages be consistent?  Or does it require components that are repeated both across and within a web page in a set of web pages be consistent?   



====   END OF    PROPOSAL  21 ====  

==== SUBMITTED TO WCAG WG ====




































====  PROPOSAL  21 -  Similar to proposal 20 except
    a) both of the last two definitions are included
    b) the notes are tweaked to match our approaches  and/or highlighted 
    c) edit from previous meetings are cleaned up so we can make any edits during the meeting

(all changes are in red  -  as is highlighted information where there are differences to note)
      ====



Definition 1:

set of software: (as used in WCAG2ICT)   {revised at WCAG2ICT meeting Nov 16 }

group of software programs that are distributed together and that can be launched and be used independently from each other, but that are interlinked comprehensively each with every other one such that users can easily move from one program to another via a link, control, or other means, without taking other actions

Definition 2: 

set of software: (as used in WCAG2ICT)     {revised at WCAG2ICT meeting Nov 20th }  

group of software programs that are distributed together and that can be launched and be used independently from each other, but that are interlinked each with every other one such that users can easily move from one program to another via a consistent list of choices that appears in each member of the set


<THESE NOTES WOULD GO WITH EITHER VERSION>

Note 1:  This definition of "set of software" 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: <to be used with definition #1> "Without taking other action" means that the user is moved to the other program but no other action occurs in the process such as opening a document, opening an object to edit, saving a file, etc.
Note 2: <to be used with definition #2> "Consistent does not mean identical.  For example, the list might not include the name of the current program."

Note 3:  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 4: Any software that is not a set, per this definition, would automatically satisfy any success criterion that 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 5: If there is any ambiguity whether the group is a set, then the group is not a set. 

EXAMPLE: One example of a set of software would be a group of programs that can be launched and used separately but are sold together and all have a menu that allows users to launch, or switch to, each of the other programs in the group. 

NON-EXAMPLES:  Examples of things that are not sets of software:

      • A suite of applications for authoring different types of documents (text, spreadsheets, presentations, etc.) but that don't provide an explicit means to launch, or switch to, each of the other programs in the group. 
      • An office package that launches as a single program that provides multiple functionality such as writing, spreadsheet, etc., but the only way to move between programs open a document in one of the programs.
      • A bundle of software is sold together but the only way to move between them is to use a platform software level menu to move between programs (not a menu provided by each program that allows you to do just the other programs this set).
      • A group of programs that would have qualified as set except that they have been moved to separate locations so that their "set" behaviors no longer work. Even though they were set at one time, because they were not installed as a set they are no longer a set and would not need to meet any success criteria created for a set.
      • Any group of software that does not provide a way to move to the other members of the group from within each member of the group without causing some other action such as opening a document or file. 


2.4.1 - Bypass Blocks   ============
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

 Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “multiple web pages” with "multiple non-web documents in a set of non-web documentsor  "multiple software (products) in a set of software (products) to explicitly state that the multiple documents (or software) are part of a set rather than any two documents or pieces of software

With these substitutions, this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

Note 2: Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

Note 3:  Although not required by the success criterion - being able to bypass blocks of content that are repeated within non-web documents or software would also be helpful when possible. 


More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web page(s)” with "non-web document(s)" and "software (product(s))

 With these substitutions, this success criterion would read:

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

Note 1See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

NOTE 2: Authors should assume that an infrastructure exists to allow a user to locate non-web documents or software 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 3: A file directory would be the equivalent of a site map for documents in that it provides a link to each of the items  in the set of non-web documents or software. The directory also acts as the HOME for the set.

NOTE 4: A search function in a file system (that finds non-web documents or software) would be equivalent to a web search function for web pages.

NOTE 5: Authors can assume that the non-web documents or software will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary


PART 4)

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

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" and "software” 

With these substitutions, this success criterion would read:

3.2.3 Consistent Navigation: 
- Navigational mechanisms that are repeated on multiple 
non-web 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."
Navigational mechanisms that are repeated on multiple software (products) within a set of software (products) occur in the same relative order each time they are repeated, unless a change is initiated by the user."

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

Note 2:  Although not required by the success criterion - having navigation elements have consistent order when repeated within non-web documents or software would also be helpful when possible. 


PART 5)

3.2.4: Consistent Identification (Level AA) ===
Components that have the same functionality within a set of Web pages are identified consistently

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" "software (products)” 

With these substitutions, this success criterion would read:

3.2.4 Consistent Identification:  
- Components that have the same functionality within a set of non-web documents are identified consistently.
Components that have the same functionality within a set of software (products)  are identified consistently

 Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.) 

Note 2:  Although not required by the success criterion - having component identification be consistent when they occur more than once within non-web documents or software would also be helpful when possible. 






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

LINK TO LATEST WCAG APPROVED TEXT

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






====  PROPOSAL  20 -  Version that incorporates the following comments from the Survey and the new definition based on Kiran's suggestion in the TF meeting on Nov 20th   ====
  • LOIC - Definitions

    • #1 - Done - shortened doc example
    • #2 - agree - but instead deleted  'comprehensively' to address Peter Korn comment since redundant
    • #3 - Done comma removed
    • #4 - Done -  removed "open"
    • #5 - Done - "changed system to Platform software
    • #6 - Fixed -  changed   "installed in" to "moved to" 
  • Peter Korn - Definitions

    • #1 - Comprehensively not defined -- Fixed, the word is just another word for "each linked to every other" so I deleted the word.  - shortened doc example
    • #2 -  No change -  Anything that meets the definition is OK - anything that doesn’t meet the definition is not OK.  
    • #3 - 'without taking other actions" -  a note was added to explain this term
    • #4  - no change requested
    • #5 -  fixed -- removed the word "open"
    • #6  - Open office would meet the new definition based on idea from Kiran at meeting -- and pasted below . 
  • LOIC - 2.4.1

    • #1 - Done    and added  "to explicitly state that the multiple documents (or software) are part of a set rather than any two documents or pieces of software"  
  • Peter Korn - 2.4.1

    • #1 - Done  (product) added in both places
  • LOIC - 2.4.5

    • #1 -  DONE  (product) added
    • #2 - Replacing web page(s) causes all other changes to be made - with less complex instructions.  Also changed "Web page" to  "Web page(s)" to make it clearer 
    • #3 - (Did not restructure the success criteria language). 
  • Peter Korn - 2.4.5

    • #1 -  Done -- the word  "a" is added back in all the places it was accidentally dropped - and the work (product) was added.
  • LOIC -  3.2.3 -  

    • #2 - Replacing web page(s) causes all other changes to be made - with less complex instructions.  Also change "Web page" to  "Web page(s)" to make it clearer 
  • Peter Korn - 3.2.3

    • #1 - Done - added (Products) as per suggestion

PROPOSED LANGUAGE IMPLEMENTING THIS 
{THERE ARE 6 PARTS TO THE PROPOSED RESOLUTION }

PART 1)

First – we add "Set of documents" – and "Set of software" to the key terms list.

set of 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. 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) are in the same order relative to each other.

set of software: (as used in WCAG2ICT)     {revised at WCAG2ICT meeting Nov 20th }  

group of software programs that are distributed together and that can be launched and be used independently from each other, but that are interlinked each with every other one such that users can easily move from one program to another via a consistent list of choices that appears in each member of the set

Note 1:  This definition of "set of software" 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: "Without taking other action" means that the user is moved to the other program but no other action occurs in the process such as opening a document, opening an object to edit, saving a file, etc.

Note 3 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 4Any software that is not a set, per this definition, would automatically satisfy any success criterion that 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 5: If there is any ambiguity whether the group is a set, then the group is not a set. 

One example of a set of software would be a group of programs that can be launched and used separately but are sold together and all have a menu that allows users to launch, or switch to, each of the other programs in the group. 

Examples of things that are not sets of software:

    • A suite of applications for authoring different types of documents (text, spreadsheets, presentations, etc.) but that don't provide an explicit means to launch, or switch to, each of the other programs in the group. 
    • An open office package that launches as a single program that provides multiple functionality such as writing, spreadsheet, etc., but the only way to move between programs open a document in one of the programs.
    • A bundle of software is sold together but the only way to move between them is to use a system platform software level menu to move between programs (not a menu provided by each program that allows you to do just the other programs this set).
    • A group of programs that would have qualified as set except that they have been installed in moved to separate locations so that their "set" behaviors no longer work. Even though they were set at one time, because they were not installed as a set they are no longer a set and would not need to meet any success criteria created for a set.
    • Any group of software that does not provide a way to move to the other members of the group from within each member of the group without causing some other action such as opening a document or file. 


The FINAL 3 (+1)  success criteria then become 


PART 2)

2.4.1 - Bypass Blocks   ============
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

 Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacingmultiple web pageswith "multiple non-web documents in a set of non-web documents" or  "multiple software (products) in a set of software (products) to explicitly state that the multiple documents (or software) are part of a set rather than any two documents or pieces of software

With these substitutions, this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

Note 2: Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

Note 3:  Although not required by the success criterion - being able to bypass blocks of content that are repeated within non-web documents or software would also be helpful when possible. 


PART 3)

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.


Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web page(s)” with "non-web document(s)" and "software (product(s))

 With these substitutions, this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

NOTE 2: Authors should assume that an infrastructure exists to allow a user to locate non-web documents or software 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 3: A file directory would be the equivalent of a site map for documents in that it provides a link to each of the items  in the set of non-web documents or software. The directory also acts as the HOME for the set.

NOTE 4: A search function in a file system (that finds non-web documents or software) would be equivalent to a web search function for web pages.

NOTE 5: Authors can assume that the non-web documents or software will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary


PART 4)

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

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" and "software” 

With these substitutions, this success criterion would read:

3.2.3 Consistent Navigation: 
- Navigational mechanisms that are repeated on multiple 
non-web 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."
Navigational mechanisms that are repeated on multiple software (products) within a set of software (products) occur in the same relative order each time they are repeated, unless a change is initiated by the user."

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

Note 2:  Although not required by the success criterion - having navigation elements have consistent order when repeated within non-web documents or software would also be helpful when possible. 


PART 5)

3.2.4: Consistent Identification (Level AA) ===
Components that have the same functionality within a set of Web pages are identified consistently

NOTE THAT WE ALSO USE SET OF WEB PAGES IN 3.2.4  
and it seems to violate the WCAG Working Group principle they stated in their last meeting  – but this was not caught when it went through the working group and it was approved with substitution of  “non-web document or software” for “set of web pages

Our old guidance was  

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing “a set of Web pages” with  “non-web documents or software".

Bringing this into conformance with our other three above would change it to:


Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" "software (products)” 

With these substitutions, this success criterion would read:

3.2.4 Consistent Identification:  
- Components that have the same functionality within a set of non-web documents are identified consistently.
Components that have the same functionality within a set of software (products)  are identified consistently

 Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.) 
Note 2:  Although not required by the success criterion - having component identification be consistent when they occur more than once within non-web documents or software would also be helpful when possible. 

 


PART 6)  {REVISED  

- text from last agreed is black normal text

new revised text is in bold red  (this uses some of the text from Peter's last version)


The General introduction Text would then read:  

 

<last paragraph of Introduction  (before Key Terms and  Closed Functionality )> 

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

But the task force found that applying the last four success criteria to software was less straightforward.  The task force found it difficult to find examples of software programs that were in 'sets' that would be equivalent to sets of web pages.  Furthermore, task force members were unaware of any accessibility problems being reported by consumers in dealing with sets of software programs.   At the same time, several of the success criteria appeared like they would be useful within a software program but the success criteria clearly apply to "sets" and not to things outside of the context of a larger "set" In the end the taskforce therefore found that these 4 could be applied to sets of software as defined below, but the sparsity of software occurring in sets limited their value.   The taskforce feels that they might be of more value as general advisory guidance for use within software, though they are not required by WCAG 2.0 outside of sets. 




========  END OF VERSION BASED ON SURVEY COMMENTS =========


=== REVISED PROPOSAL  I3+1  for final paragraph of INTRO and the Software parts of the FINAL 3+1 SUCCESS CRITERIA 
 (link to revision to Set of software definition made at meeting )  
 (see also part 6)==


Overview of situation

Before proposing a solution – it is helpful to review the situation.

WCAG WG reviewed our proposal for the last 3 items and provided the following feedback.  ( This is my (GreggV) recollection of what was said and meant.  I ran this past the WCAG chair to see if I had any of it wrong to her understanding.  )

  1. Our approach and language for Documents was OK and Approved for these last 3.
  2. The approach for Software was not.
    1. They did not accept that we were just saying we couldn’t resolve this because we could not define set – given that our text described the set we felt we could not find.
    2. The WG was asked (specifically the Co-Chair was asked her opinion) if one of our options was to say that we didn’t think it should apply – or that it didn’t apply,  and we were told that she did not believe that that was an option.  (and no one spoke up to disagree)
    3. The WG chair was then asked if we could change the focus from a  “set of software” to just “software”.   Her reply was that the SC was about a set of units.  If we could define the set of units within software that these would apply to – that were analogous to web pages – then we could apply it to those. But we had to define some things where there was a set.  We could not change an SC talking about a set to an SC that related to only an entity.   [Peter commented that we were unable to do that  (define units within software that formed a set similar to the way web pages were units in a set.]
    4. (Discussion followed that the Access Board or M376 could – and it might be a good idea – but that the SC could not be changed to that).
    5. It was suggested that we look to the language we have for a definition of set for software – because we seem to have a definition there of the set of software that we said we couldn’t find.   If we use that definition – and most all software doesn’t meet it – then that software would satisfy the SC.  If and when an example of software that did meet the definition occurred, then it would need to meet the SC. 
    6. If agencies setting requirements (like the Access Board or M376) didn’t feel it was significant enough a problem or didn’t occur enough that they wanted to require it – they could not include it from their requirements.  But that was out of scope for our group because we are only mapping WCAG 2.0 to ICT and not adding or subtracting requirements no matter how good or how unimportant they were.

From our past work we feel that definitions of “set” can be created but we were unable to find examples of “sets of software” that met these definitions.  (Though a member of the WCAG WG suggested that she had worked at a company that had such a set;  that was separate programs that can be launched and used independently, but that were sold as a set and had links back and forth between them.   I am trying to get that information for our use


SUGGESTED APPROACH

That ( as suggested/requested by the WCAG WG) we return to defining what a ‘set of software’ would be.  We would base it on our consensus language and previous discussion.

 We can then state that we didn't find any (or many, depending on what we find) examples of this and have not heard of it being a problem in the field. However, where they exist, these success criteria would apply to those sets of software. For all other software (not in a set) these success criteria would be met in the same way a page without time based media satisfies all the success criteria related to time based media.

  

PROPOSED LANGUAGE IMPLEMENTING THIS 

{THERE ARE 6 PARTS TO THE PROPOSED RESOLUTION }

PART 1)

First – we add "Set of documents" – and "Set of software" to the key terms list.

set of 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. 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) are in the same order relative to each other.

set of software: (as used in WCAG2ICT)     {revised at WCAG2ICT meeting Nov 16 }  

group of software programs that are distributed together and that can be launched and be used independently from each other, but that are interlinked comprehensively each with every other one such that users can easily move from one program to another via a link, control, or other means, without taking other actions.

Note 1:  This definition of "set of software" 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:  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 3: Any software that is not a set, per this definition, would automatically satisfy any success criterion that 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 4: If there is any ambiguity whether the group is a set, then the group is not a set. 

One example of a set of software would be a group of programs that can be launched and used separately but are sold together and all have a menu that allows users to launch, or switch to, each of the other programs in the group.

Examples of things that are not sets of software:

      • A suite of applications for authoring different types of documents (text, spreadsheets, presentations, etc.) but that don't provide an explicit means to launch, or switch to, each of the other programs in the group. 
      • An open office package that launches as a single program that provides multiple functionality such as writing, spreadsheet, etc., but the only way to move between programs open a document in one of the programs.
      • A bundle of software is sold together but the only way to move between them is to use a system level menu to between programs (not a menu provided by each program that allows you to do just the other programs this set).
      • A group of programs that would have qualified as set except that they have been installed in separate locations so that their "set" behaviors no longer work. Even though they were set at one time, because they were not installed as a set they are no longer a set and would not need to meet any success criteria created for a set.
      • Any group of software that does not provide a way to move to the other members of the group from within each member of the group without causing some other action such as opening a document or file. 


The FINAL 3 (+1)  success criteria then become 


PART 2)

2.4.1 - Bypass Blocks   ============
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

 Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents' and  "software products and explicitly stating that the "multiple non-web documents and software”  are part of a "set of non-web documents" or "set of software”. 

With these substitutions, this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

Note 2: Individual documents or software programs (not in a set) would automatically meet this success criterion because this success criterion applies only to things that appear in a set.

Note 3:  Although not required by the success criterion - being able to bypass blocks of content that are repeated within non-web documents or software would also be helpful when possible. 


PART 3)

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents and software

 With these substitutions, this success criterion would read:

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

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

NOTE 2: Authors should assume that an infrastructure exists to allow a user to locate non-web documents or software 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 3: A file directory would be the equivalent of a site map for documents in that it provides a link to each of the items  in the set of non-web documents or software. The directory also acts as the HOME for the set.

NOTE 4: A search function in a file system (that finds non-web documents or software) would be equivalent to a web search function for web pages.

NOTE 5: Authors can assume that the non-web documents or software will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary


PART 4)

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

Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" and "software” 

With these substitutions, this success criterion would read:

3.2.3 Consistent Navigation:
- Navigational mechanisms that are repeated on multiple 
non-web 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."
Navigational mechanisms that are repeated on multiple software (products) within a set of software occur in the same relative order each time they are repeated, unless a change is initiated by the user."

Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.)

Note 2:  Although not required by the success criterion - having navigation elements have consistent order when repeated within non-web documents or software would also be helpful when possible. 


PART 5)

3.2.4: Consistent Identification (Level AA) ===
Components that have the same functionality within a set of Web pages are identified consistently

NOTE THAT WE ALSO USE SET OF WEB PAGES IN 3.2.4  
and it seems to violate the WCAG Working Group principle they stated in their last meeting  – but this was not caught when it went through the working group and it was approved with substitution of  “non-web document or software” for “set of web pages

Our old guidance was  

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing “a set of Web pages” with  “non-web documents or software".

Bringing this into conformance with our other three above would change it to:


Additional guidance when applying to Non-Web Documents and Software

This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "non-web documents" "software” 

With these substitutions, this success criterion would read:

3.2.4 Consistent Identification:  
- Components that have the same functionality within a set of non-web documents are identified consistently.
- Components that have the same functionality within a set of software are identified consistently

 Note 1: See  “set of documents”  and "set of software" in Key Terms section of Introduction to determine when a group of documents or software is considered a set for this success criterion.  (Sets of software that meet this definition appear to be extremely rare.) 
Note 2:  Although not required by the success criterion - having component identification be consistent when they occur more than once within non-web documents or software would also be helpful when possible. 

 


PART 6)  {REVISED  

- text from last agreed is black normal text

- new revised text is in bold red  (this uses some of the text from Peter's last version)


The General introduction Text would then read:  

 

<last paragraph of Introduction  (before Key Terms and  Closed Functionality )> 

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

But the task force found that applying the last four success criteria to software was less straightforward.  The task force found it difficult to find examples of software programs that were in 'sets' that would be equivalent to sets of web pages.  Furthermore, task force members were unaware of any accessibility problems being reported by consumers in dealing with sets of software programs.   At the same time, several of the success criteria appeared like they would be useful within a software program but the success criteria clearly apply to "sets" and not to things outside of the context of a larger "set" In the end the taskforce therefore found that these 4 could be applied to sets of software as defined below, but the sparsity of software occurring in sets limited their value.   The taskforce feels that they might be of more value as general advisory guidance for use within software, though they are not required by WCAG 2.0 outside of sets. 




======== {END OF REVISED PROPOSAL }=========


OLD -- PART 6)  

The General introduction Text would then read:  

(this includes the edits to make sentences less long and easier to understand that Peter referred to in the last meeting and that Peter and Gregg made to the previous text.   NEW text on the end is in square brackets and red.

 

<last paragraph of Introduction  (before Key Terms and  Closed Functionality )> 

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”. Half of these twenty-six applied without any additional notes. Half applied as written but additional notes were also provided for assist in applying them to either or both non-web documents and software. 

Of the remaining 12 success criteria, the Task Force found that 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.

Four of these last 12 success criteria were confined in WCAG 2.0 to apply "a set of web pages", or "multiple web pages" that share some characteristic or behavior.  For these, the task force found that (with substitutions) the success criteria applied to non-web documents fairly straightforwardly.   But the task force found that applying them to software was less straightforward.  The task force found it very difficult to find any examples of software programs that were in 'sets' that would be equivalent to sets of web pages.  The task force members also were unaware of any accessibility problems being reported by consumers in dealing with sets of software programs.   Several of the success criteria appeared like they would be useful within a software program but the success criteria clearly apply to "sets" and not to individual items, and the taksforce was unable to identify any "set" of things in software that were clearly defined in the manner that "web pages" in a "set of web pages" are.  So the task force settled on using "non-web documents and software" as the unit of assessment as it did for all the other twelve success criteria, and added a note regarding the helpfulness of applying the general concept within individual non-web documents or software even though not required by the success criteria.  



OLD- PART 6 ALTERNATE) 

The General introduction Text would then read:  

(this includes the edits to make sentences less long and easier to understand that Peter referred to in the last meeting and that Peter and Gregg made to the previous text. 

 

<last paragraph of Introduction  (before Key Terms and  Closed Functionality )> 

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”. Half of these twenty-six applied without any additional notes. Half applied as written but additional notes were also provided for assist in applying them to either or both non-web documents and software. 

Of the remaining 12 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.

Four of these last 12 The remaining three success criteria were confined in WCAG 2.0 to apply in situations when "a set of web pages", or "multiple web pages" that share some characteristic or behavior.  For these, the task force found that (with substitutions) the success criteria applied apply to non-web documents fairly straightforwardly.   But the task force found that applying them to software was less not straightforward.  The task force found it very difficult to find any examples of software programs that were in 'sets' that would be equivalent to sets of web pages.  Furthermore, The task force members also were unaware of any accessibility problems being reported by consumers related to these three success criteria in situations in dealing with sets of software programs.  Several of the success criteria appeared like they would be are useful for accessibility within a software program but the success criteria clearly apply to in situations involving "sets" and not to individual items software outside of the context of a larger "set", and the taksforce was unable to identify any "set" of things in software that were clearly defined in the manner that "web pages" in a "set of web pages" are.  So the task force settled on using "non-web documents and software" as the unit of assessment as it did for all the other twelve nine success criteria, and added a note regarding the helpfulness of applying the general concept within individual non-web documents or software even though not required by the success criteria.  As a result, software not clearly belonging to a set would automatically meet these last three success criteria.


END

=== END OF PROPOSAL  I3+1  for final paragraph of INTRO and the Software parts of the FINAL 3+1 SUCCESS CRITERIA   ==












 Text that peter and gregg were working on -- used in above proposal  


 [YELLOW TEXT IN SQUARE BRACKETS TO BE MODIFIED TO MATCH FINAL RESULT OF TASK FORCE.] 


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”. Half of these twenty-six applied without any additional notes. Half applied as written but additional notes were also provided for assist in applying them to either or both non-web documents and software. 

Of the remaining 12 success criteria, the Task Force found that nine 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.”   Again, additional notes were provided to assist in the application for some of these.

The remaining three [FOUR?] success criteria are scoped in WCAG 2.0 to apply in situations in which 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 applied as written for non-web documents where a set would mean a group of items 1) that are published together, and 2) where the items all refer to each other by name or link. . But for software applying these three success criteria was not as straightforward.  These three WCAG 2.0 success criteria can be mapped to software but results in applying the success criteria to “sets of software”. The task force however did not find any (or many, depending on what we find) examples of a set of software as defined above and have not heard of access to sets of software as being a problem in the field. The task force felt that the general guidance provided by these three [FOUR?] success criteria was often valuable to apply to individual non-web documents or software (e.g. consistent identification and navigation, multiple ways to find things and ways to bypass repeated blocks within a non-web document or software) but since these success criteria only dealt with “sets of web pages” they did not apply directly to individual items and the task force therefore could not map them to anything but sets of non-web documents or software.]    <







WCAG

        WCAG APPROVED TEXT IS BELOW 



 

=== Text for final paragraphs in INTRO Approved by WCAG WG November 15, 2012==

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

[10:49am

===== END OF APPROVED TEXT =====




EDITED TEXT ACCEPTED BY  WCAG WG at meeting 11/8/12

(including two changes to INTENT sections in Understanding WCAG 2.0  PLUS the DOCUMENT sections only for  the FINAL three)

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add:  

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add:  

Although the success criterion does not specifically use the term “within a set of web pages”, the concept of the pages belonging to a set is implied.  An author would not need to provide a bypass mechanism for content on a page that happens to be duplicated on some other page that is not in some way related to it; that is, they are not "Web pages that share a common purpose and that are created by the same author, group or organization” (the definition of set of web pages).

Note:  Even for web pages that are not in a set, if a web page has blocks of text that are repeated within the page it may be helpful (but not required) to provide a means to skip over them.

 

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 3.2.3 be modified to add:  

Note:  If a web page has navigational mechanisms that are repeated within the page it may be helpful (but not required) to have them be consistent.



2.4.1 - Bypass Blocks

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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, this success criterion would read:

 2.4.1 Bypass Blocks:  A mechanism is available to bypass blocks of content that are repeated on multiple 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. 


2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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, this success criterion would read:

2.4.5 Multiple Ways:  More than one way is available to locate a 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 3: 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 4: 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 5: A search function in a file system (that finds documents) would be equivalent to a web search function for web pages.
NOTE 6: Authors 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.


3.2.3 - Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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, this success criterion would read:

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Documents within a set of 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.


</ END OF TEXT ACCEPTED BY  WCAG WG at meeting 11/8/12>

=======Proposal 8-  for software section only --  POST WCAG meeting  =====

<just started -- to be continued>

PART 1:   Revise the  PARAGRPAH IN INTRODUCTION WITH THE FOLLOWING (exact numbers can be adjusted by editors to match final wording)  

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 apply directly as written and as described in the "Intent" sections from the updated “Understanding WCAG 2.0”. Half of these applied without any additional notes. Half applied as written but additional notes were also provided for assist in applying them to either or both non-web documents and software.

Nine of the thirty-eight success criteria apply as written when replacing certain web specific terms or phrases like "Web page(s)" or “set of web pages” etc. 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.” For the remaining three success criteria, the task force found that (with substitutions) the success criteria applied as written for non-web documents. But for software the finding was a bit different. All three of these success criteria relate to multiple web pages and the concept of a set of web pages. While web pages are clearly delineated items on the web (each has a distinct URL) and concept of a “set” where the items are closely related to each other and link back and forth using URLs, the task force had a difficult time finding examples of a set of software where software programs were distinct but were tied together in such an integral fashion for software. URLs do not exist for the running software and the task force could not find their analog in running software. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages. The task force therefore <insert solution for the software half when we adopt it>



PART 2:   Use the following language for the ending of the INTRO paragraph text block and also for the software parts of the individual provisions. 

<still working on this>  

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

2.4.1 - Bypass Blocks

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

<Insert template text to start this one>

  

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

2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

<Insert template text to start this one>

 

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

3.2.3 - Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

<Insert template text to start this one>

 <then add the following to the end of the SOFTWARE discussion>

The task force was also unable to find a generally applicable definition of what constituted a navigational mechanism in software that is analogous to the navigational mechanisms on Web Pages.  For web pages  navigation mechanisms are links or a simple menu of links that move the user between discreet entities that alway exist (web pages) for all web content. However that does not exist for all types of software.    As a result the task force is unable to provide any guidance that could be applied across software in general.  We were also unable to find any specific scoping language that would define to which software  it would always apply.  The task force does believe that it is good advice to consider both across and within software - but not something that the task force could find a way to apply to software in general or to any subset that we were able to define.

 







===========Proposal 7- from Nov 2 meeting =====

>>>We use essentially this same language for all three of our final success criteria - with small changes for each - which are shown below.<<<

<common template text for all three> 

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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, the success criterion for >>>SC title<<< would read:

>>>SC text, with substitutions, written here<<<

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 task force has to date been unable to come up with a cogent and objective way to apply this provision across all types of  Software.  The task force has explored approaches for applying it to software that takes the appearance of a self playing Document or Book.  But for other types of software the task force did not see any way to apply it consistently or clearly.  This is because the task force was not able to unambiguously define what a "set of software" would be. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).  Further, key to the concept of a set in WCAG 2.0 is that the members of the set are hyperlinked together, and while file URLs exist for documents, they do not exist for running software, nor could the task force find their analog in running software.

Because after considerable effort we were (1) unable to find a viable definition for what a "set of software" means that could be applied across software in general, and (2) unable to find any clear example of "sets of software" in the wild that seemed to be an equivalent of "set of Web pages", the task force is unable to provide any  guidance on how to apply this success criterion to "software in a set of software" in general.  We were also unable to find any  specific scoping language that would define to which sets of software it would always apply. 

Individual  instances of software would automatically meet this success criterion - because this success criterion applies only to things that appear in a set. 
  1. </end of common template text for all three> 


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

2.4.1 - Bypass Blocks

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

<Insert template text to start this one>

<the substitution text for Documents reads: "A mechanism is available to bypass blocks of content that are repeated on multiple Documents">

<Also send the following to WCAG WG:>

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add:  

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add:  

Although the success criterion does not specifically use the term “within a set of web pages”, the concept of the pages belonging to a set is implied.  An author would not be expected to avoid any possible duplication of content in any two pages that are not in some way related to each other;  that are not "Web pages that share a common purpose and that are created by the same author, group or organization” (the definition of set of web pages).

Note:  Even for web pages that are not in a set, if a web page has blocks of text that are repeated within the page it may be helpful (but not required) to provide a means to skip over them.

 

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

2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

<Insert template text to start this one>

<the substitution text for Documents reads: "More than one way is available to locate a Document within a set of Document except where the Document is the result of, or a step in, a process.">

<then add the following to the DOCUMENTS section  (previously approved text for 2.4.5 for documents)>  

NOTE 3: 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 4: 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 5: A search function in a file system (that finds documents) would be equivalent to a web search function for web pages.

NOTE 6: Authors 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


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

3.2.3 - Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

<Insert template text to start this one>

<the substitution text for Documents reads: "Navigational mechanisms that are repeated on multiple Documents within a set of Documents occur in the same relative order each time they are repeated, unless a change is initiated by the user.">

<then add the following to the end of the SOFTWARE discussion>

The task force was also unable to find a generally applicable definition of what constituted a navigational mechanism in software that is analogous to the navigational mechanisms on Web Pages.  For web pages  navigation mechanisms are links or a simple menu of links that move the user between discreet entities that alway exist (web pages) for all web content. However that does not exist for all types of software.    As a result the task force is unable to provide any guidance that could be applied across software in general.  We were also unable to find any specific scoping language that would define to which software  it would always apply.  The task force does believe that it is good advice to consider both across and within software - but not something that the task force could find a way to apply to software in general or to any subset that we were able to define.

<Also send the following to WCAG WG:>

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 3.2.3 be modified to add:  

Note:  Even for web pages that are not in a set, if a web page has navigational mechanisms that are repeated within the page it may be helpful (but not required) to have them be consistent.


===========Proposal 6-clean Peter & Gregg 28Oct =====

>>>We use essentially this same language for all three of our final success criteria - with small changes for each - which are shown below.<<<

<common template text for all three> 

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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, the success criterion for >>>SC title<<< would read:

>>>SC text, with substitutions, written here<<<

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 task force has to date been unable to come up with a cogent and objective way to apply this provision across all types of  Software.  The task force has explored approaches for applying it to software that takes the appearance of a self playing Document or Book.  But for other types of software the task force did not see any way to apply it consistently or clearly.  This is because the task force was not able to unambiguously define what a "set of software" would be. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).  Further, key to the concept of a set in WCAG 2.0 is that the members of the set are hyperlinked together, and while file URLs exist for documents, they do not exist for running software, nor could the task force find their analog in running software.

Because after considerable effort we were (1) unable to find a viable definition for what a "set of software" means that could be applied across software in general, and (2) unable to find any clear example of "sets of software" in the wild that seemed to be an equivalent of "set of Web pages", the task force could not find a way to provide guidance on how to apply this success criterion to "software in a set of software".  Therefore:
  1. individual  instances of software would automatically meet this success criterion - because this success criterion applies only to things that appear in a set, and 
  2. since we cannot determine how to interpret "set of software", we cannot offer any specific guidance on how to apply this success criterion to "software in a set of software"
</end of common template text for all three>


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

2.4.1 - Bypass Blocks

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

<Insert template text to start this one>

<the substitution text for Documents reads: "A mechanism is available to bypass blocks of content that are repeated on multiple Documents">

<Also send the following to WCAG WG:>

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add: 

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add: 

Although the success criterion does not specifically use the term “within a set of web pages”, the concept of the pages belonging to a set is implied.  An author would not be expected to avoid any possible duplication of content in any two pages that are not in some way related to each other;  that are not "Web pages that share a common purpose and that are created by the same author, group or organization” (the definition of set of web pages).

Note:  Even for web pages that are not in a set, if a web page has blocks of text that are repeated within the page it may be helpful (but not required) to provide a means to skip over them.

 

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

2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

<Insert template text to start this one>

<the substitution text for Documents reads: "More than one way is available to locate a Document within a set of Document except where the Document is the result of, or a step in, a process.">

<then add the following to the DOCUMENTS section  (previously approved text for 2.4.5 for documents)>  

NOTE 3: 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 4: 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 5: A search function in an operating systems (that finds documents) would be equivalent to a web search function for web pages.

NOTE 6: Authors 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.


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

3.2.3 - Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

<Insert template text to start this one>

<the substitution text for Documents reads: "Navigational mechanisms that are repeated on multiple Documents within a set of Documents occur in the same relative order each time they are repeated, unless a change is initiated by the user.">

<then add the following to the end of the SOFTWARE discussion>

The task force also had difficulty determining exactly what constituted a "navigational mechanism" in at least some types of software.  Again, perfectly reasonable examples existed for some types of software, but for other types there was no clear analogy that could be identified. 

<Also send the following to WCAG WG:>

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 3.2.3 be modified to add:  

Note:  Even for web pages that are not in a set, if a web page has navigational mechanisms that are repeated within the page it may be helpful (but not required) to have them be consistent.



===========Proposal 6-markup Peter & Gregg 28Oct =====

[changes from proposal #4 are indicated: strikethrough for removal, boldface italics for adds; all changes in red]

I suggest w<We use essentially this same language for all three of our final document.> Here is some text to start the discussion.

<block that STARTS the common template text for all three> 

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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, the success criterion for <SC title> would read:

<SC text, with substitutions, written here>

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 task force has to date been unable to come up with a cogent and objective way to apply this provision to Software (unless that software takes the appearance of a self playing Document or Book).  Whenever a way to apply it to some applications was identified, the method would fail to work with another variety or type of Software.  Also "sets of Software programs" are rare.  It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).
The task force has to date been unable to come up with a cogent and objective way to apply this provision across all types of  Software.  The task force has explored approaches for applying it to software that takes the appearance of a self playing Document or Book.  But for other types of software the task force did not see any way to apply it consistently or clearly.  This is because the task force was not able to unambiguously define what a "set of software" would be. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).  Further, key to the concept of a set in WCAG 2.0 is that the members of the set are hyperlinked together, and while file URLs exist for documents, they do not exist for running software, nor could the task force find their analog in running software.

We conclude therefore that Software programs should be treated in the same manner as web apps that exist at a single URL (a single web page). Such web apps would satisfy the success criterion automatically because they do not have multiple web pages.

Because after considerable effort we were (1) unable to find a viable definition for what a "set of software" means that could be applied across software in general, and (2) unable to find any clear example of "sets of software" in the wild that seemed to be an equivalent of "set of Web pages", the task force could not find a way to provide guidance on how to apply this success criterion to "software in a set of software".  Therefore:
  1. individual  instances of software would automatically meet this success criterion - because this success criterion applies only to things that appear in a set, and 
  2. since we cannot determine how to interpret "set of software", we cannot offer any specific guidance on how to apply this success criterion to "software in a set of software"
Note that even though web apps and Software would not be required to apply this success criterion internally, they can draw good advice from it that could make web apps and Software more usable to people with disabilities.
<the above paragraph gets replaced with suggestions to WCAG WG that this idea go into Intent - see 2.4.1 and 3.2.3 below for this>

</End of common
template block that STARTS the text for all three> 


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

2.4.1 - Bypass Blocks

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

<Insert Common Block template text to start this one>

<the substitution text for Documents reads: "A mechanism is available to bypass blocks of content that are repeated on multiple Documents">

<then add the following:

< any more notes to add to this one beyond the common text above?>

<Also send the following to WCAG WG:

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add:  

“Although the success criterion does not specifically use the term “within a set of web pages”, the concept of the pages belonging to a set is implied.  An author would not be expected to avoid any possible duplication of content in any two pages that are not in some way related to each other;  that are not "Web pages that share a common purpose and that are created by the same author, group or organization” (the definition of set of web pages). 


Note:  Even for web pages that are not in a set, if a web page has blocks of text that are repeated within the page it may be helpful (but not required) to provide a means to skip over them.>

 

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

2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

<Insert Common Block template text to start this one>

<the substitution text for Documents reads: "More than one way is available to locate a Document within a set of Document except where the Document is the result of, or a step in, a process.">

<then add the following to the DOCUMENTS section  (previously approved text for 2.4.5 for documents>  

NOTE 3: 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 4: 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 5: A search function in an operating systems (that finds documents) would be equivalent to a web search function for web pages.

NOTE 6: Authors 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.


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

3.2.3 - Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.


<Insert Common Block template text to start this one>

<the substitution text for Documents reads: "Navigational mechanisms that are repeated on multiple Documents within a set of Documents occur in the same relative order each time they are repeated, unless a change is initiated by the user.">

<then add the following to the end of the SOFTWARE discussion>

The task force also had difficulty determining exactly what constituted a "navigational mechanism" in at least some types of software.  Again, perfectly reasonable examples existed for some types of software, but for other types there was no clear analogy that could be identified. 

<Also send the following to WCAG WG:

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 3.2.3 be modified to add:  

Note:  Even for web pages that are not in a set, if a web page has navigational mechanisms that are repeated within the page it may be helpful (but not required) to have them be consistent.>




===========Proposal 5 Peter, incorporating my 28Oct survey feedback to proposal #4 (below) =====

[changes from proposal #4 are indicated: strikethrough for removal, boldface italics for adds; all changes in red]

I suggest we use this same language for all three of our final document. Here is some text to start the discussion.

<common block that STARTS the template for text for all three> 

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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, the success criterion for <SC title> would read:

<SC text, with substitutions, written here>

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:
<OLD-PETER ALT="Variant #1">
The task force has to date been unable to come up with a cogent and objective way to apply this provision to Software (unless that software takes the appearance of a self playing Document or Book).  Whenever a way to apply it to some applications was identified, the method would fail to work with another variety or type of Software.  Also "sets of Software programs" are rare.  Nor was the task force able to unambiguously define what a "set of software" was. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).
</OLD-PETER>
<NEW-PETER-GREGG ALT="Variant #2">
The task force has to date been unable to come up with a cogent and objective way to apply this provision across all different types of Software.  The Taskforce task force can see how to apply has explored promising approaches for applying it to software that takes the appearance of a self playing Document or Book.  But for other types of software we could the task force did not see any easy way to apply it consistently or clearly.  Nor was the task force able to unambiguously define what a "set of software" would be. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).
</NEW-PETER-GREGG>
<NEW-GREGG-ONLY ALT="Variant #3">
The task force has to date been unable to come up with a cogent and objective way to apply this provision across all different types of Software.  The Taskforce task force can see how to apply has explored promising approaches for applying it to software that takes the appearance of a self playing Document or Book.  But for other types of software we could the task force did not see any easy way to apply it consistently or clearly to individual pieces of software.  Nor was the task force able to unambiguously define what a "set of software" would be. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).
</NEW-GREGG-ONLY>
<NEW-PETER-ONLY ALT="Variant #4">
The task force has to date been unable to come up with a cogent and objective way to apply this provision across all different types of Software.  The Taskforce task force can see how to apply has explored promising approaches for applying it to software that takes the appearance of a self playing Document or Book.  But for other types of software we could the task force did not see any easy way to apply it consistently or clearly.  Nor was This is because the task force was not able to unambiguously define what a "set of software" would be. It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).  Further, key to the concept of a set in WCAG 2.0 is that the members of the set are hyperlinked together, and while file URLs exist for documents, they do not exist for running software, nor could the task force find their analog in running software.
</NEW-PETER-ONLY>

We conclude therefore that Software programs should be treated in the same manner as web apps that exist at a single URL (a single web page). Such web apps would satisfy the success criterion automatically because they do not have multiple web pages.

<OLD-PETER ALT="Variant #A">
We conclude therefore that a 'set of Software' should be treated in the same manner as web page that doesn't contain any prerecorded media. Such a web page would automatically satisfy success criteria such as 1.2.1 Audio-only and Video-only and SC 1.2.2 Captions and 1.2.3 Audio Description or Media Alternative automatically, because there is no place where the captions/media alternative isn't present. Likewise, all software automatically satisfies this success criterion because there is no such concept as a 'set of software'.
</OLD-PETER>
<NEW-PETER-GREGG ALT="Variant #B">
We conclude therefore that a 'set of Software' should be treated in the same manner as web page that doesn't contain any prerecorded media. Such a web page would automatically satisfy success criteria 1.2.1 Audio-only and Video-only (for example), because there is no place where the captions/media alternative isn't present. Likewise, all software automatically satisfies this success criterion because we cannot define what a 'set of software' means.
</NEW-PETER-GREGG>
<New Gregg
ALT="Variant #C">
We conclude therefore that individual Software programs should be treated in the same manner as single-web-page web apps  (web apps that exist at a single URL).  Such one-page web apps would satisfy the success criterion automatically because they are not sets.  Similarly individual software programs would automatically meet this SC because they are not a set.    

As for sets of software programs, such sets would have to meet this success criterion when and where they exist as a true set.  But to date we have been unable to find a way describe what such a set would be precisely except for certain types (self playing books .       HMMMMMMM     not working --- will come back to this.   because we do and we don't.
</new Gregg>
<NEW-PETER ALT="Variant #D">
We conclude therefore that software in the context of a 'set of Software' should be treated in the same manner as web page that doesn't contain any prerecorded media. Such a web page would automatically satisfy success criteria 1.2.1 Audio-only and Video-only (for example), because there is no place where the captions/media alternative isn't present. Likewise, all software automatically satisfies this success criterion because we cannot define what a 'set of software' means isn't defined.
</NEW-PETER>

<NEW-NEW-PETER-GREGG ALT="VARIANT #E">
Just as a web page that contains no media automatically meets SC1.2.1
Audio-only and Video-only, Software meets this SC because there is no definition of what a "set of software" is, and this SC is only active for software that exists within a set of software.

We conclude therefore that individual Software programs - not in a set of Software - automatically meet this success criterion just as any single web page not in a set of web pages automatically meets this success criterion.  Furthermore, because we were unable to define what a "set of software" means, or find any example of a "set of software" in the wild, we cannot offer any guidance on how to apply this success criterion even if someone were to suggest there was a set of software.
</NEW-NEW-PETER-GREGG>

<NEW-NEW-PETER ALT="Variant #F">
Furthermore, because we were, after considerable effort, unable to find a viable definition for what a set of software means that could be applied across software in general, or find any example of sets of software in the wild, we see no way to provide guidance on how to apply this success criterion to "software in a set of software".  Therefore our guidance is that software automatically meets this success criterion - because this success criterion applies only to things that appear in a set, and we are unable to define what a "set of software" is.
</NEW-NEW-PETER>


<OLD-PETER ALT="Variant i">
Note that even though web apps and Software would not be required to apply automatically meet this success criterion internally, they can may draw good advice from it that could might make web apps and Software more usable to people with disabilities.
</OLD-PETER>
<NEW Gregg ALT="Variant ii">
Note that even though web apps and non-web Software (that are not sets of pages or programswould not be required to apply do not need to be evaluated against this success criterion because they are not sets, this success criterion can provide good (non required) advice for making   internally, they can draw  good advice from it that could might make web apps and Software more usable to people with disabilities. 
</NEW Gregg>
<NEW-PETER ALT="Variant iii">
Note that even though web apps and Software would not be required to apply automatically meets this success criterion internally, they can Software may draw good advice from it that could might make web apps and Software more usable to people with disabilities. Software is encouraged to apply this success criterion and its related Intent to the greatest extent possible.
</NEW-PETER>

</End of common block that STARTS the text for all three> 


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

2.4.1 - Bypass Blocks

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

<Insert Common Template Block to start this one>

<the substitution text for Documents reads: "A mechanism is available to bypass blocks of content that are repeated on multiple Documents">

<then add the following:

< any more notes to add to this one beyond the common text above?>

<Also send the following to WCAG WG:

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add:  

“Although the success criterion does not specifically use the term “within a set of web pages”, the concept of the pages belonging to a set is implied.  An author would not be expected to avoid any possible duplication of content in any two pages that are not in some way related to each other;  that are not "Web pages that share a common purpose and that are created by the same author, group or organization” (the definition of set of web pages). 

 

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

2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

<Insert Common Template Block to start this one>

<the substitution text for Documents reads: "More than one way is available to locate a Document within a set of Document except where the Document is the result of, or a step in, a process.">

<then add the following to the DOCUMENTS section  (previously approved text for 2.4.5 for documents>  

NOTE 3: 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 4: 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 5: A search function in an operating systems (that finds documents) would be equivalent to a web search function for web pages.

NOTE 6: Authors 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.



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

3.2.3 - Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.


<Insert Common Template Block to start this one>

<the substitution text for Documents reads: "Navigational mechanisms that are repeated on multiple Documents within a set of Documents occur in the same relative order each time they are repeated, unless a change is initiated by the user.">

<then add the following to the end of the SOFTWARE discussion>

The task force also had difficulty determining exactly what constituted a "navigational mechanism" in at least some types of software.  Again, perfectly reasonable examples existed for some types of software, but for other types there was no clear analogy that could be identified.  


===========Proposal 4 Gregg  with input from many =====

I suggest we use this same language for all three of our final document. Here is some text to start the discussion.

<common block that STARTS the text for all three> 

For Documents: 
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “web pages” with "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. 
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. 


For Software: 
The task force has to date been unable to come up with a cogent and objective way to apply this provision to Software (unless that software takes the appearance of a self playing Document or Book).  Whenever a way to apply it to some applications was identified, the method would fail to work with another variety or type of Software.  Also "sets of Software programs" are rare.  It is easy to find collections, bundles or suites but those are not sets in the same manner as sets of Web pages (where items in the set interlink or have common look and feel).    

We conclude therefore that Software programs should be treated in the same manner as web apps that exist at a single URL (a single web page). Such web apps would satisfy the success criterion automatically because they do not have multiple web pages.

Note that even though web apps and Software would not be required to apply this success criterion internally, they can draw good advice from it that could make web apps and Software more usable to people with disabilities.

</End of common block that STARTS the text for all three> 


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

2.4.1 - Bypass Blocks

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

<Insert Common Block to start this one>

<then add the following:

< any more notes to add to this one beyond the common text above?>

<Also send the following to WCAG WG:

We suggest to WCAG WG that the INTENT section of Understanding WCAG 2.0 for 2.4.1 be modified to add:  

“Although the success criterion does not specifically use the term “within a set of web pages”, the concept of the pages belonging to a set is implied.  An author would not be expected to avoid any possible duplication of content in any two pages that are not in some way related to each other;  that are not "Web pages that share a common purpose and that are created by the same author, group or organization” (the definition of set of web pages). 

 

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

2.4.5 - Multiple Ways

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

<Insert Common Block to start this one>

<then add the following to the DOCUMENTS section  (previously approved text for 2.4.5 for documents>  

NOTE 3: 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.



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

3.2.3 - Consistent Navigation

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.


<Insert Common Block to start this one>

<then add the following to the end of the SOFTWARE discussion>

The task force also had difficulty determining exactly what constituted a "navigational mechanism" in at least some types of software.  Again, perfectly reasonable examples existed for some types of software, but for other types there was no clear analogy that could be identified.  


  

=========== Proposal 3 Gregg  =====

Start with this definition of SET.   

SET  (of NWNE Content and Software)
Group of NWNE content, or software, items that were created and operate as a unit as evidenced by the fact that they all either a) link bidirectionally with each other vis hyperlink or menu or b) consist of a set of sibling pages (with our without a parent) that all interlink with each other vis hyperlink or menu, and where all the other items in the set link bidirectionally-hierarchically to one or more of the sibling pages.
    • NOTE:  If a group of items (software or NWNE content) meets this definition a user can navigate from any item in the set to any other item in the set using only the bidirectional links or menus in the items themselves. 
    • NOTE:  This is common on the Web but less common for NWNE content that was not "spidered" down from the web, and even less common for software - where multiple programs rarely interlink in this fashion. 

2.4.1 - Bypass Blocks
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

This then applies as written - with web pages replaced by "NWNE-content or software" and the implied "within a set of xxx is recognized.

NOTE: Since it doesn't make sense to talk about "blocks of content" that are repeated "in multiple software applications" if they don't belong to some kind of set (how would an author know the blocks are repeated) this provision has an implied "within a set of web pages".
   
We suggest that the INTENT section be modified to add a comment to the effect that this relates to sets.



2.4.5 - Multiple Ways
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

This then applies as written - with web pages replaced by "NWNE-content or software".

NOTE:  Just as with web pages, the combination of links to the page/software/NWNE-content combined with any search mechanism on the platform would make it very hard to not meet this SC.  But also, as with web content, it is important to ensure that different ways are available and authors should think about how to go even further than is required to make it easy to find one's way around in these sets.

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

This applies as written.  This applies to the mechanisms for navigating between the different items in the set - but this is not intended to  require that the different pages (software, NWNE-content) in the set be organized in the same order and therefore is not intended to require that navigation internal to each item (web page, software, NWNE-content) be consistent with other items (pages etc) - though if that works that is also helpful. 






=========== Proposal 2 Peter with Gregg answers  =====



As of 19 October 2012, there are 3 A/AA Success Criteria for which the TF hasn't been able to reach consensus.  All three share one thing in common: they are written to apply to a web page in the context of a set of or among multiple web pages.  

This page looks at these three SCs, describes the challenges we see in applying them to non-web software, and explores options / proposals for how we might address those challenges.  

TF members haven't yet been able to reach consensus on any of these options, and some TF members question whether the TF is even allowed to explore/use some of these options, feeling that some of the specific options/proposals are outside of the TF's scope / work statement.  

We present these issues & options to our parent WG, in hopes that they may provide guidance/direction.


The three remaining A/AA SCs are:

2.4.1 - Bypass Blocks
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

2.4.5 - Multiple Ways
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.


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

Challenges arising from these three SCs:

General challenges:

We have struggled with how to define "a set of web pages" in software or "multiple web pages" in software, and not come up with a satisfying answer.  We have tried the following substitutions:

  • web page = "screen" or "top level frame"
    And so "multiple web pages" would be the entire software application.  This wasn't satisfying because software can take so many forms - that it was not clear what a frame would be in some programs (a 3 D  environment you move around in or a program that doesn’t use frames but a screen full of objects that are used together,  audio only software, or software in a single, very small screen device).

  • web page ="interaction context" or "user interface context"
    The problem here was that we couldn't come up with a satisfying definition of either a single "interaction context" or what a "set of interaction contexts" would be (and where it would stop) (see User Interface Context and its sub-pages for more on this).  Again the diversity of software comes into play and the infinite layering of interaction contexts that begins outside of software and occurs in nested and overlapping layers within. 

  • "set of web pages" = "software"
    This seems to have the most potential, but gives rise to specific challenges in each SC (described below).  Also, there is the question of where "software" stops, particularly for large application suites that may present entirely different interfaces to different classes of users (e.g. an administrative interface as distinct from the end-user interface; an order entry interface vs. an inventory management interface).  Also, this substitution may perhaps push the boundary of our mandate; are we creating a new SC by doing this substitution?


Specific challenges with 2.4.1 - Bypass Blocks:

Intent from Understanding Success Criterion 2.4.1 in Understanding WCAG 2.0 notes that the intent is "to allow people who navigate sequentially through content more direct access to the primary content of the Web page".  It often isn't clear what the "primary content" is of a software application. 

Further, it wasn't clear what would constitute a "mechanism for bypassing" blocks of content generally in software.  Is this only moving the focus?  What about touch interfaces (and the built-in speech provided by things like VoiceOver and TalkBack? as well as switch access provided on such platforms like Tecla?)  Finally, it wasn't clear what would constitute a "block of content" - would repeated user interface controls like a menu bar and a ribbon constitute such a block?  And what does it mean for such a block to be repeated?  If there is only ever one window with a menu bar on it - though it can contain different content (e.g. a document editor), does that constitute "repetition" for this SC?

Specific challenges with 2.4.5 Multiple Ways:

Intent from Understanding Success Criterion 2.4.5 in Understanding WCAG 2.0 notes that the intent is "to make it possible for users to locate content in a manner that best meets their needs".  But what is the "unit" of content that is being located?  How important is "locating content" in software, as compared to "interacting with content" - e.g. entering data or modifying a document?  Is most of software interaction essentially "steps in a process" such that this SC rarely - if ever - applies?  In the software context, are there any users with disabilities who are running into problems somewhere because this SC isn't met in that instance? [we couldn't find any real-live examples of problems from clear violations of the SC]

Specific challenges with 3.2.3 Consistent Navigation:

Intent from Understanding Success Criterion 3.2.3 in Understanding WCAG 2.0 notes that the intent is "to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once".  Further, Understanding notes several examples, the first of which is: " A consistently located control: A search field is the last item on every Web page in a site. users can quickly locate the search function" and 

We had a lot of difficulty with the concept of what a "navigation mechanism" is in software.  Is bringing up a "Save As" dialog activating a "navigation mechanism"? (or is it an "action" instead? or a "step in a process" as per 2.4.5?).  If the focus doesn't change when operating some UI component, can it still be a "navigation mechanism"?  We also had a lot of difficulty with the boundary of "software" (which goes back to the question of what is a "set of web pages").  The situation of large software applications with multiple different UIs (admin UI vs. client user UI; order entry vs. inventory management) is particularly challenging here - not only might it be appropriate to have the same navigation mechanisms appear in different order based on frequency of use and efficiency for a given UI/task, but large applications may roll out UI changes - including a change in the sequence of presentation of a set of navigation mechanisms - over a series of releases.  In such cases, a new order of the navigation mechanisms may be rolled out to distinct and clear portions of the over software UI successively over time; something we don't think should be made an accessibility violation.  So there must be some way of defining the scope such that it isn't to "the entire software application, however large or multi-faceted".


General options we see for these three SCs:

For all of the SCs, one potential option we see is to simply say "this doesn't apply to software".  While some members of the TF don't support this specific option for specific remaining SCs (not always the same members for each SC!) - because they can find specific examples of software (that generally "look like web pages" even if they can't suggest a global rule that could be applied to all software) - others object because they don't believe it is within the TF's charter to state "this doesn't apply to software" for any of the SCs if there are any examples where it does   We would like WCAG WG to clarify whether they will categorically refuse to agree to that statement appearing anywhere. 

For some of the SCs (including specifically 3.2.3, see below), some members of the TF feel that might successfully apply the principals and guidelines behind the SCs, and directly address the Intent of the SC, by going slightly beyond simply defining what terms mean in software.  E.g. it may be more than just "navigation mechanisms" that appear in a consistent order when repeated.  Other TF members fear this goes too far toward "writing a new SC", which is beyond the TF's charter.    We would like WCAG WG to clarify whether they will entertain SC application language that addresses the spirit and purpose of the SC, but may differ more significant in the specific SC language than simple "web page" replacement would allow; that covers things not covered by the SC but is in the spirit of the SC.  

And finally, some TF members feel that one or more of the remaining SCs apply but rarely come up in real life because there are few "sets of software" that are separate but integrated in the same fashion as web pages.   Sometimes, things occur, but the nature of software causes them to automatically be met.  Other TF members feel that in such situations it would be better to state "this doesn't apply to software", out of concern that leaving it in in such a fashion would be confusing and/or detract from the value of the work overall.  

Specific options/proposals for these three SCs:

Below we capture three different proposals for each of the three remaining SCs.  These proposals are for text that would appear in our document Applying WCAG to Non-Web ICT for these SCs respectively.  Each of the three general options above are explored in specific below.  

We would appreciate WCAG WG providing the TF with direction based on these options: Is any one of them preferred by the WG?  Is any one of them categorically outside of our scope?  Does the WG find any specific options sufficient promising - but not "there yet" - that you would like us to focus on further improvements to it?


Options for 2.4.1 - Bypass Blocks:

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 2.4.1 in Understanding WCAG 2.0, the intent of this SC is  "to allow people who navigate sequentially through content more direct access to the primary content of the Web page".   In software, there often isn't a notion of "primary content".  Particularly on any given area of software (e.g. the "Save As" dialog), such isn't the case.  Separately, this provisions is scoped to those blocks that are "repeated on multiple web pages", and there is no clear analog to "multiple web pages" in software.  <further justifications needed here describing why it isn't possible to make this apply>.

    Therefore, this success criterion does not apply to non-web software.

  2. [based on saying "this applies generally to software, making certain assumptions"]

    <insert description here, and then reference a variant of software option #5 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/241-bypass-blocks explicitly replaces "on multiple Web pages" with "in software", and better describes both the bypassing mechanism & what constitutes a block that is repeated with in software>


  3. [based on saying "this is really occurs rarely or is easy or almost automatic to meet"]

    Since it doesn't make sense to talk about "blocks of content" that are repeated "in multiple software applications" if they don't belong to some kind of set (how would an author know the blocks are repeated) this provision has an implied "within a set of web pages".   For NWNE content this would seem to apply in a parallel fashion to web pages -- but there was difficulty in defining the range.  It has been proposed to define this as applying to sets of NWNE content, and software, using a clear definition of a set that is derived the interlinking that is natural on web sites. 
    1. SET  (of NWNE Content and Software)
      1. Group of NWNE content, or software, items that were created and operate as a unit as evidenced by the fact that they all either a) link bidirectionally with each other vis hyperlink or menu or b) consist of a set of sibling pages (with our without a parent) that all interlink with each other vis hyperlink or menu, and where all the other items in the set link bidirectionally-hierarchically to one or more of the sibling pages.
      2. NOTE:  If a group of items (software or NWNE content) meets this definition a user can navigate from any item in the set to any other item in the set using only the bidirectional links or menus in the items themselves. 
      3. NOTE:  This is common on the Web but less common for NWNE content that was not "spidered" down from the web, and even less common for software - where multiple programs rarely interlink in this fashion. 

Options for 2.4.5 Multiple Ways:

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 2.4.5 in Understanding WCAG 2.0, the intent of this SC is "to make it possible for users to locate content in a manner that best meets their needs".   However, the content being located is a single "Web page within a set of Web pages".  It doesn't make sense to apply this to a "software application within a set of software applications" for multiple reasons.  First, it isn't clear what comprises the "set of software applications", since, unlike sets of web pages within a web site, there isn't a clear boundary equivalent to a "web site" which could be subset to create that "set of software".  Furthermore, since any individual software application is typically its own world, how can it be responsible for location mechanisms outside of its own world?

    Therefore, this success criterion does not apply to non-web software.

  2. [based on saying "this applies generally to software, making certain assumptions"]

    <we have no real alternative fitting this slot; perhaps the best candidate is proposal #12 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/245-multiple-ways but the replacement suggestion doesn't really work for this argument (becomes "locate software within a set of software", which is really the <no-opt variant #2 below)>


  3. [based on saying "this is really occurs rarely or is easy or almost automatic to meet"]

    < variant #1> In software, virtually everything is either "the result of, or a step in, a process".  So while this SC applies as written, in truth it won't actually apply to any software applications in reality.  Thus is can essentially be ignored, but will still "technically apply".

    < variant #2> So long as the software has a name (see Page Titled), this is automatically satisfied on all known platforms that provide a function for application names, and a browse feature (including through the file system) to locate software.  Thus is can essentially be ignored, but will still "technically apply".

    [Gregg - this seemed to be your argument
     at the end of the meeting today; can you better express this?]

Options for 3.2.3 Consistent Navigation:

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 3.2.3 in Understanding WCAG 2.0, the intent of this SC is "to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once".  However, the navigation mechanisms are those that are repeated on multiple "Web pages within a set of Web pages".  It doesn't make sense to apply this to a navigation mechanisms repeated on multiple "software applications within a set of software applications" for multiple reasons.  First, it isn't clear what comprises the "set of software applications", since, unlike sets of web pages within a web site, there isn't a clear boundary equivalent to a "web site" which could be subset to create that "set of software".  Furthermore, since any individual software application is typically its own world, how can it be responsible for any aspects of the UI of applications outside of its own world?

    Therefore, this success criterion does not apply to non-web software.


  2. [based on saying "this applies generally to software, making certain assumptions"]

    <summarize / rehash option #8 at https://sites.google.com/site/wcag2ict/home/3-understandable/32-make-web-pages-appear-and-operate-in-predictable-ways/323-consistent-navigation - explicitly replacing "
    on multiple Web pages within a set of Web pages" with "in software", and replacing "navigation elements" with "User interface controls in groups">

  3. [based on saying "this is really occurs rarely or is easy or almost automatic to meet"]

    [Gregg - this seemed to be your argument at the end of the meeting today; can you put something here?]

 We would like WCAG WG to clarify whether they will categorically refuse to agree to that statement appearing anywhere.

For some of the SCs (including specifically 3.2.3, see below), some members of the TF feel that might successfully apply the principals and guidelines behind the SCs, and directly address the Intent of the SC, by going slightly beyond simply defining what terms mean in software.  E.g. it may be more than just "navigation mechanisms" that appear in a consistent order when repeated.  Other TF members fear this goes too far toward "writing a new SC", which is beyond the TF's charter.    We would like WCAG WG to clarify whether they will entertain SC application language that addresses the spirit and purpose of the SC, but may differ more significant in the specific SC language than simple "web page" replacement would allow.  

And finally, some TF members feel that there are ways to craft one or more of the remaining SCs such that are essentially "no-ops" - the text is there but it describes situations that essentially never come up in real life.  Other TF members feel that in such situations it would be better to state "this doesn't apply to software", out of concern that leaving it in in such a fashion would be confusing and/or detract from the value of the work overall.  [Gregg - this seemed to be a route you were arguing at the end of the call today, so please re-write this to better capture your position, including if appropriate a "call to WCAG" to weigh in on a question in some fashion]

Specific options/proposals for these three SCs:

Below we capture three different proposals for each of the three remaining SCs.  These proposals are for text that would appear in our document Applying WCAG to Non-Web ICT for these SCs respectively.  Each of the three general options above are explored in specific below.  

We would appreciate WCAG WG providing the TF with direction based on these options: Is any one of them preferred by the WG?  Is any one of them categorically outside of our scope?  Does the WG find any specific options sufficient promising - but not "there yet" - that you would like us to focus on further improvements to it?


Options for 2.4.1 - Bypass Blocks:

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 2.4.1 in Understanding WCAG 2.0, the intent of this SC is  "to allow people who navigate sequentially through content more direct access to the primary content of the Web page".   In software, there often isn't a notion of "primary content".  Particularly on any given area of software (e.g. the "Save As" dialog), such isn't the case.  Separately, this provisions is scoped to those blocks that are "repeated on multiple web pages", and there is no clear analog to "multiple web pages" in software.  <further justifications needed here describing why it isn't possible to make this apply>.

    Therefore, this success criterion does not apply to non-web software.

  2. [based on saying "this applies generally to software, making certain assumptions"]

    <insert description here, and then reference a variant of software option #5 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/241-bypass-blocks explicitly replaces "on multiple Web pages" with "in software", and better describes both the bypassing mechanism & what constitutes a block that is repeated with in software>


  3. [based on saying "this is really a no-op, but we're applying it anyway"]

    Since it doesn't make sense to talk about "blocks of content" that are repeated "in multiple software applications", while this SC applies as written, in truth it won't actually apply to any individual software applications in reality.  Thus is can essentially be ignored, but will still "technically apply".  [Gregg - this seemed to be your argument at the end of the meeting today; can you better express this?]

Options for 2.4.5 Multiple Ways:

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 2.4.5 in Understanding WCAG 2.0, the intent of this SC is "to make it possible for users to locate content in a manner that best meets their needs".   However, the content being located is a single "Web page within a set of Web pages".  It doesn't make sense to apply this to a "software application within a set of software applications" for multiple reasons.  First, it isn't clear what comprises the "set of software applications", since, unlike sets of web pages within a web site, there isn't a clear boundary equivalent to a "web site" which could be subset to create that "set of software".  Furthermore, since any individual software application is typically its own world, how can it be responsible for location mechanisms outside of its own world?

    Therefore, this success criterion does not apply to non-web software.

  2. [based on saying "this applies generally to software, making certain assumptions"]

    <we have no real alternative fitting this slot; perhaps the best candidate is proposal #12 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/245-multiple-ways but the replacement suggestion doesn't really work for this argument (becomes "locate software within a set of software", which is really the <no-opt variant #2 below)>


  3. [based on saying "this is really a no-op, but we're applying it anyway"]

    <no-op variant #1> In software, virtually everything is either "the result of, or a step in, a process".  So while this SC applies as written, in truth it won't actually apply to any software applications in reality.  Thus is can essentially be ignored, but will still "technically apply".

    <no-op variant #2> So long as the software has a name (see Page Titled), this is automatically satisfied on all known platforms that provide a function for application names, and a browse feature (including through the file system) to locate software.  Thus is can essentially be ignored, but will still "technically apply".

    [Gregg - this seemed to be your argument
     at the end of the meeting today; can you better express this?]

Options for 3.2.3 Consistent Navigation:

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 3.2.3 in Understanding WCAG 2.0, the intent of this SC is "to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once".  However, the navigation mechanisms are those that are repeated on multiple "Web pages within a set of Web pages".  It doesn't make sense to apply this to a navigation mechanisms repeated on multiple "software applications within a set of software applications" for multiple reasons.  First, it isn't clear what comprises the "set of software applications", since, unlike sets of web pages within a web site, there isn't a clear boundary equivalent to a "web site" which could be subset to create that "set of software".  Furthermore, since any individual software application is typically its own world, how can it be responsible for any aspects of the UI of applications outside of its own world?

    Therefore, this success criterion does not apply to non-web software.


  2. [based on saying "this applies generally to software, making certain assumptions"]

    <summarize / rehash option #8 at https://sites.google.com/site/wcag2ict/home/3-understandable/32-make-web-pages-appear-and-operate-in-predictable-ways/323-consistent-navigation - explicitly replacing "
    on multiple Web pages within a set of Web pages" with "in software", and replacing "navigation elements" with "User interface controls in groups">

  3. [based on saying "this is really a no-op, but we're applying it anyway"]

    [Gregg - this seemed to be your argument at the end of the meeting today; can you put something here?]




=========== Proposal 1 Peter with questions for Gregg  =====

As of 19 October 2012, there are 3 A/AA Success Criteria for which the TF hasn't been able to reach consensus.  All three share one thing in common: they are written to apply to a web page in the context of a set of or among multiple web pages - which we find particularly challenging in the non-web software context.

This page looks at these three SCs, describes the challenges we see in applying them to non-web software, and explores options / proposals for how we might address those challenges.  TF members weren't able to reach consensus on any of these options, and some TF members question whether the TF is even allowed to explore/use some of these options, feeling that some of the specific options/proposals are outside of the TF's scope / work statement. 

We present these issues & options to our parent WG, in hopes that they may provide guidance/direction.


The three remaining A/AA SCs are:

2.4.1 - Bypass Blocks
mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

2.4.5 - Multiple Ways
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.


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

Challenges arising from these three SCs:

General challenges:

We have struggled with how to define "a set of web pages" in software or "multiple web pages" in software, and not come up with a satisfying answer.  We have tried the following substitutions:

  • web page = "screen" or "top level frame"
    And so "multiple web pages" would be the entire software application.  This wasn't satisfying because <insert here>.

  • web page ="interaction context" or "user interface context"
    The problem here was that we couldn't come up with a satisfying definition of either a single "interaction context" or what a "set of interaction contexts" would be (and where it would stop) (see User Interface Context and its sub-pages for more on this).

  • "set of web pages" = "software"
    This seems to have the most potential, but gives rise to specific challenges in each SC (described below).  Also, there is the question of where "software" stops, particularly for large application suites that may present entirely different interfaces to different classes of users (e.g. an administrative interface as distinct from the end-user interface; an order entry interface vs. an inventory management interface).  Also, this substitution may perhaps push the boundary of our mandate; are we creating a new SC by doing this substitution?


Specific challenges with 2.4.1 - Bypass Blocks:

Intent from Understanding Success Criterion 2.4.1 in Understanding WCAG 2.0 notes that the intent is "to allow people who navigate sequentially through content more direct access to the primary content of the Web page".  It often isn't clear what the "primary content" is of a software application.

Further, it wasn't clear what would constitute a "mechanism for bypassing" blocks of content generally in software.  Is this only moving the focus?  What about touch interfaces (and the built-in speech provided by things like VoiceOver and TalkBack? as well as switch access provided on such platforms like Tecla?)  Finally, it wasn't clear what would constitute a "block of content" - would repeated user interface controls like a menu bar and a ribbon constitute such a block?  And what does it mean for such a block to be repeated?  If there is only ever one window with a menu bar on it - though it can contain different content (e.g. a document editor), does that constitute "repetition" for this SC?

Specific challenges with 2.4.5 Multiple Ways:

Intent from Understanding Success Criterion 2.4.5 in Understanding WCAG 2.0 notes that the intent is "to make it possible for users to locate content in a manner that best meets their needs".  But what is the "unit" of content that is being located?  How important is "locating content" in software, as compared to "interacting with content" - e.g. entering data or modifying a document?  Is most of software interaction essentially "steps in a process" such that this SC rarely - if ever - applies?  In the software context, are there any users with disabilities who are running into problems somewhere because this SC isn't met in that instance? [we couldn't find any real-live examples of problems from clear violations of the SC]

Specific challenges with 3.2.3 Consistent Navigation:

Intent from Understanding Success Criterion 3.2.3 in Understanding WCAG 2.0 notes that the intent is "to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once".  Further, Understanding notes several examples, the first of which is: " A consistently located control: A search field is the last item on every Web page in a site. users can quickly locate the search function" and 

We had a lot of difficulty with the concept of what a "navigation mechanism" is in software.  Is bringing up a "Save As" dialog activating a "navigation mechanism"? (or is it an "action" instead? or a "step in a process" as per 2.4.5?).  If the focus doesn't change when operating some UI component, can it still be a "navigation mechanism"?  We also had a lot of difficulty with the boundary of "software" (which goes back to the question of what is a "set of web pages").  The situation of large software applications with multiple different UIs (admin UI vs. client user UI; order entry vs. inventory management) is particularly challenging here - not only might it be appropriate to have the same navigation mechanisms appear in different order based on frequency of use and efficiency for a given UI/task, but large applications may roll out UI changes - including a change in the sequence of presentation of a set of navigation mechanisms - over a series of releases.  In such cases, a new order of the navigation mechanisms may be rolled out to distinct and clear portions of the over software UI successively over time; something we don't think should be made an accessibility violation.  So there must be some way of defining the scope such that it isn't to "the entire software application, however large or multi-faceted".


General options we see for these three SCs:

For all of the SCs, one potential option we see is to simply say "this doesn't apply to software".  While some members of the TF don't support this specific option for specific remaining SCs (not always the same members for each SC!) - because they can find specific examples of software (that generally "look like web pages" even if they can't suggest a global rule that could be applied to all software) - others object because they don't believe it is within the TF's charter to state "this doesn't apply to software" for any of the SCs.  We would like WCAG WG to clarify whether they will categorically refuse to agree to that statement appearing anywhere.

For some of the SCs (including specifically 3.2.3, see below), some members of the TF feel that might successfully apply the principals and guidelines behind the SCs, and directly address the Intent of the SC, by going slightly beyond simply defining what terms mean in software.  E.g. it may be more than just "navigation mechanisms" that appear in a consistent order when repeated.  Other TF members fear this goes too far toward "writing a new SC", which is beyond the TF's charter.    We would like WCAG WG to clarify whether they will entertain SC application language that addresses the spirit and purpose of the SC, but may differ more significant in the specific SC language than simple "web page" replacement would allow. 

And finally, some TF members feel that there are ways to craft one or more of the remaining SCs such that are essentially "no-ops" - the text is there but it describes situations that essentially never come up in real life.  Other TF members feel that in such situations it would be better to state "this doesn't apply to software", out of concern that leaving it in in such a fashion would be confusing and/or detract from the value of the work overall.  [Gregg - this seemed to be a route you were arguing at the end of the call today, so please re-write this to better capture your position, including if appropriate a "call to WCAG" to weigh in on a question in some fashion]

Specific options/proposals for these three SCs:

Below we capture three different proposals for each of the three remaining SCs.  These proposals are for text that would appear in our document Applying WCAG to Non-Web ICT for these SCs respectively.  Each of the three general options above are explored in specific below. 

We would appreciate WCAG WG providing the TF with direction based on these options: Is any one of them preferred by the WG?  Is any one of them categorically outside of our scope?  Does the WG find any specific options sufficient promising - but not "there yet" - that you would like us to focus on further improvements to it?


Options for 2.4.1 - Bypass Blocks:

mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 2.4.1 in Understanding WCAG 2.0, the intent of this SC is  "to allow people who navigate sequentially through content more direct access to the primary content of the Web page".   In software, there often isn't a notion of "primary content".  Particularly on any given area of software (e.g. the "Save As" dialog), such isn't the case.  Separately, this provisions is scoped to those blocks that are "repeated on multiple web pages", and there is no clear analog to "multiple web pages" in software.  <further justifications needed here describing why it isn't possible to make this apply>.

    Therefore, this success criterion does not apply to non-web software.

  2. [based on saying "this applies generally to software, making certain assumptions"]

    <insert description here, and then reference a variant of software option #5 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/241-bypass-blocks explicitly replaces "on multiple Web pages" with "in software", and better describes both the bypassing mechanism & what constitutes a block that is repeated with in software>


  3. [based on saying "this is really a no-op, but we're applying it anyway"]

    Since it doesn't make sense to talk about "blocks of content" that are repeated "in multiple software applications", while this SC applies as written, in truth it won't actually apply to any individual software applications in reality.  Thus is can essentially be ignored, but will still "technically apply".  [Gregg - this seemed to be your argument at the end of the meeting today; can you better express this?]

Options for 2.4.5 Multiple Ways:

More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 2.4.5 in Understanding WCAG 2.0, the intent of this SC is "to make it possible for users to locate content in a manner that best meets their needs".   However, the content being located is a single "Web page within a set of Web pages".  It doesn't make sense to apply this to a "software application within a set of software applications" for multiple reasons.  First, it isn't clear what comprises the "set of software applications", since, unlike sets of web pages within a web site, there isn't a clear boundary equivalent to a "web site" which could be subset to create that "set of software".  Furthermore, since any individual software application is typically its own world, how can it be responsible for location mechanisms outside of its own world?

    Therefore, this success criterion does not apply to non-web software.

  2. [based on saying "this applies generally to software, making certain assumptions"]

    <we have no real alternative fitting this slot; perhaps the best candidate is proposal #12 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/245-multiple-ways but the replacement suggestion doesn't really work for this argument (becomes "locate software within a set of software", which is really the <no-opt variant #2 below)>


  3. [based on saying "this is really a no-op, but we're applying it anyway"]

    <no-op variant #1> In software, virtually everything is either "the result of, or a step in, a process".  So while this SC applies as written, in truth it won't actually apply to any software applications in reality.  Thus is can essentially be ignored, but will still "technically apply".

    <no-op variant #2> So long as the software has a name (see Page Titled), this is automatically satisfied on all known platforms that provide a function for application names, and a browse feature (including through the file system) to locate software.  Thus is can essentially be ignored, but will still "technically apply".

    [Gregg - this seemed to be your argument
    at the end of the meeting today; can you better express this?]

Options for 3.2.3 Consistent Navigation:

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

  1. [based on saying "this doesn't apply"]

    As noted in Understanding Success Criterion 3.2.3 in Understanding WCAG 2.0, the intent of this SC is "to encourage the use of consistent presentation and layout for users who interact with repeated content within a set of Web pages and need to locate specific information or functionality more than once".  However, the navigation mechanisms are those that are repeated on multiple "Web pages within a set of Web pages".  It doesn't make sense to apply this to a navigation mechanisms repeated on multiple "software applications within a set of software applications" for multiple reasons.  First, it isn't clear what comprises the "set of software applications", since, unlike sets of web pages within a web site, there isn't a clear boundary equivalent to a "web site" which could be subset to create that "set of software".  Furthermore, since any individual software application is typically its own world, how can it be responsible for any aspects of the UI of applications outside of its own world?

    Therefore, this success criterion does not apply to non-web software.


  2. [based on saying "this applies generally to software, making certain assumptions"]

    <summarize / rehash option #8 at https://sites.google.com/site/wcag2ict/home/3-understandable/32-make-web-pages-appear-and-operate-in-predictable-ways/323-consistent-navigation - explicitly replacing "
    on multiple Web pages within a set of Web pages" with "in software", and replacing "navigation elements" with "User interface controls in groups">

  3. [based on saying "this is really a no-op, but we're applying it anyway"]

    [Gregg - this seemed to be your argument at the end of the meeting today; can you put something here?]


Comments