- From: Kelly Ford <Kelly.Ford@microsoft.com>
- Date: Thu, 19 Jul 2012 18:32:54 +0000
- To: "''UAWG list' (w3c-wai-ua@w3.org)'" <w3c-wai-ua@w3.org>
- Message-ID: <FDD93DBB2C16D643AABC1A7111D149F32EECA494@TK5EX14MBXW603.wingroup.windeploy.ntde>
[Description: W3C]<http://www.w3.org/> - DRAFT - User Agent Accessibility Guidelines Working Group Teleconference 19 Jul 2012 See also: IRC log<http://www.w3.org/2012/07/19-ua-irc> Attendees Present kford, Greg_Lowney, Jan, Jeanne Regrets Jim, Simon, Mark Chair Kelly_Ford Scribe Greg Contents * Topics<http://www.w3.org/2012/07/19-ua-minutes.html#agenda> * Jan Proposal 4.1.1 - Active mail thread starting at http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0013.html<http://www.w3.org/2012/07/19-ua-minutes.html#item01> * Summary of Action Items<http://www.w3.org/2012/07/19-ua-minutes.html#ActionSummary> ________________________________ <trackbot> Date: 19 July 2012 <kford> Kim, Greg) Jan Proposal 4.1.1 - Active mail thread starting at http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0013.html <kford> Group agrees that GKL's update on 4.1.1 is in general good. JS to update the doc. <kford> ACTION: JS update doc with newest 4.1.1 from today's meeting minutes. [recorded in http://www.w3.org/2012/07/19-ua-minutes.html#action01] <trackbot> Created ACTION-742 - Update doc with newest 4.1.1 from today's meeting minutes. [on Jeanne F Spellman - due 2012-07-26]. 4.1.1 Platform Accessibility Services: The user agent supports relevant platform accessibility services. (Level A) *Intent of Success Criteria 4.1.1:* The intent of this success criterion is to make user agent user interfaces more accessible to users who rely on assistive technologies, such as screen readers and speech recognition software. Most major operating environments provide platform accessibility services that allow applications (including user agents) and assistive technologies to work together more effectively, but these must... scribe: be supported by the software on both sides. The requirement is stated generally because the specifics of what constitutes a platform accessibility service will differ on each platform, but basic features common to these services are addressed by other success criteria under Guideline 4.1. 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; some of these are addressed in other success criteria. However, platform accessibility services are particularly important because they provide common functionality across all the well-behaved applications running on the platform,... scribe: reducing the amount of special-casing the assistive technology has to implement for each of the hundreds of applications it may need to support. Most web-based user agents will support this requirement automatically because they run inside host user agents, and the host is responsible for exposing all content, including nested user agents, via platform accessibility services. As long as the nested user agent's user interface is entirely web-based and complies with Web Content Accessibility Guidelines (e.g. providing alternative... scribe: text and supporting WAI-ARIA where needed) the host will understand it well enough to provide a bridge between it and platform accessibility services. *Examples of Success Criterion 4.1.1:* * A browser is developing a new type of button bar for their Microsoft Windows product. When coding the new component the developer includes support for the Microsoft Active Accessibility API (MSAA) so that assistive technologies can recognize it as representing a toolbar, and can identify, navigate, and activate the bar and its buttons on the user's behalf. *Related Resources for Success Criterion 4.1.1: * * See 4.1.2 (Name, Role, State, Value, Description) and 4.1.6 (Expose Accessible Properties) for specific information that should be exposed through platform accessibility services. * Microsoft Active Accessibility (MSAA) http://msdn.microsoft.com/en-us/library/ms971310.aspx * Microsoft UI Automation http://msdn.microsoft.com/en-us/library/ms747327.aspx * Gnome Accessibility Toolkit/Assistive Technology Service Provider Interface (ATK/AT-SPI) at http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atk/at-spi * Accessibility Programming Guidelines for Mac https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Accessibility/ * Accessibility Programming Guide for iOS https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/iPhoneAccessibility/ * Iaccessible2 http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2, http://www-03.ibm.com/able/open_computing/open_source_windows.html * Accessibility API Cross reference http://www.mozilla.org/access/platform-apis.html <Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JulSep/0017.html <Jan> ACTION: JR to Look at cleaning up glossary terms "serial access, sequential navigation" and linear navigation commands [recorded in http://www.w3.org/2012/07/19-ua-minutes.html#action02] <trackbot> Created ACTION-743 - Look at cleaning up glossary terms "serial access, sequential navigation" and linear navigation commands [on Jan Richards - due 2012-07-26]. We might want to modify the SC to say that auto-redirect pages should be skipped when navigating "back". Greg and Jan discuss how to rephrase this SC to make it clear that it's about navigation between URIs (either typed into an address bar or specified by links) rather than about navigation with the tab key and the like. Perhaps something like "The user can return to a previous URI and the navigational state associated with it using a back button or its equivalent." <Jan> previously resolved web content address? <Jan> previously resolved URI? <Jan> GL: Provide back button or equivalent functionality. Explain all the nuances in a note? <Jan> JR: Provide back button functionality. (and then define back button functionality) Does any UA not restore state when returning to a previous page? Perhaps say when returning to a URI the UA should restore scrolling position, selection, and focus, and any data or control states that the user has entered on the page. <Jan> reverse navigation functionality (e.g. "back button") <Jan> Provide reverse navigation functionality (e.g. "back button") <Jan> Provide reverse navigation functionality (e.g. "back button") navigate based on the list of previously viewed pages <Jan> I'll try to send something better to the list...maybe using concept of navigation history <Jan> Note: Submission can be triggered by server side processing (e.g. via submit button) and by client-side processing (e.g. via an onkeypress event). <Jan> 3.2.X Text Entry Undo: The user can reverse recognized text entry actions prior to submission. (Level A) Note: Submission can be triggered by server side processing (e.g. via submit button) and by client-side processing (e.g. via an onkeypress event). Submission can be triggered in many different ways, such as clicking a submit button, typing a key in a control with an onkeypress event, or by a script responding to a timer. <Jan> trying to get back in <Jan> Resolved: All agree to "3.2.X Text Entry Undo: The user can reverse recognized text entry actions prior to submission. (Level A) Note: Submission can be triggered in many different ways, such as clicking a submit button, typing a key in a control with an onkeypress event, or by a script responding to a timer." For Jan's proposed 3.2.Y I suggest a minor edit, changing "the user can require user confirmation" to something like "the user can specify that the user agent require confirmation" 3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can require user confirmation to proceed. (Level A) 3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can have the user agent request confirmation before proceeding. (Level A) <Jan> Resolved: All agree to "3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can have the user agent request confirmation before proceeding. (Level A)" <jeanne> ACTION: jeanne to update document for 3.2.X and 3.2.Y based on the "resolved" in the minutes above. [recorded in http://www.w3.org/2012/07/19-ua-minutes.html#action03] <trackbot> Created ACTION-744 - Update document for 3.2.X and 3.2.Y based on the "resolved" in the minutes above. [on Jeanne F Spellman - due 2012-07-26]. Summary of Action Items [NEW] ACTION: jeanne to update document for 3.2.X and 3.2.Y based on the "resolved" in the minutes above. [recorded in http://www.w3.org/2012/07/19-ua-minutes.html#action03] [NEW] ACTION: JR to Look at cleaning up glossary terms "serial access, sequential navigation" and linear navigation commands [recorded in http://www.w3.org/2012/07/19-ua-minutes.html#action02] [NEW] ACTION: JS update doc with newest 4.1.1 from today's meeting minutes. [recorded in http://www.w3.org/2012/07/19-ua-minutes.html#action01] [End of minutes]
Attachments
- image/png attachment: image001.png
Received on Thursday, 19 July 2012 18:33:46 UTC