- From: Jeanne Spellman <jeanne@w3.org>
- Date: Thu, 03 Feb 2011 15:12:34 -0500
- To: UAWG <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2011/02/03-ua-minutes.html
IRC Log:
http://www.w3.org/2011/02/03-ua-irc
Text of Minutes:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
03 Feb 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/02/03-ua-irc
Attendees
Present
Greg, KimPatch, Jan, sharper, Jim_Allan, Jeanne
Regrets
Jim_(90_minutes_late), KellyFord
Chair
Greg, Jeanne
Scribe
Greg
Contents
* [3]Topics
1. [4]Focus
2. [5]2.1.12 - Preferred shortcut keys
3. [6]Writing: review and approve 1.11.2 - Extended Link
4. [7]2.7.4 - direct navigation,
5. [8]2.4.2 Three Flashes
6. [9]2.7.4 - direct navigation,
7. [10]2.7.7 - Configure Set of Important Elements,
8. [11]2.8.1 - Configure Position,
9. [12]Google docs update with a new mouse heavy element
10. [13]Writing: review and approve 1.11.2 - Extended Link
* [14]Summary of Action Items
_________________________________________________________
<trackbot> Date: 03 February 2011
Focus
<jeanne> [15]http://www.w3.org/WAI/UA/tracker/actions/open
[15] http://www.w3.org/WAI/UA/tracker/actions/open
2.1.12 - Preferred shortcut keys
<jeanne> focus discussion postponed at request of Kim and Greg
Current SC: 2.1.12 (former 4.1.12) Specify preferred keystrokes: The
user can override any keyboard shortcut including recognized author
supplied shortcuts (e.g. accesskeys) and user interface controls,
except for conventional bindings for the operating environment (e.g.
access to help). (Level AA)
<jeanne> It has several purposes - to reduce conflicts with
assistive technology, and to reduce keystrokes and the distance
between keys for simultaneous or sequential use
<Jan> JR: In ATAG2: A.3.1.5 Customize Keyboard Access: Keyboard
access to the authoring tool can be customized. (Level AAA)
<Jan> JR: Intent of Success Criterion A.3.1.5: The intent of this
success criterion is to ensure that authors using a keyboard
interface have the ability to remap the authoring tool's keyboard
shortcuts in order to avoid keystroke conflicts, use familiar
keystroke combinations and optimize keyboard layout (e.g. for
one-handed use).
Interesting that ATAG has it AAA while UAAG20 has it AA.
The wording is fine except that it leaves out reducing the number of
keystrokes.
We might want to use our standard wording from other Intent
paragraphs, "specially important for people with dexterity issues
where every keystroke can be time consuming, tiring or painful."
<jeanne> To ensure that authors using a keyboard interface have the
ability to remap the user agent's keyboard shortcuts in order to
avoid keystroke conflicts, reduce number of keystrokes, use familiar
keystroke combinations and optimize keyboard layout. This is
especially important for people with dexterity issues where every
keystroke can be time consuming, tiring or painful. (e.g. for
one-handed use).
How about "reduce keystroke conflicts with assistive technology"?
<Jan> Non-web-based authoring tool: A non-web-based authoring tool
has a keyboard setup utility that lists all of the available
keyboard shortcuts and allows authors to associate each shortcut
with any of the authoring tool's commands (e.g. all of the menu
commands).
<Jan> Web-based content management system: A web-based content
management system has a keyboard setup utility that allows authors
to change the access keys that are available during authoring. These
access key rebindings are for the authors' use only and do not
affect the web content being edited.
<Jan> Social networking application on a mobile device: A social
networking application has a keyboard setup utility that allows
authors to change their keyboard shortcuts for the site. The
remapping is saved in site cookies.
<jeanne> To ensure that authors using a keyboard interface have the
ability to remap the user agent's keyboard shortcuts in order to
avoid keystroke conflicts with assistive technology, reduce number
of keystrokes, use familiar keystroke combinations and optimize
keyboard layout (e.g. for one-handed use). This is especially
important for people with dexterity issues where every keystroke can
be time
<jeanne> consuming, tiring or painful.
<jeanne> The intent of this success criterion is to ensure that
authors using a keyboard interface have the ability to remap the
user agent's keyboard shortcuts in order to avoid keystroke
conflicts with assistive technology, reduce number of keystrokes,
use familiar keystroke combinations and optimize keyboard layout
(e.g. for one-handed use). This is especially important for people
with dexterity issues
<jeanne> where every keystroke can be time consuming, tiring or
painful.
<jeanne> To ensure that people using a keyboard interface have the
ability to remap the user agent's keyboard shortcuts in order to
avoid keystroke conflicts with assistive technology, reduce number
of keystrokes, use familiar keystroke combinations and optimize
keyboard layout (e.g. for one-handed use). This is especially
important for people with dexterity issues where every keystroke can
be time consuming,
<jeanne> tiring or painful.
<jeanne> The intent of this success criterion is to ensure that
people using a keyboard interface have the ability to remap the user
agent's keyboard shortcuts in order to avoid keystroke conflicts
with assistive technology, reduce number of keystrokes, use familiar
keystroke combinations and optimize keyboard layout (e.g. for
one-handed use). This is especially important for people with
dexterity issues
<jeanne> where every keystroke can be time consuming, tiring or
painful.
<jeanne> The intent of this success criterion is to ensure that
people using a keyboard interface have the ability to remap the user
agent's keyboard shortcuts in order to avoid keystroke conflicts
with assistive technology, reduce number of keystrokes, use familiar
keystroke combinations, and optimize keyboard layout (e.g. for
one-handed use). This is important for people with dexterity issues
where every
<jeanne> keystroke can be time consuming, tiring or painful, and
also for people using assistive technologies such as screen readers,
where many keystrokes are already in use by the assistive
technology.
<jeanne> The intent of this success criterion is to ensure that
people using a keyboard interface have the ability to remap the user
agent's keyboard shortcuts in order to avoid keystroke conflicts
with assistive technology, reduce number of keystrokes, use familiar
keystroke combinations, and optimize keyboard layout (e.g. for
one-handed use). This is important for people with dexterity issues
where every
<jeanne> keystroke can be time consuming, tiring or painful. It is
also important for people using assistive technologies such as
screen readers, where many keystrokes are already in use by the
assistive technology
Instead of "remap the user agent's keyboard shortcuts" it should
also include author-specified shortcuts (e.g. accesskeys)".
2.1.10, 11, and 12 overlap quite a bit.
2.1.10 is about UA UI, 2.1.11 is about author-specified accesskeys,
and 2.1.12 appears to be an attempt to combine the two.
Should we use the split apart or combined versions?
<Jan> A.3.1.2 No Keyboard Traps: Keyboard traps are prevented as
follows: (Level A) [Implementing A.3.1.2](a) In the Authoring Tool
User Interface: If keyboard focus can be moved to a component using
a keyboard interface, then focus can be moved away from that
component using only a keyboard interface and, if it requires more
than unmodified arrow or tab keys or other standard exit methods,
the...
<Jan> ...user is advised of the method for moving focus away; and
(b) In Editing-Views that Render Content: If an editing-view renders
content (e.g. WYSIWYG view), then a documented keyboard command is
provided that moves the editing-view keyboard focus to a known
location (e.g. the start of the editing-view).
We might be able to combine them and discuss different techniques
for UA UI vs. accesskeys in the examples rather than the SC.
I'm fine either way.
Jeanne proposes we keep 2.1.10 and 2.1.11 and drop 2.1.12, since the
first two are already done.
Jan asks if we want to standardize on splitting them up, and I don't
think we do or want to.
<jeanne> Jan: Are we consistent - do we always keep interface and
author access keys in separate criterion?
Reasons to split would be (a) widely different techniques (b)
different priorities (c) give products credit when they do one but
not the other.
<jeanne> Greg: we may not want it together in all cases. If the
techniques are different, we may want them different.
2.1.10's Intent is weak, but 2.1.11's has some valuable content
specifically about AccessKeys.
In reality the approaches required for customizing shortcuts in
content are very different from doing it for the UA UI. Does any UA
allow you to override accesskeys?
The Greasemonkey extension for Firefox allows you to customize
shortcuts in content in a persistent way.
<jeanne>
[16]http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110202/#s
c-2110
[16]
http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110202/#sc-2110
Kim mentions Configure My PC extension for Firefox which is like
Greasemonkey but easier to use for casual users.
<jeanne> Drop 2.1.12, change 2.1.11 to AAA to reflect that it is
more difficult to change the author specified accesskeys
<jeanne> ... and align with ATAG
<Jan>
[17]https://addons.mozilla.org/en-US/firefox/addon/customize-your-we
b/?src=api
[17]
https://addons.mozilla.org/en-US/firefox/addon/customize-your-web/?src=api
<KimPatch> tutorial for customize your Web
<KimPatch>
[18]http://www.customize-your-web.de/w/index.php/Short_Tutorial
[18] http://www.customize-your-web.de/w/index.php/Short_Tutorial
There is a keyconfig extension for Firefox that allows changing UA
UI keyboard shortcuts ([19]http://mozilla.dorando.at/keyconfig.xpi).
[19] http://mozilla.dorando.at/keyconfig.xpi).
We can leave these two SC separate to make it easier in case we
decide to make one AAA.
<jeanne> Kim: The Customize-Your-Web addon also has features on
focus, simulated clicks and changes elements.
<jeanne> ... and the customizations are sharable.
Intent of Success Criterion 2.1.11 (former 4.1.11)
Content authors may utilize the Accesskey attribute to define short
cut keys which allow quick access to specific elements, actions, or
parts of their Web content. The author-selected short cuts may
utilize keystrokes that are unique to their site, differing from
conventions used, and or familiar, to users of other similar sites,
or sites offering similar functionality. Users of assistive...
scribe: technologies who rely upon keyboard input may wish to have a
consistent mapping of shortcut keys to similar, or common actions or
functions across the sites they visit.
User agents should allow users to define a preferred key combination
for specific instances of author defined accesskeys. The user should
have the option to make any defined override to be persistent across
browsing sessions.
User agents may also offer the user the option to automatically
apply preferred key combinations for content which has author
supplied accesskey bindings, based upon the associated text, label,
or ARIA role, and which override any author specified keybinding for
that page content.
I note that the Intent says overrides SHOULD be persistent, but the
SC does not actually require that. Should it?
One could argue that if it's not persistent, it's not useful.
So we'll use the new Intent for 2.1.10, leave the Intent for 2.1.11
as it is.
Do the examples look OK to everyone?
<jeanne> ACTION: jeanne to delete 2.1.12 as duplicate, and insert
the new intent text into 2.1.10: The intent of this success
criterion is to ensure that people using a keyboard interface have
the ability to remap the user agent's keyboard shortcuts in order to
avoid keystroke conflicts with assistive technology, reduce number
of keystrokes, use familiar keystroke combinations, and optimize
keyboard layou [recorded in
[20]http://www.w3.org/2011/02/03-ua-minutes.html#action01]
<jeanne> t (e.g. for one-handed use). This is important for people
with dexterity issues where every keystroke can be time consuming,
tiring or painful. It is also important for people using assistive
technologies such as screen readers, where many keystrokes are
already in use by the assistive technology
<trackbot> Created ACTION-493 - Delete 2.1.12 as duplicate, and
insert the new intent text into 2.1.10: The intent of this success
criterion is to ensure that people using a keyboard interface have
the ability to remap the user agent's keyboard shortcuts in order to
avoid keystroke conflicts with assistive technology, reduce number
of keystrokes, use familiar keystroke combinations, and optimize
keyboard layou [on Jeanne Spellman - due 2011-02-10].
@@ Editors' Note: good place to add i18n example, accesskey - o
umlaut, but not on local keyboard@@
<jeanne> Social networking application on a mobile device: A social
networking application has a keyboard setup utility that allows
authors to change their keyboard shortcuts for the site. The
remapping is saved in site cookies.
That example is more WCAG than UAAG.
<KimPatch> Jim, a one handed keyboardist needs to map all keys to
the left side of the keyboard in order to quickly and comfortably
reach the keyboard shortcuts he uses frequently.
<KimPatch> Jim, a one handed keyboardist, needs to map all keys to
the left side of the keyboard in order to quickly and comfortably
reach the keyboard shortcuts he uses frequently.
<jeanne> ACTION: jeanne to add example to 2.1.10 of: Jim, a one
handed keyboardist, needs to map all keys to the left side of the
keyboard in order to quickly and comfortably reach the keyboard
shortcuts he uses frequently. [recorded in
[21]http://www.w3.org/2011/02/03-ua-minutes.html#action02]
<trackbot> Created ACTION-494 - Add example to 2.1.10 of: Jim, a one
handed keyboardist, needs to map all keys to the left side of the
keyboard in order to quickly and comfortably reach the keyboard
shortcuts he uses frequently. [on Jeanne Spellman - due 2011-02-10].
Writing: review and approve 1.11.2 - Extended Link
2.7.4 - direct navigation,
2.4.2 Three Flashes
We could repeat the Intent for 2.4.1 and add a single sentence
explaining that 2.4.2 is exactly the same except for more
conservative.
<Jan> BTW: This morphed in ATAG2 into this: A.3.3.1 Static View
Option: Editing-views that render visual time-based content can be
paused and can be set to not play automatically. (Level A)
The intent of this Success Criterion is to guard against inducing
seizures due to photosensitivity, which can occur when there is a
rapid series of general flashing, or red flash. A potentially
harmful flash occurs when there is a pair of significantly opposing
changes in luminance, or irrespective of luminance, a transition to
or from a saturated red occurs. 2.4.2 has the same effect as...
scribe: 2.4.1, only is more conservative, ensuring that more
sensitive users can traverse the Web without potentially harmful
effects.
Instead of "ensuring" say "going further to ensure that"
The intent of this Success Criterion is to guard against inducing
seizures due to photosensitivity, which can occur when there is a
rapid series of general flashing, or red flash. A potentially
harmful flash occurs when there is a pair of significantly opposing
changes in luminance, or irrespective of luminance, a transition to
or from a saturated red occurs. 2.4.2 has the same effect at...
scribe: 2.4.1, only goes further to ensure that more sensitive users
can traverse the Web without potentially harmful effects.
Under Examples can we just refer the reader to 2.4.1?
Same with Related Resources.
Jan notes that ATAG dropped this, replacing it with a static view
option.
<Jan> A.3.3.1 Static View Option: Editing-views that render visual
time-based content can be paused and can be set to not play
automatically. (Level A) [Implementing A.3.3.1]
<Jan> Intent of Success Criterion A.3.3.1:
<Jan> The intent of this success criterion is to ensure that authors
with photosensitive seizure disorder can use the authoring tool to
open visual time-based web content (e.g. animations) without risk.
Some people with seizure disorders can have a seizure triggered by
flashing visual content.
<Jan> Examples of Success Criterion A.3.3.1:
<Jan> Blog: A blogging tool allows authors to import video files.
Authors have the option to turn off an auto-play feature, so that
the video files are not played until a "Play" button is activated.
<Jan> WYSIWYG web page editor: A WYSIWYG editing-view is capable of
rendering JavaScript in real-time. Authors have the option to turn
off the real-time rendering feature, so that the JavaScript is not
rendered until a "Play" button is activated.
Re ATAG's approach, UAAG20 might already have those in the sections
on Time-Based Media (disabling autoplay) etc.
<jeanne> Jim, a one handed keyboardist, needs to map all keys to the
left side of the keyboard in order to quickly and comfortably reach
the keyboard shortcuts he uses frequently.
<jeanne> 2.9.2 (former 4.9.2) Time-Based Media Load-Only:
<jeanne> The user can load time-based media content @@ Editors'
Note: DEFINE@@ such that the first frame is displayed (if video),
but the content is not played until explicit user request. (Level A)
UAAG 2.9.6 Stop/Pause/Resume Multimedia is one part.
2.9.6 is Level A.
However, the TITLE of 2.9.6 uses the word "multimedia" when it
should be "time-based media", in order to apply to purely audio and
purely video.
2.9.2 has "time-based media" in the title, 2.9.6 uses "multimedia".
2.9.2 is also Level A.
<jeanne> ACTION: jeanne to review 2.9 and change all occurances of
Multimedia to Time-Based Media [recorded in
[22]http://www.w3.org/2011/02/03-ua-minutes.html#action03]
<trackbot> Created ACTION-495 - Review 2.9 and change all occurances
of Multimedia to Time-Based Media [on Jeanne Spellman - due
2011-02-10].
Do 2.9.2 and 2.9.6 apply to UA UI or only to content?
Because 2.4.2 is both.
2.9.2 and 2.9.6 are both about content only, not about UA UI.
Therefore we can't just get rid of 2.4.2 and let 2.9.2 and 2.9.6
cover it.
We either need to keep something like 2.4.2 or change the 2.9 SCs to
apply to UI UA, which arguably might be a good thing.
Is there anything in 2.9 that we would not want to apply to UA UI?
For example, 2.9.1 requires the ability to turn off background
images in content, but shouldn't the user be able to get rid of
background images behind the user agent's own text (message boxes
and so forth)?
Jan asks if we could simply put something elsewhere, such as in the
conformance section, that says SC apply to both content and UA UI
unless otherwise stated.
I think it would be clearer to simply change the SC wording to be
more general, avoiding the word "content". For example in 2.9.2 "the
user can load time-based media content such that" would change to
"the user can load time-based media such that".
But take the example of a UA which does a big animation every time
you open or close a menu. Would that be covered by "the user can
load time-based media content such that"?
or "the user can load time-based media such that"?
Jan notes that the developers know about all UA UI animations and
can provide alternatives, but in content is harder to recognize.
Do you want simply record as an Issue the question of whether 2.9
should apply to UA UI as well as content?
<jeanne> Issue: Review section 2.9 to see if it should apply to UI
as well as content.
<trackbot> Created ISSUE-81 - Review section 2.9 to see if it should
apply to UI as well as content. ; please complete additional details
at [23]http://www.w3.org/WAI/UA/tracker/issues/81/edit .
[23] http://www.w3.org/WAI/UA/tracker/issues/81/edit
<jeanne> The intent of this Success Criterion is to guard against
inducing seizures due to photosensitivity, which can occur when
there is a rapid series of general flashing, or red flash. A
potentially harmful flash occurs when there is a pair of
significantly opposing changes in luminance, or irrespective of
luminance, a transition to or from a saturated red occurs. 2.4.2 has
the same effect at...
<jeanne> [12:13] <Greg> ...2.4.1, only goes further to ensure that
more sensitive users can traverse the Web without potentially
harmful effects.
<jeanne> [12:13] <Greg> Under Examples can we just refer the reader
to 2.4.1?
<jeanne> [12:14] <Greg> Same with Related Resources.
<jeanne> resources: refer to 2.9.2 and 2.9.6
<jeanne> ACTION: Jeanne to add IER of 2.4.2 above [recorded in
[24]http://www.w3.org/2011/02/03-ua-minutes.html#action04]
<trackbot> Created ACTION-496 - Add IER of 2.4.2 above [on Jeanne
Spellman - due 2011-02-10].
2.7.4 - direct navigation,
<jeanne>
[25]http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110202/#s
c-274
[25]
http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110202/#sc-274
<jeanne> 2.7.4 (former 4.7.2) Direct navigation
<jeanne> : The user can navigate directly to important (structural
and operable) elements in rendered content. (Level A) .
Here's some text I wrote for another document, only the first
paragraph might be appropriate for this IER:
Direct commands benefit users in several ways. First, direct
navigation benefits all users who want to reduce the number of
discrete commands they have to enter, especially those for whom
input is difficult, painful, or slow. Also, compared to spatial or
sequential navigation, it is far more efficient for users who have
difficulty reading the screen, as it greatly reduces the number of
times...
scribe: they must examine the screen contents to carry out a command
(e.g. being able to type a fixed string of keys instead of having to
press a navigation key, then read the selected item to see if it is
their final destination, repeated until the answer is yes).
It is sometimes useful to distinguish two categories of direct
commands: Direct Navigation Commands that move the focus to a
corresponding element; and Direct Activation Commands that activate
an element or function without necessarily bothering to move the
focus to it. When Ctrl+O displays the Open dialog box, that's a
Direct Activation Command that performs the same action as the Open
menu...
scribe: item on the File menu, and therefore can be considered
associated with it, but does not directly invoke it. In contrast,
when the user presses Alt+D to move the focus to the Address field
on the browser's toolbar, that is a Direct Navigation Command
associated with the Address field. There are also hybrid commands
that do both; for example, the access key associated with a push
button in...
... a dialog box typically moves the focus to the button then
activates it, and if the action does not dismiss the dialog box, the
focus is left on the button rather than on the control that had the
focus before the access key was pressed.
<sharper> SH: This SC seems all but useless unless we have a more
testable definition of the term 'important' in the context of
'(structural and operable) elements'
<jeanne> ACTION: Jeanne to put text above into IER of 2.7.4. The
first paragraph is the intent. THe second should be reworded as the
example. [recorded in
[26]http://www.w3.org/2011/02/03-ua-minutes.html#action05]
<trackbot> Created ACTION-497 - Put text above into IER of 2.7.4.
The first paragraph is the intent. THe second should be reworded as
the example. [on Jeanne Spellman - due 2011-02-10].
BTW here are the definitions I use:
direct commands:
* direct activation commands activate a specified item regardless of
which currently has the focus; they may move the focus to the item
before immediately activating it
* direct navigation commands move focus to a specified item
regardless of which currently has the focus
This is part of this big document I was working on to try to
rationalize all the SC involving keyboard commands.
1. Types of commands are:
o local activation commands activate the item that has the keyboard
focus
o direct commands:
direct activation commands activate a specified item regardless of
which currently has the focus; they may move the focus to the item
before immediately activating it
direct navigation commands move focus to a specified item
regardless of which currently has the focus
o linear navigation commands (sometimes called logical or sequential
navigation commands) move forwards and backwards through a list of
items
o structural navigation commands move forwards, backwards, up and
down a hierarchy
o spatial commands (sometimes called directional commands), require
the user to be cognizant of the spatial arrangement of items on the
screen:
spatial navigation commands move from one item to another based on
direction on the screen
spatial manipulation commands resize or reposition an item on the
screen
<jeanne> ACTION: jeanne to add the definitions above to the glossary
[recorded in
[27]http://www.w3.org/2011/02/03-ua-minutes.html#action06]
<trackbot> Created ACTION-498 - Add the definitions above to the
glossary [on Jeanne Spellman - due 2011-02-10].
Re the issue Simon raised about the definition of "important
elements" being too vague, Jeanne suggests we replace "important
(structural and operable) elements" with simply "structural and
operable elements".
I think we need to come up with some examples of how UA would
implement this.
One example is Mouseless Browsing extension for Firefox.
<jeanne> Issue: In the conformance section, should we allow browsers
to use extensions to claim conformance.
<trackbot> Created ISSUE-82 - In the conformance section, should we
allow browsers to use extensions to claim conformance. ; please
complete additional details at
[28]http://www.w3.org/WAI/UA/tracker/issues/82/edit .
[28] http://www.w3.org/WAI/UA/tracker/issues/82/edit
Example: Raymond can't use a mouse and needs to reduce the number of
keystrokes he types as much as possible. His browser provides a
keyboard shortcut that applies visible numbers to each link and
heading in the current document, and allows him to type that number
to navigate directly to the corresponding element.
This way he can usually move to any visible link or heading in four
keystrokes or fewer.
Without this feature it could take him dozens or even hundreds of
keystrokes to navigate sequentially using the Tab key.
Example: Raymond can't use a mouse and needs to reduce the number of
keystrokes he types as much as possible. His browser provides a
command that applies visible numbers to each link and heading in the
current document, and allows him to type that number to navigate
directly to the corresponding element. This way he can usually move
to any visible link or heading in four keystrokes or fewer....
... Without this feature it could take him dozens or even hundreds
of keystrokes to navigate sequentially using the Tab key.
However, the term "structural and operable elements" might still be
vague: does structural elements mean just all headings. or also all
tables and list structures?
Kim suggested we could use the phrasing that Greg sent in email
yesterday which corresponds to the definition of "actionable
elements".
Is that different from operable elements?
We no longer define "operable elements", and it's used only in 2.7.6
Direct Activation and here.
We don't define either structural or operable elements.
Kim describes how optimum keyboard navigation includes between
groups and then within groups.
Jim refers us to HTML5 nav as well as to ARIA.
Kim sees navigation as three levels: (a) arrow keys within groups;
(b) tab keys between groups; and (c) F6 key between panes or panels.
<jeanne> Kim: I think there are 3 levels: arrowkeys (for menu items,
radio buttons) tab level (link and enabled element), panes (like
address bar).
<jeanne> ... Heading belong either in the pane level, or in a level
below that. Pane/Frame, Headings, Tab, Arrow
<jeanne> JIm: What else belongs in Headings? HTML sections - header,
footer, navigation
Jim points out that screen readers allow navigation by all sorts of
structural elements, including by headings, tables (e.g. "got to
next table"), etc.
<jeanne> ... screen readers have a lot of navigation options. We
don't want to give a user a list of HTML elements and ask what you
want to navigate by
<jeanne> Greg: This SC is about direct, not sequential navigation.
Is that different from "enabled elements"?
<jeanne> Kim: no, because enabled elements is everything you can do
except with the arrow key.
Sounds like we need to replace the phrase "enabled elements" with
something roughly equivalent to more precisely the things we want to
be able to find, navigate to, and active efficiently. The problems
with the current definition of "enabled elements" include (a) it is
redefining a term with established meaning in HTML (b) it includes
disabled elements because they can be changed through API...
scribe: (c) it includes non-interactive elements such as text, etc.
So probably change to "operable elements" and define them with
something like the wording I sent in email yesterday: * (a) enabled
controls that take input (e.g. push buttons, radio buttons, check
boxes, and text input fields, but not groupings or static text and
images) regardless of whether they are read-write or read-only,...
... and * (b) elements with scripted input handlers (e.g. images or
text ranges that have onClick or onKeyPress events) regardless of
whether the current state allows them to operate.
Then 2.7.4 would change to "2.7.4 (former 4.7.2) Direct navigation:
The user can navigate directly to structural and operable elements
in rendered content. (Level A).
Should we change structural elements to headings, or headings and
sections?
We don't yet define structural elements.
We could define it for the purposes of this document as recognized
headings and section breaks?
<jeanne2> I think HTML5 has added header, footer and navigaation
elements
<jeanne2> I would consider them sections
So shall we use "structural and operable elements" and create
definitions for both?
<jeanne2> +1
<KimPatch> +1
<jeanne2> ACTION: jeanne to edit 2.7.4 with following and link to
new definitions: Direct navigation : The user can navigate directly
to structural and operable elements in rendered content. (Level A).
[recorded in
[29]http://www.w3.org/2011/02/03-ua-minutes.html#action07]
<trackbot> Created ACTION-499 - Edit 2.7.4 with following and link
to new definitions: Direct navigation : The user can navigate
directly to structural and operable elements in rendered content.
(Level A). [on Jeanne Spellman - due 2011-02-10].
Structural elements could be defined as headings that label the
following content (e.g. HTML h1, h2, etc.) as well as headers,
footers, and section breaks. For the purposes of this document,
paragraphs, lists, and labels for tables and images and the like are
not considered structural elements.
Kim would like to see tables and lists be included.
<sharper> What about block-level elements and inline elements?
Kim suggests structural elements are anything you might want to get
to but can't using normal keyboard navigation means.
<jeanne2> it is a user complaint not being able to get to lists and
tables.
Kim says that users complain to her about the fact that they want to
get to more items. The Mouseless Browsing extension has continued to
add new types of elements in response to user requests.
<jeanne2> ... and pictures. Anything you need to get to that is not
operable is structural
<jeanne2> ACTION: Kim and Greg to draft definition of Structural and
Operable elements [recorded in
[30]http://www.w3.org/2011/02/03-ua-minutes.html#action08]
<trackbot> Created ACTION-500 - And Greg to draft definition of
Structural and Operable elements [on Kimberly Patch - due
2011-02-10].
2.7.7 - Configure Set of Important Elements,
<jeanne2>
[31]http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110202/#s
c-277
[31]
http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110202/#sc-277
<jeanne2> Configure Set of Important Elements:
<jeanne2> The user has the option to configure the set of important
elements for structured navigation, including by element type (e.g.,
headers, list items, images). (Level AAA) @@ Editor's note: Review
the definition of "important elements" @@
Very closely related to what we were just discussing.
2.7.4 Direct Navigation, 2.7.6 Direct Activation and 2.7.7 Configure
Set of Important Elements are all closely related and should be
modified as part of the same effort.
Jeanne updated the action item to reflect that.
2.8.1 - Configure Position,
<Jan> JR: FF would be responsible for its toolbars and have one
claim, Googledocs would be repsonsible for its toolbars and have
another claim
Can we just address that in the Intent and Examples?
<sharper> Action on sharper to create intent for Guideline 2.8
<trackbot> Sorry, couldn't find user - on
<sharper> ACTION: on member:sharper to create intent for Guideline
2.8 [recorded in
[32]http://www.w3.org/2011/02/03-ua-minutes.html#action09]
<trackbot> Sorry, couldn't find user - on
<jeanne2> ACTION: sharper to create intent for Guideline 2.8
[recorded in
[33]http://www.w3.org/2011/02/03-ua-minutes.html#action10]
<trackbot> Created ACTION-501 - Create intent for Guideline 2.8 [on
Simon Harper - due 2011-02-10].
Google docs update with a new mouse heavy element
<jeanne2> the latest up date presently being rolled out, requires
you to use the mouse and keyboard to change to a list of multiple
documents
<jeanne2> ... the middle pane, the list document
<jeanne2> ... you can tab, but it takes all day.
<jeanne2> Greg: right-click, other than a link, gets a shortcut menu
<jeanne2> Kim: you can't use the arrow keys to do the same thing.
<jeanne2> they are getting closer to the standards in windows
exploreer, but arrow and enter and not enabled in the main document.
<jeanne2> Greg: Is that violating WCAG?
Certainly they have mouse shortcuts that aren't available by
keyboard, so it violates the spirit of equal functionality
requirements, even if you can eventually get the same selection set
using many, many more keyboard operations.
<jeanne2> Kim: they are getting closer by enabling the shift and
control keys, but need the arrow keys to go the entire keyboard
accessibility.
Writing: review and approve 1.11.2 - Extended Link
<jeanne2>
[34]http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0040.h
tml
[34]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0040.html
Greg in email asked if it was about making info available directly
to the user, or to assistive technology.
Simon says he assumed it was about presenting it directly to the
user.
What would example implementation be like?
Simon: in Wiki system a small icon identifies links to offsite
resources.
Simon sees a browser having a preference setting to "turn on
extended link information" which displays all of these pieces of
information next to the link.
Simon: browser can tell by MIME type whether it would download, run
automatically, prompt for handling, spawn external renderer, etc.
Wouldn't the browser need to query the server to get MIME type?
In some cases the browser can guess by file extension, but I don't
think we want it to query the server for each link.
In email suggested changing the SC wording to incorporate
"recognized".
Greg: what did you mean by hover?
Simon: In CSS you can change link color based on hover.
Jeanne: Need to be aware of giving users so much information that we
impede their ability to navigate the page.
To make it clearly about presenting to the user, could change "The
following information is provided for each link (Level A)" to "The
user can have the following information about a link presented
(Level A)" or some such.
Jan: Information presented on hover needs to also be available to AT
and to keyboard users.
<Jan> Jan: Also wonders whether all this link info is accessibility
or usability
In response to Jan's question, I think visited/unvisited is
accessibility because it greatly reduces short-term memory load.
I have trouble imagining any browser not showing link element
content.
Jan suggests information related MIME type, size, etc. can be done
at link activation time, rather than displaying it on the page.
Simon notes it's much more efficient for some users if the
information is presented with the link rather than elsewhere (e.g.
in a status bar).
Similar question about whether it's OK to make the info available on
request (e.g. on a link's shortcut menu) vs. showing the information
for all links on the page IN the page.
Jan notes that information appearing somewhere other than where
you're working is a general accessibility problem.
Simon adds tab order and access key as important pieces of
information.
Do people feel the things Simon proposed as Level A are all
accessibility, not just usability? Element contents, title,
visited/unvisited, hover text (or hover content), and whether it's
currently selected?
The ability to customize highlight used for selected, visited and
unvisited links are all covered by SC 1.3.1 Highlighted Items and
1.3.3 Highlighted Input Controls.
So we may not need to repeat that here, but could list it in the
Related Resources.
Jan is OK with merely cross-referencing those here.
<Jan> Jan: hmmm that wasn't me
So if visited and selected are covered elsewhere, that leaves link
content, link title, and hover content as still needing to be
somewhere.
Title could be considered alternative content, which is also
addressed by another SC?
<Jan> JR: Idea: Proximity of Status Information: The user can
specify that status information for elements always be displayed in
proximity to the element. (e.g. rather than in status bar etc.)
Jan doesn't think the HTML title attribute would fall into the
category of "alternative content" because it's not meant to REPLACE
the primary content.
Does that mean we need some SC to require access to title
attributes? Or is that implied by the fact that if they show it to a
mouse user they have to show it to keyboard users as well?
If a browser chooses to not expose title attribute to anyone, mouse
or keyboard users, is that acceptable?
Simon says if it's OK if it's not available to anyone.
One argument that could be made for presenting title being an
accessibility issue is that if a person can't see a graphical link,
the title might give them more information to help them understand
it's purpose, above and beyond the alt attribute.
So should we remove link title from 1.11.1?
Discussion of the difference between things that we feel the browser
needs to do to be accessible (e.g. ability to turn off images,
providing keyboard shortcuts) , and things it needs to do for some
users if it does equivalent for others (e.g. keyboard access to all
features you ca do with mouse).
<KimPatch> stepping away for a minute
If we say that browsers don't have to display title attributes, but
if they do they have to make it available via the keyboard, that's
handled by another guideline so we wouldn't need to mention it here,
right?
<KimPatch> back
Jan suggests creating something about the user option to have
information displayed in proximity to the thing it is associated
with, rather than elsewhere as in a status bar. We do something
similar in 2.1.6 (former 4.1.6) Present Direct Commands in Rendered
Content: The user can have any recognized direct commands (e.g.
accesskey) in rendered content be presented with their associated...
scribe: elements (e.g. "[Ctrl+t]" displayed after a link whose
accesskey value is "t", or an audio browser reading the value or
label of a form control followed by "accesskey control plus t").
(Level A)
The intent for that is Intent of Success Criterion 2.1.6 (former
4.1.6): Make it easy to for users to discover or be reminded of
keyboard shortcuts and similar commands without leaving the context
in which they're working. Easy keyboard access is especially
important for people who cannot easily use a mouse.
<Jan> ACTION: Jan to Work on SC wording related to "Proximity of
Status Information: The user can specify that status information for
elements always be displayed in proximity to the element. (e.g.
rather than in status bar etc.)" perhaps making use of wording
similar to Intent of Success Criterion 2.1.6 (former 4.1.6):
[recorded in
[35]http://www.w3.org/2011/02/03-ua-minutes.html#action11]
<trackbot> Created ACTION-502 - Work on SC wording related to
"Proximity of Status Information: The user can specify that status
information for elements always be displayed in proximity to the
element. (e.g. rather than in status bar etc.)" perhaps making use
of wording similar to Intent of Success Criterion 2.1.6 (former
4.1.6): [on Jan Richards - due 2011-02-10].
So is there anything left in 1.11.1 we still need here?
<Jan> bye
<jeanne2> chair, Greg, jeanne
Summary of Action Items
[NEW] ACTION: Jan to Work on SC wording related to "Proximity of
Status Information: The user can specify that status information for
elements always be displayed in proximity to the element. (e.g.
rather than in status bar etc.)" perhaps making use of wording
similar to Intent of Success Criterion 2.1.6 (former 4.1.6):
[recorded in
[36]http://www.w3.org/2011/02/03-ua-minutes.html#action11]
[NEW] ACTION: jeanne to add example to 2.1.10 of: Jim, a one handed
keyboardist, needs to map all keys to the left side of the keyboard
in order to quickly and comfortably reach the keyboard shortcuts he
uses frequently. [recorded in
[37]http://www.w3.org/2011/02/03-ua-minutes.html#action02]
[NEW] ACTION: Jeanne to add IER of 2.4.2 above [recorded in
[38]http://www.w3.org/2011/02/03-ua-minutes.html#action04]
[NEW] ACTION: jeanne to add the definitions above to the glossary
[recorded in
[39]http://www.w3.org/2011/02/03-ua-minutes.html#action06]
[NEW] ACTION: jeanne to delete 2.1.12 as duplicate, and insert the
new intent text into 2.1.10: The intent of this success criterion is
to ensure that people using a keyboard interface have the ability to
remap the user agent's keyboard shortcuts in order to avoid
keystroke conflicts with assistive technology, reduce number of
keystrokes, use familiar keystroke combinations, and optimize
keyboard layou [recorded in
[40]http://www.w3.org/2011/02/03-ua-minutes.html#action01]
[NEW] ACTION: jeanne to edit 2.7.4 with following and link to new
definitions: Direct navigation : The user can navigate directly to
structural and operable elements in rendered content. (Level A).
[recorded in
[41]http://www.w3.org/2011/02/03-ua-minutes.html#action07]
[NEW] ACTION: Jeanne to put text above into IER of 2.7.4. The first
paragraph is the intent. THe second should be reworded as the
example. [recorded in
[42]http://www.w3.org/2011/02/03-ua-minutes.html#action05]
[NEW] ACTION: jeanne to review 2.9 and change all occurances of
Multimedia to Time-Based Media [recorded in
[43]http://www.w3.org/2011/02/03-ua-minutes.html#action03]
[NEW] ACTION: Kim and Greg to draft definition of Structural and
Operable elements [recorded in
[44]http://www.w3.org/2011/02/03-ua-minutes.html#action08]
[NEW] ACTION: on member:sharper to create intent for Guideline 2.8
[recorded in
[45]http://www.w3.org/2011/02/03-ua-minutes.html#action09]
[NEW] ACTION: sharper to create intent for Guideline 2.8 [recorded
in [46]http://www.w3.org/2011/02/03-ua-minutes.html#action10]
[End of minutes]
_________________________________________________________
Received on Thursday, 3 February 2011 20:12:46 UTC