See also: IRC log
<trackbot> Date: 27 March 2014
<scribe> Scribe: Jan
<jeanne> comments document: http://www.w3.org/WAI/UA/2014/LCcomments.html
<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.
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.
<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].
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.
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
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].
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 0.98) Found Scribe: Jan Inferring ScribeNick: Jan Default Present: Jim_Allan, Greg_Lowney, Jeanne, Jan, Kim_Patch, Kelly_Ford Present: Jim_Allan Greg_Lowney Jeanne Jan Kim_Patch Kelly_Ford Regrets: Eric WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 27 Mar 2014 Guessing minutes URL: http://www.w3.org/2014/03/27-ua-minutes.html People with action items: jeanne WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]