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

On Jul 13, 2012, at 8:51 PM, Peter Korn wrote:

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

GV2: Sure it does.  Think about it.   The purpose of the provision is to keep people from having to step through the same controls over and over. Whether that is stepping over them on pages that are next to each other -- or a page where the content keeps changing so they go back to the same url and have to step through the same controls is essentially the same.   So it makes perfect sense though for web pages you would usually have them on different pages -- so the SC is targeted that way. 


> 
>> 
>>> <PK> However, if instead we used language from the consensus text for 2.4.2 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. 

GV2: That is like saying that WCAG is 20,000 words long because its support documents are long. user interface context is only 3 words.   The definition supports the term and the notes do as well.       Once you learn what it means -- it is just 3 words each time it is used. 

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

GV2: that would be equivalent but I think 'top level frame' is very technical and hard to understand  (much harder than user interface context).   I also think it is much harder to apply in different contexts.   But that is just me.  

> 
>> 
>>> 
>>> 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. 
GV2: depends on what you call a top level frame.   If you have each window be a TLF, the each palette is a TLF.   And tearing a palette off gives you the same interface but a very different TLF profile.    And if you have the main window and its palettes be one TLF -- where do you label it?

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

GV2: not sure which you are referring to but you do know that I am not suggesting we use UIC where we can use a simpler term.   
> 
>>> 
>>> 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?

GV2: not sure I see how TLC would work in key uses.   How would it work with a main window,  floating palettes and perhaps a non-modal dialog box?


> 
> 
> Peter
> -- 
> <oracle_sig_logo.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 506 9522 
> 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-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment