W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2011

Ideas to simplify UAAG2 Guideline 4.1 Facilitate programmatic access

From: Richards, Jan <jrichards@ocad.ca>
Date: Wed, 20 Jul 2011 14:42:57 +0000
To: UAWG list <w3c-wai-ua@w3.org>
Message-ID: <0B1EB1C972BCB740B522ACBCD5F48DEB031A713B@ocadmail-maildb.ocad.ca>
Hi all,

On the last call Simon and I took an (unrecorded) action to discuss tersifying the SCs in Guideline 4.1. Here are my thoughts (that I have discussed with Simon). Simon and I are discussing an additional requirement related to programmatically conveying onscreen relationships (e.g. elements that are close together).



Definition Changes:
-------------------

NEW "Base User Agent" 
A user agent that has direct access to the platform accessibility services of an operating system. This includes user agents running on or tightly integrated with operating systems as well as some user agent plugins.


CHANGE TERM "platform accessibility architecture" to "platform accessibility service" (this matches 508 and is a better term in my opinion)

Success Criteria:
-----------------

4.1.1 Platform Accessibility Service: User agents implement communication with platform accessibility services for all aspects of the user agent user interface, including rendered content. (Level A)
Note 1: The information communicated will typically include the name, role, state, value, and description of user interface controls.
Note 2: For web-based user agents, this will involve communication via the *base user agent*.
Ed. Combines 4.1.1 and 4.1.2 and clarifies that the base browser will be involved.

4.1.2 Programmatic Availability of DOMs: If the user agent maintains one or more DOMs, they must be made programmatically available to assistive technologies. (Level A)
Note: For web-based user agents, this will be the DOM(s) of the *base user agent*.
Ed. New number, text relatively unchanged because our definition of DOM is nicely general.

4.1.3 Additional Platform Accessibility Service Properties: For each of the following properties, if the property can be communicated by the accessibility platform service, then property is communicated in that way: (Level A)
    the bounding dimensions and coordinates of rendered graphical objects
    font family of text
    font size of text
    foreground color of text
    background color of text.
    selection
    highlighting
    input device focus
Note: These properties are also often included in one or more DOMs as well.

Ed. Removes "change state/value notifications" since those notification events are up to the OS.

REMOVE 4.1.3 Accessible Alternative 
Ed. I think it is better to say at the top of the entire document that is ok to have functionality that doesn't meet UAAG as long as it is redundant (i.e. something else provides the same functionality) and it does not interfere with the accessibility of the other parts.

REMOVE 4.1.5 Write Access
Ed. According to Joseph this is in flux due to the deprecation of DOM mutation events. The issue is that web apps don't have access to changes made directly to the DOM by ATs.

REMOVE 4.1.7 Timely Communication:
Ed. It is not easily testable unless we add an X seconds. And if a particular communication exchange takes a while, is that a fail for the whole UA, especially since the AT will be a complicating factor? 

 


Cheers,
Jan
Received on Wednesday, 20 July 2011 14:43:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 14:43:21 GMT