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: Hoffman, Allen <Allen.Hoffman@HQ.DHS.GOV>
Date: Fri, 13 Jul 2012 12:31:10 +0000
To: Gregg Vanderheiden <gv@trace.wisc.edu>, Peter Korn <peter.korn@oracle.com>
CC: "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
Message-ID: <9F7B0040F7A7C4428E160959229DE9F3018CB7BD@D2ASEPRSH126.DSA.DHS>
I have to say I lean towards the concept that this one is not clear enough for software application currently and we may need to just document this as what we have to date.  For example, if you have a software application which puts up a screen of controls, are we requiring some jumping mechanism, if so, jump in what increments, with what criteria of jumps saved?  If the same software application puts up a text box with a end user license agreement with an accept and don't accept button at the bottom, I can see that paragraphs might be jumped over, whole text might be jumpable so the person could select OK, or Accept more quickly, but outside line-by-line type of contexts with reading and navigating I am not sure this one is clearly defined enough for folks yet.

From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: Thursday, July 12, 2012 9:30 PM
To: Peter Korn
Cc: public-wcag2ict-tf@w3.org
Subject: Re: Looking at SC 2.4.1 Bypass Blocks with "UI Context"

On Jul 13, 2012, at 2:41 AM, Peter Korn wrote:

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


    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.

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.

Peter Korn | Accessibility Principal
Phone: +1 650 5069522<tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
<green-for-email-sig_0.gif><http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Received on Friday, 13 July 2012 12:31:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:44 UTC