See also: IRC log
<trackbot> Date: 05 February 2015
<scribe> scribe: allanj
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
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.
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)
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)
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.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: allanj Inferring ScribeNick: allanj Default Present: Jeanne, Jim_Allan, Greg_Lowney, Jan Present: Jeanne Jim_Allan Greg_Lowney Jan Regrets: Kim Found Date: 05 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/05-ua-minutes.html People with action items: greg[End of scribe.perl diagnostic output]