- From: Patrick H. Lauke <patrickl@opera.com>
- Date: Fri, 01 Jul 2011 15:39:56 +0100
- 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 UTC