See also: IRC log
<trackbot> Date: 26 August 2010
<oedipus> agenda adendum request: UAAG Review of PF Keyboard Access Requirements (http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements)
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements
<oedipus> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0058.html
<oedipus> Requirement 1: A device independent means to activate an access command.
<oedipus> Requirement 2: Ability for an author to define a default access command mapping, and for a user to override the default mapping.
<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.
<oedipus> Requirement 4: Ability for an author to provide a description for an access command assignment.
<oedipus> Requirement 5: Ability to specify the target elements that will respond to an access command, based on their id reference.
<oedipus> Requirement 6: Ability to specify target elements in terms of their role, or implied ARIA semantics for the role if not overridden by ARIA.
<oedipus> Requirement 7: Ability to specify a custom order for cycling through multiple objects attached to a single access command.
<oedipus> Requirement 8: As long as the document is loaded in the browser, user agents must be able to return the user to their previous place in the navigation sequence.
<oedipus> Requirement 9: Access command mappings should be available at the beginning of the document.
<oedipus> proposed first draft of "Access Element: Enabling Generic Document Accessibility" http://lists.w3.org/Archives/Public/www-archive/2010May/att-0020/access-element-20100519.html
<inserted> SCRIBENICK: Greg
Gregory posted a list of 9 requirements that PF has gathered for HTML5 keyboard access features.
Before these are taken to accessibility task force, they want to ensure that UA's more recent work is reflected in the requirements.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements
Kim asks if UA's "direct access to any element" should be included; Gregory thinks item 5 would cover that.
Originally HTML5 had no accesskey or tabindex, so PF asked them to consider use of the access module, which was rejected.
A new proposal has too much complexity, such as author defined pseudo-cascade of access keys without any guidance on how to handle the cascade.
Gregory offered to serve as a conduit to the HTML accessibility task force.
Jim points out that UA work applies to both UA UI and content, whereas currently the list is only addressing content.
<AllanJ> gl: the lines between the UI and content interfaces get blurry
Greg points out that there is no clear distinction between content and UI anymore, as they're often implemented by the same code.
Gregory would like to treat them the same, but the HTML5 working group may not approve of that approach.
<oedipus> thanks, y'all
<oedipus> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0058.html
<oedipus> http://www.w3.org/2002/09/wbs/36791/20100802-2/results
<oedipus> 3.6.1 configure text
<oedipus> for 3.6.1 i intended to propose: "In order to better suit individual visual needs, some users will need to increase the size of the text, change the font in which the text is rendered and/or change the background-and-foreground color combinations in order to make the text usable by that user."
Here's the existing draft wording:
3.6.1 Configure Text: The user can globally set the following characteristics of visually rendered text content, overriding any specified by the author or user agent defaults (Level A):
* (a) text scale (i.e., the general size of text) ,
* (b) font family, and
* (c) text color (i.e., foreground and background).
* Intent of Success Criterion 3.6.1:
There are many types of low vision, with different needs for font size, font resolution, and color contrast. Some users want to reduce the font size to decrease the need to scroll the content.
* Examples of Success Criterion 3.6.1:
o Lee has low vision from albinism and has difficulty with screen resolution and brightness. She changes all text to 16 pt Palatino font, with white text on a black background. The serif Palatino font has character spacing that resolves better for her vision. The white on black reduces glare.
<AllanJ> ACTION: jallan to word smith http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq6 for 3.6.1 [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action01]
<trackbot> Created ACTION-433 - Word smith http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq6 for 3.6.1 [on Jim Allan - due 2010-09-02].
<oedipus> 3.6.2. Preserve Distinctions
General agreement on the proposed change adding to Intent: ", and because some content may be authored in a way that would make it difficult or impossible to understand when if font distinctions were hidden."
<oedipus> plus 1 to proposed change
<oedipus> 3.6.2. Preserve Distinctions
<jeanne> ACTION: jeanne to update document for 3.6.2 with the edits from Greg in results of http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq7 [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action02]
<trackbot> Created ACTION-434 - Update document for 3.6.2 with the edits from Greg in results of http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq7 [on Jeanne Spellman - due 2010-09-02].
Current draft wording:
3.6.3 Option Range: The range of options for each text characteristic includes at least (Level A):
* (a) the range offered by global preference settings supported by the operating environment (i.e configured though the Control Panel or System) utility, or
* (b) if no such utility is available, the range supported by the conventional APIs of the operating environment for drawing text.
* Intent of Success Criterion 3.6.3:
Users need to be able to access the full range of text characteristics that the operating system supports. The full range may be determined by the operating environment (as determined by the settings). If platform does not provide a range of text characteristics in the control panel, then whatever text characteristics are supported by drawing programs for that operating environment,...
scribe: must be made available to the user.
* Examples of Success Criterion 3.6.3:
o Browser A supports only 3 font sizes: Small, Medium, and Large. Lee, who has low vision, needs to use a font size of 16 pt, which is between the medium and large sizes. Browser A provides an option to override the 3 font sizes with the operating system font range, so that Lee can select the 16 pt font size she needs.
<oedipus> 3.6.3. Option Range
<oedipus> http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq8
Jan points out the SC is about range (min to max), but the example is about number of increments, which is a separate issue.
<oedipus> GL: most graphical OSes DON'T have limited set of font sizes they support - no difficulty in UA UI interface offering small or large
(That is, *don't* have a limited set of font sizes they support.)
Thus there is no technical difficulty for UA to offer an extremely wide range of options for font size.
<oedipus> fine tune control (by increment) - relative control (max min and preset increments) ?
Jim: The SC doesn't provide any specific requirements for size range, other than what the platform supports.
Jeanne: knows of no research on minimum range requirements.
We need to decide if it sufficient to require a range, without addressing increments within that range.
<oedipus> GL: jan pointed out that example discusses increments - haven't heard anyone formally say put in an SC for this
<oedipus> fine tune control (by increment) - relative control (max min and preset increments) ?
Is it acceptable for UA to offer only very small and very large, for example, without anything in between?
<oedipus> user control (enter point size) fine tune control (increase by supported increments) relative control (max, min, preset increments)
Consensus seems to be that it would be unacceptable to have, for example, just Tiny, Normal, and Huge.
<oedipus> user control (enter point size) fine tune control (increase by supported increments) relative control (max, min, preset increments)
<oedipus> user control (user decides precisely what setting), fine tune control (increase or decrease by supported increments), relative control (gross manipulation: max to min, preset increments)
If we only change the Intent and Examples, but leave the SC as is, then the normative requirements would still be met with very minimal, unfriendly options (such as just Tiny, Normal, Huge). It sounds like we want to redo the SC.
<oedipus> ACTION: Gregory - propose SC and intent for 3.6.3 based on WBS survey and feedback to list [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action03]
<trackbot> Created ACTION-435 - - propose SC and intent for 3.6.3 based on WBS survey and feedback to list [on Gregory Rosmaita - due 2010-09-02].
<oedipus> 3.1.4. Rendering Alternateive (Enhanced) Intent
<oedipus> GL: looks like mostly editorial; although felt that intent restated SC instead of explaining user benefit;
<AllanJ> 3.1.4 Rendering Alternative (Enhanced): Provide the user with the global option to configure a cascade of types of alternatives to render by default, in case a preferred type is unavailable. If the alternative content has a different height or width, then the user agent will reflow the viewport. (Level AA) * Intent of Success Criterion 3.1.4: For a give piece of non-text content...
<AllanJ> ...the author may have provide one or several alternatives. For example, an image may have different versions based on resolution, ‘alt text’ (@alt) or a link to a long description (@longdesc). A video may have bandwidth alternatives, caption files in different languages, audio descriptions in different languages. There may be others. The user is able to choose which item(s) to render by...
<AllanJ> ...default, and specify the order of the cascade of alternatives to be rendered if the author did not provide a type of alternative. * Examples of Success Criterion 3.1.4: o Mary has a learning disability. She finds looking at images on a webpage very distracting. Mary would like to see all images rendered in the following order. First, for images with long descriptions have...
<AllanJ> ...the long description rendered in place of the image. If the long description does not exit, she wants the ‘alt text’ to be rendered. If neither is available, Mary wants the file name rendered. Added functionality would allow Mary to right click (context menu) on an image to list and select the rendering of the available alternatives (thumbnail, original size, full screen,...
<AllanJ> ...low...
<oedipus> GL: for given piece of content -- example says "user" - doesn't express to user what is required/constitutes success
<AllanJ> ...resolution, high resolution, alt text, long description, file name) o @@ Editors' Note: where do we put the ability for the user to individually pick an image and have the image displayed. It should not have to be an all or nothing. o Juan is hard of hearing. He wants to always see video on the page. Also, Juan would like the Spanish language track used if available,...
<AllanJ> ...along with Spanish captions as a default. If these are not available, he wants to see the video with English audio and captions. If no captions are available Juan wants the the video and English audio. Added functionality would allow Juan to right click (context menu) on an video to list and select the rendering of the available alternatives (still image, caption languages,...
<AllanJ> ...audio languages, audio-description languages)
<oedipus> GL: intent misses point; intent should be written in 2 parts
<oedipus> GL: should state why users with disabilities need and not describe functionality
I think the Intent should be rewritten to start with and emphasize why users with disabilities need this functionality, which is mostly obscured by the current text.
<oedipus> GL: when X happens, is a problem, here is how to get around it; users often need to do Y in order to accomplish task Z
<oedipus> GL: problem is this, here is solution
<oedipus> GL: intent paragraph good information, just not presented correctly
<AllanJ> ACTION: jallan rewrite 3.1.4 based on comments http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq9 and comments here [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action04]
<trackbot> Created ACTION-436 - Rewrite 3.1.4 based on comments http://www.w3.org/2002/09/wbs/36791/20100802-2/results#xq9 and comments here [on Jim Allan - due 2010-09-02].
The rest of my comments were purely editorial/wordsmithing.
<oedipus> General 3.11. Intent
<oedipus> JA: take intent of 3.11.1 and merge with GL 3.11 and say that is good for all and add examples for specific SC?
<oedipus> GL: do we need to repeat stuff for every SC? do you need to read 3.11 in order to understand 3.11.1 -- could just be a simple link back to GL
<oedipus> GL: each intent start with or end with "see GL x.x for a general introduction to mechanisms"
The Intent of each SC in 3.11 could start or end with a sentence such as "See the Intent for Guideline 3.11 for an introduction to the concept of focus mechanisms and their importance."
<oedipus> plus 1 to Greg's suggestion
<oedipus> JA: need something new, or move part to intent of GL?
That is, factor out all the common Intent material that applies to every SC in 3.11, move that into the Intent for Guideline 3.11, and for the Intent for 3.11.1 just put a very narrow discussion of what makes this SC different from the others in this section.
<inserted> scribenick: oedipus
JS: could link to 3.11.1 in resources -- keep 3.11 as overall intro and then have 3.11.x link to 3.11
GL: no intent for GL, but only SC?
JS: want intents for all GLs
<inserted> scribenick: Greg
Jeanne we should have Intent paragraphs for all or none of the Guidelines, but be consistent.
<inserted> scribenick: oedipus
GL: as long as referenced,
doesn't matter where it is, info needs to be linked;
... 3.11.1 talks about things that aren't part of 3.11 --
cursors aren't part of req for 3.11 -- content focus may or may
not have visual indicator (cursor)
... 3.11.1 says need at least 1 kind of focus
JA: doesn't say has to be visible
GL: need to review all focus definitions -- are they complete?
KP: should be in there
JA: "need to find HREFs and fix
them" -- all defs of cursors, and similar appear before that
anchor; don't talk about content focus
... no "content focus" in list
KP: content focus is keyboard focus
GL: whether content pane or menu, takes focus; at other times does not; focus in dialog box ontop of a menu, active focus on menu; close menu, inactive focus on menu
JS: explainatory chart at
beginning of focus section
... input focus and keyboard focus most common; also pointer
focus
... sometimes want to specify active or inactive focus
GL: maybe need a new focus section?
JS: should be "at least 1 keyboard focus "
GL: haven't normalized all of the defined terms
JA: operationally, this is the outline around an active element in viewport that is keyboard focused/active focused; talking specifically about enabled elements -- if have page with enabled elements, focus must be provided so user knows what can act upon
GL: has to be concept if there
are elements that can take kbd input, UA has to know which
element receives event if key invoked
... does imply "focus being on something" like first input
field
<AllanJ> ACTION: jeanne change in 3.11.1 'content focus' to 'keyboard focus' [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action05]
<trackbot> Created ACTION-437 - Change in 3.11.1 'content focus' to 'keyboard focus' [on Jeanne Spellman - due 2010-09-02].
JA: def of "point of regard" is "AT-focus" -- AT keeps track of where one is going, but doesn't necessarily show on screen; keyboard focus, UA has to know which actionable item will receive action or input
GL: was "keyboard focus in content"
KP: we changed all these -- what happened to that version?
JS: 23 August 2010 draft
KP: focus defs all correct in 2010-08-23 draft
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100823.html
<AllanJ> http://www.w3.org/WAI/UA/2010/ED-IMPLEMENTING-UAAG20-20100823/
KP: made other edits requested by GL
trackbot, close action-437
<trackbot> ACTION-437 Change in 3.11.1 'content focus' to 'keyboard focus' closed
action-437: OBE (reviewing wrong draft - fixes in 2010-08-23 draft)
<trackbot> ACTION-437 Change in 3.11.1 'content focus' to 'keyboard focus' notes added
<Greg> I’ll write an example for 3.11.1 that talks through what happens when the UA displays a Web page for the first time. That is, focus is on the document as a whole so pressing Space scrolls, pressing tab move to the first focusable element, etc.
<AllanJ> ACTION: GregL to create another intent example for 3.11.1 that talks through what happens when the UA displays a Web page for the first time. That is, focus is on the document as a whole so pressing Space scrolls, pressing tab move to the first focusable element, etc. [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action06]
<trackbot> Sorry, couldn't find user - GregL
<AllanJ> ACTION: Greg to create another intent example for 3.11.1 that talks through what happens when the UA displays a Web page for the first time. That is, focus is on the document as a whole so pressing Space scrolls, pressing tab move to the first focusable element, etc. [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action07]
<trackbot> Created ACTION-438 - Create another intent example for 3.11.1 that talks through what happens when the UA displays a Web page for the first time. That is, focus is on the document as a whole so pressing Space scrolls, pressing tab move to the first focusable element, etc. [on Greg Lowney - due 2010-09-02].
http://www.w3.org/2002/09/wbs/36791/20100802-3/results
<Greg> Current wording:
<Greg> 2.1.1 Platform Accessibility Architecture: Support an platform accessibility architecture relevant to the operating environment. (Level A)
<Greg> * Intent of Success Criterion 2.1.1:
<Greg> Computers, including many smart phones, have accessibility features built into the operating system. Some well-known APIs for the Windows operating system are: MSAA, iAccessible2, UIAutomation, [more]. Where ever technically possible, support the existing accessibility APIs.
<Greg> * Examples of Success Criterion 2.1.1 :
<Greg> o Browser A is developing a new user interface button bar for their Microsoft Windows product. The developer codes a call to the MSAA API for the functionality.
proposal 2.1 1. http://www.w3.org/2002/09/wbs/36791/20100802-3/results#xq1
-> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html#guide-AT-access 2.1.1. Platform Accessibility Architecture
note: IA2 is IAccessible2, not iAccessible2
ATK/AT-SPI (accessible toolkit/assistive technology service provider interface) should be mentioned http://a11y.org/atspi
<Greg> "Assistive technologies often use a combination of methods to get information about, and manipulate, a user agent's user interface and the content it's rendering. These methods include DOMs, accessibility APIs such as MSAA or JAA, general-purpose platform APIs such as those used to determine a window's title, application-specific APIs that are typically a last resort when an application does...
<Greg> ...not make all information available through the former means, and hard-coded heuristics. It is the user agent's responsibility to make the necessary information and facilities available through the appropriate corresponding means. Platform accessibility API is particularly important because it provides common functionality across all (or at least all well behaved) applications running on...
<Greg> ...the platform, reducing the amount of special-casing the assistive technology has to implement for each of the hundreds of applications it supports..."
<AllanJ> AX-API accessibility API for Mac
IA2 dev in harmony with AT-SPI dev
sounds good
-> http://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/a11y-dom-apis.html Accessibility and DOM API Comparisons
<AllanJ> ACTION: jeanne to replace intent of 2.1.1. to include Assistive technologies often use a combination of methods to get information about, and manipulate, a user agent's user interface and the content it's rendering. These methods include DOMs, accessibility APIs such as MSAA or JAA, general-purpose platform APIs such as those used to determine a window's title, application-specific APIs that... [recorded in http://www.w3.org/2010/08/26-ua-minutes.html#action08]
<trackbot> Created ACTION-439 - Replace intent of 2.1.1. to include Assistive technologies often use a combination of methods to get information about, and manipulate, a user agent's user interface and the content it's rendering. These methods include DOMs, accessibility APIs such as MSAA or JAA, general-purpose platform APIs such as those used to determine a window's title, application-specific APIs that... [on Jeanne Spellman - due 2010-09-02].
<AllanJ> ...are typically a last resort when an application does... ...not make all information available through the former means, and hard-coded heuristics. It is the user agent's responsibility to make the necessary information and facilities available through the appropriate corresponding means. Platform accessibility API is particularly important because it provides common functionality across...
<AllanJ> ...all (or at least all well behaved) applications running on... ...the platform, reducing the amount of special-casing the assistive technology has to implement for each of the hundreds of applications it supports
http://www.w3.org/2002/09/wbs/36791/20100802-3/results#xq2
<Greg> Current wording:
<Greg> 2.1.2 Name, Role, State, Value, Description: For all user interface components including the user interface, rendered content, generated content, and alternative content, make available the name, role, state, value, and description via an platform accessibility architecture. (Level A)
<Greg> * Intent of Success Criterion 2.1.2:
<Greg> The information that assistive technology requires is the
<Greg> o Name (component name)
<Greg> o Role (purpose, such as alert, button, checkbox, etc)
<Greg> o State (current status, such as busy, disabled, hidden, etc)
<Greg> o 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 widget)
<Greg> o Description (user instructions about the component).
<Greg> For every component developed for the user agent, pass this information to the appropriate accessibility platform architecture or application program interface (API). Embedded user agents, like media players can pass Name, Role, State, Value and Description via the WAI-ARIA techniques.
-> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html#guide-AT-access 2.1.2 Name, Role, State, Value, Description
GL: suggested minor rewrite of paragraph
<Greg> 1. I suggest rewriting the intent as:
<Greg> Some assistive technology (such as speech recognition or macro utiliies) interacts with software on the user's behalf, and some (such as screen readers) need to conveys information about it to the user. To do this effectively, it needs the following information about each component of the user agent user interface or rendered content:
<Greg> * Name (the brief name by which the user or documentation would refer to the component, e.g. for a button labeled "OK" the name would be "OK".)
<Greg> * Role (the type of component in a generic sense, such as button, checkbox, alert, heading, etc.)
<Greg> * State (whether the component is disabled, hidden, busy, etc.)
<Greg> * Value (information associated with the component such as the data in a text box, the position number of a slider, or the date in a calendar widget)
<Greg> * Description (user instructions about the component)."
sounds good
markuu's comment on 2.1.2 "change: Name (accessible name or label for the component) -- Rationale: simply stating "component name" might lead one to think SysGridView32 may be a valid component name."
plus 1
<Greg> No objections to the proposed rewrite of Intent.
GL: description should be taken out of required list due to ambiguity of what means for diff standards -- non-existent in some
<Greg> In my Intent rewrite I merely copied the previous definition of Description, but my 2nd and 3rd comments are about how that's actually problematic.
http://www.w3.org/WAI/PF/aria/roles#Properties
<Greg> If the definition of Description as user instructions is from ARIA, and we require it, does that mean every element needs to be marked up with user instructions?
5.2.7.2. Description Computation An accessible description may be computed by concatenating the text alternatives for nodes pointed to by an aria-describedby attribute on the current node.
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) Succeeded: s/have limited/DON'T have limited/ Succeeded: s/invokeed/invoked/ Succeeded: s/action-437 OBE (reviewing wrong draft - fixes in 2010-08-23 draft)// Succeeded: i/Gregory posted a list of 9/SCRIBENICK: Greg Succeeded: i/GL: as long as referenced/scribenick: oedipus Succeeded: i/JS: could link to 3.11.1 in resources/scribenick: oedipus Succeeded: i/Jeanne we should have Intent/scribenick: Greg Found ScribeNick: Greg Found ScribeNick: oedipus Found ScribeNick: Greg Found ScribeNick: oedipus Inferring Scribes: Greg, oedipus Scribes: Greg, oedipus ScribeNicks: Greg, oedipus Default Present: AllanJ, Jan, Jeanne, Greg, Gregory_Rosmaita, +1.617.325.aaaa, Kim Present: AllanJ Greg Gregory_Rosmaita Jan Jeanne Kim Regrets: MarkkuH KFord PLauke Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0052.html Found Date: 26 Aug 2010 Guessing minutes URL: http://www.w3.org/2010/08/26-ua-minutes.html People with action items: greg gregl gregory jallan jeanne WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]