Minutes: Joint UAWG PFWG call on Oct 6, 2011

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