Minutes: User Agent telecon 28 May 2015

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

See also: IRC log  http://www.w3.org/2015/05/28-ua-irc
<http://www.w3.org/2015/05/28-ua-irc>
Attendees
PresentJim, Jeanne, Greg, KimRegretsChairjimallanScribeallanj
Contents

   - Topics <http://www.w3.org/2015/05/28-ua-minutes.html#agenda>
      1. GL 4 proposal <http://www.w3.org/2015/05/28-ua-minutes.html#item01>
      2. 4.1.2 <http://www.w3.org/2015/05/28-ua-minutes.html#item02>
      3. 4.1.4 revised <http://www.w3.org/2015/05/28-ua-minutes.html#item03>
   - Summary of Action Items
   <http://www.w3.org/2015/05/28-ua-minutes.html#ActionSummary>

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

<trackbot> Date: 28 May 2015

open item 1
GL 4 proposal

https://lists.w3.org/Archives/Public/w3c-wai-ua/2015AprJun/0046.html

no change to 4.1.1, 4.1.3, 4.1.5
4.1.2

gl: remove bullet change state/value notification because it is mentioned
in the body of the SC

js: but they might miss it if not in the list

gl: concerned about "relationships" should (aria) be an example

js: make it specific to aria. as greg says 'relationships' is very broad

gl: if we make specific then if they don't do aria then they don't have to
do anything?

ja: is covered in 1.10.1

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

ja: keep relationships broad use (e.g. ARIA) and reference 1.10.1

<Greg> We could add a bullet to 4.1.2 that said "Relationships per 1.10.1
"Show Related Elements".

<Greg> Related, should 1.10.1 also mention ARIA explicitly?

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

ja: cross reference 1.10.1 and 4.1.2

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

<Greg> In each of the latter two cases, the phrase "Explicitly defined
relationships" is taken from 1.10.1.

ja: +1 to Explicitly-defined relationships (e.g. ARIA)

js: concern about broadness, trying to think of use cases

proposal:

<jeanne> Explicitly defined relationships (e.g. ARIA relationships [ARIA
1.0])

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)

Name

Role

State

Value

Selection

Focus

Bounding dimensions and coordinates

Font family of text

Font size of text

Foreground and background color for text

Highlighting

Keyboard commands

Explicitly defined relationships (e.g. ARIA relationships [ARIA 1.0])

Caret position

@@cross reference 1.10.1 and 4.1.2

*RESOLUTION: Accept 4.1.2 as above.*
4.1.4 revised

proposal:

4.1.4 DOMs Programmatically Available as fallback:

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)

*RESOLUTION: delete 4.1.6 (merged with 4.1.2)*

gl: not thrilled

<Greg> I'm concerned because one screen reader developer indicated that
some applications implement platform API but so badly that the AT must fall
back on DOM access. Similarly, a second screen reader developer 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.

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

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

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

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

js: seems that browsers are getting rid of the DOM, old technology.

gl: but that would break all of JavaScript

js: is writing contacts asking about dom vs api, how javascript works with
out dom

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

<Greg> ...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
provide access to the content (including but not limited to the DOM).

whatwg is working on DOM https://dom.spec.whatwg.org/

http://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/a11y-dom-apis.html

ja: table this for now. revisit 4.1.4 next week with new information.
 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