- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Tue, 19 Jun 2012 01:32:40 +0200
- To: Peter Korn <peter.korn@oracle.com>
- Cc: public-wcag2ict-tf@w3.org
- Message-id: <668A4AEF-096E-4843-9DCE-A8465770E6DC@trace.wisc.edu>
On Jun 19, 2012, at 12:39 AM, Peter Korn wrote: > Gregg, > > Thanks for your thoughts. In part because of the importance of objective testability, I'm going to push a little bit harder than may wind up being necessary on terms and how well they work. Rather that then find out in practice there is ambiguity that bites us in implementation... > > Also to keep this growing conversation thread readable/managable, I'm going to snip liberally. > > Finally, I'd like to stay a little while longer on the WIMP GUI before getting to deeply into your proposed more general proposed language. > > <snip> > >> >> Now here are your questions. >> >> 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) >> All windows (with or without a title) from a single author, that a person can move about in without acting on anything ,along with anything else outside of that window 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) - most commonly the top-most or "current" window - along with anything else outside of that window that belongs to the same application and a user can directly interact (e.g. the menu bar on the top of the screen of a Macintosh) > > I'm troubled by your notion of "author". What is "author"? The creator of the ICT/Document. that was the model in WCAG. > 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. > Running in the same process is much more precise, technical, and measurable - though it may not quite match what the user is seeing (and of course we have some situations in which multiple processes are contributing to visually rendering the contents of a single window - e.g. Java applets within a web browser content region - though on second though, a Java applet is perhaps its own "interaction context"?). Process sounds like thread. And as you say -- if it is an app on an environment on an OS -- and you borrow from all.... It is the final author - that is responsible for all the layers they use working together. > > 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. > >> What ISN'T an IC >> >> (these are all part of a context of interaction >> A menu bar, a menu >> A toolbar >> A pane of a window (e.g. in a split view or a side-by-side compare of two documents) >> A list box >> A single pane in a tab panel >> The entire collection of tabs in a tab panel > > Cool, we are agreed here. > > Though... as I think more about it, we need to perhaps explicit include as NOT an IC floating palette windows (which are covered by your expanded 2nd and 3rd "what is an IC" above). yep we do > > >> Also NOT and IC >> >> (although parts of them may be part of other contexts if the authors designed their products to work with them. An argument could be made that all of the standard parts of the taskbar/dock would be part of the context because the author intended the app to work with the standard doc features (in fact it probably is part of the testing.) >> The Windows Explorer Taskbar. Is this like the menu bar of the Macintosh UI - outside of the (Folder / drive) Windows but part of the Windows Explorer process and therefore a constant adjunct to the Explorer windows? Or are those OS-level toolbars their own "interaction contexts" - since they aren't really tied to the Windows and in fact are nearly always active nearly all the time? >> The Macintosh Dock. Same comment as Windows Taskbar above... > > If these aren't their own IC, then whose IC do they belong to? Windows OS desktop > Because the Windows Explorer Taskbar is clearly running in the Windows Explorer process, that feels like a fairly natural fit to me (to put it into that IC). Yes it WOULD be PART of the Win Explorers IC but it is not its own. It is ALSO part of every other APP's IC if they incorporate them (e.g. for navigating windows) > But unless I'm mistaken, the Finder application on Macintosh is different from the Dock application. I woudnt say that. > 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. > > So, things that are "desktop-wide" like this I think aren't so clearly in one IC or another, or should perhaps be in their own IC. Frankly, if it wasn't for 2.4.2 and a desire to avoid saying that the Macintosh Dock might fail 2.4.2 in certain formulations, I would more naturally say that something like the Dock is it's own IC. No. it doesn’t fit. > > 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. > >> >> 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. > >> >> You wrote: >>> "1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)" >>> >>> Since we care about audio accessibility issues all the time, we need to make sure that everything within the WIMP GUI is contained within an "interaction context". So we therefore must include "the desktop" as an additional case (not all UIs place the desktop formally in its own "window"). This concern likewise appears for 2.1.2 No Keyboard Trap (we don't want a focus keyboard trap to be OK on the desktop), 2.2.2 Pause, Stop Hide, etc. etc. >> The desktop is only part of the interaction context if the author intended it to be. This is usually true. But for Easy One communicator for example a modal state is created where none of the desktop or even the task bard is visible or accessible. So they would NOT be part of the interaction context. >> >> Also, for this SC, the need could be met by the app or the OS as long as the OS is maintained as part of the interaction Context. > > My sense is that the desktop is part of the software UI of the OS, and so 1.4.2 applies to the desktop as a software application, distinct from any non-desktop/folder windows open from other applications on the desktop. Of course things get tricky with various desktop hooks/plugins (e.g. adding to the context menu when right-clicking on certain file types which might add "7zip this file", or "check in this source file to the SCCS system". These are specific and somewhat prosaic examples multiple processes/authors (such as I noted with Java applets, Flash content in web pages, etc.). I THINK I follow you. but yes -- the Desktop includes the OS in its IC. And users may modify that IC but the desktop 'author' is not responsible for those add ons unless it endorses or blesses them. > > >> >> You wrote: >>> "2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)" >>> >>> Here is the first place where we encounter the plural. We also encounter a situation where what is stated in the Intent for the SC isn't well met by a simple substitution. So here is a provision where I think we greatly benefit by moving away from a strict language substitution, and treat it differently (as I have tried to do with Proposal #3 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/241-bypass-blocks and which Gregg has further polished and shortened). >> This actually should be a SET OF WEB PAGES. >> >> I think we can get the WCAG to agree to that. Then it falls back into the "same author, group or organization". Then I think the substitution works charmingly. There are many contexts created by all the combinations of components and features -- but if the same block keeps appearing there should be a way to skip over it. and there is for almost all software that is software program like. Software that is document like though.... it may not be automatic - though it should too if the page is well structured in a standard way. > > You may be charmed by the substitution, but I think it misses what is key to the Intent of 2.4.1, which is why I proposed language that goes beyond a strict substitution (which, again, you further polished). > > Separately, if we go with your bullet #3 of what is a single IC (or at least my reading of it) -> that the 4 different OpenOffice windows I have open constitute a single IC, then how does "repeated on multiple ICs" have meaning? If the "multiple ICs" all have to be from the same author (since it seems out of scope if nothing else to require different authors to have to work together to share the same blocks of content for bypassing). > > So... I remain uncharmed by any "web page" / "multiple web pages" (or "set of web pages") substitution for this SC. I continue to believe this is an irregular verb that needs its own treatment. 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. > >> >> You wrote: >>> "2.4.2 Page Titled: Web pages have titles that describe topic or purpose. (Level A)" >>> >>> Do we feel that in fact a title is truly needed for everything that is an "interaction context"? >> Yes definitely > > I disagree. From Intent: > The intent of this Success Criterion is to help users find content and orient themselves within it by ensuring that each Web page has a descriptive title. Titles identify the current location without requiring users to read or interpret page content. When titles appear in site maps or lists of search results, users can more quickly identify the content they need. User agents make the title of the page easily available to the user for identifying the page. For instance, a user agent may display the page title in the window title bar or as the name of the tab containing the page. > Titles of modal dialogs don't appear in any search results lists (nor a Taskbar or Dock, though you would say those are N/A). Sure they do. Every screen reader allows you do get a list of the windows. and to search the windows for a word. > There is no software user agent that might make such text available. tis true. so the way to do it is generally to step through them (like stepping through a menu in some ways) > Many modal dialogs have little text, so giving them the first sentence to read to avoid having to read the 1-3 sentences that are in the dialog is of de minimus value. No one said anything about giving them a first sentence. They all have one.. And read them . they usually do (or could ) orient the user to the purpose of the box. that is just good design. > So we fall back to the first sentence of intent - to help users find content & orient themselves. OK > When a non-titled IC is clear from being a fixture of the UI and how it is laid out, etc., Visually laid out????? > I think that a title isn't necessary. if the only way to figure out the box is to either glance at it (visually) or examine it carefully in text -- it would seem to fail. it shold be able to glance at it textually (which means a title or the first text should give you a cue as to what it is for) > And even if you claim the Dock isn't its own IC, you can perhaps imagine something rather like it that might be. Only if it operates in a vacuum and doesn’t expect to be used with other things. THen yes. > > <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. > >> >> You wrote: >>> "2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)" >>> >>> Again I think we can't go the substitution route here, as much of the desktop GUI is reachable outside of a simple focus order (e.g. the menu bar is outside of the focus order; you only read it by going directly to it - from anywhere else - and not by TABbing around the UI until you reach it in a specific place in the order). >> I don't see how you feel it doesn’t fit. First, mostly it is irrelevant because there is nothing linear about accessing all of this. The context can be navigated in many different ways and they all have meaning. So a linear presentation is not needed. You DO have to have some means of linearly going through all of the items on the desktop so you don't miss any. But there are many ways to linearly go through them and any would meet the SC. ONLY when the meaning or function must be in a linear fashion - is it required that any linear means of navigating is required. > > Sorry, I glossed over the latter part of the sentence, specifically "and the navigation sequences affect meaning or operation". > > You've convinced me that we don't need to treat this specially. OK Great. > > <snip> > >> >> You wrote: >>> "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. (Level AA)" >>> >>> This is the second place where we get the plural, with I think a similar problem (as with 2.4.1). What is the boundaries of a "set of interaction contexts" - when are they in the same set and when not? Since the Intent spells out >> I don't see any plural. "Set of web pages" is singular and is the defined term. The set of interaction contexts is clearly defined in the definition of "set of web pages" (see previous note) > > The plural is that the SC is talking about not just a single IC, but multiple ICs (even though they are part of a "singular" set). OK, let's do the substitution (in bold italics below): > But they are not just mutliple ICs. they are a SET. that is key. if not a SET then there is no requirement on them. > "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. (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. (Level AA)" > How exactly is this accomplished? ALT-TAB (or in some desktops/circumstances, CTRL-TAB which restricts cycling of non-modal windows to only those of the same application). And... that's generally it. So every WIMP GUI would fail 2.4.5? Or does Macintosh Exposé / Mission Control constitute a 2nd one (as well as the similar feature in GNOME Shell), so it is only Windows & most Linux desktops that would fail 2.4.5? And violating my earlier scoping for this conversation, what about tablet and similar UIs (e.g. iOS) - what are the multiple ways (besides swiping through them) to locate all of the screens in an iOS application? > > I think Loïc Martínez gets this one right, where he writes in Proposal #2 (my emphasis added) "This success criterion does not apply to software user interfaces, as it would require multiple ways of reaching any interaction context (window, dialog...) and that is not always feasible nor desirable." Windows and dialogs are not ICs so this is all moot and not related to the topic at hand. > > > > 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. We are only to say how it would apply. not to say that it should not. that is for the regulators. and is out of scope for us. We would be dead without exceptions though. Very late have to go > > > > Regards, > > Peter > -- > <oracle_sig_logo.gif> > Peter Korn | Accessibility Principal > Phone: +1 650 5069522 > 500 Oracle Parkway | Redwood City, CA 94065 > <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 18 June 2012 23:33:17 UTC