16:47:17 RRSAgent has joined #ua 16:47:17 logging to http://www.w3.org/2015/05/21-ua-irc 16:47:19 RRSAgent, make logs public 16:47:20 Zakim has joined #ua 16:47:21 Zakim, this will be WAI_UAWG 16:47:21 ok, trackbot; I see WAI_UAWG()1:00PM scheduled to start in 13 minutes 16:47:22 Meeting: User Agent Accessibility Guidelines Working Group Teleconference 16:47:22 Date: 21 May 2015 17:01:33 chair: JimAllan 17:02:59 WAI_UAWG()1:00PM has now started 17:03:06 +Kim_Patch 17:03:46 Happy Global Accessibility Awareness Day 17:03:48 Agenda+ remove 4.1.4 17:03:49 Agenda+ 1.7 rewrite 17:03:51 agenda+ Cynthia comments 17:04:37 -Kim_Patch 17:04:38 WAI_UAWG()1:00PM has ended 17:04:38 Attendees were Kim_Patch 17:05:00 https://mit.webex.com/mit/j.php?MTID=mfab9fc3e2da645fd813b885234375ecf 17:05:25 WAI_UAWG()1:00PM has now started 17:05:33 +Greg_Lowney 17:08:14 Greg has joined #ua 17:08:39 -Greg_Lowney 17:08:40 WAI_UAWG()1:00PM has ended 17:08:40 Attendees were Greg_Lowney 17:11:08 scribe: allanj 17:11:55 Rich S. from IBM will join the call at 1 pm Central Time 17:18:10 discussion of voice input accessibility 17:20:12 limited tools. none focused on accessibility. 17:21:32 present+ jeanne 17:21:34 Greg has joined #ua 17:21:37 Kim has joined #ua 17:21:41 rrsagent, set logs public 17:21:42 present+ Jim, Greg, Kim 17:25:07 topic: DOM Access 4.1.4 17:25:55 kp: know of users who use OLD technology because their access works better for the information they need. 17:26:08 The Accessibility API for Internet Explorer is implemented using MSAA and UIA. 17:26:10 The Accessibility API for Firefox is implemented using MSAA and IAccessible2. 17:26:11 The Accessibility API for Chrome is implemented using MSAA and IAccessible2. 17:33:05 zakim, agenda?\ 17:33:05 I see 3 items remaining on the agenda: 17:33:06 1. remove 4.1.4 [from allanj] 17:33:06 2. 1.7 rewrite [from allanj] 17:33:06 3. Cynthia comments [from allanj] 17:35:12 Topic: 1.7 stylesheets 17:35:26 Change Stylesheet to “styles” (this is what Stylish uses as a term for stylesheets) 17:35:48 1.7.3 Disable Author Styles: 17:35:49 If the user agent supports a mechanism for author styling rendered content, the user can disable the author styles on the current page. (Level A) 17:35:51 @@ this seems the lowest level of control. Turn off the author stylesheet and use the default browser styles 17:36:11 1.7.1 Support User Style Modification Mechanism: 17:36:12 If the user agent supports a mechanism for author styles, the user agent also provides a mechanism for a user to override author styling on specified elements. (Level A) 17:36:14 @@then the user can look at modifying the existing user styles. Added “on specified elements” seemed that overriding could be viewed as simply turning off the styles. Wanted it to be more. 17:36:34 1.7.2 Apply User Styles: 17:36:35 If a mechanism for user styles is supported, then the user can enable or disable user styles for: (Level A) 17:36:37 • All pages on specified websites, or 17:36:38 • @@All pages @@this should be removed. Or marked AAA. Cannot find any implementation 17:36:52 1.7.4 Save Copies of Styling Profile: 17:36:54 The user can save copies of the user styles referenced by the current page. This allows the user to edit and load the copies on other devices. (Level AA) 17:39:10 gl: reviewed 1.7. the wording is accurate - according to the DEF in the glossary. because we REDEFINE "stylesheets" (which is a specific technical term) to be very broad 17:40:48 http://w3c.github.io/UAAG/UAAG20/#s 17:41:34 gl: we need an * to indicate that we have different than normal/typical definition 17:46:41 gl: comment was stylesheets are too complicated for end users. We need say that there is some extension to expose the stylesheet to the user and modifiable by some party. 17:46:41 Last week we were concerned that stylesheets meant CSS, not including other mechanism, and thus wasn't sufficiently technology neutral. However, if one follows the chain of glossary entries, it turns out to be sufficiently broad. It's just that reading the SC alone gives the misleading impression that it's not. 17:47:17 Re Cynthia's actual concern that style sheets are too complex for end users, we already addressed this somewhat in the glossary entry: "user style sheet: Style sheets that are not provided by the web content author. The user interface for configuring user style sheets can be targeted at advanced users." 17:50:08 http://w3c.github.io/UAAG/UAAG20/#gl-style-sheets-config 17:52:39 http://w3c.github.io/UAAG/UAAG20/#gl-style-sheets-config 17:53:36 https://www.w3.org/WAI/UA/work/wiki/Comments_%26_Responses_30_April_2015 17:55:00 comment: User Style Sheets should not be required to be exposed to the USER. It is fine to expose this to developers (both web at AT), but it’s not a workable solution for any but the most technical users, who would be able to access it via a developer path anyway. (relates to 1.7). Change to developer, or remove, or make AAA. 17:58:38 topic: DOM Access 17:59:49 gl: reviews APIs used by browsers 18:00:16 Doug Geoffrey from GW Micro joined the call 18:00:43 richardschwerdtfeger has joined #ua 18:02:57 Rich S. from IBM joined the call 18:03:08 Rich: Not everything is mapped to the accessibility API 18:03:16 ... this is more for older browsers 18:03:16 need access to accessibility API for other things 18:03:39 ... need a11y info for the content including styling and javascript for web pages. 18:03:54 need to provide access to styling and javascript to provide accessibility information. 18:03:58 DOM can't be used for CSS content injection (text & images, including alt) 18:04:13 ... you don't get a full implementation in older browsers 18:04:41 where you don't have good implementation of the accessiblity api, need access to the DOM 18:04:41 ... I think where you don't have a full implementation of the accessibilityAPIs, you will need access to the DOM 18:04:53 ... it will get to the point where you can't rely on the DOM. 18:05:20 ... Look at Edge, Chrome, Safari (Webkit), the only way to get at the information is the AccessibilityAPI. 18:05:50 ... You have to give access to both the AccessibilityAPI and the DOM. 18:05:55 eventually DOM will not longer be available. Must have Accessibility API. 18:06:00 Jeff: Only if they did it right 18:06:32 Rich: IE only maps half of what you need to UIA. You have to go to the DOM for the rest 18:06:52 ... That will change in MS, that is where they are going 18:07:23 ... for content injection, flexbox in CSS (which changes the order on screen that doesn't match the DOM) 18:08:18 ja: what do we write as an SC so they get the Accessiblty API right 18:08:57 Rich: Getting it right means a lot of different things. I think you need to say that you need programmatic access to all the available content. Multiple techniques can satisfy this: DOM, AccessibilityAPIs, -- the issue is to know when to look at the API and when to look at the DOM. 18:09:13 ... it may be an either/or, but you have to provide full access. 18:09:35 ja: or have both 18:09:50 Greg: We required DOM access because of the holes in AccessibilityAPI. 18:10:09 ... because we were trying to find a way to get it right. 18:10:31 ... if the DOM access is poor or the AAPI access is poor, this would fill a hole. 18:10:57 ... are we on the right track? Or should we just say how they should do it? 18:11:51 use dom as fallback 18:11:58 Rich: IF there is a normative mapping (which we have now [lists the mappings]) to the AAPIs, then those things that map should be done. Then the DOM should just be a fallback 18:12:54 Doug: We can get to the content editable from IE directly. TOday's IE is provided, but not through MSAA or UIA. 18:13:23 Rich: 508 Refresh says a mechanism for defining interoperability. You could use that 18:13:38 508 refresh - if you use an API it must meet the following criteria...you could use that 18:13:43 Doug: What do you do to find the heuristics if the page is not tagged directly. 18:14:01 Rich: All the user agents have error correction built in. 18:14:08 s/directly/correctly 18:14:55 Doug: Example of an edit box that is not tagged. We say "editbox" but we have no label. Visually it is obvious, but it is not coming through the AAPI mapping. 18:15:11 ... there is a ton of failed pages, and how do we correct that? 18:16:13 Rich: If you say that -- we are talking about accuracy -- you can do heuristics to say that it labels the field. You should be able to do that from the AAPI. If they don't, they have a bug. 18:17:05 ... we can't rely on the DOM in the future. Browser companies want to create web components. They could have a tag, say, Grid, that will never appear in the DOM and can only be accessed from the AAPIs. 18:18:10 ... authors less and less want to use HTML and more want to use Web Components. The browsers want features added to ARIA to allow more flexibility to authors. 18:18:36 ... it's the only way we can accurately get that. User agents need to conform to those specifications. 18:19:12 ... I would take the requirements in the 508 Refresh as a starting point. 18:19:51 Doug: it all makes sense, but my fear is that they have to do it right. If they don't, then the blind user loses, and they think screenreaders are at fault 18:20:16 Rich: Uses the DOM as a fallback, won't work in the future. 18:20:41 Doug: There is a ton of legacy garbage that has to be supported in the future. 18:21:12 Rich: We have built internal tools that walk the DOM and test for accessibility information. 18:21:37 ... we can't detect if someone has injected and image without alternative text. So how do we test this? 18:22:16 ... it doesn't guaranty that it works. 18:23:17 ... IT11 isn't going to make any more accessibility enhancements. The gov is only on IE. It is not clear when or if gov will move to Edge. 18:24:24 Jim: The other issue is "just in time" accessibility, because it is a performance hit. There are a lot of tools that don't make an AAPI call. 18:25:00 Rich: I had to modify a internal tool to add an AAPI call so that the tool would work. 18:25:25 ... I am thinking about a media call to tell the provider to load the ARIA code. 18:25:27 ja: perhaps a user setting to turn on AAPI 18:25:47 ja: on the platform or the UA? 18:26:03 Rich: We would have to put the features in the @@ 18:26:27 Doug: There is a documented API call to the OS that says "I'm an AT". 18:26:43 Greg: Is there a way that the browser can expose it to web content. 18:27:57 section 508 - 502 Interoperability with Assistive Technology 18:28:05 Rich: lead with an AAPI, where there is no AAPI, there must be a programmatic way to get to the content. FOr accuracy, this API that you are exposing must have the following features: Then look at the 508 refresh. 18:29:01 Rich: We have API mapping for all the HTML features. 18:29:14 http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/proposed-rule/text-of-the-proposed-rule 18:29:20 Doug: the spec is good, but the implementation? THey have to resolve the mistakes quicker. 18:29:49 http://www.w3.org/TR/html-aapi/ 18:30:19 Rich: We are creating test suites for HTML and writing Web DRiver extensions to see if the mapping passes. 18:30:32 ... WE can hand those test suites to the browsers for execution 18:30:46 http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=http%3A%2F%2Fwww.w3.org%2FTR%2Fsvg-aam-1.0%2F&ei=SCReVfXiF421oQSnroCAAw&usg=AFQjCNFNSKmLMXvkVNeBDZXaXer6JUw2ew&bvm=bv.93990622,d.cGU 18:30:53 ... if there are test cases we are missing, we can write it and add it to the bucker. 18:30:57 http://www.w3.org/TR/svg-aam-1.0/ 18:31:07 s/bucker/bucket 18:31:57 http://www.w3.org/TR/core-aam-1.1/ 18:32:15 http://www.w3.org/TR/accname-aam-1.1/ 18:33:12 Doing it right, may requiring normative reference to these mapping questions 18:35:21 richardschwerdtfeger has joined #ua 18:35:32 gl: if DOM is going away what happens to extensions. will they go away also. 18:37:13 kp: there is so much that doesn't work. it will only get worse. 18:37:20 That is, if the DOM is increasingly presenting an incomplete mapping of the content, browser extensions will be less effective at modifying, driving, or otherwise interacting with content. Will extensions be relegated to affecting the UA UI but not the content? This would be a huge setback for accessibility. 18:37:39 js: its what we have to live with. 18:41:11 ja: we have no SC that say you must have an extension mechanism 18:42:11 rrsagent, make minutes 18:42:11 I have made the request to generate http://www.w3.org/2015/05/21-ua-minutes.html allanj 18:43:03 Browser extensions allow for new accessibility features beyond those required by UAAG. For a (non-embedded) browser to not support extensions would be a huge step backwards for accessibility. The same is true if those extensions can no longer access and modify the full document content. 18:44:35 rrsagent, make minutes 18:44:35 I have made the request to generate http://www.w3.org/2015/05/21-ua-minutes.html allanj 19:18:49 zakim, please part 19:18:49 Zakim has left #ua 19:18:55 rrsagent, make minutes 19:18:55 I have made the request to generate http://www.w3.org/2015/05/21-ua-minutes.html allanj 19:19:16 rrsagent, please part 19:19:16 I see no action items