- 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