Re: [1.2T LC] should @role in SVG be animatable? (ISSUE-2076)

Hi, Al-

Al Gilman wrote (on 9/28/08 9:01 PM):
> 
> 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.
> 
> SVG documents that animate the value of @role would confuse the AT
> consumers of the accessibility APIs.  I suppose that the browser could
> trap these
> property-change events and destroy and create the object in the
> accessible object graph, but then...

I specified it as animatable because of its similarity to the 'class'
attribute, which is also animatable.  We added this attribute in large
part to work with ARIA, but as indicated in the XHTML Role Attribute
Module, and also in our spec, it is intended for general processing as
well, not just for ARIA.

Note that this (like most attributes) can be changed via the DOM, as
well, so there is no guarantee that the value will remain immutable
through the life of the document.

I do think it's reasonable to impose this restriction on the role
attribute when used with WAI-ARIA.  My initial reaction, though, is that
this is a restriction that should be placed on the attribute by the
WAI-ARIA spec, not by SVG.  I don't think that there is any conflict in
doing so.

There may be other uses of @role that would be made easier by allowing
it to be animated, and which might not affect AT UAs at all (that is, it
may not change the ARIA roles, but some other role value).


> Can anybody come up with a use case for animating the @role value using
> the currently-defined roles from either the XHTML Role Module or WAI-ARIA?

Personally, my philosophy is that specs should not impose undue
restrictions on authors, such that innovation is stifled.  This is both
a blessing and a curse, I realize, but it is impossible for the authors
of specs to anticipate and dictate every use for a Web language.

In conclusion, I would prefer not to change the spec in this instance.
If this doesn't satisfy your comment, we can revisit it, but if you're
okay with this, please do let us know promptly.


Regards-
-Doug

Received on Thursday, 9 October 2008 06:33:15 UTC