17:12:22 RRSAgent has joined #ua 17:12:22 logging to http://www.w3.org/2015/05/28-ua-irc 17:12:24 RRSAgent, make logs public 17:12:24 Zakim has joined #ua 17:12:26 Zakim, this will be WAI_UAWG 17:12:26 ok, trackbot; I see WAI_UAWG()1:00PM scheduled to start 12 minutes ago 17:12:27 Meeting: User Agent Accessibility Guidelines Working Group Teleconference 17:12:27 Date: 28 May 2015 17:12:37 Kim has joined #ua 17:12:45 rrsagent, make logs public 17:12:51 Agenda+ GL4 proposal based on last weeks meeting 17:12:52 Agenda+ 1.7 rewrite 17:12:54 agenda+ Cynthia comments 17:13:01 open item 1 17:13:23 topic: GL 4 proposal 17:13:25 https://lists.w3.org/Archives/Public/w3c-wai-ua/2015AprJun/0046.html 17:16:40 no change to 4.1.1, 4.1.3, 4.1.5 17:23:20 topic: 4.1.2 17:24:30 gl: remove bullet change state/value notification because it is mentioned in the body of the SC 17:24:50 js: but they might miss it if not in the list 17:26:14 gl: concerned about "relationships" should (aria) be an example 17:26:45 js: make it specific to aria. as greg says 'relationships' is very broad 17:29:18 gl: if we make specific then if they don't do aria then they don't have to do anything? 17:29:35 ja: is covered in 1.10.1 17:30:38 1.10.1 requires that explicitly defined relationships (e.g. that image A labels button B) are made available directly to the user, but Guideline 4 fails to require the same information be made available to assistive technology (e.g. screen readers). That seems like a major oversight. 17:32:09 ja: keep relationships broad use (e.g. ARIA) and reference 1.10.1 17:32:24 We could add a bullet to 4.1.2 that said "Relationships per 1.10.1 "Show Related Elements". 17:33:11 Related, should 1.10.1 also mention ARIA explicitly? 17:35:26 We should attempt to keep the wording consistent, e.g. if we add relationships to 4.1.2 we should say "explicitly-defined relationships in content", the phrase we use in 1.10.1. 17:35:35 ja: cross reference 1.10.1 and 4.1.2 17:46:53 Discussing whether 4.1.2 should have a bullet for "ARIA relationships" or the broader "Explicitly-defined relationships (e.g. ARIA)". The latter is closer to 1.10.1. Or, should it be "Explicitly-defined relationships in content (e.g. ARIA)", omitting UA UI? 17:47:01 Kim has joined #ua 17:47:40 In each of the latter two cases, the phrase "Explicitly defined relationships" is taken from 1.10.1. 17:47:45 ja: +1 to Explicitly-defined relationships (e.g. ARIA) 17:49:01 js: concern about broadness, trying to think of use cases 17:49:41 proposal: 17:49:51 Explicitly defined relationships (e.g. ARIA relationships [ARIA 1.0]) 17:50:53 4.1.2 Expose Basic Properties: For all user interface components (including UA user interface, rendered content, and generated content) the user agent makes available the following properties and any change notifications via a platform accessibility service: (Level A) 17:50:55 Name 17:50:56 Role 17:50:58 State 17:50:59 Value 17:51:01 Selection 17:51:02 Focus 17:51:04 Bounding dimensions and coordinates 17:51:05 Font family of text 17:51:07 Font size of text 17:51:08 Foreground and background color for text 17:51:10 Highlighting 17:51:12 Keyboard commands 17:51:13 Explicitly defined relationships (e.g. ARIA relationships [ARIA 1.0]) 17:51:15 Caret position 17:51:16 @@cross reference 1.10.1 and 4.1.2 17:54:48 RESOLUTION: Accept 4.1.2 as above. 17:57:23 topic: 4.1.4 revised 17:57:50 proposal: 17:58:34 4.1.4 DOMs Programmatically Available as fallback: 17:58:35 If the user agent does not implement one or more platform accessibility services, then Document Object Models (DOM), must be made programmatically available to assistive technologies. (Level A) 17:58:57 RESOLUTION: delete 4.1.6 (merged with 4.1.2) 17:59:31 gl: not thrilled 18:01:18 I'm concerned because Mike Hill of Dolphin indicated that some applications implement platform API but so badly that the AT must fall back on DOM access. Similarly, Doug Geoffray of AI Squared indicated that for a range of user agents they need to rely on the DOM to pick up individual details that the applications omits or exposes incorrectly through the platform API. 18:02:06 In those cases, if we say that the browser making any token use of the platform API then need not provide DOM access for filling in the gaps, the SC accomplishes very little. 18:09:27 s/Mike Hill of Dolphin/one screen reader developer/ 18:10:16 s/Doug Geoffray of AI Squared/a second screen reader developer/ 18:11:29 I am unclear on how Microsoft Edge will prevent extensions from accessing the DOM and bridging the information to external AT. Perhaps that's only because they will not have Chrome extensions supported in their first release? 18:12:42 Kim has joined #ua 18:13:55 4.1.4 Make content programmatically Available: The user agent makes all content programmatically available to the assistive technology, either through implementation of a platform accessibility API or, if not available, by exposing the DOM. 18:14:22 Keep in mind that the SC as it stands does not requires a UA to implement a DOM, or implement it where it's not already implemented for their own needs. It only says that where they implement one, it should be available to AT for taking advantage of it. 18:16:01 js: seems that browsers are getting rid of the DOM, old technology. 18:16:31 gl: but that would break all of JavaScript 18:23:46 js: is writing contacts asking about dom vs api, how javascript works with out dom 18:27:20 My takeaways from last week's call with Rich and Doug was that the DOM will have an increasing number of holes (e.g. webapps that draw directly into a grid element, and also the use of injected or generated content, all of which won't be reflected in the DOM). Thus, AT should not rely entirely on the DOM. However, it does not mean that DOM access cannot help the AT fill in gaps. Similarly,... 18:27:22 ...DOM access may be superseded by new API that is more effective and complete for automated testing (e.g. WebDriver). If that's the case, perhaps what we should be requiring is not that UA should expose the DOM to AT but that it should expose *ALL* API that it already supports that provides access to the content (including but not limited to the DOM). 18:27:54 whatwg is working on DOM https://dom.spec.whatwg.org/ 18:28:32 s/that provides/that provide/ 18:30:46 http://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/a11y-dom-apis.html 18:34:59 ja: table this for now. revisit 4.1.4 next week with new information. 18:35:06 rrsagent, make minutes 18:35:06 I have made the request to generate http://www.w3.org/2015/05/28-ua-minutes.html allanj 18:37:15 zakim, please part 18:37:15 Zakim has left #ua 18:37:21 rrsagent, make minutes 18:37:21 I have made the request to generate http://www.w3.org/2015/05/28-ua-minutes.html allanj 18:38:03 Present: Jim, Jeanne, Greg, Kim 18:38:12 Chair: jimallan 18:38:15 rrsagent, make minutes 18:38:15 I have made the request to generate http://www.w3.org/2015/05/28-ua-minutes.html allanj