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

GV3:  Interesting discussion/ comments.    I can see what you are trying here with TLF instead of UIC.  But have questions - and other comments.  Not sure it works as well as UIC and some parts I don't see how TLF works. 

Comments below. 


On Jul 13, 2012, at 10:18 PM, Peter Korn wrote:


> 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. 
> 
> PK3: OK.  I have a weather service page.  Only page on the site.  It has a block at the top of the page that is always there (ads ad such).  This page updates every 4 hours.  By your logic 3.2.3 applies to it, because it is a different page 4 hours from now.  Same logic for 2.4.1.  So both 3.2.3 and 2.4.1 apply.  
> 
> Presumably then a WCAG assessment couldn't be complete unless it is was carried out over multiple days to look for changes to all pages (particularly those that didn't otherwise share any navigation links with any other pages, and those that didn't otherwise share any blocks to bypass with any other pages) - in order to determine whether 3.2.3 and 2.4.1 should apply to them.
> 
> Yes, this is a highly contrived example.  But I see it as fundamentally the same thing as a single non-web application that is a document editor, for which you claim 3.2.3 and 2.4.1 apply because when the user chooses to edit a different document this single window becomes one of a set of windows and therefore 3.2.3/2.4.1 kick in.


GV3: Hi Peter,  I don't think that is contrived.  I think it is a fair example.   So lets look at the purpose of the Provision.    If a person looks at a page or set of navigation links just once, then it is fair to assume they would like to step through them to figure out what they are.  But if a person is going to keep running into the same block of information, they they should be able to jump over it so they don't have to keep reading through the same long list of items before the get to the new information on the page.  

Now there are two ways that you keep running into the same long list of items.   1) they are repeated on the top of each page you go to on a site.   2) every time you go back to the site -- and need to see the same page because the content keeps changing   (essentially a 'new page' at the old URL) -- you have to tab through the same content to get to the new page of information.   This is your example above.

So the intent was to avoid a person having to keep seeing repeated information.  This  is also related to the "web site at one URL" question where you could have one URL that keeps changing the content of the page -- so that you never leave one url but you actually see the equivalent of an entire web site at the one url.  

While a strict constructionist might claim that this means that many of the SC don't apply since there is only one web page on the site,  most people would say that that site should be treated as it would if all of the virtual pages were real pages at new URLs.   Each time the page substantially changed, it would be treated as a new page even though the entire web site was at the same URL.   This in fact is a good point that regulators should pick up and make part of their  regulations to keep sites from skirting the whole WCAG by simply using a tactic of keeping the whole site at one URL.

So this brings us to what the ICT equivalent would be.  There are two bits here that both independently get you to the same location.   
	1) On websites, the norm is have a template that you use and then you put different content on different pages into that template.    The navigation bar on the template would constitute repeated text (even though it only existed once on a template - it would show up at the top of each page.)   In ICT the equivalent would be a window frame that shows up at the top of each document you open.  So opening different documents (one at at time - just like looking at web pages one at at time) would yield repeated blocks of items (menus or ribbons) at the top of each document. 
	2) the same rationale as the "web site all at one URL".  Where the URL (or the "document")  stays the same but all of the contents change.  the user repeatedly sees the same block of items each time the come to the page to see the "new page of information"





>>>>> <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. 
> 
> PK3: No.  My point is that if we find "top level frame" (TLF) is useful in a bunch of places, we would consider pulling it out into a definition and then simply using that defined term/phrase in those places.  So saying that "the text is too long to use in multiple places" is only different here because unlike UIC we didn't start out by making it a defined term.  AND I note that TLF's definition is 1/4th to 1/7th the length of UIC.  Being so much shorter suggests it is a simpler concept to understand, though it isn't dispositive on that score.

GV3: Fair enough.  So you are suggesting we create a new term (top level frame) and define it and use it.   That is something to discuss.  I think that it is more technical and will be confused with "frames" that actually exist in some technologies.  Also the definition isn't really a lot shorter.  The UIC just has lots of examples and notes to help teach the concept.  I expect "frames" will need much more before it will be understandable by non-programmers.   

Question:   When you have a document window open and 3 floating palette windows -- those should all be considered one entity  (tearing a menu or menubar free should change the dynamic -- just the layout options)  what would the Top Level Frame be,  where would it be, and where would its name or other attributes be found that would not also include another document window open in the same app?  None of the windows clearly are the TLF.   

Also - the same question when the app is implemented as separate parallel windows from the start -- and none is "torn off" of any of the others.  





>>> 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.  
> 
> TLF is decidedly technical.  So is URI and many other terms we use in W3C standards.  The real question is whether it is significantly easier/harder for the consumers of this document to understand and to apply consistently.  Those consumers being: (a) developers, (b) procurement officers, and (c) folks assessing accessibility of software.
> 
> It might be interesting to use UIC and TLF once each in an SC that we sent out for public comment, and see whether and how many comments we get on those concepts.  

GV3: Might be.   As noted earlier -- the exact name etc for UIC is not key - it is the general concept.   if TLF can fill that -- there is no religion that UIC be used.   I am just one person who can seem to figure out what the TLF would be for key situations and the definition doesn’t lead me to an answer

Tell me more about eh TLF and how it would apply to different groups of windows.  (don't worry about making your definition get as long as UIC - the definition is the definition -- not the number of notes to help teach or clarify it).   And both are about the same length I think.

Another problem with TLF is that it doesn’t seem to account for the Template or " New page of content" issues though perhaps they could be handled in a similar manner to UIC.  








>>>>> 
>>>>> 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?
> 
> PK3: My initial proposal for 2.4.2 was to state that if EVERY intentional grouping of UI components had a descriptive name, then certainly all the ones that were "web page" analogs would have them.

GV3: right.  good idea but beyond the SC 

>   In discussions with you this got trimmed to TLF UI groupings which we then consensed on. 

GV3: right again.   til I lost track of what the TLF would be for key situations -- and the proposal from M376 seemed to work better in more places.

I haven't checked but does TLF work if plugged into all the places Web Page is used.  (Not suggesting we replace simpler text with this -- but if it is going to replace UIC as a concept it should fit in more places I would think. 

> Under my initial proposal, the descriptive name could stay the same, and would apply when the palette was attached or in its own window.  Under consensus 2.4.2 the name need only be descriptive when it is in a TLF.

GV3: if it was in its own window -- then the parent window would no longer be the TLF.  So what would be the TLF? 

> 
> With respect to 3.2.3 and consistent navigation, it would only matter if the palette contained the same controls (e.g. "move to next photograph", "move to previous photograph") in the same order as some other palette/window/whatever, and if it could be torn off. An edge case that is covered by TLF-ing 3.2.3.

GV3: I still don't know what the TLF is for a group of windows that work as one app.  Whether they are torn off or just come as a cluster at startup.  The APP would seem to be the TLF but then every other document opened up would also belong to that TLF and you were treating them as separate.  So I keep losing what the TLF would be?  

This is covered in UIC.  But I can't find it in TLF.







>>> 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.   
> 
> PK3: I believe TLF is simpler than UIC.  You have objected to using TLF here on the grounds that we would repeat the text and that repetition is less simple.  If we make TLF a "term", then... it terms of size & number of concepts to think about per SC that uses it, they are the same; and the questions then become: is the TLF concept easier/harder to understand than UIC and is TLF eaiser/harder for consumers of this document to fit into the various SCs.

GV3:  Agree - TLF could be a term like UIC.   and if it works better could be used instead of UIC.  But I don't think it is easier to understand -- (I thought I did at one time - but don't anymore)  and I'm not sure it works as well across SC's.  But am open to it if it turns out it is with further information   







>>>>> 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?
> 
> PK3: So let's construct an example.  A photo viewing/editing application that also retrieves images directly from my camera or from an inserted memory card (I actually use an application just like this regularly with my Canon camera).  When I'm in the window that gives me a direct view of what's on the memory card in my camera over a USB connection, there is a "next photo" button and a "previous photo" button.  I have a slightly different window when this same application is looking at the memory card when it is inserted directly into my computer, but it also has a "next photo" and a "previous photo" pair of buttons.  Likewise when I'm looking at the photos in a directory on my hard drive: "next photo" and "previous photo" buttons.  Perhaps in the hard-drive-viewing case the "next photo" and "previous photo" buttons are in a palette that can optionally be torn off into its own top level frame.
> 
> Since we have 3 (or 4) top level frames in which the same navigation commands are repeated, they must appear in the same relative order (e.g. "previous photo" first to the left and "next photo" immediately after that to the right).  If they don't, this application fails 3.2.3.
> 
> Now: if instead of TLF we used UIC, and all windows are open at the same time (which they can be!) we have a single UIC so we have to go to some lengths to create a "repetition situation" in order to trigger 3.2.3 -> e.g. observe that this set of windows tomorrow might be looking at a different set of photos on a different memory card / hard drive folder than it is looking at today, and so therefore we really have multiple UICs after all and so therefore 3.2.3 applies.

GV3: You are correct that UIC works here too.    I don't see this as being "at some lengths".   See discussion above.   This repetitive situation is key for single window apps where a person has to get past the same block of information for each document they open all day long.   Each new page has new information but with the same frame.    The TLF would fail this important situation.   The UIC doesn’t.  


> 
> Do you see why this feels contrived to me (the introduction of temporality in order to trigger provisions) as compared to using top level frame?  [or in some cases better still, petitioning WCAG and the W3C to allow us to derive our software guidance more directly from INTENT]

GV3: Sorry.  But the Access Board and M376 are not referencing the understanding document.   They are referencing the WCAG.   The Understanding WCAG 2.0 is informative but it is the WCAG that was reviewed and passed and is the standard.   We can't use the INTENT to override or expand on the SC.  Only to explain it.     

GV3: Similarly the Guidelines and Principles are broader and more sweeping than the SC but the SC are the only parts that are normative.  The principles and guidelines are 'aspirational"   and include all of the advisory techniques and more  (none of which are required to conform to WCAG).    Conforming to WCAG is only conforming to the SC as defined by the Conformance Requirements.     So our guidance (if it is guidance on how to conform or apply the WCAG standard to ICT),  has to be based off of ONLY the requirements of the SC and not any other informative information or broader desires.     Those informative aspect were used to frame (Principles and guidelines) the SC  or to explain them (Understanding and techniques) but not to define them or broaden or narrow them. 



GV3: Looking forward to further info on TLFs and how they would get around the problems I mentioned above. 





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