Comments from Joseph S. on Guideline 4.1 - Facilitate programmatic access to assistive technology

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