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

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

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)

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.

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.

>
>>   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 naming buttons or controls.
> *

PK: If this were really about consistent use of controls & control 
behaviors (as I think we would both apparently like it to be) rather 
than just relative layout, then so long as developers always used 
buttons for button things and checkboxes for checkbox things, etc., it 
would be automatically satisfied.  It is pretty rare for this not to be 
the case - hence "automatically satisfied".

>
>> (and so of little added value),
>
> *GV:  based on what?   This can be very confusing cognitively. *
>
>> 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.

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