W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > July 2012

Re: Looking at SC 2.4.1 Bypass Blocks with "UI Context"

From: Peter Korn <peter.korn@oracle.com>
Date: Fri, 13 Jul 2012 11:10:15 -0700
Message-ID: <50006487.1000907@oracle.com>
To: Gregg Vanderheiden <gv@trace.wisc.edu>
CC: public-wcag2ict-tf@w3.org
Hi Gregg,

>> <PK>
>> 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).
>
> *GV:  this doesn't "kick in " with a change of context in the WCAG 
> sense of this.   And it think the definition makes it quite clear what 
> different contexts are.   Can you give examples of things that are 
> ambiguous?     Please apply the definition first though - to see if it 
> differentiates.
> *

PK: Quoting from the second paragraph of the Notes, it says: " 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."  I read this as meaning that when some threshold of changes 
within the context of a single UI Context occurs, THEN we have a 
sufficiently different UI Context in front of us SUCH THAT the repeated 
blocks situation is triggered.  That's what I mean by "kick in".

To take a concrete - though constructed - example:

  * I have an application with two non-modal windows always open all the
    time
  * At the top of one of these windows ("window A") is a ribbon
    containing a bunch of controls
  * At certain times a lot of the content and controls change in the UI
    Context (perhaps "window B" changes layout & design very significantly)
  * Based on this proposal, I may or may not be in a situation in which
    a "change of context" has occurred and therefore I may (or may not)
    be required to provide a mechanism to skip over the ribbon of
    "window a" because that ribbon has been "repeated" in two different
    "incarnations" of this single UI Context

That's my reading of these notes.  And it isn't at all clear to me how I 
would describe the threshold to an engineer which situations and 
behaviors of their application would trigger the need to apply this SC 
under this proposal to their application.


Also, can you please cite a reference for the first sentenced in the 2nd 
paragraph of the Notes, which reads: "As with WCAG, changing a major 
portion of the user interface elements or information presented would 
constitute a "change of context""  If the URL doesn't change for a 
single web page, but the content of that pages changes substantially, I 
don't believe this SC would apply - unless that single URL was part of a 
set of URLs and that set of URLs shared repeated blocks of content.

> *
> *
>>
>> 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).
>>
>
> *GV: lets try to find some language that is within our (and WCAG's ) 
> power to write.   Clearly we are not empowered (and neither is WCAG) 
> to do anything that is a precursor to a new version of WCAG.
> *

PK: Gregg, I'm sorry, but this is NOT clear to me.  It is a conversation 
I think we should have with Judy and/or WCAG WG.  I understand that you 
are co-chair of WCAG WG and so have far more experience in this space 
than I do.  But as I say, it is not clear to me that it is pointless to 
have the conversation.


Regards,

Peter
-- 
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 506 9522 <tel:+1%20650%20506%209522>
Oracle Corporate Architecture Group
500 Oracle Parkway | Redwood City, CA 94065
------------------------------------------------------------------------
Note: @sun.com e-mail addresses will shortly no longer function; be sure 
to use: peter.korn@oracle.com to reach me
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
Received on Friday, 13 July 2012 18:10:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 July 2012 18:10:53 GMT