Minutes: User Agent telecon 5 Feb 2015 from Jim Allan on 2015-02-05 (w3c-wai-ua@w3.org from January to March 2015)

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 5 Feb 2015 13:43:26 -0600
To: WAI-ua <w3c-wai-ua@w3.org>
Message-ID: <CA+=z1WkX-KVovTzMWKU3zJV0su-TKQgB=cDhQF9e+x9LKYuR8Q@mail.gmail.com>
User Agent Accessibility Guidelines Working Group Teleconference 05 Feb 2015

See also: IRC log <http://www.w3.org/2015/02/05-ua-irc>
Attendees
PresentJeanne, Jim_Allan, Greg_Lowney, JanRegretsChairJimAllanScribeallanj
Contents

   - Topics <http://www.w3.org/2015/02/05-ua-minutes.html#agenda>
      1. Mobile taskforce survey
      <http://www.w3.org/2015/02/05-ua-minutes.html#item01>
      2. comment MS06 on 4.1.4 Action-1065
      <http://www.w3.org/2015/02/05-ua-minutes.html#item02>
      3. 4.1.5 Write access to DOM
      <http://www.w3.org/2015/02/05-ua-minutes.html#item03>
      4. comments on 4.1.2
      <http://www.w3.org/2015/02/05-ua-minutes.html#item04>
      5. 4.1.3 comments
      <http://www.w3.org/2015/02/05-ua-minutes.html#item05>
   - Summary of Action Items
   <http://www.w3.org/2015/02/05-ua-minutes.html#ActionSummary>

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

<trackbot> Date: 05 February 2015

<scribe> scribe: allanj
Mobile taskforce survey

https://www.w3.org/2002/09/wbs/36791/20150203/results

<jeanne> Mobile Accessibility: How WCAG 2.0 and Other W3C-WAI Guidelines
Apply to Mobile

<scribe> new title - Mobile Accessibility: How WCAG 2.0 and Other W3C-WAI
Guidelines Apply to Mobile

js: we could review document and add in UAAG20 SCs

<Greg> Very minor, but I thought the section "A user agent that follows
UAAG 2.0 will improve accessibility through its own user interface and
through its ability to communicate with other technologies, including
assistive technologies." to "A user agent that follows UAAG 2.0 will
improve accessibility through its own user interface, *through options it
provides for rendering and interacting with...

<Greg> ...content,* and through its ability to communicate with other
technologies, including assistive technologies."

<Greg> I thought they mischaracterized UAAG20 a little bit there.

<jeanne> public-mobile-a11y-tf@w3.org
comment MS06 on 4.1.4 Action-1065

jr: we don't have the expertise to test this.

gl: read documentation, or write to manufacturer and find out

jr: how much of the DOM is enough?
... happy with AA, no strong objection

gl: want UAs to support ARIA, info is exposed in the DOM
... DOM is important

<Jan> https://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0080.html

ja: can UAWG just say we disagree.

wording from pf

4.1.4 Make DOMs Programmatically Available: If the user agent implements
one or more Document Object Models (DOM), they must be made
programmatically available to assistive technologies, but no more than any
other (non-assistive) technology's programmatic access to the DOM.

jr: does DOM hold true for Mobile
... a quick search shows that there are mobile DOMs for browsers
... we want AT to have access to DOM because APIs are weak, and DOMs are
consistent across platforms

gl: consistent DOMs are important

not accepted. UAWG believes strongly that access to the DOM is important to
accessibility because DOMs are consistent across platforms and OSs, and
accessibility APIs do not always provide all of the information ATs need

<scribe> *ACTION:* greg to write "not accepted" phrasing for MS06 on 4.1.4
modeled on "not accepted. UAWG believes strongly that access to the DOM is
important to accessibility because DOMs are consistent across platforms and
OSs, and accessibility APIs do not always provide all of the information
ATs needs" [recorded in
http://www.w3.org/2015/02/05-ua-minutes.html#action01]

<trackbot> Created ACTION-1068 - Write "not accepted" phrasing for ms06 on
4.1.4 modeled on "not accepted. uawg believes strongly that access to the
dom is important to accessibility because doms are consistent across
platforms and oss, and accessibility apis do not always provide all of the
information ats needs" [on Greg Lowney - due 2015-02-12].

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. It is the user agent's responsibility to expose the DOM
to assistive technology which...

scribe: in many cases is the richest source of information on web content.
4.1.5 Write access to DOM

from comment
https://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0080.html

<jeanne> 4.1.5 Make Input Access Programmatically Available:

<jeanne> If the user can input information through the user interface (e.g.
by checking a box or editing a text area), the same degree of input access
is programmatically available.

js: perhaps change stem "Make Write Access Programmatically Available" to
"Make Input Access Programmatically Available"

gl: the SC is only talking about modifying a state or value of a piece of
content to the same degree that a user using the user interface
... they are misinterpreting the language of the SC

the intent of the SC: If users can control the user interface using any
form of input, they can control it through programmatic access. It is often
more reliable for assistive technology to use the programmatic method of
access versus attempting to simulate mouse or keyboard input.

<Greg> A slight change to Jeanne's wording: "Where the user can interact
with content (e.g. by checking a box or editing a text area), the same
degree of input access is programmatically available."

Make content interaction Programmatically Available. Where the user can
interact with content (e.g. by checking a box or editing a text area), the
same degree of interaction is programmatically available.

<Greg> "is programmatically available" or "can be done programmatically"?

Make content interaction Programmatically Available. Where the user can
interact with content (e.g. by checking a box or editing a text area), the
same degree of interaction can be done programmatically.

<Greg> Make Content Interaction Programmatically Available: Where the user
can interact with content (e.g. by checking a box or editing a text area),
the same degree of interaction is programmatically available. (Level A)

*RESOLUTION: change 4.1.5 to Make Content Interaction Programmatically
Available: Where the user can interact with content (e.g. by checking a box
or editing a text area), the same degree of interaction is programmatically
available. (Level A)*
comments on 4.1.2

from: https://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0080.html

<jeanne> 4.1.5 Make Content Interaction Programmatically Available:

<jeanne> If the user can interact with content (e.g. by checking a box or
editing a text area), the same degree of interaction is programmatically
available.

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, if present, via a platform accessibility
service: (Level A)

<Greg> 4.1.2 Expose Basic Properties: For all user interface components,
including UA user interface, rendered content, and generated content, if
the following attributes are present the user agent makes them available
via a platform accessibility service: (Level A)

+1

jr: +1

gl: see no reason for 'state' to be plural.

<jeanne> +1

<jeanne> UAWG agrees and changed the SC to include "if present"

*RESOLUTION: change 4.1.2 to content, and generated content, if the
following attributes are present the user agent makes them available via a
platform accessibility service: (Level A)*
4.1.3 comments

current wording: 4.1.3 Provide Equivalent Accessible Alternatives: If a
component of the UA user interface cannot be exposed through platform
accessibility services, then the user agent provides an equivalent
alternative that is exposed through the platform accessibility service.
(Level A)

<Greg> Intent: Like everyone else, users who rely on assistive technology
need to be able to carry out all tasks provided by the user agent. When a
particular user interface component cannot support the platform
accessibility service, and thus can't be made compatible with assistive
technology, the user agent should let the user achieve the same goal using
another component that is fully accessible.

comment: I don't understand this one. It reads to me like, "If something
can't be exposed through a11y services, then UAs must find an equivalent
alternative and expose it". Is this a better way to put it: "If something
can't be exposed through a11y services, then UAs must expose the equivalent
alternative provided by the author"? The problem with the first reading is
it requires UAs to...
... be intelligent.

<Jan> Maybe: 4.1.3 Provide Equivalent Accessible Alternatives: If UA user
interface functionality cannot be exposed through platform accessibility
services, then the user agent provides equivalent functionality that can be
exposed through the platform accessibility service. (Level A)

+1

jr: not a component thing it is a functionality thing, can the user do a
given task that is provided somehow through the UA UI

*RESOLUTION: change 4.1.3 to 4.1.3 Provide Equivalent Accessible
Alternatives: If UA user interface functionality cannot be exposed through
platform accessibility services, then the user agent provides equivalent
functionality that can be exposed through the platform accessibility
service. (Level A)*

gl: need a better example

<Greg> I think we could use a simpler example; the existing one is very
complicated and not easy to follow.

jr: the user need to move an time, the UA has a drag and drop feature, but
provides a keyboard accessible way to doing the same task

<Jan> XXX is a screen reader user. She wants to bookmark the current page.
Her browser allows her to drag a bookmark icon into the current document to
bookmark the location. This functionality cannot be accessed effectively
with her screen reader. However, the browser does allow her to add a
bookmark from the context menu at the current focus.

<Jan> XXX is a screen reader user. She wants to bookmark the current page.
Her browser allows a bookmark icon to be dragged with a mouse into the
current document to bookmark the location. This functionality cannot be
accessed effectively with her screen reader. However, the browser does
allow her to add a bookmark from the context menu at the current focus.
 Summary of Action Items *[NEW]* *ACTION:* greg to write "not accepted"
phrasing for MS06 on 4.1.4 modeled on "not accepted. UAWG believes strongly
that access to the DOM is important to accessibility because DOMs are
consistent across platforms and OSs, and accessibility APIs do not always
provide all of the information ATs needs" [recorded in
http://www.w3.org/2015/02/05-ua-minutes.html#action01]

[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
Received on Thursday, 5 February 2015 19:43:52 UTC