Looking at SC 2.4.1 Bypass Blocks with "UI Context"

Hi gang,

SC *2.4.1 
<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>**Bypass 
Blocks *was not one we reached consensus on.  We struggled with it for a 
while, and have developed 6 proposals in attempts to solve it.  
Discussion of our last (non-UIC) proposal can be found July 6 survey 
<https://www.w3.org/2002/09/wbs/55145/JUL062012/results#xq3>.  Many felt 
that this SC was one we need to discuss with WCAG WG, as it is generally 
a poor match for software.  Some of those who felt that way are part of 
the UIC proposal, and crafted the UIC version.

My thoughts on that can be found at the Applying UI Context 
<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/applying-ui-context> 
page in the second row, but to facilitate discussion, I reiterate them here.

The software portion of the UIC Proposal is:

    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:

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

Key to this (2nd paragraph of Notes) is the concept that there can be a 
"change of context" which is part of how this SC would kick in.  I'm 
very concerned about having a clean enough description of what 
does/doesn't trigger such a change such that it can be objectively 
evaluated independently by different people who nonetheless reach the 
same conclusion.  Also, to go with this proposal we will further need to 
define "software program" (which I know is being discussed already in a 
different thread).

I remain unconvinced that this is the right approach for 2.4.2. Bypass 
Blocks.  I think this is one (of a small handful) where we should have a 
discussion with WCAG WG.  I find the way Bypass Blocks is triggered in 
either this proposal or the earlier #6 proposal as being too 
"constructed" in order to capture only a portion of the situations in 
which it is truly needed for some users with disabilities, and that the 
best thing to do is see if the WG would give us permission to be a bit 
more broad in the software context (perhaps ahead of an eventual WCAG 
2.x revision of this SC).


Peter
-- 
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment