- 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