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

Re: UAWG question

From: Patrick H. Lauke <patrickl@opera.com>
Date: Fri, 01 Jul 2011 15:39:56 +0100
Message-ID: <4E0DDC3C.3060902@opera.com>
To: w3c-wai-ua@w3.org
On 30/06/2011 23:23, Jim Allan wrote:
> Patrick,
> we need some technical help.
> at question is GL 4.1
> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110609/#gl-AT-access
>
> we have 4.1.4 which covers devices with DOMs...
>
> 4.1.4 Programmatic Availability of DOMs:
> If the user agent implements one or more DOMs, they must be made
> programmatically available to assistive technologies. (Level A)
>
>
> we also have 4.1.5 which was intended to be technology agnostic,
> non-DOM oriented. It describes most things a DOM would do.
> the question is do we need it?
> Does this really add anything beyond 4.1.1 and 4.1.2? see after 4.1.5.
> We are not sure.

Personally I think the order and relationship is quite important. Would 
it be possible to maybe merge this idea of conveying structure and 
relationship into either 4.1.2 or 4.1.4?

e.g.

4.1.2 *Structure, Relationship,* Name, Role, State, Value, Description: 
: For all user interface components including user interface, rendered 
content, generated content, and alternative content, make available the 
element structure, relationship to other elements, name, role, state, 
value, and description via a platform accessibility architecture. (Level A)

or

4.1.4 Programmatic Availability of *structure*::  the User Agent's 
internal representation of the user content in terms of element 
structure, relationships between elements, element meaning, or some 
combination thereof, must be must be made programmatically available to 
assistive technologies (normally by using the platform accessibility 
architecture or a programmatically available DOM) (Level A)

Or does this overload 4.1.2 or 4.1.4 too much?

>
> Your thoughts, please.
>
> 4.1.5 Access:
> If a User Agent keeps an internal representation of the user content
> in terms of element structure, relationships between elements, element
> meaning, or some combination thereof, it must expose this internal
> representation via an appropriate means (normally by using the
> platform accessibility architecture or a programmatically available
> DOM) (Level A) .
>
> If a platform that does not support a platform accessibility API like
> MSAA, and thus 4.1.1 does not apply, 4.1.2 would require the UA to
> expose information about each element, but would not require it to
> expose information about relationships between them such as any
> *order*. 4.1.5 would do that.

I'm not sure if exposing all the information (name, role, state, etc) 
*without* logical/document order would be useful in practical terms 
though. Imagine if it were exposed in a completely random or arbitrary 
order - would this be useful at all? Better than nothing, I suppose, but 
confusing in practice.

> 4.1.1 Platform Accessibility Architecture:
> Support a platform accessibility architecture relevant to the
> operating environment. (Level A)
>
> 4.1.2 Name, Role, State, Value, Description:
> For all user interface components including user interface, rendered
> content, generated content, and alternative content, make available
> the name, role, state, value, and description via a platform
> accessibility architecture. (Level A)
>
> 4.1.3 Accessible Alternative:
> If a component of the user agent user interface cannot be exposed
> through the platform accessibility architecture, then provide an
> equivalent alternative that is exposed through the platform
> accessibility architecture. (Level A)
>
> thanks to Greg L for some the notes in irc
>


-- 
Patrick H. Lauke

Web Evangelist
Developer Relations Team
Opera - http://www.opera.com
Received on Friday, 1 July 2011 14:40:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 July 2011 14:40:42 GMT