- From: Peter Korn <peter.korn@oracle.com>
- Date: Mon, 18 Jun 2012 15:39:11 -0700
- To: Gregg Vanderheiden <gv@trace.wisc.edu>
- CC: public-wcag2ict-tf@w3.org
- Message-ID: <4FDFAE0F.1080708@oracle.com>
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"? How do we
determine whether the author is the same or not? 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"?).
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).
> *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).
> *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? 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). But unless I'm mistaken, the Finder application on Macintosh is
different from the Dock application. 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.
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.
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 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.
>
> You wrote:
>>
>> * *"1.4.2 Audio Control:* If any audio on a /*Web page */plays
>> automatically for more than 3 seconds, either a mechanism
>> <http://www.w3.org/TR/WCAG/#mechanismdef> 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.).
>
> You wrote:
>>
>> * *"2.4.1 Bypass Blocks:* A mechanism
>> <http://www.w3.org/TR/WCAG/#mechanismdef> is available to bypass
>> blocks of content that are repeated on multiple Web pages
>> <http://www.w3.org/TR/WCAG/#webpagedef>. (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.
>
> You wrote:
>>
>> * "*2.4.2 Page Titled:* Web pages
>> <http://www.w3.org/TR/WCAG/#webpagedef> 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). There is no
software user agent that might make such text available. 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. So we fall back to the first sentence of intent - to
help users find content & orient themselves. When a non-titled IC is
clear from being a fixture of the UI and how it is laid out, etc., I
think that a title isn't necessary. And even if you claim the Dock
isn't its own IC, you can perhaps imagine something rather like it that
might be.
<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.
>
> You wrote:
>>
>> * *"2.4.3 Focus Order:* If a Web page
>> <http://www.w3.org/TR/WCAG/#webpagedef> can be navigated
>> sequentially <http://www.w3.org/TR/WCAG/#nav-seqdef> 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.
<snip>
>
> You wrote:
>>
>> * *"2.4.5 Multiple Ways:* More than one way is available to locate
>> a Web page <http://www.w3.org/TR/WCAG/#webpagedef> within a set
>> of Web pages
>> <http://www.w3.org/TR/WCAG/#set-of-web-pagesdef> except where the
>> Web Page is the result of, or a step in, a process
>> <http://www.w3.org/TR/WCAG/#processdef>. (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):
*"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)"
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*/."
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.
Regards,
Peter
--
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, 18 June 2012 22:39:51 UTC