Minutes: User Agent Telecon 21 May 2015

source:  http://www.w3.org/2015/05/21-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference 21 May 2015

See also: IRC log  http://www.w3.org/2015/05/21-ua-irc
<http://www.w3.org/2015/05/21-ua-irc>
Attendees
PresentGreg_Lowney, jeanne, Jim, Greg, KimRegretsChairJimAllanScribeallanj
Contents

   - Topics <http://www.w3.org/2015/05/21-ua-minutes.html#agenda>
      1. DOM Access 4.1.4
      <http://www.w3.org/2015/05/21-ua-minutes.html#item01>
      2. 1.7 stylesheets
      <http://www.w3.org/2015/05/21-ua-minutes.html#item02>
      3. DOM Access <http://www.w3.org/2015/05/21-ua-minutes.html#item03>
   - Summary of Action Items
   <http://www.w3.org/2015/05/21-ua-minutes.html#ActionSummary>

------------------------------

<trackbot> Date: 21 May 2015

Happy Global Accessibility Awareness Day

<jeanne>
https://mit.webex.com/mit/j.php?MTID=mfab9fc3e2da645fd813b885234375ecf

<scribe> scribe: allanj

Rich S. from IBM will join the call at 1 pm Central Time

discussion of voice input accessibility

limited tools. none focused on accessibility.
DOM Access 4.1.4

kp: know of users who use OLD technology because their access works better
for the information they need.

The Accessibility API for Internet Explorer is implemented using MSAA and
UIA.

The Accessibility API for Firefox is implemented using MSAA and
IAccessible2.

The Accessibility API for Chrome is implemented using MSAA and IAccessible2.
1.7 stylesheets

Change Stylesheet to “styles” (this is what Stylish uses as a term for
stylesheets)

1.7.3 Disable Author Styles:

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)

@@ this seems the lowest level of control. Turn off the author stylesheet
and use the default browser styles

1.7.1 Support User Style Modification Mechanism:

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)

@@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.

1.7.2 Apply User Styles:

If a mechanism for user styles is supported, then the user can enable or
disable user styles for: (Level A)

• All pages on specified websites, or

• @@All pages @@this should be removed. Or marked AAA. Cannot find any
implementation

1.7.4 Save Copies of Styling Profile:

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)

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

<jeanne> http://w3c.github.io/UAAG/UAAG20/#s

gl: we need an * to indicate that we have different than normal/typical
definition
... 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.

<Greg> 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.

<Greg> 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."

<jeanne> http://w3c.github.io/UAAG/UAAG20/#gl-style-sheets-config

<jeanne> http://w3c.github.io/UAAG/UAAG20/#gl-style-sheets-config

<jeanne>
https://www.w3.org/WAI/UA/work/wiki/Comments_%26_Responses_30_April_2015

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.
DOM Access

gl: reviews APIs used by browsers

Doug Geoffrey from GW Micro joined the call

Rich S. from IBM joined the call

<jeanne> Rich: Not everything is mapped to the accessibility API

<jeanne> ... this is more for older browsers

need access to accessibility API for other things

<jeanne> ... need a11y info for the content including styling and
javascript for web pages.

need to provide access to styling and javascript to provide accessibility
information.

<jeanne> DOM can't be used for CSS content injection (text & images,
including alt)

<jeanne> ... you don't get a full implementation in older browsers

where you don't have good implementation of the accessiblity api, need
access to the DOM

<jeanne> ... I think where you don't have a full implementation of the
accessibilityAPIs, you will need access to the DOM

<jeanne> ... it will get to the point where you can't rely on the DOM.

<jeanne> ... Look at Edge, Chrome, Safari (Webkit), the only way to get at
the information is the AccessibilityAPI.

<jeanne> ... You have to give access to both the AccessibilityAPI and the
DOM.

eventually DOM will not longer be available. Must have Accessibility API.

<jeanne> Jeff: Only if they did it right

<jeanne> Rich: IE only maps half of what you need to UIA. You have to go to
the DOM for the rest

<jeanne> ... That will change in MS, that is where they are going

<jeanne> ... for content injection, flexbox in CSS (which changes the order
on screen that doesn't match the DOM)

ja: what do we write as an SC so they get the Accessiblty API right

<jeanne> 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.

<jeanne> ... it may be an either/or, but you have to provide full access.

ja: or have both

<jeanne> Greg: We required DOM access because of the holes in
AccessibilityAPI.

<jeanne> ... because we were trying to find a way to get it right.

<jeanne> ... if the DOM access is poor or the AAPI access is poor, this
would fill a hole.

<jeanne> ... are we on the right track? Or should we just say how they
should do it?

use dom as fallback

<jeanne> 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

<jeanne> Doug: We can get to the content editable from IE directly. TOday's
IE is provided, but not through MSAA or UIA.

<jeanne> Rich: 508 Refresh says a mechanism for defining interoperability.
You could use that

508 refresh - if you use an API it must meet the following criteria...you
could use that

<jeanne> Doug: What do you do to find the heuristics if the page is not
tagged correctly.

<jeanne> Rich: All the user agents have error correction built in.

<jeanne> 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.

<jeanne> ... there is a ton of failed pages, and how do we correct that?

<jeanne> 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.

<jeanne> ... 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.

<jeanne> ... 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.

<jeanne> ... it's the only way we can accurately get that. User agents need
to conform to those specifications.

<jeanne> ... I would take the requirements in the 508 Refresh as a starting
point.

<jeanne> 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

<jeanne> Rich: Uses the DOM as a fallback, won't work in the future.

<jeanne> Doug: There is a ton of legacy garbage that has to be supported in
the future.

<jeanne> Rich: We have built internal tools that walk the DOM and test for
accessibility information.

<jeanne> ... we can't detect if someone has injected and image without
alternative text. So how do we test this?

<jeanne> ... it doesn't guaranty that it works.

<jeanne> ... 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.

<jeanne> 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.

<jeanne> Rich: I had to modify a internal tool to add an AAPI call so that
the tool would work.

<jeanne> ... I am thinking about a media call to tell the provider to load
the ARIA code.

ja: perhaps a user setting to turn on AAPI
... on the platform or the UA?

<jeanne> Rich: We would have to put the features in the @@

<jeanne> Doug: There is a documented API call to the OS that says "I'm an
AT".

<jeanne> Greg: Is there a way that the browser can expose it to web content.

section 508 - 502 Interoperability with Assistive Technology

<jeanne> 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.

<jeanne> Rich: We have API mapping for all the HTML features.

http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/proposed-rule/text-of-the-proposed-rule

<jeanne> Doug: the spec is good, but the implementation? THey have to
resolve the mistakes quicker.

http://www.w3.org/TR/html-aapi/

<jeanne> Rich: We are creating test suites for HTML and writing Web DRiver
extensions to see if the mapping passes.

<jeanne> ... WE can hand those test suites to the browsers for execution

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

<jeanne> ... if there are test cases we are missing, we can write it and
add it to the bucket.

http://www.w3.org/TR/svg-aam-1.0/

http://www.w3.org/TR/core-aam-1.1/

http://www.w3.org/TR/accname-aam-1.1/

<jeanne> Doing it right, may requiring normative reference to these mapping
questions

gl: if DOM is going away what happens to extensions. will they go away also.

kp: there is so much that doesn't work. it will only get worse.

<Greg> 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.

js: its what we have to live with.

ja: we have no SC that say you must have an extension mechanism

<Greg> 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.
 Summary of Action Items [End of minutes]

-- 
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>Jim Allan,
Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964