W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2011

Minutes of Teleconference 3 February 2011

From: Jeanne Spellman <jeanne@w3.org>
Date: Thu, 03 Feb 2011 15:12:34 -0500
Message-ID: <4D4B0C32.9030908@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 3 February 2011 20:12:46 GMT