- From: Jeanne Spellman <jeanne@w3.org>
- Date: Thu, 02 Aug 2012 14:48:58 -0400
- 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