W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > September 2012

Re: We area close !

From: Peter Korn <peter.korn@oracle.com>
Date: Mon, 17 Sep 2012 10:20:00 -0700
Message-ID: <50575BC0.4060806@oracle.com>
To: Gregg Vanderheiden <ez1testing@gmail.com>
CC: "public-wcag2ict-tf@w3.org Force" <public-wcag2ict-tf@w3.org>
Gregg,

PK: I think you mis-read my comments, or I was otherwise unclear.

I think there is a show-stopper for your proposal for 2.4.2 Page 
Titled.  I see that you had in-line comments after your sign-off, so 
I'll also address those in-line.

Yes, for 2.4.1 Bypass Blocks, I think we have a reasonable way to apply 
this that holds up to the three examples I cited, across the desktop GUI 
and mobile world.  I think it needs further scrutiny before we declare 
ourselves done, but I am cautiously optimistic about this one.

For the other two - 2.4.5 Multiple Ways & 3.2.3 Consistent Navigation, I 
didn't see how they applied to the examples I was looking at.  I didn't 
do an exhaustive look this past Sunday evening.  Doing no harm to a 
handful of examples (but not applying) isn't the same as saying "it 
works, let's use it".  And frankly, if we cannot find good examples 
where they DO apply, then I am of the opinion that they likely SHOULDN'T 
apply.  Which is why I said we need to find positive examples of them 
applying first.

Now, on to in-line replies..

On 9/16/2012 11:23 PM, Gregg Vanderheiden wrote:
>
> *GV:  Thanks Peter*
> *
> *
> *Looks like things are working wherever they are applied to the thing 
> the SC with the **words* I *proposed are present.*
> *and - where they are not present -- then of course the success 
> criterion is automatically satisfied like all the other success 
> criterion *
> *
> *
> *The only problems or confusion seemed to be when you tried to apply 
> the SC against something "inside" a doc or software program - which 
> would be like applying WCAG inside a web page or web app (that resided 
> at one URL).    And that of course is going beyond what WCAG does.   
> And is what had us confused for so long.*
> *
> *
> *So no show stoppers here for the proposals. *
> *
> *
> *Gregg*
> *
> *
> *
> *
> *
> *
>
> On Sep 16, 2012, at 9:08 PM, Peter Korn <peter.korn@oracle.com 
> <mailto:peter.korn@oracle.com>> wrote:
>
>> Hi Gregg,
>>
>> I really think it would be useful to take the Examples for UI Context 
>> discussion 
>> <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples> 
>> and apply your suggested definitions to them.
>>
>> *2.4.1. Bypass Blocks: *
>>
>>   * Looking at How many Example #1: two document windows
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-two-document-windows>
>>     since the menu bar & toolbar can be repeated in the software,
>>     some bypass mechanism would be needed... *This seems like a
>>     reasonable application.*
>>   * Looking at Changed? Example #3: Tabbed panes
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-3-tabbed-panes>**there
>>     is nothing formally repeated, so this wouldn't apply. *That too
>>     *seems like a reasonable application.**
>>   * Looking at Changed? Example #24 calender appointments
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-24-calender-appointments>
>>     since the calendar title & days repeat while content below
>>     changes, arguably again some bypass mechanism would be needed.
>>     *This seems like a reasonable application.*
>>
> *GV: Good.    One down.*

PK: yes, perhaps.  I want to see more examination, more looking at more 
of our examples, before I mark this one as "down".

> *
> *
>>
>> *2.4.2 Page Titled:*
>>
>>   * Looking at How many Example #1: two document windows
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-two-document-windows>
>>     there is no obvious visible page title; "Untitled Document 1" is
>>     no more or less the obvious "software title" than "Untitled
>>     Document 2" is (and in fact, clearly neither one  is correct).
>>     *This seems like a poor fit to this situation. *
>>
> *GV: I am confused -- and I think maybe you are confounding my 
> proposal for this SC with another one. (see below).      The document 
> hasn’t been saved -- or hasn’t been saved with a meaningful title.  So 
> clearly it fails -- as it should.   If you pick anything that fails an 
> SC and use it as an example it will of course fail. ***
> *
> *
> *GV:  Remember my proposal was to replace  "web pages" with 
> "documents" and "software". Since the windows are not software (but 
> internal bits of a program) then you must be evaluating this as to how 
> it applies to documents.   This isn't a document yet (or someone is 
> distributing documents titled 'untitled' -- maybe it is an art piece) 
> or it is something the user is creating and they will know what it is 
> (and they should save soon! -- with a title !*

PK: Nope, I 'm not applying this to documents.  I'm saying we have one 
software app whose only visible UI is these two documents.  And I'm 
scratching my head trying to figure out what the "page titled" should be 
for this software.  Note my "Note" below, that starts with "Note: Since 
Understanding for 2.4.2 begins with...".  There is no obvious, 
user-visible text to be the "page title" for this two-windows-showing 
software app that addresses the user needs described in Intent.  
Therefore I question whether this applies (as you have proposed writing 
it for software).

I strongly suggest we start doing what we discussed last Friday: writing 
a specific "WCAG2ICT Notes" for all language we are proposing for the 
remaining unconsensed SCs (and as a separate background task, write them 
for the consensed ones), describing how the user needs described in 
Understanding are addressed in the non-web context.  I commit to doing 
that for any text proposals I make.


>>   * **
>>   * Looking at Changed? Example #3: Tabbed panes
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-3-tabbed-panes>**we
>>     don't know for sure what the application name is.  If it is
>>     "Media Center" then this would be helpful; if not... then not.
>>     *This seems like may not be a good fit to this situation. *
>>
> *GV: These aren't documents or software programs.  So Im not sure why 
> you mention them when you want to talk about my proposal.  You are 
> looking at subparts of a software program and trying to evaluate if 
> you can identify  the program from the piece.  That isn't part of what 
> I was proposing.*

PK: No - I'm taking the example and saying "if this is the only visible 
part of the software application at this moment in time, then how would 
the proposed text for 2.4.2 apply in practice?".  And then I'm recording 
my answer above: "This seems like it may not be a good fit to this 
situation".  Again, take this in context with my Note below, looking at 
Intent for this SC.

> *
> *
> *GV: I DO think it would be useful for a person to know what program 
> each bit of UI on the screen belonged too -- and that they all had a 
> program name on them.   But that is not what the success criterion 
> requires and not what I proposed. *
> *
> *
> *What I proposed was that it was possible to identify the software 
> program.  On a mac - when I am in a program, its name appears at the 
> top of the screen.*
> *
> *
> *On a PC - every program I opened (and I opened a dozen or so) had its 
> name on the top title bar of the main window in one form or another.   
> So it doesn’t look like it would be hard to do.*

PK: Ahhh.... So what you are really saying is that (some of) my examples 
are wrong, and that the application name WOULD NORMALLY BE APPEARING in 
the title bars of these windows, and should be to satisfy your proposed 
text of the SC.

>>   * Looking at Changed? Example #24 calender appointments
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-24-calender-appointments>
>>     it is pretty obvious to folks raised with a cultural familiarity
>>     with the Julian calendar that this is a calendar / appointment
>>     application.  It is not at all clear what the software title is;
>>     it isn't "October".  And consuming a significant portion of a
>>     small screen to display the software application name would come
>>     at significant cost, and somewhat questionable benefit. *This
>>     seems like may not be a good fit to this situation. *
>>
> *GV: What program and operating system did you get this screen capture 
> from?   It looks like only part of a program -not the whole program.
> *

PK: This is an abstraction derived from the iOS calendar application 
when viewed on an iPhone.  I do see additional text (with the word 
"calendars" on it) when in portrait mode, so that too isn't a real life 
example of a mobile UI that is missing anything that would help orient a 
user with cognitive impairment as to what is going on. Rotate that 
screen 90 degrees to landscape mode, and you will loose the word 
"calendar".  Also go to just about any mobile phone's dialing 
application, and you won't see the word "phone" on it - just the NumPad 
for entering numbers (plus perhaps the word "Call" appearing on one of 
the buttons no where near where one would look for a "title" to the 
software).

Do you propose that the landscape view of the iOS calendar on an iPhone, 
and the dialing apps of most mobile phones, should fail this SC?  The 
visual layout at least of the latter is pretty clearly different and so 
I would question the need for a title in that case for folks with 
cognitive impairments (something perhaps to discussion with Clayton 
Lewis and other cognitive impairment experts).

>
>>     Note: Since Understanding for 2.4.2 begins with "The intent of
>>     this Success Criterion is to help users find content and orient
>>     themselves within it", and specific benefits include "People with
>>     visual disabilities will benefit from being able to differentiate
>>     content when multiple Web pages are open" and "People with
>>     cognitive disabilities, limited short-term memory and reading
>>     disabilities also benefit from the ability to identify content by
>>     its title". 
>>
>
> *GV:  Yes.  So substituting Software for "web page" you get 
> "differentiate content when they have multiple programs open".  The SC 
> would apply to figuring out which program you are using -- in the same 
> way WCAG would apply to knowing which page you were on.*

PK: A key difference is that in WCAG, the "which page you are on" is 
about the pages WITHIN a website, not over the entire Internet. Most of 
the programs you run likely aren't from Oracle; so is it Oracle's 
responsibility to help you distinguish our programs from whatever else 
you might decide to run?  It certainly isn't our responsibility for 
things outside our website with regards WCAG.

In any case, as I mentioned above and tying back to our Friday 
conversation, I think this SC needs to have "proposed WCAG2ICT Notes" 
describing how Intent from WCAG is being carried forward into the 
non-web software world, for us to better discuss it.

> *
> *
> *GV: It would be good to have orientation at levels inside a program 
> and inside a web page -- but as you know-- when we try that we run 
> into all sorts of problems.   Then people start saying that it doesn’t 
> apply. *
> *
> *
> *My proposal it so apply it as the level that is parallel (web page = 
> web app = software app)  and then it works.    Drilling down and 
> finding it doesn’t work, and then saying it doesn’t apply doesn’t seem 
> to be the way to go or to make sense. *
> *
> *
> *So - two down.
> *

PK: Sorry, this one isn't settled yet.  Not even close.

> **
>>
>> *2.4.5 Multiple Ways:*
>>
>>   * Looking at How many Example #1: two document windows
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-two-document-windows>
>>     it wouldn't apply, as there isn't a "set of software products"
>>     visible in the example.*
>>     *
>>
> *GV:   Huh?  I lost you.   It doesn’t apply to OK buttons in a dialog 
> box either.  or any other pieces of a program.     But that isn't what 
> is proposed.   I don't follow you here.   My proposal was that it 
> applied to software programs in a set of software programs.   You 
> don't have a set of software programs so it automatically meets -- 
> just like all the SC when applied to something that are not addressed 
> in the SC. *
>>
>>   * **
>>   * Looking at Changed? Example #3: Tabbed panes
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-3-tabbed-panes>**again
>>     it wouldn't apply, as there isn't a "set of software products"
>>     visible in the example.
>>
> *GV:   Ditto.   why are you citing examples that don't have anything 
> to do with the SC as proposed? *
>>
>>  *
>>
>>
>>   * Looking at Changed? Example #24 calender appointments
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-24-calender-appointments>
>>     again it wouldn't apply, as there isn't a "set of software
>>     products" visible in the example. *
>>     *
>>
> *GV:   Ditto.*

PK: I'm looking at a handful of examples - only specifically chosen at 
the outset to help illustrate the first of your four SCs in this thread, 
and then carried forward to the other three late on a Sunday night.


>>   * **
>>
>>     Note that Understanding is tied to locating content &
>>     information, not locating applications and functions; not clear
>>     how much application 2.4.5 has to software UIs.  Or perhaps none
>>     of these (or any of our) examples are useful to illustrate where
>>     2.4.5 would be helpful.  Perhaps we need other examples for
>>     software, showing where and how it would work.  AND more
>>     especially, describing HOW the helpfulness in WCAG 2.0
>>     Understanding translates into similar helpfulness in the software
>>     world!
>>
> *GV:  Again - if you look at WCAG you will see that it only applies to 
> pages.  So if a web app is a page-- it only applies to finding the Web 
> App -- not to finding any information in the Web app.  Same for 
> documents. *
> *    Yes - it would be  good to have multiple ways to find content 
> WITHIN a web page or WITHIN a web app -- but WCAG doesn’t require it. 
>  Similarly, it would be good to find have multiple ways to find 
> content WITHIN a single doc or WITHIN a single application.  But that 
> would go beyond what is parallel with WCAG. *
> *    My proposal is to apply it to documents and software to the same 
> level as it is applied in  WCAG for at least the most common forms of 
> web content (docs that are on a page and web apps at one URL). *
> *And it does work for that. *
> *
> *
> *
> *
> *So three down - though this won't come up terribly often.    IT does 
> give us a good place to hand all the advisory techniques that WOULD 
> drill down into docs and apps.
> *

PK: Until we have positive, real-world examples where it would apply 
that we can discuss and reach consensus on, this one isn't "down" either.

>
>> *3.2.3: Consistent Navigation: *
>>
>>   * Looking at How many Example #1: two document windows
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-two-document-windows>
>>     since the windows are simply repeated except with different
>>     non-GUI content, if any of the UI components are termed
>>     "navigation" this would be automatically met.  If none are termed
>>     "navigation", then it doesn't apply. *This seems like it could be
>>     OK; certainly no harm is done.*
>>
> *GV:  OK*
>>
>>   * Looking at Changed? Example #3: Tabbed panes
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-3-tabbed-panes>**it
>>     looks like it wouldn't apply, as there aren't any "repeated
>>     navigation mechanisms" visible in the example.
>>
> *GV:  You misunderstand the way conformance works in WCAG.   Look at 
> CR1 and at the definition of "satisfies the success criterion"*
> satisfies a success criterion
>     the success criterion does not evaluate to 'false' when applied to
>     the page
> *GV: so for example, if a page has no images on it then the 
> requirement that all images have alt text will not evaluate to "false" 
> and the success criterion is satisfied. *
> *GV: now take your example.  Since there are no repeated navigation 
> mechanisms*
> Navigational mechanisms that are repeated on multiple Web pages 
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#webpagedef> within a 
> set of Web pages 
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#set-of-web-pagesdef> occur 
> in the same relative order 
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#samerelorderdef> each 
> time they are repeated, unless a change is initiated by the user.**
> *For these pages this is not false -- so the success criterion is 
> satisfied and the pages conform.*
>>
>>   * Looking at Changed? Example #24 calender appointments
>>     <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-24-calender-appointments>
>>     again it looks like it wouldn't apply, as there aren't any
>>     "repeated navigation mechanisms" visible in the example. **
>>
> *GV: Ditto.  there aren't any movies or  a dozen other things covered 
> by success criterion either. So the success criterion are all 
> satisfied since none are violated. *
> *
> *
> *GV:  Think of it this way.  Are you conforming to the law that you 
> not run stop signs if there are no stop signs? **
> *

PK: Again, unless we can come up with actual real-life examples where 
this language would apply, and agree on that application, then we 
haven't done our job.

>>     Note that this seems like it is a rare situation to actually
>>     occur in most software, other than "content-driven" software like
>>     books or other sets of information with things like next/prev
>>     links on them (e.g. Help applications and the like, which are
>>     essentially similar to HTML/web content).
>>
> *GV:  not sure what you are referring to.   Consistent navigation -- 
> or repeated navigation -- in apps and doc is very common   But also 
> very easy to meet.
> *

PK: Please give me some real-life examples to discuss and review. That 
was my core point in my first response to your e-mail: we need to run 
your text by real-life examples and evaluate them there.

> *
> *
>>
>>
>>
>> From this quick analysis, I think we may have something not too 
>> unreasonable for 2.4.2 Bypass Blocks.
>
> *GV:   Not sure why it is just "not too unreasonable"
> *

PK: See my more positive characterization above.

> *
> *
>
>> We might have something for 2.4.5 Multiple Ways  and for 3.2.3 
>> Consistent Navigation - but I think we need to come up with a set of 
>> positive examples where this really occurs & would apply;
>
> *GV:
> *

PK: Did you mean to write something here?

>
>> it isn't clear from the examples we've generated on the Examples for 
>> UI Context discussion 
>> <https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples> 
>> that they are particularly useful.
>
> *GV:  those examples were for looking inside of apps and docs and the 
> breakthrough is in realizing that that is like looking inside web 
> pages. and these were not designed to be applied inside of a web page. 
>   So it is no surprise that those do not fit.*

PK: Yes.  So we need other/better then to move this discussion forward.

> *
> *
>>
>> I think this approach fails for 2.4.2 Page Titled.  If we instead say 
>> that the "title" of the "software" is the software applications 
>> "name" (whether the executable name or the name as it appears in 
>> things like the Windows Start menu),
>
> *GV:  That is exactly what I proposed. *
>
>> then we have moved significantly away from what Understanding for 
>> 2.4.2 is all about -> helping users locate the content & information 
>> they want.
>
> *GV:  WCAG does not provide all that user's want.  OR all that can be 
> done.   It is a minimum standard for accessibility.  You can go much 
> further.    Our goal however was to come up with a parallel to WCAG 
>  --- not to go beyond it to meet broader needs.   I would love to -- 
> but not our job here.
> *

PK:  I believe it isn't enough to simply have some words that don't fail 
in the software context.  Those words should also support the user needs 
expressed in Intent.  Not all of the user needs.  Not writing new SCs - 
I'm not arguing for that expansion of our charter.  But if seems like a 
good idea but we can't actually find examples where this helps & works & 
makes things better for users with disabilities, then we shouldn't write 
that application text.


>
>> Rather, if we want to apply 2.4.2 to the GUI environment, going with 
>> window title seems a better match.
> *GV:  that is inside the app.   and these do not apply inside a web app. *
> *that would be good -- but beyond what our charge is.   AND as we have 
> found out -- it gets complicated and ambiguous as soon as we go deeper.*

PK: OK, for Page Titled, this is pretty clearly about a VISIBLE page 
title, helping the user orient themselves to the correct content.

What is the content of a document editor that when launched opens a 
blank page?

> *
> *
>>   But then what do we do about the burgeoning world of mobile 
>> software UIs?  And what about audio UIs?  Does Page Titled really 
>> make sense in those worlds?  Maybe not...
>
> *GV:  yep.  part of the complexity and ambiguity I was referring too.*
> *
> *
> *Go back through this will fresh eyes and see if you can see what I 
> saw.    It eluded me / us for some time.  But once you grasp it -- 
> these last 4 fall out nicely like the others.   Some are not as 
> profound as what we were shooting for -- but they are what is parallel 
> to WCAG and a number of the WCAG items were also not profound-- but 
> were included to give a place to tie a whole raft of untestable, 
> ambiguous but extremely helpful advisory techniques to. *
> *
> *
> *When you or others define techniques to go along with this -- then 
> there will be these provisions to tie them all on to, and to go all 
> the places you want to go - without worrying about whether they apply 
> everywhere (they won't) or are all testable (they won't be).  But 
> instead can worry about if they are helpful and powerful - which many 
> of them will be.
> *

PK: To repeat myself, I think each of these four need a paragraph or two 
of "WCAG2ICT Notes" describing how the user needs expressed in Intent 
are addressed in the non-web contexts of non-web documents & non-web 
software.


Peter


>
>>
>>
>> Peter
>>
>>
>> On 9/14/2012 5:04 AM, Gregg Vanderheiden wrote:
>>>
>>> We have just 4 success criterion left.   And I think we are 
>>> overthinking ourselves.
>>>
>>> Taking a cue from Mike -- we need to take a step back and look at 
>>> what it is that we are trying to do.  Substituting individual words 
>>> works for much but not all.    But if we look at the objective of 
>>> the success criteria -- and we look at the fact that
>>>
>>>   * Web Apps often (usually?) are just a single web page -  then we
>>>     can equate  "software" with "web page" in many places.
>>>   * "web page in a set of web pages" also often (usually?) is
>>>     intended to apply to a set of pages that work as an entity on
>>>     the web.  So the equiv of "web page in a set of web pages" for
>>>     these SC would also be "software" (or document).
>>>
>>>
>>> this then leads us to something like the following  (Which I have 
>>> put into the worksite as proposals.
>>>
>>> but look at them here and we may be able to close these.
>>>
>>> Replace “web pages” with “documents” and “software”
>>> *
>>> *
>>> *We have just 4 success criterion outstanding*
>>>
>>> * 2.4.1  Bypass Blocks: A mechanism is available to bypass blocks of 
>>> content that are repeated on multiple Web pages.*
>>>
>>>  *
>>>     Replace “ multiple web pages” with “in a document” and “in software"
>>>
>>> Note that the INTENT section of WCAG already says:
>>>
>>> “Examples of repeated blocks of content include but are not limited 
>>> to navigation links, heading graphics, and advertising frames. Small 
>>> repeated sections such as individual words, phrases or single links 
>>> are not considered blocks for the purposes of this provision”
>>>
>>> *2.4.2: Page Titled: Web pages have titles that describe topic or 
>>> purpose.*
>>>
>>>  *
>>>     Replace “web pages” with “documents” and “software”
>>>
>>>     Note that web pages are often full applications,  so a software
>>>     application would be parallel.
>>>
>>> *2.4.5: Multiple Ways: More than one way is available to locate a 
>>> Web page within a set of Web pages except where the Web Page is the 
>>> result of, or a step in, a process.*
>>>
>>>   * replacing "web pages" with "documents" and replacing "set of web
>>>     pages" with "set of documents"
>>>   * replacing "web pages" with "software products" and replacing
>>>     "set of web pages" with "set of software products"
>>>
>>> NOTES:
>>>
>>> 1.*A set of documents *(or software products) is a group of 
>>> documents (or software products) that are
>>>
>>>     1.*published together*, and
>>>
>>>     2.*labeled as a set* within at least one of the member documents
>>>     (or software products).
>>>
>>> 2.*Republishing or bundling *previously published documents or 
>>> software products as a collection does not constitute a set of 
>>> documents. (i.e. They do not become a set if bundled but not 
>>> originally published as a set)
>>>
>>> 3.*A set that is broken* apart and distributed is no longer a set.
>>>
>>> 4.*A file directory *would be the equivalent of a site map for 
>>> documents (or software products) in that it provides a link to each 
>>> of the documents (software products) in the set of documents 
>>> (software products).  The directory also acts as the HOME for the set.
>>>
>>> 5.*A search function* in an operating systems (that finds documents 
>>> or software products) would be equivalent to a web search function 
>>> for web pages.
>>>
>>> 6.*Authors can assume* that the non-web documents or software 
>>> products will be stored and accessed on a major operating system 
>>> with browse and search abilities unless they have specific 
>>> information to the contrary.
>>>
>>> Final note to those evaluating 2.4.5:
>>>
>>> Although this provision is easily met, it is not always met. The 
>>> presence of this success criteria also makes it easier for people 
>>> creating support materials to later include a wide range of advisory 
>>> techniques that, while not always applicable, would
>>>
>>> *3.2.3: Consistent Navigation:Navigational mechanisms that are 
>>> repeated on multiple Web pages within a set of Web pages occur in 
>>> the same relative order each time they are repeated, unless a change 
>>> is initiated by the user.*
>>>
>>>   * Replace “multiple Web pages within a set of Web pages*” * with
>>>     “in documents” and “in software”
>>>
>>>     And ask WCAG to add the following or something like it to the
>>>     Understanding WCAG 2.0 document
>>>
>>>     "In this success criteria the term 'navigation mechanisms' is
>>>     meant to refer to active lists of standard (not user generated)
>>>     locations in the content that are provided by the author and
>>>     that, when activated, cause the user to move to that particular
>>>     standard location.
>>>
>>>         Navigation bars, a pull down menu that jumps you to
>>>     different locations, and a set of tabs provided by the author,
>>>     would be examples.
>>>
>>>         The following may be used for navigation but are not
>>>     included in what is meant by navigation mechanisms in this
>>>     success criterion :  escape keys, arrow keys, page down keys,
>>>     headers that are only in the text of the document, tabs that a
>>>     user creates or re-orders (because they are initiated by the
>>>     user), the OK and Cancel buttons on a dialog (don't take you to
>>>     consistent locations)."
>>>
>>>
>>>
>>
>> -- 
>> <oracle_sig_logo.gif> <http://www.oracle.com/>
>> Peter Korn | Accessibility Principal
>> Phone: +1 650 5069522 <tel:+1%20650%205069522>
>> 500 Oracle Parkway | Redwood City, CA 94065
>> <green-for-email-sig_0.gif> <http://www.oracle.com/commitment> Oracle 
>> is committed to developing practices and products that help protect 
>> the environment
>

-- 
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
Received on Monday, 17 September 2012 17:20:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 September 2012 17:20:41 GMT