Minutes: User Agent Working Group Telecon 27 Mar 2014

Minutes:
http://www.w3.org/2014/03/27-ua-minutes.html

Full text:
User Agent Accessibility Guidelines Working Group Teleconference

27 Mar 2014

See also: IRC log

Attendees

Present
Jim_Allan, Greg_Lowney, Jeanne, Jan, Kim_Patch, Kelly_Ford
Regrets
Eric
Chair
SV_MEETING_CHAIR
Scribe
Jan
Contents

Topics
Web Applications Working Group Charter
CSUN recap
Finish Jan's OP06 comments
Proposal on 2.3.1
Proposal on 2.3.3
Summary of Action Items
<trackbot> Date: 27 March 2014
<scribe> Scribe: Jan
<jeanne> comments document: http://www.w3.org/WAI/UA/2014/LCcomments.html
Web Applications Working Group Charter

<jeanne> http://www.w3.org/2014/03/webapps-charter.html
JS: UA has been identified as a dependency
... We have a week to look at it. Pls send comments directly to Jeanne not to the UA list.
... They have a huge list of deliverables

http://www.w3.org/2014/03/webapps-charter.html#deliverables

GL: Wow!

JS: In 2 years...
... I think we are interested in custom elements

GL: I lot of these I would need to read more...one sentence is not enough

JS: Key thing here is "The WebApps WG will actively seek security, privacy, internationalisation and accessibility review on all its specifications."
... We just need to approve charter

KP: What are the main things that excite/scare you about this?

GL: Scare...shadow DOM....
... Will ATs be impacted?
... Full screen API has implications for onscreen keyboards
... Pointer lock.... allows restriction of where the mouse can go... may impact onscreen keyboards, magnifiers
... I can see possible impacts for half of these

KP: Anything good for accessibility?

GL: Anything with events...
... Anything helping user interaction

KP: How does IndieUI fit in?

JS: Originally WebApps was going to be joint group with PF.
... But they pulled out

GL: I suspect problem if IndieUI not developed with input from WebApps group

JS: Maybe we should note lack of mention of IndieUI

JA: Membership...anyone we know?

<Greg> Restricting pointer actions and full-screen apps could affect accessibility aids such as on-screen keyboards.
JS: Chaals

<Greg> Events and DOM partitioning could affect AT that hooks into the DOM for presenting info to the user, manipulating the document or its presentation for the user's benefit, or manipulates the document at the user's request.
JA: Ecmascript etc?

JS: It's external group they are interacting with

JA: All good stuff
... Pointer lock?

<Greg> "Pointer Lock: Defines APIs that provide scripted access to raw mouse movement data while locking the target of mouse events to a single element and removing the cursor from view." Obviously could be disastrous for some AT scenarios.
<jeanne> JR: HTML Editing should be coordinated with ATAG
<jeanne> JR: Emulation of GamePad
JR: Gamepad...would also need to be able to emulate

GL: We should create a little list of thoughts on this? Maybe on wiki

JS: I'm pretty psyched about the input they are expecting from us
... User Agent Accessibility Guidelines Working Group: To ensure that WebApps WG deliverables support accessibility requirements, particularly with regard to interoperability with assistive technologies, and inclusion in deliverables of guidance for implementing WebApps deliverables in ways that support accessibility requirements.

<KimPatch> https://www.w3.org/WAI/UA/work/wiki/index.php?title=Comments_on_Web_Applications_Working_Group_Charter&action=edit&redlink=1
JA: Anyone who reviews this, please put your comments into the wiki page

GL: How will liaising work?

JS: Not sure, I've never been an official liaison before.
... I know in PF, different people have different responsibilities to various outside groups
... Maybe better to establish relationships with Chaals or Art

JA: One would think they would ping us for firs public drafts etc

JS: Good question. Dependency vs liaison are different.

GL: If they have subgroups working on things, we should give them a list of relevant accessibility topics to think about

KP: I could put them in wiki

<jeanne> http://w3c.github.io/webcomponents/spec/custom/
<jeanne> JR: Use case of person in wheelchair with the tablet bolted to a particular orientation, needing to force all web apps to the needed orientation.
<KimPatch> https://www.w3.org/WAI/UA/work/wiki/Comments_on_Web_Applications_Working_Group_Charter#Categories_Related_to_UAAG
<jeanne> ACTION: jeanne to check what is expected for Liaison for Web Apps. [recorded in http://www.w3.org/2014/03/27-ua-minutes.html#action01]
<trackbot> Created ACTION-961 - Check what is expected for liaison for web apps. [on Jeanne F Spellman - due 2014-04-03].
CSUN recap

JA: Jeanne?

JS: Great conversations.

JA: I raised UAAG a few times
... Telling people to write bugs on browsers and checkput our GLs
... Also mentionned I was concerned about reliance on extensions...since browsers can change out from underneath extensions

JS: One idea is browsers developer's OWN extensions

GL: Good except there might also be 3rd party ones that are very good

JA: Are there paid extensions?

JS: I think so

JA: Anyone else at CSUN?
... Nope...
... Realized ARIA required is not same as HTML5 required.

Finish Jan's OP06 comments

http://www.w3.org/2014/03/13-ua-minutes.html

http://www.w3.org/2014/03/13-ua-minutes.html#item05

Last time, there was a resolution to Accept Jan's proposal for 1.9.1 with minor edits

KP: Clarifieds that Mouseless browsing does go to all enabled elements

Jan's email: http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0046.html

Proposal on 2.3.1

Internal draft http://www.w3.org/WAI/UA/UAAG20/

Maybe a note about virtual keyboards here: http://www.w3.org/WAI/UA/UAAG20/#def-keyboard-focus

"Keyboard emulators and interfaces may be used on devices which do not have a physical keyboard, such as mobile devices based on touchscreen input."

<Greg> I recommend we put note in UAAG 2.0 Conformance Applicability Notes.
>From http://www.w3.org/WAI/UA/UAAG20/#def-keyboard

http://www.w3.org/WAI/UA/UAAG20/#def-direct-command

GL: Should link "directly" to the definition http://www.w3.org/WAI/UA/UAAG20/#def-direct-command

Resolution: All agree to change 2.3.1 to say 2.3.1 Allow Direct Navigation to Enabled Elements: The user can move keyboard focus directly to any enabled elements in the rendered content. (Level AA)

<scribe> ACTION: Jeanne to Edit 2.3.1 Allow Direct Navigation to Enabled Elements: The user can move keyboard focus *directly* to any enabled elements in the rendered content. (Level AA) [recorded in http://www.w3.org/2014/03/27-ua-minutes.html#action02]
<trackbot> Created ACTION-962 - Edit 2.3.1 allow direct navigation to enabled elements: the user can move keyboard focus *directly* to any enabled elements in the rendered content. (level aa) [on Jeanne F Spellman - due 2014-04-03].
Proposal on 2.3.3

JR: Proposed 2.3.3 Allow Direct Activation of Enabled Elements: The user can perform an activation action on any enabled element in the rendered content. (Level A)

GL: Doesn't say ditrectly and doesn't say what manner

Original: 2.3.3 Allow Direct Activation of Enabled Elements: The user can move directly to and activate any enabled element in rendered content. (Level A)

GL: If I had to choose which is more important, I would say navigation is higher priority than activation

JR: Do we need the other?

KP: Yes we do

2.3.3 Allow Direct Activation of Enabled Elements: The user can perform a direct activation action on any enabled element in the rendered content. (Level A)

<Greg> Direct navigation can be used for many purposes, such as scrolling, changing where you search from, etc., and activating is generally only one more keystroke or equivalent once you've moved keyboard focus to an element. Thus direct nav higher priority than direct activation.
KP: Question...is activation without navigation going to mess people up?

<Greg> Kim: separating direct activation from direct navigation may be causing a problem...
<Greg> Jan: Then we *do* want a combined navigate and move?
<Greg> Kim: We want to make sure the two input methods do the same thing as people get mixed up if mouse and speech behave differently, especially subtle differences.
<Greg> Kim: Thus a combined activation and navigation is very useful.
2.3.3 Allow Direct Activation of Enabled Elements: The user can, in one step, move keyboard focus *directly* to any enabled elements and perform a direct activation action on any enabled element in the rendered content. (Level A)

<Greg> Kim: When click a link with the mouse then use back button, focus is on the link. If using direct activation on a link then use back button, focus is not on the link.
2.3.3 Allow Direct Activation of Enabled Elements: The user can, in one step, move keyboard focus *directly* to and perform a direct activation action on any enabled element in the rendered content. (Level A)

KP: see bove

<Greg> Jan: If Windows Phone has no keyboard focus concept, they could implement direct activation but not direct navigation, thus felt the latter should be lower priority.
<Greg> Greg: I'm willing to fail Windows Phone if it does not implement API for keyboard focus.
<Greg> Discussion of whether iOS and Windows Phone have keyboard focus, if for example iOS has the functionality only when VoiceOver is on.
Next call Apr 3

Summary of Action Items

[NEW] ACTION: jeanne to check what is expected for Liaison for Web Apps. [recorded in http://www.w3.org/2014/03/27-ua-minutes.html#action01]
[NEW] ACTION: Jeanne to Edit 2.3.1 Allow Direct Navigation to Enabled Elements: The user can move keyboard focus *directly* to any enabled elements in the rendered content. (Level AA) [recorded in http://www.w3.org/2014/03/27-ua-minutes.html#action02]





(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
OCAD UNIVERSITY

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca

Received on Thursday, 27 March 2014 18:37:31 UTC