W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2010

Minutes of UAWG teleconference of 23 September

From: Jeanne Spellman <jeanne@w3.org>
Date: Thu, 23 Sep 2010 14:37:34 -0400
Message-ID: <4C9B9E6E.2040907@w3.org>
To: User Agent Working Group <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2010/09/23-ua-minutes.html

Summary of Action Items

    [NEW] ACTION: Gregory - email event handler proposed bugs to UA list
    [recorded in
    [27]http://www.w3.org/2010/09/23-ua-minutes.html#action01]
    [NEW] ACTION: Jeanne to update document 4.6.1 with text from minutes
    of 23 September [recorded in
    [28]http://www.w3.org/2010/09/23-ua-minutes.html#action02]
    [NEW] ACTION: Jeanne to update examples of 3.6.2 with updated text,
    from minutes of 23 [recorded in
    [29]http://www.w3.org/2010/09/23-ua-minutes.html#action03]

Text version of Minutes
    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

    User Agent Accessibility Guidelines Working Group Teleconference

23 Sep 2010

    See also: [2]IRC log

       [2] http://www.w3.org/2010/09/23-ua-irc

Attendees

    Present
           Greg, Gregory_Rosmaita, Jeanne, Jim_Allan, kford, sharper,
           Kim

    Regrets
           Jan

    Chair
           Kelly_Ford

    Scribe
           Greg

Contents

      * [3]Topics
          1. [4]AccewssKey in HTML5
          2. [5]Writers Meeting Survey#4 -
             http://www.w3.org/2002/09/wbs/36791/20100802-4/
      * [6]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 23 September 2010

    <kford> rrs agent, make minutes

    <kford> Scribe: Greg

AccewssKey in HTML5

    <oedipus> dialing in now -- lost track of time -- was on phone with
    physician

    Jeanne: Coordination group meeting yesterday. Concern that deadline
    looming on filing HTML5 bugs, and even though requirements for PF
    for accesskey equivalent does not have to be done, we have to
    identify all the places where bugs need to be filed against the
    HTML5 spec. PF is working on identifying those places. We need to
    reconcile UA's comments with PF's.
    ... Deadline for filing bugs against HTML5 is Friday, October 1.

    GR: He identified a specific list of bugs against HTML5's current
    definition of AccessKeys, but was asked to hold off on logging them
    as bugs until they were compared with UAAG20's work on keyboard
    access, activation vs. focus, discoverability, etc.
    ... Judy wants to ensure that HTML5 has mechanisms to support all
    requirements in UAAG20 that would relate to accesskeys.

    <oedipus>
    [7]http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

       [7] http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

    <oedipus>
    [8]http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

       [8] http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

    GR: Final list of bugs need to be logged by October 1, but details
    can be fleshed out later. His Access Keys Requirements document will
    probably be logged as a bug identifying which mechanisms aren't yet
    supported by HTML5.
    ... Don't think of them as AccessKey requirements only; some might
    be shaken out into other elements or attributes.
    ... The first link above is what PF came up with, the second his
    summary of what he found in UAAG.
    ... Also working on filing bugs against how accesskey currently
    appears in HTML5, which fails to address known problems from HTML4
    and introduces new issues as well.

    <oedipus> proposed HTML5 bug requiring @title for FRAME and IFRAME:
    [9]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.ht
    ml

       [9] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.html

    GR would like individuals members of UAWG to review and comment on
    PF requirements based on our understanding of what keyboard access
    means, to supplement PFs ongoing work.

    <oedipus> what is broken with accesskey in HTML5:
    [10]http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requir
    ements#what_is_broken_with_accesskey_in_HTML5.3F

      [10] 
http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements#what_is_broken_with_accesskey_in_HTML5.3F

    <oedipus>
    [11]http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

      [11] http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

    <oedipus> oedipus@hicom.net

    <oedipus> eric, i am free most of tomorrow

    <oedipus> KF: what i don't see listed -- how is this displayed

    KF: These nine requirements include functionality but not UI, such
    as how keyboard commands are conveyed to the user.

    <oedipus> Jeanne: Requirement 9: Access command mappings should be
    available at the beginning of the document. incomplete

    JS: Missing ability to user to assign priorities of various keyboard
    shortcuts, e.g. when user, user agent, and content all try to assign
    the same key to different functions. Browser needs to mediate, but
    the user needs final say.

    <oedipus> email Proposal: User Interface Independence for Accessible
    Rich Internet Applications:
    [12]http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0106.html

      [12] http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0106.html

    <oedipus> actual proposal:
    [13]http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/
    UserInterfaceIndependence.html

      [13] 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

    <oedipus> Requirement 3: Access commands should default to focus
    behaviour, ability for authors to specify whether the default
    behaviour focuses or activates the target, and for a user to
    overwrite any author specified or default behaviour.

    GL: Wondering whether it would be useful for UA to give the user the
    option to force access keys to navigate to an item without
    activating it, allowing the user to then check what it is before
    manually activating it. Generally accessible UI design guidelines
    say user should be able to navigate without side effects (e.g.
    activation), and it's not clear that the user would always be able
    to...
    ... navigate to the items through other means (e.g. tabbing).
    ... (That is regarding the "explanatory note" on meaning of "access
    commands".)

    KF: Doesn't feel UAAG2.0 4.2 is covered by PF's nine requirements,
    yet.

    GR: It's in his document calling out UAAG20 requirements not yet in
    the PF requirements list.
    ... Will consider entering UAAG20 4.2.1 through 4.2.3 as separate
    bugs against HTML5.

    <oedipus> ACTION: Gregory - email event handler proposed bugs to UA
    list [recorded in
    [14]http://www.w3.org/2010/09/23-ua-minutes.html#action01]

    <trackbot> Created ACTION-450 - - email event handler proposed bugs
    to UA list [on Gregory Rosmaita - due 2010-09-30].

    GL: Requirements could explicitly say that when there is a conflict
    between keyboard commands defined by content, user, and user agent,
    that all of the commands still *need to be available*, even if the
    user's preferences end with some being overridden. For example, if
    two things want to be Ctrl+S, one would be changed to another
    modifier, or a menu provides access to the various commands...
    ... and lists their origins and originally requested keys.
    ... It's worth noting that documentation often refers to the
    keyboard commands originally specified by the content author or UA
    developer, and so user may need to be able to map those to the
    actual keyboard commands used on their system as it's currently
    configured (e.g. overridden keys, or change of modifier imposed by
    the user agent).

    KF: UAAG20 has requirement 4.7.2 about direct navigation to
    important structural and functional elements.
    ... 4.7.6 says user can choose "important elements".

    GR: 4.7.7 wording will serve well.

    <oedipus> issues with global attribute "accesskey as-is in HTML5:
    [15]http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/010
    3.html

      [15] 
http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0103.html

    <oedipus>
    [16]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.h
    tml

      [16] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.html

    <oedipus> above is link to proposed bug on @title req for FRAME and
    IFRAME

    <oedipus>
    [17]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.h
    tml

      [17] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.html

    GL: The user agent should be able to provide the user with
    information as to what a keyboard command does, or at least which
    component (e.g. which html document, script, plug-in, etc.) is
    handling it.

    <oedipus> PROBLEM: @title is not required for FRAME or IFRAME in
    HTML5

    GR: Needs signoff by UAWG on the proposed bug requiring title on
    frame and iframe.

    <oedipus> DETAILS: @title has been used since HTML4 by assistive
    technologies to present the user with information as to the nature
    and function of the FRAME or IFRAME for which it is defined

    <oedipus> action-447?

    <trackbot> ACTION-447 -- Gregory Rosmaita to - send proposed bug
    report on IFRAME and FRAME requesting that @title be required (used
    by AT to identify FRAMEs and IFRAMEs to user) -- due 2010-09-16 --
    PENDINGREVIEW

    <trackbot> [18]http://www.w3.org/WAI/UA/tracker/actions/447

      [18] http://www.w3.org/WAI/UA/tracker/actions/447

    <oedipus> action-447: email proposal
    [19]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.h
    tml

      [19] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0079.html

    <trackbot> ACTION-447 - send proposed bug report on IFRAME and FRAME
    requesting that @title be required (used by AT to identify FRAMEs
    and IFRAMEs to user) notes added

    GR: Will be logging bug that title be required on iframe and frame,
    that some method needs to be provided for long descriptions of
    visual content in an iframe.
    ... DOM3 events working on hybrid control key/character, such as
    when you want to enter a navigation key such as tab into a text
    entry form field.

    <oedipus>
    [20]http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/
    UserInterfaceIndependence.html

      [20] 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html

    GR: Apple doing the User Interface Independence proposal linked to
    above. Meeting/call Monday at 10 AM Boston time that some UA reps
    will be on.
    ... Any other items that we want to advance or ensure is being
    addressed re HTML5?

    KP: (She's been intermittently on the call due to phone problems.)
    Asks about direct navigation to elements, which is a key
    requirement.

    <oedipus>
    [21]http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

      [21] http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

    <oedipus>
    [22]http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

      [22] http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

Writers Meeting Survey#4 -
[23]http://www.w3.org/2002/09/wbs/36791/20100802-4/

      [23] http://www.w3.org/2002/09/wbs/36791/20100802-4/

    First question is titled 4.6.3 but the actual link is to 3.6.1
    Configure Text.

    We have 2 accept and 3 recommend changes, but none of the proposed
    changes are major, substantial criticisms.

    Jan suggests an expanded Intent paragraph: "There are many types of
    low vision and each affects the perception of text differently. As a
    result, users will have a variety of preferences for text size
    (larger, smaller), font (letter shape, spacing, etc.) contrast (by
    adjusting foreground and background colors). In providing these
    preferences, it is important to avoid making assumptions. For...

    scribe: example, some users want to reduce the font size to decrease
    the need to scroll the content."

    Corrects typo: "There are many types of low vision and each affects
    the perception of text differently. As a result, users will have a
    variety of preferences for text size (larger, smaller), font (letter
    shape, spacing, etc.), and contrast (by adjusting foreground and
    background colors). In providing these preferences, it is important
    to avoid making assumptions. For example, some users want...

    scribe: to reduce the font size to decrease the need to scroll the
    content.

    Greg's survey response brought up a related question, but not
    specific to this SC: We might also want to include guidance on
    topics like, when user prints the document or saves it to their hard
    drive, or when it's exposed to assistive technology, should it be
    saved/printed/exposed as it appears on the screen or as the author
    specified?

    <oedipus> GL: configure text

    <oedipus> KF: when print, don't magnify do they?

    <oedipus> GL: some do -- can be a good or bad thing according to
    user

    <kford> Issue: We need to think about how to handle printing and
    such for accessible configurations.

    <trackbot> Created ISSUE-74 - We need to think about how to handle
    printing and such for accessible configurations. ; please complete
    additional details at
    [24]http://www.w3.org/WAI/UA/tracker/issues/74/edit .

      [24] http://www.w3.org/WAI/UA/tracker/issues/74/edit

    Next question is titled Proposal for 4.6.4 but the link is to 3.6.2
    Preserve Distinctions Intent, Examples and Related Resources.

    <jeanne> ACTION: Jeanne to update document 4.6.1 with text from
    minutes of 23 September [recorded in
    [25]http://www.w3.org/2010/09/23-ua-minutes.html#action02]

    <trackbot> Created ACTION-451 - Update document 4.6.1 with text from
    minutes of 23 September [on Jeanne Spellman - due 2010-09-30].

    The existing wording is: 3.6.2 Preserve Distinctions: The user has
    the ability to preserve distinctions in the size of rendered text
    when that text is rescaled (e.g., headers continue to be larger than
    body text) within absolute limitations imposed by the platform.
    (Level A)

    * Intent of Success Criterion 3.6.2:

    Users who need to enlarge or reduce text should be able to preserve
    visual cues like proportionally larger headlines so they can easily
    scan through them.

    * Examples of Success Criterion 3.6.2:

    o Lee changes all her text to 16 pt Palatino. She needs the
    headlines to scale proportionally (e.g. 24 pt) in order to preserve
    headline prominence.

    Jan's proposed rewrite of the Intent paragraph: The relative size of
    text provides visual cues that help in understanding and navigating
    web content. For example, headlines in a larger font than the body
    text. Users who set preferences to enlarge or reduce the text size
    need to have these visual cues preserved.

    Greg's proposed revised and additional examples:

    Examples of Success Criterion 3.6.1:

    Lee has low vision from albinism and has difficulty with screen
    resolution and brightness. She chooses to have all text displayed in
    Palatino font, with white text on a black background, and at least
    16 points tall. The serif Palatino font has character spacing that
    resolves better for her vision, while the white on black reduces
    glare and the larger size allows her to distinguish fine...

    scribe: detail more clearly.

    Tomas has extremely low vision and chooses to have his browser
    display all text the same size, and sets that size as large as he
    can without making the letters too tall for his screen. He chooses
    not to have headings be proportionately larger than normal text
    because that would make them taller than his screen and so
    unreadable.

    Examples of Success Criterion 3.6.2:

    Lee finds text easiest to read at 16 pt Palatino, but can chooses to
    have her browser display all in the Palatino font and at least 16 pt
    in size. She needs the headlines to scale proportionally (e.g. 24
    pt) in order to preserve headline prominence.

    Corrected to: Lee finds text easiest to read at 16 pt Palatino, so
    chooses to have her browser display all text in the Palatino font of
    at least 16 pt in size. She needs the headlines to scale
    proportionally (e.g. 24 pt) in order to preserve headline
    prominence.

    General agreement to those changes.

    <jeanne> ACTION: Jeanne to update examples of 3.6.2 with updated
    text, from minutes of 23 [recorded in
    [26]http://www.w3.org/2010/09/23-ua-minutes.html#action03]

    <trackbot> Created ACTION-452 - Update examples of 3.6.2 with
    updated text, from minutes of 23 [on Jeanne Spellman - due
    2010-09-30].

    <jeanne> September

Summary of Action Items

    [NEW] ACTION: Gregory - email event handler proposed bugs to UA list
    [recorded in
    [27]http://www.w3.org/2010/09/23-ua-minutes.html#action01]
    [NEW] ACTION: Jeanne to update document 4.6.1 with text from minutes
    of 23 September [recorded in
    [28]http://www.w3.org/2010/09/23-ua-minutes.html#action02]
    [NEW] ACTION: Jeanne to update examples of 3.6.2 with updated text,
    from minutes of 23 [recorded in
    [29]http://www.w3.org/2010/09/23-ua-minutes.html#action03]

    [End of minutes]
      _________________________________________________________
Received on Thursday, 23 September 2010 18:37:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:39 UTC