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

Re: Looking at SC 3.2.3 Consistent Navigation with "UI Context"

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

PK: OK, so we focus now on the consistent navigation part.  My 
understanding is that a single User Interface Context can include 
multiple, non-modal windows.  Thus if I have two windows in my UIC, and 
both of them contain navigation buttons (e.g. "Next" & "Previous"), and 
they were in different orders, they would not be in violation of this SC 
(with UIC).  However, if instead we used language from the consensus 
text for 2.4.2 Page Titled 
<https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/242-page-titled> 
and tied this to "top-most explicit groupings of user interface 
components (things like "windows", "dialog boxes", "frames", and 
"screens")", then our pair of windows with the inconsistent relative 
order of "Next" and "Previous" WOULD be a violation of the SC.

First question to Gregg: do you agree with my reading of the definition 
of UIC, and my application of it to this SC & this situation?

Second question: which outcome do you think we want?  Should the "Next" 
| "Prev" in showing non-modal window A while "Prev" | "Next" showing in 
non-modal window B be allowed or not?


Regards,

Peter

On 7/13/2012 1:50 AM, Gregg Vanderheiden wrote:
> *Hi Peter*
> * - yep  you were right - I had my SC numbers switched.   I fixed my 
> comments now to fit this one. *
> *
> *
> *new comments marked *
> *GV2: *
> *
> *
> On Jul 13, 2012, at 4:14 AM, Peter Korn wrote:
>
>> Hi Gregg,
>>
>>>> <PK> Hi gang,
>>>>
>>>> SC *3.2.3 
>>>> <https://sites.google.com/site/wcag2ict/home/3-understandable/32-make-web-pages-appear-and-operate-in-predictable-ways/323-consistent-navigation>*****was 
>>>> not one we reached consensus on, nor have we had much discussion 
>>>> about it.
>>>>
>>>> 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 seventh row, but to facilitate discussion, I reiterate 
>>>> them here.
>>>>
>>>> The software portion of the UIC Proposal is:
>>>>
>>>>     This applies to software aspects of products directly as
>>>>     written and as described in INTENT from Understanding WCAG
>>>>     (above) with the word “user interface context” substituted for
>>>>     Web Page and "software program" substituted for "Set of Web Pages".
>>>>
>>>> I don't think this SC really make sense in software.
>>>
>>> *GV: I don't follow you here.   It makes lots of sense to me.   This 
>>> says that if you have two controls that do the same thing that they 
>>> should be named consistently.     It is always done with good 
>>> design. (But then many of the SC would be met with good design).   
>>> The purpose is to avoid bad design.
>>> *
>>
>> PK: The text of the SC is:
>>
>>
>>         *Success Criteria 3.2.3: *Navigational mechanisms that are
>>         repeated on multiple Web pages
>>         <http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-locations.html#webpagedef>
>>         within a set of Web pages
>>         <http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-locations.html#set-of-web-pagesdef>
>>         occur in the same relative order
>>         <http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-locations.html#samerelorderdef>
>>         each time they are repeated, unless a change is initiated by
>>         the user. (Level AA)
>>
>> I don't read that as "controls that DO the same thing should be NAMED 
>> consistently", I read it as (a) only applying to navigational 
>> mechanisms, and (b) speaking to their relative order on the screen 
>> (or web page).
>
> *GV2:  you are correct.  I crossed my wires on the access provisions. 
>   This is just about order.   3.2.4 is about naming. *
>>
>> I very much like your reading, but I see your reading as doing 
>> exactly what I argue for this (and a few other) SC: going back to 
>> Understanding and Intent and apply the purpose to software rather 
>> than a straight language substitution.  The straight language 
>> substitution (abbreviated) reads:
>>
>>     Success Criteria 3.2.3: Navigational mechanisms that are repeated
>>     on [user interface contexts] within a [software application]
>>     occur in the same relative order each time they are repeated,
>>     unless a change is initiated by the user. (Level AA)
>>
> *GV2:  yes - and it works very well here.  Clear and correct. *
> *
> *
> *If people just think of  UI Context as  "everything they see when 
> using an app (if windows aren't overlapping) "  then they have a good 
> picture of what UIC is. *
> *
> *
>> So if I have things like "next" and "previous" buttons that appear in 
>> multiple modal dialog boxes, they must appear in the same relative 
>> order (e.g. next on the lower right, previous on the lower left).  If 
>> we say that "Cancel" is a navigation mechanism, then this might 
>> require that Cancel and perhaps OK must likewise appear in the same 
>> relative locations.
>
> *GV2:  Careful not to change the words.   It says "order" not 
> location.    And yes this is exactly what it means.    And if you 
> swapped OK and Cancel in order on a  dialog box I would expect that 
> there would be many people who would click the wrong one all the time. *
> *
> *
>>
>> But I don't see how this says that the printer icon/button must 
>> always be named "Print" if it appears in multiple modal dialog 
>> boxes.  Or really anything about naming.  This seems to be only about 
>> layout.
>
> *GV2:  Correct. as I mentioned above I crossed wires. *
> *
> *
> *So lets just revisit with this focused on ORDER.  So I repaired my 
> comments below *
>
>>
>>>
>>>>   I find it to be a lot like Bypass Blocks.  It is either generally 
>>>> automatically satisfied
>>>
>>> *GV:  how would it be automatically satisfied.   There is nothing 
>>> automatic that I can see about the order buttons or controls are 
>>> presented.
>>> *
>>>
>>>> (and so of little added value),
>>>
>>> *GV:  based on what?   This can be very confusing cognitively to 
>>> have a list of commands that keeps being reordered. *
>>>
>>>> or it can be looked at based on Intent and Understanding, and 
>>>> applied more thoughtfully to software (e.g. for cognitive 
>>>> disabilities, some variant of "things that look the same should 
>>>> behave the same, things that behave differently should look 
>>>> different").
>>>
>>> *GV:  What do you mean "applied more thoughtfully".    Do you mean 
>>> write a new SC? *
>>> *Isn't what you propose essentially what this SC says already?
>>> *
>>
>> PK: I mean moving beyond "relative order layout" into exactly your 
>> first paragraph above in this e-mail: consistent naming and use of 
>> controls - beyond simply position.
>
> *GV2:  yes - well we can't re-write this SC and that topic is handled 
> in another SC anyway (SC 3.2.4)*
> *
> *
>>
>>>
>>>>   I think the right thing to do is go back to WCAG and see if we 
>>>> have their blessing to either say this doesn't really apply, or to 
>>>> develop something more fitting and appropriate to software.
>>>
>>> *GV: Again - the WCAG has no authority to do either of these - so it 
>>> cannot grant that authority to the task force.   I hate to see us 
>>> continually not working on language we can use -- instead of trying 
>>> to rewrite WCAG or get permission to write new SC or cut SC. *
>>> *
>>> *
>>> *There are examples in the previous items as to how to handle things 
>>> that are a problem _--- by pointing out the problem.*
>>> *
>>> *
>>> *I don't see any problem with this one though.
>>> *
>>
>>
>> Regards,
>>
>> Peter
>> -- 
>> <oracle_sig_logo.gif> <http://www.oracle.com/>
>> 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
>>
>>
>

-- 
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 17:42:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 July 2012 17:42:15 GMT