See also: IRC log
<trackbot> Date: 23 September 2010
<kford> rrs agent, make minutes
<kford> Scribe: Greg
<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> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements
<oedipus> 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: 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: http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements#what_is_broken_with_accesskey_in_HTML5.3F
<oedipus> 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: http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0106.html
<oedipus> actual proposal: 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 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: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0103.html
<oedipus> 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> 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> http://www.w3.org/WAI/UA/tracker/actions/447
<oedipus> action-447: email proposal 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> 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> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements
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 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 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 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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Greg Inferring ScribeNick: Greg Default Present: kford, Greg, Jim_Allan, sharper, Jeanne, Gregory_Rosmaita, +1.617.435.aaaa, +1.617.435.aabb, +1.617.435.aacc Present: Greg Gregory_Rosmaita Jeanne Jim_Allan kford sharper Kim Regrets: Jan Found Date: 23 Sep 2010 Guessing minutes URL: http://www.w3.org/2010/09/23-ua-minutes.html People with action items: - bugs email event gregory handler jeanne proposed[End of scribe.perl diagnostic output]