See also: IRC log
<trackbot> Date: 06 October 2011
<kford> Agenda update on 1.7.x + y
<scribe> scribe: jallan
Title: Joint UA & PF telecon
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
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].
<jeanne> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110922/#sc-532 <- 5.3.2 Implement Accessibility Features of platform:
jc: verbosity settings, tab
preferences, screen reader, etc
... anyone reviewed, will it work?
jc: extensions to navigator
... 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
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
... and comment
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
... 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
... 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
... some audio to headset, some to audio card x, others to y
kf: this sounds like an OS
... on windows. Screen readers and magnifier allow multiple audio output.
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
... authors need to have expectations that user will have an accessible experience
<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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/MAC/Mac/ Succeeded: s/acj c// Succeeded: s/ackc// Succeeded: s/works in IOS, can override lang tag/auto-switches voice by @lang on iOS, but user can override that voice if the web page specifies the language incorrectly/ Found Scribe: jallan Inferring ScribeNick: JAllan WARNING: No "Topic:" lines found. Default Present: kford, Jim_Allan, Janina, AlexQiangChen, Jeanne, Jan, Kim_Patch, +1.609.734.aabb, Mark, Rich_Schwerdtfeger, jcraig, Cynthia Present: kford Jim_Allan Janina AlexQiangChen Jeanne Jan Kim_Patch +1.609.734.aabb Mark Rich_Schwerdtfeger jcraig Cynthia Found Date: 06 Oct 2011 Guessing minutes URL: http://www.w3.org/2011/10/06-ua-minutes.html People with action items: kford WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]