- From: Joseph Scheuhammer <clown@utoronto.ca>
- Date: Thu, 05 Mar 2009 16:09:51 -0500
- To: David Bolter <david.bolter@utoronto.ca>
- CC: "wai-xtech@w3.org" <wai-xtech@w3.org>
>
> Good catch. I'm not sure this is the best case though, since we already
> have a working system for native markup. FF exposes and performs a click
> action to/for AT.
Yes, but the point is to have a *common* method for webapp developers to
handle changes, and the proposal on the table is to use AriaAttrModified
events for that. The above advocates using AriaAttrModified for DHTML
checkboxes, and click handling for native checkboxes -- that is no
longer a common technique.
Interestingly, though, it does suggest one, namely, that changes to
aria-checked are click actions. Put another way, that DHTML checkbox
events mimic native checkbox events. Note that this is a weak argument
against AriaAttrModified in the sense that it advocates using events
that are already supported where that can be done. One wonders how far
one can take this.
On another tack: click actions won't work for <input type="text">, nor
its @role="textbox" cousin. Changes to the text content of these
widgets is not a click event. It's most definitely a mutation event. I
don't think this is telling either, but it is the beginning of a
slippery slope -- if the web app developer must code for mutation events
anyway, why AriaAttrModified?
> I personally don't like aria-checked applied to a
> native checkbox.
Neither do I (in case it wasn't clear).
--
;;;;joseph
'What did one snowman say to the other snowman?'
- "Adrift", D. Hume -
Received on Thursday, 5 March 2009 21:10:28 UTC