See also: IRC log
<trackbot> Date: 03 February 2011
<jeanne> http://www.w3.org/WAI/UA/tracker/actions/open
<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> 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> https://addons.mozilla.org/en-US/firefox/addon/customize-your-web/?src=api
<KimPatch> tutorial for customize your Web
<KimPatch> 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 (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 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 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].
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 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 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 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].
<jeanne> 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 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 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 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 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 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].
<jeanne2> 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.
<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 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 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].
<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.
<jeanne2> 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 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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/to make it easier for/to reduce conflicts with/ No ScribeNick specified. Guessing ScribeNick: Greg Inferring Scribes: Greg Default Present: Greg, Jeanne, +1.617.325.aaaa, KimPatch, Jan, sharper, Jim_Allan Present: Greg KimPatch Jan sharper Jim_Allan Jeanne WARNING: Replacing previous Regrets list. (Old list: KellyFord, Jeanne_(30_minutes_late), Jim_(90_minutes_late)) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ KellyFord, Jeanne, JAllan WARNING: Replacing previous Regrets list. (Old list: KellyFord, Jeanne, JAllan) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ KellyFord, Jim_(90_minutes_late) Regrets: Jim_(90_minutes_late) KellyFord Found Date: 03 Feb 2011 Guessing minutes URL: http://www.w3.org/2011/02/03-ua-minutes.html WARNING: No person found for ACTION item: on member:sharper to create intent for guideline 2.8 [recorded in http://www.w3.org/2011/02/03-ua-minutes.html#action09] People with action items: greg jan jeanne kim sharper[End of scribe.perl diagnostic output]