- From: Richards, Jan <jrichards@ocadu.ca>
- Date: Fri, 12 Dec 2014 14:33:18 +0000
- To: WAI-ua <w3c-wai-ua@w3.org>
Hi all, Here are some comments from Joseph Scheuhammer on on the SCs in Guideline 4.1: > (http://w3c.github.io/UAAG/UAAG20/#gl-AT-access) > > Note: UAAG 2.0 assumes that a platform accessibility API will be built on top of underlying security architectures that will allow user agents to comply with both the success criteria and security needs. My understanding of this note is that access to the platform accessibility service is through the security service, as necessary. Is that correct? > > 4.1.1 Support Platform Accessibility Services: The user agent supports relevant platform accessibility services. (Level A) > > 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 via a platform accessibility service: (Level A) > Name Two points about Names: First, not all content requires a name. For example, generally the content of an html <p> element, e.g., <p>Hello world.</p>, doesn't need a Name. In fact, it's incorrect to take the content of the <p> element and make that its name, since its redundant. In this example, the name of the paragraph would be "Hello world", and the content would also be "Hello world". However, if the author wanted to call out that a particular paragraph is the summary of the current section, they could to the following: <p aria-label="summary"> Lorem ipsum dolor sit amet, consectetur ...</p>. So, if the role requires a name, and/or the author has provided it, then the UA must make it available. Secondly, and by implication, *if* the author has provided a description as well as a name, then the description should be made available as well. I'm leaning toward a UA making available any description Level A as well. Now that I've written that, I'm having doubts. Name is required either when (a) a role requires it, or (b) the author has provided it. I know of no requirement of descriptions based on roles, but they should be provided by the UA if the author has specified a description. > Role > State Shouldn't "State" be plural, i.e. "States"? Also, ... > Value > Selection > Focus ... Selection and Focus are states as far as accessibility API services are concerned. I guess they are relatively more important, and need to be called out separately? > > 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) 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. > 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. (Level A) You might want to add, "but no more than any other (non-assistive) technology's programmatic access to the DOM." Some might read 4.1.4 as allowing ATs to bypass the security module. > > 4.1.5 Make Write Access Programmatically Available: If the user can modify the state or value of a piece of content through the user interface (e.g. by checking a box or editing a text area), the same degree of write access is programmatically available. (Level A) This one is tricky since it's a good principle. Unfortunately, for ARIA 1.0, this isn't allowed with respect to the values of aria-* attributes. The reason is that author scripts sometime rely on the value of aria-* attributes, and cannot know if something outside of the script, such as an AT, changes its. For that reason, the UAIG states that the flow of control is one-way only: http://www.w3.org/TR/wai-aria-implementation/#mapping_general (the second paragraph). > > 4.1.6 Expose Additional Properties: For all user interface components, including the UA user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (Level AA) > Bounding dimensions and coordinates > Font family of text > Font size of text > Foreground and background color for text > Change state/value notifications I would make changing states/values level A. Consider any interactive UI such as a combobox, or a slider, or a live region. Surely it's a basic (level A) requirement that if the value of slider changes, or if a chat log changes (live region), then the AT is notified. Accessibility APIs support a whole raft of accessibility events. They don't just store role, states, and properties; they also send out notifications whenever these change. Here are links to changes supported by a11y API event systems: http://www.w3.org/TR/wai-aria-implementation/#focus_state_event_table http://www.w3.org/TR/wai-aria-implementation/#mapping_events_state-change http://www.w3.org/TR/wai-aria-implementation/#mapping_events_visibility http://www.w3.org/TR/wai-aria-implementation/#mapping_events_selection http://www.w3.org/TR/wai-aria-implementation/#mapping_events_menus http://w3c.github.io/aria/accname-aam/accname-aam.html#events (this one is pending). Any UA that has a complete implementation of some a11y API service MUST have implemented the event model thereof. Of course, it's up the AT to decide which events it wants to pay attention to, but these 4.1.x rules apply to the UA. > Highlighting > Keyboard commands Hope that helps.
Received on Friday, 12 December 2014 14:33:58 UTC