- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 6 Oct 2011 13:48:25 -0500
- To: WAI-ua <w3c-wai-ua@w3.org>, w3c-wai-pf@w3.org
from: http://www.w3.org/2011/10/06-ua-minutes.html User Agent Accessibility Guidelines Working Group Teleconference 06 Oct 2011 See also: IRC log http://www.w3.org/2011/10/06-ua-irc Attendees Present kford, Jim_Allan, Janina, AlexQiangChen, Jeanne, Jan, Kim_Patch, +1.609.734.aabb, Mark, Rich_Schwerdtfeger, jcraig, Cynthia Regrets Chair Jim_Allan, Kelly_Ford Scribe jallan Contents Topics Summary of Action Items Summary of Action Items [NEW] ACTION: kford ensure UAAG has a current list of expected operating system accessibility conventions, e.g. high contrast. [recorded in http://www.w3.org/2011/10/06-ua-minutes.html#action01] <trackbot> Date: 06 October 2011 <kford> http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JulSep/0010.html <kford> Agenda update on 1.7.x + y <scribe> scribe: jallan Title: Joint UA & PF telecon all: introductions js: call is in relation to comment on ARIA spec rs: OS settings. how is UAWG picking up OS settings (color, high contrast) and enhancing the user experience kf: UAAG has several different guidelines. UA should respect and not interfer with OS settings rs: does UAAG list any kf: can list more. also add information in the IER (intent, examples, resources) for specific success criteria ... we want to give enough guidance, we will review and expand as necessary. rs: what about platform keyboard conventions (control-p) to print <Jan> 5.3.2 Implement Accessibility Features of platform js: we have those, should be respected <Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110922/ jc: how are we planning to expose. or are suggesting that they should be exposed. kf: in response to rs, UAAG responds and accepts standard operating keys ... are we passing the keys to the web app? jc: are we talking about comment 78. confused as to purpose of meeting. <jeanne> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110922/#sc-416 4.1.6 is the properties js: review issue 375 <jeanne> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110922/#sc-411 <- 4.1.1 Platform Accessibility Architecture <kford> ACTION: kford ensure UAAG has a current list of expected operating system accessibility conventions, e.g. high contrast. [recorded in http://www.w3.org/2011/10/06-ua-minutes.html#action01] <trackbot> Created ACTION-621 - Ensure UAAG has a current list of expected operating system accessibility conventions, e.g. high contrast. [on Kelly Ford - due 2011-10-13]. jc: proposal, User Agent User Interface Independence, extension to javascript <jeanne> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110922/#sc-532 <- 5.3.2 Implement Accessibility Features of platform: <janina> http://www.w3.org/WAI/PF/Group/track/issues/365 jc: verbosity settings, tab preferences, screen reader, etc ... anyone reviewed, will it work? all: silence <jcraig> http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html#identification <jcraig> window.navigator.accessibility.screenreader.active jc: extensions to navigator object ... specific example...full keyboard access ja: UAAG is high level, not technical jeanne: opposed to AT settings for privacy. want the user to control what they see. so if want mobile version, can get it cs: how to users feel about privacy issue...any data jc: user would be prompted to provide information. Users like option of opting out. kf: anecdotal evidence is total opposite...want to keep AT use private, majority in US jc: his data is from working groups. mh: in past have strong concerns about privacy jc: UA setting for sharing information on AT use kf: what is status of proposal js: Judy and others about to charter group (Intentional Events) jc: beginning of document explains the intention as abstract from physical action rs: Access4All confirms kf privacy concern. Not that they needed AT but had preference for specific changes to content jc: David Singer made a CSS proposal along similar veing <Zakim> jcraig, you wanted to discuss comment 78 rs: mac will know if user turns on voiceover, then UA will know and could communicate to author/content kf: we have morphed to different area. RS ... UA should be aware of xyz OS accessibility and implement <richardschwerdtfe> brb kf: this is a new area. kp: UAAG talks alot about keyboard control and clashes (settings and preferences), this may be useful jeanne: what do we need to add to support ARIA in UAAG. kf: UAWG can review proposal http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html ... and comment <richardschwerdtfe> back kf: are there other things we may be missing? rs: as long as you map to a11y layer, should be ok ... keyboard access. on a mobile device may not have keyboard. what needs to be added ... needs to be something in UAAG about non-keyboard access. jc: on whatever platform, the chrome and view must be accessible. ... file bugs on given platforms, rs: example. webpage that is keyboard accessible, how does it make accessible via gesture kf: level of detail in UAAG today, in the mobile scenario, allow the user to navigate to all navigable and focusable elements. would be a Success Criteria. then expand in the intent ... any user can navigate and operate a webpage without a keyboard (using gesture0 jr: not only gesture, may be keypad (phone), voice based, etc. rs: want to spec higher level events arrows (up, down, previous, next) kf: this is totally needed, rs: need something that talks to the higher level functions (alternate input solutions) to generate events based on input method kf: current UAAG, should we define this, or wait for the intent proposal to do it, ... we are concerned with end user functionality. jc: agree...wait. let intent group spec these. kf: actionable items...review UAAG for mobile, PF could review UAAG to see if anything is missing, new working draft with call outs for these discussed issues jc: comment 78, issue 365 on aria, commenter wants to override everything and it should work ... slider could control style, and keyboard action and it still work ... html5 slider, author can control look and feel, uesr can override, it will work ... but some aria control...it won't work kf: out of scope of UAAG. jc: UAAG should have overrides for CSS kf: yes CSS and keyboard mapping ... and keyboard controls. ... more than that would be difficult if not impossible. ... comment 78, point to UAAG, it should be covered ... are there other issues? janina: concerned about device access, multiple sound cards (usb, etc), use one to dedicate for screen reader...does UA need to know what the OS is doing. ... some audio to headset, some to audio card x, others to y kf: this sounds like an OS issue. ... on windows. Screen readers and magnifier allow multiple audio output. <mhakkinen> +q janina: if screen reader is pointing to device 2, the UA should honor it. jc: this is an OS issue. it should control where audio is going. Mac has this functionality. js: voip, bigger issue, direct phone to one device, media to different device kf: screen readers are asking which device gets the sound (default and alternates . . speakers, headphones, etc) ... UA could have a setting to say where to play audio. js: different streams to different devices is fine, but to restrict and block all other streams for each device mh: GL 1.6 don't we do this already. js: honor OS settings for volume? kf: yes we have that js: at some time it becomes an accessibility preference. kf: some setting, never play x on device y. the UA should respect that. we cover that. cs: which things should be covered by UA and which by AT. should be more on the AT. jc: are you asking for AT cs: want requirements for AT to be more standards compliant. rs: how to monitor that? AT merging on mobile kf: UAAG has tried to separate AT. in some cases AT has done things that should be in base UA ... authors need to have expectations that user will have an accessible experience <mhakkinen> -q <Zakim> jcraig, you wanted to discuss that AT standardization could limit interface differentiation js: where do we draw the line. eg. support for multilingual documents, parse document and preload languages for quick switching jc: perhaps a list that AT should support. AT should support ARIA, canvas, etc. but stay away from user interface issues, keyboard definitions cs: go through UAAG, when user agent is mentioned determine UA or AT or combo. kf: we have worked hard. UA mean UA not AT. cs: can we user 'browser', UA is broad. kf: working on comprehensive definition of UA (wcag, etc) jeanne: for previous drafts, we eliminated AT from UAAG, but have gotten some push back due to defs kf: discussion of language switching jc: auto-switches voice by @lang on iOS, but user can override that voice if the web page specifies the language incorrectly kf: works in windows (auto lang switching) janina: switching an issue in Orca <richardschwerdtfe> I have to drop folks <richardschwerdtfe> over time cs: what does AT do. kf: it is not UAAG job to tell AT what to do. That should be a different document. js: lang is part of html, what should AT do to support it properly? what is properly? rrsagent: make minutes [End of minutes] -- Jim Allan, Accessibility Coordinator & Webmaster Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 6 October 2011 18:49:04 UTC