- From: Al Gilman <Alfred.S.Gilman@ieee.org>
- Date: Mon, 29 Sep 2008 10:53:10 -0400
- To: "Anne van Kesteren" <annevk@opera.com>
- Cc: www-archive <www-archive@w3.org>, "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>
On 29 Sep 2008, at 10:06 AM, Anne van Kesteren wrote: > On Sun, 28 Sep 2008 21:01:21 -0400, Al Gilman > <Alfred.S.Gilman@ieee.org> wrote: >> As regards WAI-ARIA alone, the answer should be 'no.' In our best >> practices we instruct script authors not to change the role of an >> element, but rather to destroy the DOM object for that element and >> create a new object with the new role. >> >> This is because the consumers of the accessibility APIs expect the >> role of a node to be static, just as xml:lang is not animatable in >> SVG. > > FWIW, a lot of controls from HTML are mutable (by changing the type > attribute value of the input element). Good point. At this level, @role is just as mutable as @type. One can just go in and change it in the DOM. But not expect good results, based on what we are expecting (for now) of the browsers in the binding-to-accessibility-API processing. > If these are expressed in terms of ARIA for AT they would need to > deal with mutation. .. or warn authors off using this mutability. Usually we would rather rely on code in the browser rather than guideline conformance in the author crowd. But there are limits. Yes, we have this issue to deal with in HTML. No, it doesn't have to commit us to creating or exacerbating the same situation in SVG. Al PS: minor editorial s/expressed in terms of ARIA/mapped to the accessibility APIs Why? ARIA repairs gaps in the mapping to the APIs, it does not cover or subsume the mapping to APIs. Different order of magnitude problem. > -- > Anne van Kesteren > <http://annevankesteren.nl/> > <http://www.opera.com/>
Received on Monday, 29 September 2008 14:53:57 UTC