Re: [aapi] ARIAAttrModified?

David,

Some pros and cons.

Pro:  if aria does become ubiquitous in the sense that it is used for 
markup other than HTML, then it would be good to have a common way of 
detecting changes to aria attributes.  Thus, regardless of its use in 
SVG, XUL, or whatever, there is a standard way to react to changes to 
aria information.

Con: it has taken a long time for user agents to support DOM mutation 
events.  I despair of a new event coming along anytime soon.  I guess it 
depends on the will to do it -- get enough people behind it and it will 
happen.

Con: and a very specific one.  What about "native" widgets such as 
<input type=checkbox>?  They typically do not need aria information. 
Specifically, aria-checked isn't needed for checkbox inputs.  
Furthermore, there is a reason not to include aria attributes in these 
cases because it leads to a synchronization issue.  That is, given 
<input type=checkbox checked="checked" aria-checked="true">, which of 
@checked vs. @aria-checked do you trust if they are not in agreement?  
But, if aria-checked is left out there won't be an AriaAttrModified 
event when the checked state changes.  So:  how do you deal with native 
widget state changes?

Miscellaneous:  maybe it doesn't need to be a mutation event.  There are 
other "high level" events in the DOM3 event model, such as UIEvent.  
Since a lot of aria deals with the user interface, perhaps that branch 
of the event model should be extended.  That is, perhaps aria events are 
a fomr of UIEvents.  (This obviously needs more thought).

-- 
;;;;joseph

'What did one snowman say to the other snowman?'
             - "Adrift", D. Hume -

Received on Thursday, 5 March 2009 20:00:53 UTC