- From: Peter Korn <peter.korn@oracle.com>
- Date: Mon, 17 Sep 2012 15:45:49 -0700
- To: Gregg Vanderheiden <ez1testing@gmail.com>
- CC: "public-wcag2ict-tf@w3.org Force" <public-wcag2ict-tf@w3.org>
- Message-ID: <5057A81D.3070201@oracle.com>
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 UTC