Input modality requirements (was [Bug 10873] Provide a method of explicitly setting a tooltip for an element)

  Hi Patrick,

Not that I necessarily disagree with your suggestion of changing to something like "ensure full access with all available input modalities", but a few things we should keep in mind:

*1. Keyboard (and keyboard-emulator) *is* the most important input modality *because it is discrete commands, generally independent of screen location, and easily emulated using other input modalities. Requiring UI optimized for input by keyboard and keyboard emulators should definitely remain Level A.

*2. Other input modalities can be very useful *in making access easier and more efficient for users who can't use a keyboard (or when one is not available), but mouse and touchscreen are inconvenient to emulate with the keyboard. Because it's so much easier to emulate the keyboard with the mouse than the other way around, I consider native mouse UI lower priority than native keyboard UI; I support adding them, but probably at lower priority than Level A.

*3. We don't want to discourage developers from adding limited support for input modalities *when they can't add full support, which could be implied by the phrase "full access by all available input modalities". For example, we wouldn't want a product to fail UAAG because they added the ability to record voice notes but didn't go all the way to include full command, control, and dictation via speech. Similarly, I would not discourage a product from adding speech command and control for its UI even if it could not provide it for interacting with content. We would have to craft the wording to avoid these problems. Thus we might want to distinguish between:

    * /*command input modalities*/: input modalities with which the product or platform takes native command input (e.g. keyboard, mouse, voice commands)
    * /*non-command input modalities*/: input modalities with which the product or platform does not take native command input (e.g. audio recording, video and still image capture, drawing pad that's only used for drawing)

For our purposes in the document, rather than defining both terms we could simply defined input modality as referring only to input modalities with which the product or platform takes native command input (e.g. keyboard, mouse, voice commands), and note that it does not include other forms of input that are not used for commands (e.g. audio recording, drawing pad that's only used for drawing).

*4. We do want to encourage optimized rather than merely emulated UI. *Requiring "full access by all available input modalities" might be too vague because products would technically comply by having just keyboard UI, if the platform has an on-screen keyboard and perhaps basic speech recognition. What we really want to do is encourage software to incorporate UI that's optimized for each input modality supported by the platform. That is, if running on a platform that is optimized for touchscreen, the product should be designed to let the user access all features using touchscreen. Thus we might want to distinguish between:

    * */"native UI"/ *optimized for a specific input modality (e.g. keyboard shortcuts for keyboards and keyboard emulators, drag and drop for mouse and touchscreen, speaking control names to activate them with speech input, etc.) is most efficient for users of that modality, and generally has to be implemented by each application
    * */"emulating UI"/ *where one modality controls UI optimized for another (e.g. on-screen keyboards lets you control keyboard UI using a mouse, and speaking key names lets you control keyboard UI using speech) which is not as efficient as a native UI but is usually better than nothing, and is generally provided by the platform (e.g. by including an on-screen keyboard) rather than by each application


Thus, at the moment I'm thinking we should require everything has to be accessible by the keyboard (and keyboard emulators), that keyboard emulation be provided for each command modality, and on systems with keyboards that keyboard access needs to be efficient. In addition, we recommend that efficient access be provided for all the other command modalities.

And here's a more longer version:

   1. require full access by keyboard (and keyboard emulators) (e.g. navigation between controls using tab and arrow keys, direct access using keyboard shortcuts(Level A)
   2. require keyboard emulation for all non-keyboard input modalities that are used for command input (e.g. the platform includes an on-screen keyboard)  (Level A)
   3. on platforms that have a keyboard (not emulated), require full access using UI optimized for keyboard (and keyboard emulators) (Level A)
   4. for each input modality in which the product or platform takes command input, recommend full access using UI optimized for that modality (rather than using one modality to emulate another) (Level AA)

As always those are just thoughts and I'm completely open to arguments or suggestions.

     Thanks,
     Greg

-------- Original Message  --------
Subject: Re: Fwd: FW: [Bug 10873] Provide a method of explicitly setting a  tooltip  for an element
From: Patrick H. Lauke <patrickl@opera.com>
To: UAWG list <w3c-wai-ua@w3.org>
Date: 10/7/2010 10:11 AM
> Copying this from the IRC discussion, for consideration (though it is a lot of work, potentially?)
>
> (7:05:39 PM) patrickhlauke: if i was a radical, i'd say the title of guideline 4.1 should be "ensure full access" (with all available input modalities)
> [...]
> (7:06:44 PM) patrickhlauke: and then split into the various prominent modalities, with explanation (e.g. what is keyboard, with definition of kbd-like modalities)
>
>
>
> On 05/10/2010 15:46, Jim Allan wrote:
>> any ideas, comments
>>
>>
>> ---------- Forwarded message ----------
>> From: John Foliot<jfoliot@stanford.edu>
>> Date: Sat, Oct 2, 2010 at 3:27 PM
>> Subject: FW: [Bug 10873] Provide a method of explicitly setting a
>> tooltip for an element
>> To: jimallan@tsbvi.edu, Kelly Ford<Kelly.Ford@microsoft.com>
>> Cc: Maciej Stachowiak<mjs@apple.com>
>>
>>
>> UAAG friends,
>>
>> Please note Maciej's comments below:
>>
>>>
>>> --- Comment #6 from Maciej Stachowiak<mjs@apple.com>  2010-10-02
>>>
>>> Seems to me UAAG 4.1.1 already applies, since it explicitly applies to
>>> all
>>> functionality. It would be helpful if the Implementing UAAG 2.0 draft
>>> could
>>> give examples of how to offer access to tooltips using the keyboard. It
>>> seems
>>> to me this is important for @title even if a new feature is also added.
>>>
>>> http://www.w3.org/TR/2010/WD-IMPLEMENTING-UAAG20-20100617/#gl-keyboard-
>>> access
>>>
>>> However, UAAG 4.1.1 does not strike me as "device agnostic". It
>>> specifically
>>> requires access via the keyboard. This is surely not appropriate for
>>> devices
>>> without a physical keyboard, for example the iPhone. iOS has been
>>> praised for
>>> its accessibility support, through voice and touch:
>>> <http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/>.
>>> Interaction using a virtual onscreen keyboard would be much worse.
>>>
>>> That being said, tooltips themselves do not work very well for any
>>> users on
>>> touchscreen devices, since there is no concept of hover. So it is
>>> probably not
>>> good for device-independence to further encourage their use.
>>>
>>
>> The full discussion can also be found at:
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10873
>>
>>
>>
>
>