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

Minutes for teleconference of 2 August 2012

From: Jeanne Spellman <jeanne@w3.org>
Date: Thu, 02 Aug 2012 14:48:58 -0400
Message-ID: <501ACB9A.7090302@w3.org>
To: User Agent Working Group <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2012/08/02-ua-minutes.html

Text of Minutes:

    [1]W3C

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

                                - DRAFT -

     User Agent Accessibility Guidelines Working Group Teleconference

02 Aug 2012

    See also: [2]IRC log

       [2] http://www.w3.org/2012/08/02-ua-irc

Attendees

    Present
           kford, Jim_Allan, Jeanne, Greg_Lowney, Jan, Kim_Patch

    Regrets
           Jaime, Mark

    Chair
           Kelly Ford

    Scribe
           Jan

Contents

      * [3]Topics
          1. [4]WAI Mobile Strategy
          2. [5]New 1.1.3 incorporating and adding to Jan's
             suggestions. from
          3. [6]1.2.2 Action-725 - Write IER for "1.2.2 Repair
             Missing
          4. [7]Structure" (Jan)
          5. [8]2.1.9 appears to overlap with 2.3.5 2.3.5 looks
             better] Jim
          6. [9]Name, Role, State Proposal Action-649, Action-651
      * [10]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 02 August 2012

    <kford> Hakkinen, Mark - Note Mark was going to update one more
    time from last meeting
    [11]http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0
    004.html

      [11] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0004.html

    <kford>
    [12]http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0
    005.html

      [12] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0005.html

    <scribe> scribe: Jan

    <kford> Scribe: Jan

    JS: Just came out of a WAI meeting regarding mobile....

WAI Mobile Strategy

    JS: Idea that we might have a opportunity to address mobile in
    uaag

    <kford> JS summarizes WI strategy meeting on mobile.

    JS: Strategy would be to publish to TR soon....
    ... Then to look at any gaps in mobile...
    ... And to see about working them in.
    ... But I don't have all the details
    ... We'll also be discussing in CG

    KP: Maybe could beef things up by going through and making sure
    we have mobile examples.

    JA: Also the other WG....if they find something they should let
    us know.

    KP: Maybe that can be a way to get people to read uaag

    JS: There is a Mobile Accessibility community group
    ... Also I need to turn the wiki page we made into a note etc

    KP: On mobile speech, most voice rec engines are server based
    ... So can get stranded...
    ... So I've been talking to developers
    ... Apparently there is no technical reason preventing it being
    on phone
    ... Big issue is that when they control servers they can
    improve the speech
    ... Just wanted people to know its not technical, but is
    business issue

    Greg: like the IBM-Siri issue

    JS: Certainly could be problem on simpler platforms.

    JA: Remarkable that mobiles have the HP to do that.

New 1.1.3 incorporating and adding to Jan's suggestions. from

    [13]http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0
    029.html

      [13] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0029.html

    1.1.3 Display of Time-Based Media Alternatives: For recognized
    on-screen alternatives for time-based media (e.g. captions,
    sign language video), the following are all true: (Level AA)

    (a) Do Not Obscure Primary Media: The user can specify that the
    display of media alternatives does not obscure the primary
    time-based media; and

    (b) Do Not Obscure Controls: The user can specify that the
    display of media alternatives does not obscure recognized
    controls for the primary time-based media; and

    (c) Configurable Text: Text within media alternatives (e.g.
    captions) can be configured in conformance with 1.4.1; and

    Note: Depending on the screen area available, the display of
    the primary time-based media may need to be reduced in size to
    meet this requirement.

    1.1.X Size and Position of Time-Based Media Alternatives: The
    user can configure recognized on-screen alternatives for
    time-based media (e.g. captions, sign language video) as
    follows: (Level AAA)

    (a) Resize: The user can resize the media alternatives up to at
    least the size of the primary time-based media.

    (b) Reposition: The user can reposition the media alternatives
    to at least the top, bottom, left and right of the primary
    time-based media.

    Note 1: Depending on the screen area available, the display of
    the primary time-based media may need to be reduced in size or
    hidden to meet this requirement.

    Note 2: Implementation may involve displaying media
    alternatives in a separate window, but this is not required.

    <Greg> Does "the user can specify" imply a setting that affects
    automatic placement, rather than manual placement, when both
    are acceptable?

    <Greg> Perhaps "The user can have".

    <Greg> As in "The user can have media alternatives not
    obscure..."

    <Greg> Perhaps change "text within media alternatives" to
    "Recognized text within media alternatives" so that text
    appearing, for example, in the sign language video is not
    counted.

    1.1.3 Display of Time-Based Media Alternatives: For recognized
    on-screen alternatives for time-based media (e.g. captions,
    sign language video), the following are all true: (Level AA)

    (a) Do Not Obscure Primary Media: The user can specify that the
    display of media alternatives does not obscure the primary
    time-based media; and

    (b) Do Not Obscure Controls: The user can specify that the
    display of media alternatives does not obscure recognized
    controls for the primary time-based media; and

    (c) Configurable Text: Recognized text within media
    alternatives (e.g. captions) can be configured in conformance
    with 1.4.1.

    Note: Depending on the screen area available, the display of
    the primary time-based media may need to be reduced in size to
    meet this requirement.

    <jeanne>
    [14]http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3
    .org%2FWAI%2FUA%2F2012%2FED-UAAG20-20120731%2FMasterUAAG2012073
    1.html&doc2=http%3A%2F%2Fwww.w3.org%2FWAI%2FUA%2F2012%2FED-UAAG
    20-20120731%2FMasterUAAG20120802.html#def-recognize

      [14] 
http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FWAI%2FUA%2F2012%2FED-UAAG20-20120731%2FMasterUAAG20120731.html&doc2=http%3A%2F%2Fwww.w3.org%2FWAI%2FUA%2F2012%2FED-UAAG20-20120731%2FMasterUAAG20120802.html#def-recognize

    Resolved: All accept new wording for 1.1.3 (see above) with
    clarification around how user can specify placement, etc. in
    the IER

    1.1.X Size and Position of Time-Based Media Alternatives: The
    user can configure recognized on-screen alternatives for
    time-based media (e.g. captions, sign language video) as
    follows: (Level AAA)

    (a) Resize: The user can resize the media alternatives up to at
    least the size of the primary time-based media.

    (b) Reposition: The user can reposition the media alternatives
    to at least the top, bottom, left and right of the primary
    time-based media.

    Note 1: Depending on the screen area available, the display of
    the primary time-based media may need to be reduced in size or
    hidden to meet this requirement.

    Note 2: Implementation may involve displaying media
    alternatives in a separate window, but this is not required.

    <Greg> Why limit it to the size of the primary time-based
    media? Why not the size of the display? If the primary media is
    small, this would be useless.

    (a) Resize: The user can resize the media alternatives up to at
    least the maximum size of the primary time-based media.

    (a) Resize: The user can resize the media alternatives up to at
    least the size of the user agent's viewport.

    (a) Resize: The user can resize the media alternatives up to
    the size of the user agent's viewport.

    <Greg> As long as it's AAA, why not also include positioning
    the alternative to overlap the primary media?

    (b) Reposition: The user can reposition the media alternatives
    to at least the top, bottom, left, and right of the primary
    time-based media as well as overlaying the primary time-based
    media.

    (b) Reposition: The user can reposition the media alternatives
    to at least the top, bottom, left, and right of the primary
    time-based media (either overlaying or not the primary
    time-based media).

    <Greg> "The user can reposition the media alternatives to at
    least above, below, to the right, to the left, and overlapping
    the primary time-based media."?

    (b) Reposition: The user can reposition the media alternatives
    to at least above, below, to the right, to the left, and
    overlapping the primary time-based media.

    1.1.X Size and Position of Time-Based Media Alternatives: The
    user can configure recognized on-screen alternatives for
    time-based media (e.g. captions, sign language video) as
    follows: (Level AAA)

    (a) Resize: The user can resize the media alternatives up to
    the size of the user agent's viewport.

    (b) Reposition: The user can reposition the media alternatives
    to at least above, below, to the right, to the left, and
    overlapping the primary time-based media.

    Note 1: Depending on the screen area available, the display of
    the primary time-based media may need to be reduced in size or
    hidden to meet this requirement.

    Note 2: Implementation may involve displaying media
    alternatives in a separate window, but this is not required.

    Resolved: All accept new wording for 1.1.X (see above)

    KF: Who wants to write the IER?

    <kford> Note: we need to get IERs for these partly based off of
    Mark's original text.

1.2.2 Action-725 - Write IER for "1.2.2 Repair Missing

    [15]http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0
    034.html

      [15] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0034.html

    Intent of Success Criterion 1.2.2:

    When an author has neglected to provide labels and/or headers
    as necessary for accessibility, the user agent can, in some
    cases, use heuristics to determine potential labels and/or
    headers from presentation attributes. Once potential headings
    and/or labels have been identified, the user agent can proceed
    (e.g. with communication via platform accessibility services)
    as if the relationship was...

    scribe: defined in the markup. The user must have the option to
    specify whether the heuristics should be applied because some
    users will need to experience the content as the author
    provided it, for example to perform evaluations.

    When an author has neglected to provide labels and/or headers
    as necessary for accessibility, the user agent can, in some
    cases, use heuristics to determine potential labels and/or
    headers from presentation attributes. Once potential headings
    and/or labels have been identified, the user agent can proceed
    (e.g. with communication via platform accessibility services)
    as if the relationship was...

    <Greg> I think turning off heuristics because they're wrong is
    a more prominent accessibility issue than the need to turn it
    off for testing.

    scribe: defined in the markup. The user must have the option to
    specify whether the heuristics should be applied because some
    users will want to experience the content as the author
    provided it, for example to perform evaluations or they may
    find that heuristics occasionally fail.

    <Greg> "or when they find"?

    When an author has neglected to provide labels and/or headers
    as necessary for accessibility, the user agent can, in some
    cases, use heuristics to determine potential labels and/or
    headers from presentation attributes. Once potential headings
    and/or labels have been identified, the user agent can proceed
    (e.g. with communication via platform accessibility services)
    as if the relationship was...

    scribe: defined in the markup. The user must have the option to
    specify whether the heuristics should be applied because some
    users will want to experience the content as the author
    provided it, for example to perform evaluations or when they
    find that heuristics occasionally fail.

    Resolved: All accept intent text (above) for 1.2.2

    Examples of Success Criterion 1.2.2:

    - content markup includes a checkbox without a specified label,
    but the user agent detects that a static text component is
    positioned immediately to the right of the checkbox and no
    other static text components are nearby. The nearby text is
    treated as the label.

    - content markup includes a table with no header row. The user
    agent detects that top row contains textual entries while the
    other rows contain numeric entries. The top row of the table is
    treated as table headers.

    - content markup (in English) includes instances of static text
    that differ from surrounding text due to being styled sentence
    fragments and being styled with a larger font, bold weight and
    additional spacing. The instances are treated as headings.

    Examples of Success Criterion 1.2.2:

    - content markup includes a checkbox without a specified label,
    but the user agent detects that a static text component is
    positioned immediately to the right of the checkbox and no
    other static text components are nearby. The nearby text is
    treated as the label.

    - content markup includes a table with no header row. The user
    agent detects that the top row contains textual entries while
    the other rows contain numeric entries. The top row of the
    table is treated as the table header row.

    - content markup (in English) includes instances of static text
    that differ from surrounding text due to being sentence
    fragments and being styled with a larger font, bold weight and
    additional spacing. The instances are treated as headings.

    <Greg> Could acknowledge in the examples that there are
    different approaches to implementation, e.g. right now all are
    are default actions by the user agent, could have one be at
    user request.

    Examples of Success Criterion 1.2.2:

    - content markup includes a checkbox without a specified label,
    but the user agent detects that a static text component is
    positioned immediately to the right of the checkbox and no
    other static text components are nearby. The nearby text is
    treated as the label.

    - Maria sets her user agent to automatically assume that when
    tables lack marked up header rows, the first row should be
    treated as the table header row.

    - content markup (in English) includes instances of static text
    that differ from surrounding text due to being sentence
    fragments and being styled with a larger font, bold weight and
    additional spacing. The instances are treated as headings.

    Examples of Success Criterion 1.2.2:

    - George uses speech input. When content markup includes a
    checkbox without a specified label, the user agent detects that
    a static text component is positioned immediately to the right
    of the checkbox and no other static text components are nearby.
    The nearby text is treated as the label. This enables George to
    toggle the checkbox by speaking its name.

    - Maria uses a screen reader. When a table lacks marked up
    header rows, the user agent gives her the option to have the
    first row treated as the table header row.

    - Li uses a scanning keyboard and makes use of the user agent's
    outline view to more efficiently navigate web pages. The
    content markup (in English) includes instances of static text
    that differ from surrounding text due to (a) being sentence
    fragments and (b) being styled with a larger font, bold weight
    and additional spacing. The instances are treated as headings
    as therefore appear in the...

    scribe: outline view, enabling Li to more efficiently navigate
    to them.

    Resolved: All accept examples (above) for 1.2.2

    Related Resources for Success Criterion 1.2.2:

    - Understanding WCAG 2.0: Heading and Labels:
    [16]http://www.w3.org/TR/2012/NOTE-UNDERSTANDING-WCAG20-2012010
    3/navigation-mechanisms-descriptive.html

      [16] 
http://www.w3.org/TR/2012/NOTE-UNDERSTANDING-WCAG20-20120103/navigation-mechanisms-descriptive.html

    Resolved: All accept related resource (above) for 1.2.2

Structure" (Jan)

    <jeanne> close action-725

    <trackbot> ACTION-725 Write IER for the new "1.2.2 Repair
    Missing Structure" closed

    JA: Jaime still working on it, so will have it next week.

2.1.9 appears to overlap with 2.3.5 [2.3.5 looks better] Jim

    [17]http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0
    033.html

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

    <Greg> 2.1.9 is better with modifier keys, but worse with
    "help" and lacking saving. And vice versa.

    <jeanne> +1 to progress not perfection

    <Greg> (If F1 can't be remapped then almost anything could be
    considered reserved.)

    <Greg> I think the 2.3.5 was supposed to replace 2.1.9, but the
    confusion stems from the fact that "author supplied...and user
    interface controls" is ambiguous as to whether it means user
    supplied UI controls or UA supplied UI controls. We could
    clarify by changing "user interface controls" to "user agent
    user interface controls" and then delete 2.1.9.

    <Greg> We can either incorporate the sentence about modifier
    keys from 2.1.9 or leave it out.

    <Greg> 2.3.5 Customize Keyboard Commands: The user can override
    any keyboard shortcut including recognized author supplied
    shortcuts (e.g. accesskeys) and user agent user interface
    controls, except for conventional bindings for the operating
    environment (e.g. arrow keys for navigating within menus). The
    user must be able to save these settings beyond the current
    session. (Level AA)

    <Greg> Do we want to add back in "The rebinding options must
    include single-key and key-plus-modifier keys if available in
    the operating environment." ?

    KP: Better if that extra text in

    JR: Agreed

    KP: One handed keyboard is already in as examples in 2.3.5

    <Greg> 2.3.5 Customize Keyboard Commands: The user can override
    any keyboard shortcut including recognized author supplied
    shortcuts (e.g. accesskeys) and user agent user interface
    controls, except for conventional bindings for the operating
    environment (e.g. arrow keys for navigating within menus). The
    rebinding options must include single-key and key-plus-modifier
    keys if available in the...

    <Greg> ...operating environment. The user must be able to save
    these settings beyond the current session. (Level AA)

    brb

    <Greg> Resolved: Delete 2.1.9 and modify 2.3.5 with wording
    immediately above.

    <kford> Action kford look at IER from 2.3.5 and 2.1.9 and
    ensure the new 2.3.5 covers what was important from the now
    deleted 2.1.9

    <trackbot> Created ACTION-750 - Look at IER from 2.3.5 and
    2.1.9 and ensure the new 2.3.5 covers what was important from
    the now deleted 2.1.9 [on Kelly Ford - due 2012-08-09].

Name, Role, State Proposal Action-649, Action-651

    <jeanne>
    [18]http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0
    030.html

      [18] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0030.html

    <kford> From Jim's mail:

    <kford> close items related to 4.1.2 Name, Role, State, Value,
    Description:

    <kford> leave SC and Intent as is because:

    <kford> --if we genericize terms no one will know what we are
    talking about.

    <kford> --we have added the descriptions of Name, Role, State,
    etc. in the Intent, so the terms could be used with other
    technologies...

    <kford> Name (component name)

    <kford> Role (purpose, such as alert, button, checkbox, etc)
    State (current status, such as busy, disabled, hidden, etc)
    Value (information associated with the component such as, the
    data in a text box, the position number of a slider, the date
    in a calendar

    <kford> widget)

    <kford> Description (user instructions about the component).

    <kford> remove example 1 "A browser is developing a
    component..." it is incomplete and need lots more work. Jeanne
    says it lame.

    <jeanne> Resolved: Close action 649 and 651 without change
    except to delete example 1

    <jeanne> close action-649

    <trackbot> ACTION-649 Rewrite in modern terms (genericize)
    4.1.2 with greg closed

    <jeanne> close action-651

    <trackbot> ACTION-651 Combine 412 and 416, with Mark closed

    <jeanne> REsolved: the group agrees to publish a new working
    draft.

Summary of Action Items

    [End of minutes]

-- 
_______________________________
Jeanne Spellman
W3C Web Accessibility Initiative
jeanne@w3.org
Received on Thursday, 2 August 2012 18:49:01 UTC

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