- From: Jeanne Spellman <jeanne@w3.org>
- Date: Thu, 23 Sep 2010 14:37:34 -0400
- 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