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

New proposal (#5) for success criterion 2.4.1, which links to a proposal for guideline 2.4; and a more general approach to 'set(s) of web pages'

From: Peter Korn <peter.korn@oracle.com>
Date: Fri, 22 Jun 2012 13:42:44 -0700
Message-ID: <4FE4D8C4.1000908@oracle.com>
To: "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
Hi gang,

I've taken another whack at SC 2.4.1 Bypass Blocks (see Proposal #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

Note that this SC is one of five success criteria (by my count) that 
involve one or more sets of web pages (3 of the 5 are part of Guideline 
2.4, while the other 2 are part of Guideline 3.2).  So as part of this 
new whack, I've tried to address the question of "set of pages" in a 
proposal for how to apply the larger Guideline 2.4 to software aspects 
of UIs (see Proposal #2 at 
https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are).

In summary what I've done is:

  * State that the problem being addressed in 2.4 in the case of
    multiple pages in a set essentially exists in a single software
    interface, and so is appropriately addressed there (without needing
    to be limited only to situations in which there are multiple
    windows/screens)
  * While recognizing (and applying) 2.4.1 to those rare cases when the
    same block is repeated, directly apply the navigation requirement
    even to a single software screen/window


If this general approach works for us, we might then also apply it to 
2.4.5 Multiple Ways and also to 2.4.8 Location (at such time as we get 
to AAA SCs) -> in other words to say that multiple ways to reach parts 
of the UI should be supported even in a single screen/page [e.g it would 
be a failure if TABbing through what could be a huge UI of scores of 
components is the only way to reach them], and that the user should be 
able to figure out where they are in a UI [e.g. the "where am I" command 
of screen readers].

Likewise if this works, we could do something similar for 3.2.3 
Consistent Navigation and 3.2.4 Consistent Identification (where here 
the key aspect of the "operate in predictable ways" guideline has to do 
with predictability of a given software UI relative to other software 
sharing that platform -> apps that use checkboxes on platform x should 
use them as per the standard for that platform; if ESC is the same as 
canceling a dialog for that platform then ESC should also work for 
dismissing all dialogs with a cancel button in software UIs for that 
platform).


What I particularly like about this approach is that it flows nicely 
from the WCAG principals in question, and doesn't force us to resolve 
the question of when any given "interaction context" is a single "web 
page" vs. when it is "a set of web pages".  It doesn't even require that 
we define what an "interaction context" is!


Regards,

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
Received on Friday, 22 June 2012 20:43:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 20:43:26 GMT