User Agent Accessibility Guidelines Working Group Teleconference -- 06 Oct 2011

<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

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

06 Oct 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output