2.4.1 Bypass Blocks:







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


NEW TEXT FOR THIS ITEM CAN BE FOUND AT 
                                                                                                            .
https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/remaining-3-scs








                                                                                                                               
               <NEW TEXT TO SENT OUT FOR REVIEW #2                                     .
                                                                                                                               

Success Criterion 2.4.1: Bypass Blocks (Level A)

From Success Criterion 2.4.1:

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

Intent from Understanding Success Criterion 2.4.1 in Understanding WCAG 2.0:

The intent of this Success Criterion is to allow people who navigate sequentially through content more direct access to the primary content of the Web page. Web pages and applications often have content that appears on other pages or screens. Examples of repeated blocks of content include but are not limited to navigation links, heading graphics, and advertising frames. Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision.

This is in contrast to a sighted user's ability to ignore the repeated material either by focusing on the center of the screen (where main content usually appears) or a mouse user's ability to select a link with a single mouse click rather than encountering every link or form control that comes before the item they want.

It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent. Most web browsers provide keyboard shortcuts to move the user focus to the top of the page, so if a set of navigation links is provided at the bottom of a web page providing a "skip" link may be unnecessary.

Note: Although this Success Criterion deals with blocks of content that are repeated on multiple pages, we also strongly promote structural markup on individual pages as per Success Criteria 1.3.1.

Specific Benefits of Success Criterion 2.4.1
  • When this Success Criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily.

  • Screen reader users who visit several pages on the same site can avoid having to hear all heading graphics and dozens of navigation links on every page before the main content is spoken.

  • People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users.

  • People who use screen magnifiers do not have to search through the same headings or other blocks of information to find where the content begins each time they enter a new page.

  • People with cognitive limitations as well as people who use screen readers may benefit when links are grouped into lists


    <request WCAG WG to modify INTENT as follows>

    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.



*** Note: the text just below this section incorrectly reflects the final decision of WCAG as published in Working Draft 13 December 2012 which can be found at: http://www.w3.org/TR/2012/WD-wcag2ict-20121213/#navigation-mechanisms-skip
That published text is:
Additional guidance when applying Success Criterion 2.4.1 to Non-Web Documents and Software:

For Documents:

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

With these substitutions, it would read:

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

For Software: 

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


Additional guidance when applying to Non-Web Documents and Software

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 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, 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 of software 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.



                                                                                                                             .
               </END of NEW TEXT TO SENT OUT FOR REVIEW #2                      .
                                                                                                                               




<         PUBLIC COMMENTS ON THIS ITEM ARE ABOVE  >.   
 <  OUR RESPONSE TO PUBLIC COMMENTS ARE BELOW>




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

Success Criterion 2.4.1: Bypass Blocks (Level A)

From Success Criterion 2.4.1:

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

Intent from Understanding Success Criterion 2.4.1 in Understanding WCAG 2.0:

The intent of this Success Criterion is to allow people who navigate sequentially through content more direct access to the primary content of the Web page. Web pages and applications often have content that appears on other pages or screens. Examples of repeated blocks of content include but are not limited to navigation links, heading graphics, and advertising frames. Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision.

This is in contrast to a sighted user's ability to ignore the repeated material either by focusing on the center of the screen (where main content usually appears) or a mouse user's ability to select a link with a single mouse click rather than encountering every link or form control that comes before the item they want.

It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent. Most web browsers provide keyboard shortcuts to move the user focus to the top of the page, so if a set of navigation links is provided at the bottom of a web page providing a "skip" link may be unnecessary.

Note: Although this Success Criterion deals with blocks of content that are repeated on multiple pages, we also strongly promote structural markup on individual pages as per Success Criteria 1.3.1.

Specific Benefits of Success Criterion 2.4.1
  • When this Success Criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily.

  • Screen reader users who visit several pages on the same site can avoid having to hear all heading graphics and dozens of navigation links on every page before the main content is spoken.

  • People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users.

  • People who use screen magnifiers do not have to search through the same headings or other blocks of information to find where the content begins each time they enter a new page.

  • People with cognitive limitations as well as people who use screen readers may benefit when links are grouped into lists

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

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



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

Success Criteria 2.4.1: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)


Intent of WCAG Success Criteria 2.4.1  (Quoted from Understanding WCAG 2.0)

The intent of this Success Criterion is to allow people who navigate sequentially through content more direct access to the primary content of the Web page. Web pages and applications often have content that appears on other pages or screens. Examples of repeated blocks of content include but are not limited to navigation links, heading graphics, and advertising frames. Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision.

This is in contrast to a sighted user's ability to ignore the repeated material either by focusing on the center of the screen (where main content usually appears) or a mouse user's ability to select a link with a single mouse click rather than encountering every link or form control that comes before the item they want.

It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent. Most web browsers provide keyboard shortcuts to move the user focus to the top of the page, so if a set of navigation links is provided at the bottom of a web page providing a "skip" link may be unnecessary.

Note: Although this Success Criterion deals with blocks of content that are repeated on multiple pages, we also strongly promote structural markup on individual pages as per Success Criteria 1.3.1.

Specific Benefits of Success Criterion 2.4.1:

  • When this Success Criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily.

  • Screen reader users who visit several pages on the same site can avoid having to hear all heading graphics and dozens of navigation links on every page before the main content is spoken.

  • People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users.

  • People who use screen magnifiers do not have to search through the same headings or other blocks of information to find where the content begins each time they enter a new page.

  • People with cognitive limitations as well as people who use screen readers may benefit when links are grouped into lists


<End of material Quoted from Understanding WCAG 2.0>


Additional guidance when applying to ICT

< Task force language goes here when consensus is reached > 

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




PROPOSALS FOR  CONSENSUS TEXT =================

Insert your proposals for the text to go above.  Label each Proposal separately.  Trace has provided a startup proposal for each.   Below is a template.  Please copy it and leave a template behind for others to add their proposal.
 

Proposal #1 (Trace Center) ========================

Additional guidance when applying to Electronic Documents \

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above)   with the word “document” substituted for Web Page.  This would apply to documents in a set – or documents bound into a set (pages or sections or chapters in a large document) that have repeated blocks of text..

(see Introduction for how to interpret "content" and "Web Page")

Additional guidance when applying to Software Aspects of Products

This applies directly as written and as described in INTENT from WCAG (above) with the word “interaction context” substituted for Web Page.

This is very important provision for software, where menus, ribbons and much other content is repeated throughout.   For much software (all well structured software)  - this provisions is easy and almost automatically met by the structure of the software.   However for other software, and for books and documents with built in interaction, which also fall into the category of software, attention needs to be paid to this provision in order to allow users to skip over blocks of repeated information for the reasons cited in the Intent section above from the WCAG 2.0 understanding document. 

Proposal #2 (Loïc Martínez) ========================

Additional guidance when applying to Electronic Content and Electronic Documents 

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with the word “document” substituted for Web Page. This would apply to documents in a set – or documents bound into a set (pages or sections or chapters in a large document) that have repeated blocks of content.


Additional guidance when applying to Software Aspects of Products

This applies directly as written and as described in INTENT from WCAG (above) with the word “interaction context” substituted for Web Page.This would apply to software user interfaces that have blocks of content that are repeated on multiple interaction contexts (windows, dialog boxes...) of one software product.

In most cases, platform software provide standard menu interfaces and those menu interfaces can be easily bypassed by users. In such cases developers don’t have to develop any explicit support for success criterion 2.4.1.


Proposal #3 (Peter Korn) ========================

[I know this is long; I'm sure it can be made shorter with good editing, but I wanted to get the ideas out for discussion ASAP]

Additional guidance when applying to Electronic Documents 

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with the word “document” substituted for Web Page. This would apply to documents in a set – or documents bound into a set (pages or sections or chapters in a large document) that have repeated blocks of content.


Additional guidance when applying to Software Aspects of Products

As stated at the start of the Intent for WCAG Success Criteria 2.4.1 (quoted from Understanding WCAG 2.0) "The intent of this Success Criterion is to allow people who navigate sequentially through content to more direct access the primary content of the Web page."  Software Aspects of products rarely consist of repeated blocks of content that appear in different windows, dialog boxes, etc. (though it does happen occasionally).  However, it is fairly common to have blocks of user interface elements that appear sequentially in software user interfaces ahead of the main content area - e.g. a menu bar at the top of a window, a ribbon containing controls above the editable content region.  

Furthermore, the first specific benefit cited in the Intent for WCAG Success Criteria 2.4.1 (quoted from Understanding WCAG 2.0) is "When this Success Criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily."  Similarly in software user interfaces, it may be difficult for people with some disabilities to reach the main content region of the interface if they cannot quickly skip over blocks of user interface elements that appear sequentially in software user interfaces ahead of the main content area

This success criterion applies directly as written for those cases where software aspects of products include repeated pages/screens [interaction contexts?] where a block of content or user interface elements are repeated across them.  Furthermore, this success criterion also applies to those cases where a block of content or a block of user interface elements appear sequentially above the main content of the software user interface - such as a menu bar or a ribbon - so that users have a way to skip directly to the main content and over the block(s) of user interface elements.

Note that in the case of software user interfaces involving things like menu bars and ribbons, it is common in that interface paradigm to automatically skip over that content and immediately place the users focus in the main content region.  Specific keystroke or other commands are then commonly employed to bring the user interaction to items that were skipped over, automatically returning to the main content region afterward.  Such design patterns automatically meet this criterion.


Proposal #4 (Trace - inspired by Peter Korn's but shortened and (hopefully) tuned) ========================

 Additional guidance when applying to Electronic Documents  and Software Aspects of Products

For documents this applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with the word “document” substituted for Web Page. This would apply to documents in a set – or documents bound into a set (pages or sections or chapters in a large document) that have repeated blocks of content.

For software this would also apply as written - though the problem with software is often that the repeated blocks are of user interface elements (menus or ribbon bars for example) rather than blocks of text. 

Note that in the case of software user interfaces, it is common in that structure of the program allows the user to easily skip skip over these repeated blocks (e.g.  menu bars and ribbons) and immediately place the users focus in the main content region.  Specific keystroke or other commands are then commonly employed to bring the user interaction back to the items in that block when they are needed.  In these cases the structure naturally would allow the software to meet this criterion rather than needing to provide any dedicated mechanism for skipping over the blocks. 



Proposal #5 (Peter Korn, leveraging the contents of Proposal #2 for Provision 2.4 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are) ========================

Additional guidance when applying to Electronic Documents 

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with the word “document” substituted for Web Page. This would apply to documents in a set – or documents bound into a set (pages or sections or chapters in a large document) that have repeated blocks of content.


Additional guidance when applying to Software Aspects of Products

This success criterion applies directly as written for those cases where software aspects of products include repeated block(s) of content or user interface elements. 

In keeping with the application of Guideline 2.4 to Software Aspects of Products, this success criterion also applies to those cases where a block of content or a block of user interface elements appears above the main content of a software user interface - such as a menu bar or a ribbon - even if this happens only one time in the interface.  It is important that users have a way to skip directly to the main content and over the block(s) of user interface elements.

Note that in the case of software user interfaces such as menu bars and ribbons, it is common in that interface paradigm for the software to automatically place the user's focus in the main content region.  Specific keystroke or other commands are then commonly employed to bring the user interaction to items that were skipped over, automatically returning to the main content region afterward.  Such design patterns automatically meet this criterion.



Proposal #6 (Trace - incorporating more Peter Korn observations) ========================

 Additional guidance when applying to Electronic Documents  and Software Aspects of Products

For documents this applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with the word “document” substituted for Web Page. This would apply to documents in an author defined set – or documents bound into a set (pages or sections or chapters in a large document) that have repeated blocks of content.

For software aspects of products this would also apply as written - with the phrase "on different windows or screens, or the same window or screen when loaded with different content" substituted for "on multiple Web Pages".

Notes:  
  1. For some non-windowing products, there is only ever one "window" or "screen" visible at a time. 
  2. With software the repeated blocks are often repeated blocks of user interface elements (menus or ribbon bars for example)  more often than blocks of repeated text.   
  3. In the case of software user interfaces, it is common in that structure of the program allows the user to easily skip skip over these repeated blocks of user interface elements (e.g.  menu bars and ribbons) and meet this success criterion without any special considerations by the author being made other than good, structured, interface design. 
  4. When these blocks are at the top of a page, focus is often placed below them in the main content area.   Specific keystroke or other commands are then commonly employed to bring the user interaction back to the items in the block above when they are needed.  

  

<NOTE TO TASK FORCE:  THE ABOVE "or the same window when loaded with different content" COVERS THE SITUATION WHERE, WITHOUT THE ABILITY TO SKIP, THE USER WOULD HAVE TO STEP THROUGH ALL THE CONTROLS EACH TIME THEY OPENED A NEW DOCUMENT OR DATA FILE OR OTHER CONTENT IN THE WINDOW WITH THE BLOCK OF CONTROLS AT THE TOP>

Proposal #6 REVISED (Gregg - incorporating Peter Korn observations and new Loic Mike Language) ========================

 Additional guidance when applying to Electronic Documents  and Software Aspects of Products

For documents, this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for Web Page  and "set of documents published as a single entity" substituted for "set of web pages".

For software this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “user interface context” substituted for Web Page  and "software program" substituted for "set of web pages".


Notes:  
  1. For some non-windowing products, there is only ever one "window" or "screen" visible at a time and it would be the 'user interface context'. 
  2. As with WCAG, changing a major portion of the user interface elements or information presented would constitute a "change of context".  So an application window that has very different content at different times would constitute a new 'context' for each instance and blocks of material that appear on each instance (each context) would be considered repeated. 
  3. In the case of software user interfaces, it is common in that structure of the program allows the user to easily skip skip over these repeated blocks of user interface elements (e.g.  menu bars and ribbons) and meet this success criterion without any special considerations by the author being made other than good, structured, interface design. 
  4. When these blocks are at the top of a page, focus is often placed below them in the main content area.   Specific keystroke or other commands are then commonly employed to bring the user interaction back to the items in the block above when they are needed.  

  

<NOTE TO TASK FORCE:  NOTE 2 ABOVE COVERS THE SITUATION WHERE, WITHOUT THE ABILITY TO SKIP, THE USER WOULD HAVE TO STEP THROUGH ALL THE CONTROLS EACH TIME THEY OPENED A NEW DOCUMENT OR DATA FILE OR OTHER CONTENT IN THE WINDOW WITH THE BLOCK OF CONTROLS AT THE TOP> 



Proposal #7 (Gregg - incorporating  Mike approach) ========================

Additional guidance when applying to Electronic Documents  and Software Aspects of Products

For documents, this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above)  replacing "multiple web pages" Web Page  with "in a document".

For software this applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above) "multiple web pages"  with "in software" 

Note that the INTENT section of WCAG already says:

“Examples of repeated blocks of content include but are not limited to navigation links, heading graphics, and advertising frames. Small repeated sections such as individual words, phrases or single links are not considered blocks for the purposes of this provision”


FOR REFERENCE

Success Criteria 2.4.1: mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)


Proposal #8 (From Gregg's Whitepaper) ========================

Additional guidance when applying to Electronic Documents  and Software Aspects of Products

This applies directly as written and as described in  INTENT  from Understanding WCAG 2.0  (above)  replacing "on multiple web pages" with "in non-embedded content or software".


Proposal #x (Submitter) ========================

Additional guidance when applying to Electronic Documents and Software Aspects of Products


DISCUSSION POINTS, OPINIONS, ISSUES, NOTES etc. 

---- Proposal explanation -----

Proposal #2 (Loïc Martínez)

  • Documents. I mostly accepted the TRACE proposal with a minor change at the end. I've written "repeated blocks of content" instead of "repeated blocks of text", to be more general.
  • Software. I've taken the first paragraph of the TRACE proposal, added an explanation similar to the second sentence of the documents proposals and added the applicability note from M376 where it explains that in most cases nothing needs to be done because there is platform support for skipping standard menus.


---- ISSUES-----

RE – Documents

Issue1: "Generally won't apply to nearly all documents.  Also this is more a user-agent issue if any"                                         :

Comment on Issue1: It could easily occur in document that has headers and footers on every page.  Also if it had a sidebar or other material that is repeated at every chapter or page.   But if marked as such – user agents can skip them.  There is a user agent interaction – as with many provisions.   Think of it as “interaction with the next platform above”.  All content and most software has such interactions.

 

RE - Software

Issue1: Not clear what this means in a software context.  Key topic for group discussion!  :

Comment on Issue1: "Blocks of content that are repeated"  would be the menus and ribbons and panes (e.g. doc outline pane ) etc.  that are repeated within a context of interaction.

Comment on above comment on issue1: From the introduction, there is text giving examples of an "interaction context" are are: Some examples of interaction contexts would be a window, a dialog box, a speech-based menu an audio menu, and an application.   The comment above seems to speak to interactions contexts (though stated as "context of interaction"), and speaks to things repeated "within" one of them.  In a given window, there is typically only one ribbon (if any); where there are multiple they are different.  Likewise there tends to be only one menu bar for an application (or window) - not repeated "within a context of interaction".  Issue1 still seems to stand: it isn't clear what this means in the software context.1

Comment on above comment on above comment on issue 1: this SC does not refer to content repeated "within" one interaction context, but to content repeated in "multiple" interaction contexts.



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

For Software
In most cases, platform software provide standard menu interfaces and those menu interfaces can be easily bypassed by users. In such cases developers don’t have to develop any explicit support for success criterion 2.4.1.



IBM comments on 2011 ANPRM, Appendix A (p. 21, 6 March 2012)
How can this be applied to a software application or to a platform?  Is “content” to be interpreted to mean “user interface components”, where things like toolbars/ribbons are considered “blocks” that one should be able to skip over (e.g. with a hot-key for bringing focus to the content region when focus might be on a specific toolbar item)?

How can this requirement be applied to documentation content such as help text or other display of content where there may be blocks of content repeated among sets of documents?  Is there some other meaning?



2010 ANPRM Text (22 March 2010)
406 Navigation
406.1 General.  ICT shall conform to 406.
406.2 Bypass Blocks of Content.  A mode of operation shall be provided for the user to bypass blocks of content that are repeated within an ICT product.



Teitac Report (3 April 2008)
Level A WCAG guidelines not included:
  • 2.4.1 Bypass Blocks
Comments