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

Hi Gregg,

PK6: (I think we're up to 6 in this large thread, though not in this 
specific message).  And as a side note, this exchange has gotten awful 
long.  I am starting a related new discussion in a new e-mail thread, 
rather than continue it here (you'll see my reference to that below - 
and look to the thread with the subject: `UIC vs. TLF vs. "SUI"... 
OMG!?!?  Trying to put the "web page" SCs into related groups`)

>>
>> PK4: In case there was any misunderstanding... I am *not* proposing 
>> TLF as a general replacement for UIC - and more specifically I am not 
>> proposing that it as the mapping to use everywhere (or even 
>> everywhere we haven't otherwise reached consensus) in place of "web 
>> page".
>>
>> WCAG was written in a world where every web page has a clear 
>> identifier - the URL - and every web page is either a fairly 
>> self-contained "world" (with frames and what-not) or part of some 
>> defined "set of pages".  This is not the more general software world.
>>
>> Fundamentally I think the "web page" SCs can be broken down into 
>> roughly three groups:
>>
>>   * Those where the natural analog to "web page" is "the entire
>>     software user interface" (e.g. "the world")
>>   * Those where the natural analog to "web page" is top-level-frame
>>   * Those for which neither "the entire software UI" nor "the
>>     top-level frame" is the right analog (the "weird ones" ->
>>     typically those referring to "set of web pages")
>>
> *GV 4: I think this is a very good observation. We might tweak your 
> categories a bit with discussion -- but I think this is a very good 
> way to think/examine this   (though I don't agree that web page 
> definition is easy - think of web apps.  In the end the WG made it 
> clear -- but not easy - as that was the best the WG could do)*

PK6: I don't believe web apps were quite as sophisticated then as they 
are now though. The definition of a single URI is precise, but then some 
problems may arise in specific SCs as they are applied to the world as 
it exists on the Internet today.  I'm not suggesting we try to fix that 
(no question it is outside our charter), but I do raise the idea that 
when apply a handful of SCs to non-web applications...

>
>>  *
>>
>>
>>
>> This is the core of my objection to UI Context - it is trying to 
>> cover all three of those groups
>>
> *GV 4: I think it has been posted many times - that there was no-one 
> saying that that UIC should replace Web Pages in all the SC.   It is 
> frustrating when it seems that the concept is rejected for things that 
> are not true about it.    Several people DID say that we should try 
> plugging it in to all the places and see if there were problems.  But 
> those same people (in the same postings most or all the time) said 
> that there was no suggesting to replace simpler terms where they 
> worked.    I think the UIC was to handle the places where you might be 
> thinking Frames approach -- though it may be a bit broader in 
> application than that. Not sure. *

PK6: I appreciate - and do not dispute - that nobody in this TF is 
saying UIC should replace "web page" in this TF's work product.  But 
this TF exists because both the Access Board and (because of them) the 
M376 folks are applying WCAG to non-web ICT, AND Mike Pluke said explicitly:

    "What Peter has written is, however, of great interest to the
    Mandate 376 folk as it is our intention to only add SCs to our
    “Applicability notes for WCAG 2.0 success criteria” table when a
    simple substitution of “UI context” for “web page” does not make the
    intent sufficiently clear. I do not think that 1.4.2 would need to
    be added to our table (and is not there currently)."

Because one of the two main consumers of our output wants to have as few 
SCs that deviate from an otherwise standard "web page" analog in 
software, and several key members of that consuming org are here (and 
further are proponents of UIC in particular), I feel it is appropriate 
to subject UIC (and any potential rival candidates) across all SCs where 
the M376 folks are considering using it.

>> and I think it not only fails to cover all three, but by trying to 
>> cover them all it actually isn't the best fit for any of them.  E.g. 
>> where "UI Context is all Windows you can get to via navigation (but 
>> not activation)", it doesn't actually quite cover all of the software 
>> UI -> you need to ensure that that provision encompasses all of the 
>> UI Contexts that might be shown.  And because a single UI Context can 
>> be more than a single window, stuff like page title gets weird.  Etc.
>>
> *GV 4: again - no one is suggesting this -- so you don't need to keep 
> arguing against it.  It just confuses the discussion.*
>>
>>
>> Further comments in-line below.
>>
>> On 7/13/2012 8:43 PM, Gregg Vanderheiden wrote:
>>> 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.
>>
>> PK4: I'm not sure that "most people would say" that.  I rather think 
>> that most folks would say that can be no repeated block(s) among 
>> multiple pages if the set is a single page.
> *GV 4:  What does this mean?  Is there  a typo?      How can there be 
> multiple pages in a set if the set is 1?   Or are you saying that most 
> people would say that if you implement the whole site as one WebApp 
> page -- that you should be able to ignore all of the SC that relate to 
> multiple pages?   Please clarify?
> *

PK6: I believe I addressed this in my previous message about 20 minutes 
ago.

> *
> *
>>   I think WCAG assessment tools should be a good indication of what 
>> "most people would say".  Do any of them require that you evaluate a 
>> site over time in order to determine that contents at a single URL 
>> change in order to invoke SC 3.2.3?  Please cite product names.
>
> *GV 4: What WCAG assessment tools?  Do you mean tools by third 
> parties?      Any time you have a Web App - you have the same "page" 
> changing over time.  Each time you click on something -- the page 
> changes content.  As noted above, you can implement the whole site in 
> one page.   So that page changes over time - from click to click. *
> *
> *
> *It sounds like you are saying that implementing a web site as one 
> page would mean that you only need to evaluate the page that is on the 
> site when you start? *
> *
> *
> *I'm not following something.   Please elaborate.*


PK6: I believe I addressed this, at a higher level, in my previous 
message about 20 minutes ago.  I used the example of WCAG assessment 
tools as part of my claim disagreement with your statement that "most 
people would say" that a single page that changed over time is covered 
by SC 3.2.3.  If the WCAG assessment tools assessed based on that 
assumption, it bolsters your "most people" argument.  If they don't, it 
counters it.

>
>>
>>>
>>> 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"*
>>>
>>>
>>>
>
> *GV 4:  PK - can you tell me what you think the purpose of the 
> 'Repeated blocks" provision is?   And why that would not apply to a 
> page that you must repeated view in order to know it current contents 
> - because they keep changing? Would that not trigger the exact 
> behavior that the SC was designed to prevent (e.g. a user having to 
> keep stepping over the same block of controls or text or whatever that 
> they had read before. in order to get to the different content?)*

PK6:  I completely agree with you on purpose.  I disagree on the precise 
reading of the text, and the meaning of, essentially "bypass blocks of 
content that are repeated on multiple URIs" (treating "URI" as shorthand 
for "web page" since the definition of "web page" 
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-locations.html#webpagedef> 
begins with the text "a non-embedded resource obtained /*from a single 
URI */using HTTP").  If you only ever have a single URI, then you never 
have "repeated on multiple URIs" occurring.  Period.

If you want to get into the purpose of the SC, by all means let's go 
there.  But they we need to truly go there, and look at several SCs in 
that light.

>
>>>
>>>>>>>> <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.
>>>>>
>>>>> *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.
>>
>> PK4: I am suggesting that IF we find that the top-level-frame concept 
>> fits best for multiple SCs, THEN we pull it out into a defined term 
>> and simply use the term in those multiple SCs.  And of course, 
>> if/when we decide to do that, we should bring a higher level of 
>> scrutiny to the definition (including all of the questions you raise 
>> above around whether it is too technical, etc.)
>
> *GV 4: How is this different than what is being proposed for UIC? 
> (remember that no one is proposing that it be applied to all SC or any 
> more than it fits.) *
> *GV 4: If you see it as a parallel to this - then I would suggest you 
> fill it out so that it can be compared. **
> *

PK6: This concept of using some concept that works in multiple places 
with its own definition is no different for TLC vs. UIC.  I happen to 
believe, however, that UIC - /under its currently proposed definition /- 
is not quite fish nor fowl.  It is somehow both (a) more than a single 
top-level-frame in many circumstances, and yet not (b) the entire 
software UI in many circumstances.  As such I don't think it fits as 
well as TLF for some provisions; for others I think TLF is completely 
wrong (and that something else - "the software user interface" is better 
and is also better than UIC there).

>>
>>>
>>> *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.
>>> *
>>
>> PK4: It will take more time than I have at this moment to go through 
>> windowing GUI terms to give you a precise definition of a 
>> top-level-frame from that fairly well understood CS graphics 
>> discipline.  Fundamentally any modal window and any window that be 
>> moved independently of all others (e.g. isn't an MDI-style window 
>> that is constrained to the boundary of the parent window it is "in") 
>> is a top level frame.  In your example above with 3 floating palette 
>> windows, there are 4 top level frames.  When they are "re-attached" 
>> and become toolbars, they stop being top-level frames.
>>
>
> *GV 4: I see this as a fatal flaw,   since tearing the palettes off 
> shouldn’t fundamentally change the situations -- and I doubt if the 
> palettes would all pass the SC - though we would have to think of all 
> the possible types of tear off items that could exist.     But I'm 
> open to listening.  Just seem wrong -- and I thought you argued 
> earlier that if tearing the menus off meant everything changed was 
> something that was a fatal flaw in UIC (before it was understood that 
> UIC didn’t do that).*

PK6: if a torn-off ribbon/palette has different user interaction 
behaviors, why shouldn't that give rise to a different situation. If I 
use different keystrokes to get to a items on a ribbon vs. items on a 
palette (e.g. CTRL-ALT-TAB to cycle through palette windows, or if 
palette windows are part of the larger ALT-TAB order; while when they 
are attached I reach them without ever touching the ALT key), why 
wouldn't we consider treating them differently?

If my AT has a "list of windows" command, and it displays palette 
windows in that list but not ribbons, why then does it not become 
important (as set forth in INTENT for 2.4.2) to help folks identify 
which window they might be interested in?

>
>> Under SC 2.4.2 (with the TLF approach) they would need titles when 
>> they are top-level, and stop needing titles when they are re-attached.
>>
>>>
>>>>>> 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
>>
>> PK4: As I noted at the top of this missive, TLF is not a concept I 
>> propose as a universal web page replacement.  I think it works best 
>> in several SCs that use "web page" but definitely not all of them.
>
> *GV 4: I see that.   But my comment was not about that.  UIC was not 
> proposed to do that either (at least not in recent memory -- I think 
> M376 did and we did at the start).   As mentioned above -- we DID 
> think that we should see what happened if tried in all SC - and it 
> would be good it if it did fit -- though where simpler words fit it 
> would be good to use the simpler terms. *
>>
>>>
>>> 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.
>>
>> How are these "groups of windows" related to each other? Can they 
>> move entirely independently of each other, with none contained 
>> entirely within the other?  Then they are all independent 
>> top-level-frames.  A group of them might all belong to the same 
>> application (in which case they would fully contain the currently 
>> visible "software user interface" of that application in a GUI.
>
> *GV 4: Thanks.   That is clear now.   Concerns are mentioned above -- 
> but this is clear now thanks.*
>>
>>> GV3: 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.
>>
>> PK4: I think that issue is entirely separate from TLF vs. UIC.  
>> AND... I think that the right way to address those issues is by going 
>> from INTENT.
>
> *GV 4: Don't understand the comment.
> *

PK6: I read your inner-most comment immediately above (which I have 
identified with "GV3" as I think that is where it came from) as relating 
to the situation of a web-app or non-web app with a single page/URI 
having content that changes a lot over time (e.g. the word processor 
example).  In that situation, I believe the issue of whether or not 
SC3.2.3 (and likewise SC 2.4.1) apply or not has nothing to do with 
whether we use TLF or UIC here.  It has to do with how we read the text 
of the SCs and to what extent we pay attention to the purpose of the SCs 
and not simply a literal reading of the SC text itself.

>
>>
>>>>>>>>
>>>>>>>> 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.
>>> *
>>
>> PK4: As I wrote above, no it does not.  But then, I claim that UIC 
>> doesn't either.  I think it fits better than UIC does for some 
>> provisions, and not at all for others.
>
> *GV 4:  I see that you don't think of it as universal.    And UIC 
> doesn’t either.    But I think UIC fits better here - -and in more 
> places -- and even in places where there are simpler words that we 
> SHOULD RETAIN.    But again - the best would be for you to flesh out 
> exactly what the TLF is and to how many SC you are thinking it would 
> apply as an equivalent to  Web Page(s)*

PK6: I have done this in a new column of the "Applying" page 
<https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/applying-ui-context>, 
which I will introduce separately in a separate e-mail shortly (look for 
the Subject: `UIC vs. TLF vs. "SUI"... OMG!?!? Trying to put the "web 
page" SCs into related groups`).  I ask that you direct your comments on 
that exercise in the thread I'll start with its introduction, in order 
to keep our discussions more tractable.

>
>>
>>> *
>>> *
>>>> 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?
>>
>> If a toolbar gets "torn off" from an existing TLF, it becomes its own 
>> TLF and all of the TLF rules apply to it at that point.  If it 
>> happened to already have a descriptive name while "attached", then 
>> the name doesn't need to change upon being "torn off".
>>
>>>
>>>>
>>>> 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.*
>>
>> A single TLF doesn't encompass an application of multiple windows.  
>> Each window is it's own TLF.  The "thing" that is the full collection 
>> of windows in an application is "the software user interface".
>>
>>>
>>>>>> 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
>>
>> PK4: Again see my opening comments about the scope of TLF.
>>
>>>>>>>> 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.
>>
>> PK4: I see no different between TLF and UIC for this issue. Either 
>> you decide that an application consisting of a single window in which 
>> the contents may change over time is somehow covered by "repeated 
>> blocks" (because the content can change) or you decide it doesn't.  
>> Doesn't matter if that single window application is a TLF or a UIC.  
>> Unless you somehow further modify the UIC definition to explicitly 
>> call out this situation (which could just as easily be called out 
>> only in that SC).
>
> *GV 4:  I don't see how they are the same.   The definition of UIC is 
> that it is a UI CONTEXT and if the context changes - then the UIC 
> changes.   I see no such designation in TLF or its definition.    The 
> TLF (FRAME) would be the same even if almost all of the contents were 
> different.   I think you argued this above.*

PK6: Yes, I hope I answered this more clearly above in an earlier "PK6".

>
>
>>
>>>
>>>> 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.
>>
>> The Access Board has referenced WCAG 2.0 in the 2011 ANPRM. The 
>> Access Board hasn't published anything since 2011 with respect to 
>> Section 508.  I would rather hear from Bruce or others on the Access 
>> Board staff as to whether and what they might reference in the 
>> forthcoming NPRM.  Note that "reference" isn't the same thing as "use 
>> this normative document in place of our provisions".
>
> *GV 4: First I think you know that the Access Board  is in rule-making 
> and cannot comment on what will be in the next round of ANPRM.     RE 
> your last sentence - can you elaborate?  I don't understand what you 
> are trying to say. Here is what I know from past work on standards and 
> regulations and from discussion on general principles (which Bruce CAN 
> comment on)*
> *
> *
>
>   * *The Access Board *
>       o *CAN normatively reference (and thereby draw into the
>         regulations) things that are standards and stable.*
>       o *CAN refer to other (non-normative) documents in an advisory
>         note or equivalent
>         *
>

PK6: Yes!  This is one of the two ways the Access Board (and M376 folks) 
can use our non-normative output.  They can direct companies selling ICT 
to Federal Agencies (and any other entity who adopts 508), and folks on 
the procurement side, to read our non-normative text to help them 
understand what applying WCAG SC x.y.z means.  So that if we say some 
non-normative, informative thing - e.g.

    (starting out first by quoting you) "The purpose of the provision is
    to keep people from having to step through the same controls over
    and over", (and now my text) "and so even though S.C. 2.4.1 Bypass
    Blocks is limited in the web context to blocks repeated across
    multiple different URIs, in the non-web software world applying it
    also to single window applications such as editors will more fully
    address the purpose of the provision."

Such text contains no "shoulds" or "shalls"; it is entirely 
non-normative.  And it looks to the INTENT of the provision in order to 
provide effective guidance based on WCAG.

Nothing in my understanding of what the Access Board is doing would 
disallow the Access Board from either having such text in their own 
advisory note, or in having their advisory note quote our non-normative 
report.

>       o *CANNOT normatively cite any language from other non-normative
>         documents in their standards *
>       o *CAN excerpt any language from anywhere and adopt it as their
>         own putting it directly into their standard (with our without
>         edits)*
>           + *(in which case it is not language from the document but
>             language in the standard)
>             *
>

PK6: Yes again!  The Access Board is free in their procurement standards 
to exceed WCAG for web technologies (though I very much hope they do 
NOT), and they are likewise free to deviate from WCAG for non-web 
technologies in their procurement standard.  If their deviation happens 
to derive from our non-normative, consensus report... then it will be 
based on the considered expertise of this group that has been operating 
with their participation.


>
>>
>>>
>>> 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.
>>
>> PK4: Until there is a clear statement from the W3C, I think we will 
>> simply have to disagree on this.
>
> *GV 4: That is fine. *
>
>> We are writing a non-normative document.  You are saying that we are 
>> further restricted to only providing guidance on "ONLY the 
>> requirements of the SC and not any other informative information", 
>> YET our approved Work Statement 
>> <http://www.w3.org/2012/04/WCAG2ICT-WorkStatement.html> says: 
>> "Producing a Working Group Note (a form of W3C Technical 
>> Report)...that describes...how each of the WCAG 2.0 principles and 
>> guidelines would apply non-Web ICT".  If as you say above "the SC are 
>> the only parts that are normative" of WCAG, that WE HAVE ALREADY BEEN 
>> DIRECTED to provide guidance on how to apply non-normative parts of 
>> WCAG - namely the principles and guidelines.
>>
> *GV 4: correct.  We can talk about how those would apply.  But we 
> cannot narrow or expand either the SC or the Guidelines or principles.
> *

PK6: In my reading of what you have said (and I have already quoted a 
few times - but here it is again: "the purpose of the provision is to 
keep people from having to step through the same controls over and 
over"), I believe you are already expanding SC 3.2.3 and SC 2.4.1 from 
the text by allowing "a single URI that changes over time" to be read in 
place of "multiple URIs" - in order to support "the purpose of the 
provision".

>
>> Given this, I don't see why it is unreasonable to ask the question: 
>> might we ALSO be able to provide guidance based in part on INTENT, 
>> particularly for those few SCs where the mapping to software is 
>> particularly troublesome.
>
> *GV 4: the intent informs on - but cannot change the SC.  The Access 
> Board and m376 cannot cite the intent - only the SC with the intent as 
> guidance of intent.  (and for normative uses of WCAG -- only the 
> intent published at the time can be used -- though they can cite a 
> later intent in their later rules. )
> *

PK6: Your shorthand statement above disagrees with the 4 bulletted 
options you set forth above.  They cannot cite AS NORMATIVE something 
from WCAG or anywhere else that isn't normative in its original 
location.  They can cite it as the source for their own normative 
procurement guidelines, and they can cite it in their own advisory notes 
-> as you yourself have already said above.

> *
> *
> *But this is all separate from the discussion of whether our task 
> force can broaden the reach of the SC by noting text in the Guidelines 
> or INTENT if that language cannot be drawn from the language of the 
> SC.  That is,  if the the SC says x and the INTENT says something that 
> you cannot read directly from the SC -- then the SC not the intent 
> rules. *
> *
> *
> *A non-normative document can help one to read a normative document 
> correctly (the intent) but it cannot change the meaning of a normative 
> document if the two differ. *
> *
> *
> *
> *
>
>>
>>> GV3: Looking forward to further info on TLFs and how they would get 
>>> around the problems I mentioned above.
>>
>> I hope I have given that to you!
>
> *GV 4: yep thanks.   some requests for additional info above. *
> *
> *

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