- From: Kelly Ford <Kelly.Ford@microsoft.com>
- Date: Thu, 12 Jan 2012 19:34:30 +0000
- To: "''UAWG list' (w3c-wai-ua@w3.org)'" <w3c-wai-ua@w3.org>
- Message-ID: <FDD93DBB2C16D643AABC1A7111D149F32E435BCB@TK5EX14MBXW601.wingroup.windeploy.ntde>
[Description: W3C]<http://www.w3.org/> - DRAFT - User Agent Accessibility Guidelines Working Group Teleconference 12 Jan 2012 See also: IRC log<http://www.w3.org/2012/01/12-ua-irc> Attendees Present Kelly, Jan, Greg, Simon, Mark, Wayne, Jeanne, Simon, Kim Regrets Jim Chair Kelly_Ford Scribe wayne Contents * Topics<http://www.w3.org/2012/01/12-ua-minutes.html#agenda> * call on Friday<http://www.w3.org/2012/01/12-ua-minutes.html#item01> * Still needs writing from Jim - http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JanMar/0011.html<http://www.w3.org/2012/01/12-ua-minutes.html#item02> * Keyboard definition<http://www.w3.org/2012/01/12-ua-minutes.html#item03> * review proposals<http://www.w3.org/2012/01/12-ua-minutes.html#item04> * Summary of Action Items<http://www.w3.org/2012/01/12-ua-minutes.html#ActionSummary> ________________________________ <trackbot> Date: 12 January 2012 <kford> http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0077.html <jeanne> aaaa is really Wayne <kford> Scribe: wayne call on Friday Item Scheduling Longer Calls: Jeanne: Meeting 1-3pm EDT <jeanne> attending <Greg> attending wayne - not there <sharper> SH: not attending <mhakkinen> attending 1-2, 3-4 Still needs writing from Jim - http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JanMar/0011.html <kford> kford, Jim sent a list of what still needs writing. Agenda 4 has a liink to those items. Keyboard definition Item: Keyboard means device independent equivalent <Jan> ...as external keyboards that may be connected). Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces." <kford> kford: want to close down on our definition of keyboard. Greg: Use keyboard interface or Keyboard or Keyboard emulator Jan - Described Keyboard Interface as descrbed above, ATAG Glossary <KimPatch> The Modality Independence Principal <KimPatch> Users interacting with a web browser may do so using one or more input methods including keyboard, mouse, speech, touch, and gesture. It's critical that each user be free to use whatever input method or combination of methods works best for a given situation. Therefore every potential user interaction must be accessible via modality independent controls that any input technology can access. <KimPatch> For instance, if a user can't use or doesn't have access to a mouse, but can use and access a keyboard, the keyboard can call a modality independent control to activate an OnMouseOver event. <sharper> these are keyboard scan codes Wayne = Character interface might be more apropriate <jeanne> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111227/#intro-modality-independence Kim - modality independent control... perhaps here Greg - later in agenda: another guideline on other input devices to address modality independence <Greg> http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0077.html <kford> ACTION: JS to update UAAG glossary with ATAG definition of keyboard interface [recorded in http://www.w3.org/2012/01/12-ua-minutes.html#action01] <trackbot> Created ACTION-702 - Update UAAG glossary with ATAG definition of keyboard interface [on Jeanne F Spellman - due 2012-01-19]. Kelly: Editorial replace key board with keyboard interface.. try that plan <kford> ACTION: KFord and others to review document for keyboard term and ensure it can be modified slightly to say keyboard interface and match with glossary definition. [recorded in http://www.w3.org/2012/01/12-ua-minutes.html#action02] <trackbot> Created ACTION-703 - And others to review document for keyboard term and ensure it can be modified slightly to say keyboard interface and match with glossary definition. [on Kelly Ford - due 2012-01-19]. <Zakim> Jan, you wanted to suggest "Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can <kford> qZAKIM, CLOSE ITEM 2 review proposals <kford> GL's proposal http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0077.html <mhakkinen> dropping off the call, will stay on IRC GL Proposal: Kim: On screen keyboard, and trackball -- Cannot enter text with trackbal ... is this accessible Jan - device turn into keyboard commands Jan - have a new part of partial connformance <Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2012JanMar/0001.html <Jan> "Statement of Partial ATAG 2.0 Conformance - Platform Limitation (Level A, AA, or AAA) <Jan> This conformance option may be selected when an authoring tool is unable to meet one or more success criteria because of intrinsic limitations of the platform (e.g., lacking a platform accessibility service). The (optional) explanation of conformance claim results should explain what platform features are missing." A monochrom cannot adjust color <Greg> Looks good Local phone keyboard that lack navigation Greg responting to Kim: If a phone has a nophysical interface, but if you can plug in an emulator then it would work. Should we expect an emulator for the user agend and not the system? Kelly: Partial conformance issues. Not a full user agent, but this is how much I can do. Jan: You must have accessible interface, but your platform omits some possibility. Kelly: The app does not handle the shortcommings of the platform Jan: A stripped down browser that is as accessible as the kiosk? can handle. Kelly: Do we need another success criteria for this. <Jan> ACTION: JR to propose a type of partial conformance for mobile apps that are actually packaged user agents that display limited types of content [recorded in http://www.w3.org/2012/01/12-ua-minutes.html#action03] <trackbot> Created ACTION-704 - Propose a type of partial conformance for mobile apps that are actually packaged user agents that display limited types of content [on Jan Richards - due 2012-01-19]. <Greg> Possible guideline about non-keyboard input devices: <Greg> http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0077.html Kim - For voice input it is easy to say the word. Are cases where speech users is keyboard emulater. Greg - initially did not require textual navigational (key letter etc.) Greg - navigation has for modes, but not textual. Kim - Reverse mouse. Most people think of one input isn't needed but others need it. <Greg> We currently have four of the five basic navigation mechanisms: direct, sequential, search, and structural, but we do not address textual (e.g. typing first characters of an item's text to navigate to it). Jan - the sc are different for level analysis. Jan - Say what we want to say about what will be an accessible UA. Greg: Do you mean remove conditionality? Jan: A browser that met UAWG on a fully accessible platform then is is accessible, but it it is not on inferior devices then it is it is conditionally accessible on the inferior device. Greg: The reason the conditional is present is to require actions for device options that are not present. q1 Jan - Confomance rides over the document.. Seems to be as easy. Jan - Is is worth an SC set for non=keyboard devices Jan- Should not make every User Agend recognize speech because a microphone is present. <Greg> 1st issue: is it worth putting in any SC about making functions available through non-keyboard devices? <Greg> 2nd issue: should we remove the if clauses of these. <Greg> 3rd issue: ensure that we don't require every UA to add speech recognition just because the system has a microphone. Kelly - Would Greg take a second stab. <kford> GL and JR to talk and come back with updates on these proposals. <Greg> Wayne: SC 1.11.1 and 2.5.3 and 2.5.5 overlap because they all deal with outlines. <Greg> 1.11.1 Access Relationships: The user can access explicitly-defined relationships based on the user's position in content (e.g. show form control's label, show label's form control, show a cell's table headers). (Level A) <Greg> 2.5.3 Location in Hierarchy: The user can view the path of nodes leading from the root of any content hierarchy in which the structure and semantics are implied by presentation, as opposed to an explicit logical structure with defined semantics (such as the HTML5 Canvas Element), or as a consequence of decentralized-extensibility (such as the HTML5 item / itemprop microdata elements), and... <Greg> ...only if the user agent keeps an internal model of the hierarchy that it does not expose via the DOM or some other accessibility mechanism. (Level A) . <Greg> 2.5.5 Access to Relationships which Aid Navigation: The user can access explicitly-defined relationships based on the user's position in content, and the path of nodes leading from the root of any content hierarchy to that position. (Level AA) <sharper> 1.11.2 got moved or changed or some such Summary of Action Items [NEW] ACTION: JR to propose a type of partial conformance for mobile apps that are actually packaged user agents that display limited types of content [recorded in http://www.w3.org/2012/01/12-ua-minutes.html#action03] [NEW] ACTION: JS to update UAAG glossary with ATAG definition of keyboard interface [recorded in http://www.w3.org/2012/01/12-ua-minutes.html#action01] [NEW] ACTION: KFord and others to review document for keyboard term and ensure it can be modified slightly to say keyboard interface and match with glossary definition. [recorded in http://www.w3.org/2012/01/12-ua-minutes.html#action02]
Attachments
- image/png attachment: image001.png
Received on Thursday, 12 January 2012 20:45:22 UTC