Minutes: User Agent telecon 11 June 2015

http://www.w3.org/2015/06/11-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference 11 Jun 2015

See also: IRC log   http://www.w3.org/2015/06/11-ua-irc
<http://www.w3.org/2015/06/11-ua-irc>
Attendees
PresentGreg, Jim, JeanneRegretsChairjim AllanScribeallanj
Contents

   - Topics <http://www.w3.org/2015/06/11-ua-minutes.html#agenda>
      1. GL 4.1.4 <http://www.w3.org/2015/06/11-ua-minutes.html#item01>
      2. response 1 <http://www.w3.org/2015/06/11-ua-minutes.html#item02>
      3. response to 2 <http://www.w3.org/2015/06/11-ua-minutes.html#item03>
      4. response to 3 <http://www.w3.org/2015/06/11-ua-minutes.html#item04>
      5. response to 4 <http://www.w3.org/2015/06/11-ua-minutes.html#item05>
      6. response to 1.1.3
      <http://www.w3.org/2015/06/11-ua-minutes.html#item06>
      7. response to 1.3.1
      <http://www.w3.org/2015/06/11-ua-minutes.html#item07>
      8. response to 1.4.5
      <http://www.w3.org/2015/06/11-ua-minutes.html#item08>
      9. response to 1.7
      <http://www.w3.org/2015/06/11-ua-minutes.html#item09>
      10. response to 1.8.14
      <http://www.w3.org/2015/06/11-ua-minutes.html#item10>
      11. response to 2.7
      <http://www.w3.org/2015/06/11-ua-minutes.html#item11>
      12. response to 4.1.4
      <http://www.w3.org/2015/06/11-ua-minutes.html#item12>
   - Summary of Action Items
   <http://www.w3.org/2015/06/11-ua-minutes.html#ActionSummary>

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

<trackbot> Date: 11 June 2015

http://www.w3.org/WAI/UA/work/wiki/Use_Cases_for_UAAG_Applicability

open item 1
GL 4.1.4

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

Proposal: 4.1.4 DOMs Programmatically Available as fallback:

If the user agent accessibility API does not provide sufficient information
to one or more platform accessibility services, then Document Object Models
(DOM), must be made programmatically available to assistive technologies.
(Level A)

Several screenreader vendors say one particular browser has an insufficient
accessibility API, and they need DOM access

discussion of technical work arounds for lack of DOM access

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

ja: +1 on proposal

<jeanne> +1 to proposal

<Greg> +1

*RESOLUTION: change 4.1.4 to be DOMs Programmatically Available as
fallback: If the user agent accessibility API does not provide sufficient
information to one or more platform accessibility services, then Document
Object Models (DOM), must be made programmatically available to assistive
technologies. (Level A)*

Close item 1

<jeanne> 4.1.4. Intent proposed: Assistive technologies need all possible
information. Applications such as user agents and assistive technologies
use a combination of DOMs, accessibility Application Programming Interfaces
(API), native platform APIs, and hard-coded heuristics to provide an
accessible user interface and accessible content. While most assistive
technology vendors prefer to use the AAPIs, if

<jeanne> the AAPI cannot provide enough access to the content, then It is
the user agent's responsibility to expose the DOM to assistive technology.

<jeanne> revision: Assistive technologies need all possible information.
Applications such as user agents and assistive technologies use a
combination of DOMs, Accessibility Application Programming Interfaces
(AAPI), native platform APIs, and hard-coded heuristics to provide an
accessible user interface and accessible content. While most assistive
technology vendors prefer to use the AAPIs, if the AAPI

<jeanne> cannot provide enough access to the content, then It is the user
agent's responsibility to expose the DOM to assistive technology.

<Greg> Even though a UA developer may think that they've exposed all
necessary information through the AAPI, it is extremely difficult to be
sure that the coverage is indeed complete until a screen reader actually
tries to rely on it. That is why developers are strongly encouraged to
provide redundant information through as many mechanisms as possible,
including the DOM.
response 1

ok
response to 2

gl: add swapping styles between users

ok

<Greg> Re #2, add that we require the ability to copy settings from one
system to another, allowing a technical expert to develop the customized
style sheet which is then distributed to many end users.

<Greg> Might also add that we've altered the wording to make it clearer
that this is not just about style sheets in the CSS-specific meaning, but
also includes other mechanisms for that could include graphical approaches
that would be easier for the average end user.
response to 3

ja: so operating systems settings are high contrast, bounce keys, repeat
keys. Font family, size and color are over ridden by the browser, as are
foreground and background, except for high contrast mode.
... not sure what other OS accessibility settings the UA should pick up

<Greg> Jim points out that one advantage of requiring accessibility
settings be at the browser level (rather than only at the OS level) is that
2.7.5 recommends browser settings be transferrable between systems, while
we cannot say the same for OS settings.

for the UA UI it should respect the OS settings

ok
response to 4

ok
response to 1.1.3 response to 1.3.1

<Greg> Our response to Cynthia's comment on 1.3.1 could say that 1.3.1 does
not require the UA to provide it's own UI for adjusting the settings. If
the UA wants to simply respect user-settings from the OS level, that is
fine. However, if the OS does not allow the user to set one of the listed
values (e.g. distinguishing visited from unvisited links) then the UA would
be required to provide its own...

<Greg> ...UI for this user option.

additionally, this can be met through the a user styling mechanism

(aside) in the future we should have an sc that would merge user styles
(default for selection, font, etc) with the authors
response to 1.4.5

<Greg> If the UA does not provide an option to pick up default text
settings from the OS, it will not block users from accessing any content,
it merely makes it a bit more work for the user to configure the UA to have
equivalent settings. That extra one-time effort does not seem to be enough
to justify making it Level A.

<Greg> That being said, we agree that every browser should provide this
option as a convenience.
response to 1.7

reference: see response to 2 above
response to 1.8.14

for some users they may have to break a site to get the information.

ok
response to 2.7

ok
response to 4.1.4

ok
 Summary of Action Items [End of minutes]

-- 
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>Jim Allan,
Accessibility Coordinator
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