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

Hi Gregg,


> *...*
> **
>> <PK> 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).
>
> *GV:  Not at that moment.  (This is what I call an extreme example 
> that is unlikely and is constructed to test something -- but OK -- for 
> the moment it would pass)    But when you open the window on another 
> document tomorrow it would be a new UI Context because the information 
> would  be different.  And at that point you would be in conflict with 
> either instance one or instance two.
> *

PK2: "Tomorrow"?  Using this thinking in the web world, if I have a 
single page web site, and if on one day the content is X and tomorrow 
the content is Y but in both days there is a block of content at the top 
- that is "repeated content" and so the SC applies.  That makes no sense 
in the web world.  Why should it make sense in the software world across 
multiple times I run a software application (e.g. once today and once 
tomorrow)?

>
>> <PK> 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.
>
> *GV:  already covered as above without using this long and 
> indeterminate language.   I understand it but I think it would lose 
> many people.  And one can probably come up with many ambiguous 
> examples here.   But the real point is - why use a long text string 
> with embedded example list (not a good idea in standards) when you 
> have a simpler concept and term that can be used?
> *

PK2: Point taken - the Page Titled "top level frame" language at this 
point occurs in only one SC, and is longish at 76 words (I'm looking at 
the one sentence in consensus 2.4.2 starting with "However, since there 
is always..."; if you count the entire software paragraph of 2.4.2 you 
get 128 words).  The UI Context definition with notes (using the shorter 
"or perhaps more simply" text) is 397 words.  At this point we are 
considering using UI Context in 4 SCs (5 if you count the use in the 
note in 3.1.2).  If it turns out "top level frame" works in several SCs 
(not just 2.4.2 and 3.2.3), then we would more likely pull that out as a 
term, define it once, and use in in the SCs that it applies in (e.g. 
"Definition: top level frame is <blah blah>", and then we say that for 
3.2.3 the analog to web page is top level frame, etc.).

>
>>
>> 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?
>
> *GV:  No.   You did find a way to temporarily conform with a not nice 
> example.  But I don't think you fully understood UI Context.  We have 
> added a note to make it clearer.   But your example fails with both UI 
> context and your longer text. *

PK2: One of my core concerns with UI Context is that a single UI Context 
encompasses multiple top-level frames.  This concern arises for me in 
several SCs that we are considering using UI Context for.  I'm not 
trying to construct abstruse examples for the sole purpose of attacking 
something I don't like.  I fundamentally think that "multiple top level 
windows" is a bad analog to "web page" for multiple SCs.  In a couple of 
places I think "web page" maps to the entire application, in others to a 
single top-level window (or screen).  What I see UI Context doing is 
trying to straddle these two different things with one concept, and in 
so straddling, we get any number of edge cases which fall through the 
cracks.

>>
>> 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?
>
> *GV:  clearly not -- and it isn't with either. *
> *
> *
> *This one is trickier than usual  (the whole UI Context - or any of 
> our terms/concepts --  and software) because windows are used both for 
> palettes - and navigation is the same for both.   But with repeated 
> use - everything falls out and works.
> *

PK2: But I find your repeated use construction very uncomfortable.  As I 
noted above, we don't use it in WCAG for web pages.  Why should that 
somehow make a block repeated for software when the exact same behavior 
doesn't make it so for web pages?  AND when we can address the criterion 
by using "top level frame" instead of UI Context?


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