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 15:45:49 -0700
Message-ID: <5057A81D.3070201@oracle.com>
To: Gregg Vanderheiden <ez1testing@gmail.com>
CC: "public-wcag2ict-tf@w3.org Force" <public-wcag2ict-tf@w3.org>
Gregg,

PK: No screen shots came through.  But two things came to me while 
reading your reply I want to call out:

 1. For Page Titled, since in your characterization this is at the
    software (application) level, and we can have non-titled windows
    appearing on top of (and potentially obscuring) the titles of
    windows which do contain the page title, what then?  Page Title
    won't help in that situation.  Is it a failure?  Or just a case
    which we couldn't fully cover because of limitations of mapping WCAG
    to non-web ICT?  OR...?

 2. You've made the point multiple times that this is about
    inter-application issues, not intra-application issues.  But I'm
    reading 2.4.2 Bypass Blocks as intra-application: if the blocks are
    repeated within a single application (e.g within a single web
    page).  Is that also how you intend it, or not?


Peter


On 9/17/2012 3:08 PM, Gregg Vanderheiden wrote:
>
> On Sep 17, 2012, at 12:20 PM, Peter Korn <peter.korn@oracle.com 
> <mailto:peter.korn@oracle.com>> wrote:
>
>> 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.
>
> *GV: correct.  They don't apply to the examples you were looking at. 
>  Because those were not things they would apply to.   Multiple ways is 
> for getting to software - not around in it and consistent navigation 
> only applies to navigation elements. *
>
>> 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.
>
> *GV:  It is entirely likely that some will be of less importance than 
> others for docs and software.  Or occur more often others.       In 
> not sure that I follow how one gets from 'it doesn’t apply in many 
> places" to "it doesn’t apply".    If we were deciding whether to 
> include things in a standard or not -- then importance and prevalence 
> are both things we would look at when deciding what to devote time and 
> standard space.  But we arent doing that.  We are just saying how it 
> would apply.   So the fact that it may not apply in as many places as 
> other provisions doesn’t seem as relevant to us. *
> *
> *
>>
>> 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.
>
> *GV:  right.  and what I was proposing was that we apply this at the 
> software level (software as a single object) -- not to parts of the 
> software.   So looking at windows isn't relevant. *
>
>> And I'm scratching my head trying to figure out what the "page 
>> titled" should be for this software.
>
> *GV:  I would be -- is the software titled.    Not pieces inside it. *
>
>>   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).
>
> *GV:  it does -- and if you look at real world apps -- I see the apps 
> name on the menubar *
>>
>> 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.
>
> *GV:  I agree. *
>>
>>
>>>>   * **
>>>>   * 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:  it would be helpful if you used screen shots of real programs. 
>  These look like hypothetical drawings that don't have all the detail 
> on them.    Are these screen shots from a real OS?  Ah -  see that you 
> picked up on this below.*
>
>
>>
>>> *
>>> *
>>> *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.
>
> *GV:  yes. bingo*
>
>>
>>>>   * 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).
>
> *GV:  this is to orient you to the program.  not within it.   in a 
> single-screen (non-windowing) app like you are talking about -- the 
> user knows what app they are looking at . *
>>
>> 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,
> *
> *
> *GV2: WCAG isn't about web sites.  It is about web pages.    So the 
> comparison is a web page to an app.     And within an application 
> would map to within a page. *
> **
>> 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?
>
> *GV2:  no.  and not suggesting that you do. *
> *
> *
>>   It certainly isn't our responsibility for things outside our 
>> website with regards WCAG.
>
> *GV2:  right.*
>>
>> 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.
>
> *GV2:   agree *
>>
>>> *
>>> *
>>> *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.
>
> *GV2:  OK -- look back at it and think APP level rather than "inside 
> the app"  and I think you will see how it falls out.   it would be 
> good to also have "inside the app" guidelines but that can come as 
> advisory techniques -- and then we don't need to worry about each 
> technique or guideline applying everywhere. *
>>
>>> **
>>>>
>>>> *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.
>
> *GV2: I see that -- but don't understand why since they don't relate ? *
>
>>
>>
>>>>   * **
>>>>
>>>>     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.
>
> *GV2:  Fair enough.   After all - I'm asking for you to use real world 
> examples.*
>
>>
>>>
>>>> *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.
>
> *GV2:  ive cited real world examples dozens of times.   But an easy 
> one is open office. *
> *
> *
> *Screen shots at the bottom of the page. *
> *
> *
>>
>>>>     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.
>
> *GV2:   see below*
>>
>>> *
>>> *
>>>>
>>>>
>>>>
>>>> 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.
>
> *GV2:  OK*
> *
> *
>>
>>> *
>>> *
>>>
>>>> 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?
>
> *GV2:  getting old.     See below. *
>
>>
>>>
>>>> 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.
>
> *GV2:  below*
> *
> *
>>
>>> *
>>> *
>>>>
>>>> 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.
>>
>
> *GV2:  not sure what you are trying to get to / get at.    All of 
> these are based on user needs.   Some things are more important in 
> some contexts than others.  These success criteria were developed in 
> the Web context and while they apply to software they may not be as 
> important.   The consistency one is though. *
>
>>
>>>
>>>> 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?
>>
>
> *GV2:  Good to have -- but beyond what is proposed here. *
> *
> *
> *> until a document is published it does not need to conform to anything.*
> *> and windows inside of an application are not covered as entities if 
> the unit of conformance is software.  So for the TITLE provision -- I 
> applies to the unit of conformance which for WCAG was a web page but 
> for WCAG2ICT it would be the software application.    Now in WCAG we 
> would then attach any advisory techniques (for things that are not 
> required but good to do) to that success criterion.   We aren't doing 
> that in WCAG2ICT  but that is where all the techniques you want to 
> document would be stored. *
>
>>> *
>>> *
>>>>   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.
>>
>
> *GV2: agreed.     Now to find the time. *
>
>>
>> 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_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 22:46:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 September 2012 22:46:26 GMT