WAI-ARIA and Fluid Inline Edit
a.cheetham at utoronto.ca
Wed Jul 2 16:43:14 UTC 2008
Last week, I did a bit of research into ARIA, and a bit of further
testing with JAWS, and found the following:
The ARIA specs describe a "textbox" as:
"Inputs that allow free-form text as their value"
This sounds quite appropriate for the inline edit, but:
In both IE and FF, placing a role of "textbox" on the element affects
no change whatsoever in JAWS' behaviour:
- IE simply speaks the text.
- FF speaks the text if the virtual cursor is on, and is silent if
it is off.
The ARIA specs describe a "button" as:
"Allows for user-triggered actions"
Not quite right, but given the ineffectiveness of "textbox," you can
see why dojo uses it, if you squint and turn your head sideways a bit.
In IE, placing a role of "button" on the element still affects no
change whatsoever in JAWS' behaviour: IE still just speaks the text.
In FF, placing a role of "button" on the element causes JAWS to follow
its reading of the text with either:
a) the text again and then the word "button" if the virtual cursor
is on, or
b) the word "button" if the virtual cursor is off.
So it seems to me that there is no ideal solution, and that until ATs
like JAWS do something reasonable with the "textbox" role, using
"button" at least does something.
A side note on the "readonly" property for the "textbox" role (in case
we ever switch to "textbox"):
The ARIA specs describe the "readonly" property to mean:
"Indicates that the widget is not editable"
To me, setting this to true would send the wrong message for the
inline edit. The whole point of the inline edit is that the text IS
editable. If we do use the "textbox" role, we *should* set
readonly=false to convey the editable-ness of the text.
As Jonathan pointed out, there should be an "editable" property.
Anastasia Cheetham a.cheetham at utoronto.ca
Software Designer, Fluid Project http://fluidproject.org
Adaptive Technology Resource Centre / University of Toronto
More information about the fluid-work