- From: Peter Korn <peter.korn@oracle.com>
- Date: Tue, 19 Jun 2012 08:29:16 -0700
- To: Gregg Vanderheiden <gv@trace.wisc.edu>
- CC: public-wcag2ict-tf@w3.org
- Message-ID: <4FE09ACC.5020705@oracle.com>
Gregg, If what an IC is isn't clearly defined - but is a very fluid thing that can in fact change dynamically - then we will have a major compliance problem. Therefore I think we need a clear, concrete, objective definition - that doesn't change with author intent. Peter On 6/18/2012 11:15 PM, Gregg Vanderheiden wrote: > > > Getting there.... > > You are thinking of a IC as being a fixed thing like a package. A > SET of ICs is such a thing -- but ICs are whatever the Author > intended the "total user experience', if you will. > > The parts of an iCs do NOT have to all come from one author -- (in > fact they almost never do -- except in the case of something like the > EasyONe communicator that erases all trace of the OS's UI when it > launches. The UI is intended by the app author but the app author > incorporates the OS UI for example into the IC that their app presents > or is used in. > > Perhaps the term "user experience" needs to be brought in here - not > sure. have to think about it. > > More comments below with this as an intro > > G > > > On Jun 19, 2012, at 2:29 AM, Peter Korn wrote: > >> Gregg, >> >> I'm going to cut-and-paste a bit out of order, to hopefully help >> focus the conversation on a few key issues. >> >> You wrote: >> >>> *What is an IC* >>> >>> * a modal dialog box (with or without a title) all by itself >>> * a nonmodal dialog (with or without a title) along with anything >>> else outside of that dialog that belongs to the same application >>> (or it could be a suit) (same 'author) that a user can >>> directly interact with (e.g. ONLY those parts of the menu bar on >>> the top of the screen of a Macintosh that the author intends to >>> work with their program. Other things added by the user are not >>> part of the context for the application (though they are for the >>> user) >>> ... >>> >> >> and later you wrote in response to me: >> >>>> >>>> I'm also troubled by your 3rd bullet. As I read it, if I have 4 >>>> windows open - two Writer documents, a Calc spreadsheet, and an >>>> Impress slide presentation - they would all be the same IC because >>>> they are all part of the OpenOffice suite and therefore the same >>>> "author". That doesn't make sense to me. It also breaks down for >>>> me 2.4.1 below (which I'll discuss in more detail there). >>> >>> IF they are designed to all work together -- and you can navigate >>> among them -- and they are intended to work as one -- then yes. >>> If they are just miscellaneous programs from the same company - then >>> they are not the same context. >> >> and yet later: >> >>> Grin. I has to do with how they are viewed and work together. >>> Remember that a single application presents MANY DIFFERENT ICs from >>> one moment to the next. So All the apps can be one IC one moment >>> and yet different ICs at another. >>> >>> the key word is CONTEXT not application. You change context >>> within an app. And your context of operation at any point in time >>> includes the app and the OS. >> >> and finally getting to 2.4.5, in response to me, you wrote: >> >>> >>>> *"2.4.5 Multiple Ways:* More than one way is available to >>>> locate a /*dialog box*/ within a/*set of windows all belonging >>>> to the same application */except where the Web Page is the >>>> result of, or a step in, a process >>>> <http://www.w3.org/TR/WCAG/#processdef>. (Level AA)" >>>> >>> ????? dialog boxes are not ICS -- so I wouldn’t expect this to make >>> sense. >>> >>> I don't understand your substitutions. Hence I'm not surprised the >>> sentences don't computer. >>> >>> this reads >>> >>> *"2.4.5 Multiple Ways:* More than one way is available to locate >>> a /*IC*/ within a/* set of ICs */except where the IC is the >>> result of, or a step in, a process >>> <http://www.w3.org/TR/WCAG/#processdef>. (Level AA)" >>> >> >> So a "modal dialog box" is an IC - perhaps all of the time (or nearly >> all of the time?). > > Yes if it truly locks out all other interface when it is open. To > be absolutely modal it should block all view of the app and be > immovable - but this is rarely true. Usually it allows all the info > in the background to still be visible to the person who can see. > Can screen readers still access this information? > >> And sometimes a single application with multiple windows is multiple ICs, > > Not because of the multiple windows per se. The IC changes as that > app changes what is available to the user to view, navigate and > operate. Those are the multiple ICs whether they involve windows or > not. > >> and other times a single application with multiple windows is a >> single IC. > > Yes - see above. If the person can move between windows without > activating anything then they are all part of the IC. As a > programmer, in Windows you know that what an ordinary person would > refer to as a window was in fact often made up of may windows that > were just visually glued together. And sometimes a singe window is is > pieces or can be torn to pieces (pallets) by a user and still operate > largely the same. > >> But in any case, a "set of web pages" (I mean "set of ICs") must >> always be from the same author to be within the set, > > No. In fact this is almost never true. ICs themselves are rarely > from a single author -- though a single author...org may / usually > does/ define them or essentially most of the experience (the lower > layers may change some). (the app running on an OS) > >> so I guess "set of ICs" must always be a set of windows/dialog >> boxes/etc. from the same application or application suite, else they >> aren't in the same set. > > No. do you see now how they are not? > >> >> So, scratching my head a bit about 2.4.5... I come to the following >> specific recasting (remember, getting specific like this is a way to >> test the definition - if you cannot substitute the definition for the >> term, then the definition >> fails): > > yes - this looks ike you are changing the SC which may confuse people. >> >> *"2.4.5 Multiple Ways:* More than one way is available to locate >> a /*modal dialog box*/ within a/*set of windows/dialog boxes/... >> all belonging to the same application or suite of applications, >> from the same author */except where the Web Page is the result >> of, or a step in, a process >> <http://www.w3.org/TR/WCAG/#processdef>. (Level AA)" >> > > I would do it like this > > So subsituting a specific example into the SC we get >> >> *"2.4.5 Multiple Ways:* More than one way is available to locate >> a [/*modal dialog box] */ within a/* set of[windows/dialog >> boxes/... all belonging to the same application or suite of >> applications, from the same author ] */except where the Web Page >> is the result of, or a step in, a process >> <http://www.w3.org/TR/WCAG/#processdef>. (Level AA)" >> > But of course that is now what the IC means > > first of all --when you have a truly modal dialog box active you > cannot choose between it and anything. it is the whole world at that > point and none of the rest of the app is visible. But for non-modal > dialogs (or partially) they should be able to be identified in the > pallet of UI components on the page. I like your note about the > title no needing to be visible by the way. good point. > >> How does that text above NOT flow from your proposed definitions of >> these terms? > > See above. > > >> >> And again - and perhaps more importantly - WHAT DOES THIS MEAN in >> practice? What are the actual, multiple ways for the ICT itself to >> provide these multiple ways. Note: unlike 508/M376, we cannot "meet >> the SC directly or through the use of supported AT" - that's not a >> WCAG concept. > > ??? > > it certainly is. Why would you think it was not? > > The WCAG was purposely written to only say WHAT the effect should be > not HOW it should be done. Many of the SC are expected to be done by > User agents including AT today. > > >> So these multiple ways must be directly provided by the software, >> or the software fails the SC. > > ????? Don't know where this comes from. > >> >> More generally - would /*you */please do as I have done, and give at >> least one concrete WIMP GUI example of a single IC within a set of >> ICs and describe the multiple ways of locating that single IC within >> that set of ICs? Because I'm just not seeing it... > > OK. > > I have a word processing app. I present many different ICs to the > user at different times when they are using my program. sometimes the > IC I present is all locked up in a modal dialog box where I dim out > the background and force them to live in a little box til they are > done. Most of the time though the IC I give them has a menubar and > ribbon bar (multiple usually) and sometime floating pallets. > > These ICs represent a set of ICs that a person encounters when using > my program. > > NOW = I must (in my app, or relying on features in the OS, or using AT > if my software is supported by AT (works with AT) ) : > > - make sure that users can skip over those menus and ribbons and > floating pallets and does not need to tab through all of the controls > of each of them before I get to to the content they are writing each > time the IC changes. > > - > > > >> >> >> >> Now, on to some other parts of our discussion... >> >> <snip> >> >>>> How do we determine whether the author is the same or not? >>> >>> IF the product is a microsoft product then Microsoft is the >>> 'author". Note that is says author ... organization. >> >> ... >> >>>> >>>> I'm also troubled by your 3rd bullet. As I read it, if I have 4 >>>> windows open - two Writer documents, a Calc spreadsheet, and an >>>> Impress slide presentation - they would all be the same IC because >>>> they are all part of the OpenOffice suite and therefore the same >>>> "author". That doesn't make sense to me. It also breaks down for >>>> me 2.4.1 below (which I'll discuss in more detail there). >>> >>> IF they are designed to all work together -- and you can navigate >>> among them -- and they are intended to work as one -- then yes. >>> If they are just miscellaneous programs from the same company - then >>> they are not the same context. >> >> ... >> >>> Remember that a single application presents MANY DIFFERENT ICs from >>> one moment to the next. So All the apps can be one IC one moment >>> and yet different ICs at another. >> >> >> I don't think this is tenable without a more clear rule. It isn't >> objectively testable. > > don't follow > >> How do we say when a collection of apps designed to work well >> together but also available separately is "miscellaneous programs >> from the same company" or not? > > If they say the work together > if the app says it is compatible with windows OS then one can assume > that the app is intended to work with the OS UI elements that are used > with the APP (for example print dialog boxes) > >> If sold separately they are each their own IC, but when available >> together they loose there separate identities and become part of a >> larger shared IC? > > No. you are an individual but you are also part of your family. You > don't stop being one when you are also part of another. > > the apps are ICs. But if they are INTENDED (see the box or > documentation or advertising for intent) to work together as one > cohesive IC then they are also (when this is done) part of that IC. > >> And your final two sentences above are also not at all testable. > > review them again now that you have more information / context > >> How can we evaluate provisions that speak to multiple ICs (or a "set >> of ICs") when sometimes this collection of things is a single IC and >> other times it is multiple ICs? How do we when when it is one and >> when it is the other? (like a photon, sometimes a particle, sometimes >> a wave? > > Grin. No not like that. more like you being a person and a member of > your family. ICs nest. > >> and sometimes oth at the same time? but sometimes a particle among a >> set of waves...??? - quantum electrodynamics isn't my strong suit) > > >> >> >> >> Next topic: >> >>>> And even if I am mistaken, in a variety of UNIX graphical >>>> environments that is the case - there are a number of different >>>> apps that may appear to be "the desktop" - certainly different >>>> programming groups may have authored them. >>> >>> Right - and if the authors intend them to all work as one IC they >>> are. Authors intent. >> >> At some point we are going to also have to deal with conformance to >> WCAG in the context of non-web ICT. A major part of how WCAG >> conformance is playing out in the world is through evaluation not >> just by the author. Also by the user or purchaser (or a third >> party). If "author intent" plays a role in how to give meaning to >> the terms we use in the context of software, then we have a large >> potential train wreck ahead of us as folks other than authors attempt >> to assess whether WCAG is met or not by software ICT. >> > > When software is sold separately - the authors are ONLY responsible > for what they sell. If they sell a package that is sold as working > together -- they are responsible for them working together as one UI > then they are responsible for the ICs of that UI. > > IF they say it works on Windows then they are responsible for the UI > that is the combination of their package and the parts of the windows > UI that they incorporate into their app > > they are NOT responsible for the user pairing their app with another > and using them together. (unless the RFP specifically said that must > be true -- in which case the "author" (the system integrator) is > warranting that these all work together as one UI. > > I think it is as clear as any other part of 508 where software is > integrated. > > > > > >> >> >> Next topic: >>>> >>>> I also, frankly, question whether 2.4.2 needs to apply to all ICs >>>> in the software world - precisely because much of the Intent is >>>> addressable without needing to have a visible text title (and the >>>> Dock's title isn't visible, just spoken via AT). >>> >>> You are defining IC as being bits of IC's so you get a dead >>> end-which you should. >> >> Actually, I was caught up in a different way. I was caught up in the >> notion that the title should be visible. If we addressed 2.4.2 with >> a Note making clear that the title doesn't have to be visually >> rendered on the screen by the ICT, then I think we solve the example >> scenarios I was bringing up. I've added this to DISCUSSION POINTS >> for 2.4.2: >> >> Note: the title doesn't have to be made visible on the the screen >> in order to satisfy this Criterion, so long as it is >> programmatically determinable and available to AT. >> > > YEs that was a great insight by you . Thank you for noticing that. > I added that specifically to a revised version of a Trace submission. > > >> >> Next topic: >> >>> >>>> >>>>> >>>>> You wrote: >>>>>> >>>>>> [Also, we may need to reconcile that a web browser is software, >>>>>> yet by this definition both a portion of the web browser window - >>>>>> the web page - and the entire window, are both an "interaction >>>>>> context". Is that a problem?] >>>>>> >>>>> >>>>> The web browser is a context by itself -- but the browser is not >>>>> responsible for the content. >>>>> >>>>> >>>>> The content Plus the browser is a context to the page author - at >>>>> least for the browsers the authors intend their page to work with. >>>> >>>> Hmmm... So really any sort of "software player" would be >>>> presenting 2 ICs: one for the player "chrome", and a second for the >>>> "player content". E.g. a Flash application, or Java applet, or... >>>> running within a web page is an IC separate from the hosting >>>> application (or to use W3C terminology, the User Agent). That >>>> certainly is in keeping with the "author" notion. >>> >>> I think I follow you here. But remember that the author of the >>> "content" includes the player in their IC. >> >> Sorry, you've lost me here. In the web context, we don't hold web >> page authors responsible for the accessibility of the user agent. If >> the IC of a Java applet includes the Java runtime, and the IC of the >> Flash app includes the Flash player, and the IC of the PDF document >> includes Adobe Reader (or some other PDF viewer)... then you are >> making authors responsible for something they cannot control. > > No we don't. but if they are relying on the UI of the player - then > we do. > > and we do also kind of in another way -- via the accessibility support > bit. If you create content that has captions, but not in a way that > any player can display, (or if there IS no player that displays > captions for the technology you choose) then you fail. The goal is > not to have captions - but to have captions the user can view. > > so yes - the author is responsible for a) ensuring their content works > with players for access features and b) that players are available > that support the access in their content (accessibility support) > >> >> Why should web authors not be responsible for accessibility of the >> web browser but authors of highly interactive PDF documents (so they >> aren't simple electronic content) be responsible for one of several >> PDF viewers on the market? > > they are both equally responsible > >> If they are the same IC, then it seems to me the responsibility >> issue follows from that (as a WCAG in the software context >> conformance assessment would get made on the entire IC). > > yep. and that is the way it should be (and is if we didn’t/ don't > make a mistake somewhere) >> >> >>>> >>>> <snip> >>>> >>>>>> * My feeling is that "interaction context" is a poor substitute >>>>>> for web page" in 2.4.2 - as it also is with 2.4.1. This SC >>>>>> is an "irregular verb" that we just need to deal with >>>>>> separately, relying more on the Intent language. >>>>>> >>>>> Seems to fit to me. >>>> >>>> I only see a possible fit here, and only for the first of the >>>> multiple sentences in the Intent, and by doing so in a way that >>>> goes beyond what is strictly necessary in the more varied world of >>>> software UIs generally. >>>> >>>> I think SC is still better served by treating it a (slightly) >>>> irregular verb. >>> >>> Sorry -- I don't understand either sentence. Nor what you mean by a >>> sentence being an irregular verb. If you mean that the term doesn’t >>> work here -- I still don't see why. >> >> >> As I'm now comfortable with 2.4.2, now that I realize the title >> doesn't have to be visible on the screen, I think the 'irregular >> verb' and related discussions for 2.4.2 are "overtaken by events". > > > > OK thanks > > > > >> >> >> And finally to a larger concept: >> >>> >>>> Anyway... my point in this discussion isn't to try to wrestle a >>>> whole bunch of provisions all at once, but to see if as a group we >>>> have rough consensus that: >>>> >>>> * there is a workable notion - precise definition TBD - that >>>> works in a lot of places >>>> * there are some places (my "irregular verbs") where a straight >>>> substitution doesn't work; so we should some up with a term >>>> that does work in the "lots of places" and use it there, but >>>> not try to twist either the term or the fitting in order to >>>> insist it be used everywhere - (in other words, let our world >>>> have a few irregular verbs) >>>> >>>> It sounds to me Gregg that you want to keep pushing for a world >>>> free of exceptions. Or maybe it is just that you don't see the >>>> exceptions where I see them. >>> >>> >>> Don't know where you get that... I don't agree we should have a >>> world free of exceptions. WCAG is full of them. ANd I endorse a >>> bunch of global exceptions in 508. But we have no authority to >>> create any new exceptions in WCAG or 508. So I'm not sure where >>> the topic comes from. >> >> The 'exception' notion is this: specific SCs for which our mapping of >> "web page" to "IC" doesn't (quite) work are "exceptions" to *our* >> mapping rule of "web page" to "IC". For those exceptions we have >> more work to do in our mapping of the SC to the non-web ICT world. > > Mapping is matching one thing to another. Like one set of rules to > another set of rules. > > I know the term keeps getting used and I always comment that it > doesn’t make sense to use it here. Map wcag to 508 - yes. or map > 508 to m376 yes. > but we are not mapping > > > Our charge is to say what the WCAG SC would mean when applied to ICT. > it is not to say that they should or shouldn’t. that is out of scope. > we also cannot add exceptions. we can only point out what they would > mean or how the words can be understood in a broader context. > > if by mapping you mean connecting -- I sort of see that. But it > can't mean disconnecting or mapping to a bit bucket. That isn't in > our scope. > > So far I haven't see an problem. But we haven't gotten to the end -- > and I am learning as we explore this along with everyone else. > > have to run > > g > > > >> >> Make sense now? >> >> >> Regards, >> >> Peter >> >> -- >> <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 Tuesday, 19 June 2012 15:30:00 UTC