WAI-ARIA and Fluid Inline Edit
clown at utoronto.ca
Wed Jul 2 18:21:28 UTC 2008
> I think Joseph is doing some investigation into
I have had an email discussion with the dijit programmer who was
responsible for the aria in their inline edit box. Here is a summary.
> InlineEditbox was a challenge. The current behavior is a little
> unusual from an a11y perspective (and even from the perspective of a
> sighted user) but it seems to work for ATs.
Initially, the @role is "button" and the rationale is that at this point
the widget is not a text box in terms of its behaviour. It may well
look like one, but it is something that the user "pushes", and behaves
like a button in that respect. Users certainly cannot type any text
into it at this point.
Aside: to my mind, if this is a button at all, it is toggleable (is
that a word?), in that by pushing it, you temporarily switch it to
another state; an "active" state wherein the user can enter text. The
aria spec does have a property for the button role named @aria-pressed
that can be true or false. If this state is present, the button is a
toggle button and can be either "pressed" or "not-presssed". If the
@aria-pressed state is missing, it's simply a "command button".
However, dijit's InlineEditbox does not use the @aria-pressed state.
End of aside.
Continuing on with how dijit's InlineEditbox works: when the button is
pressed, its display property is set to "none", effectively making it
invisible even to a screen reader. A structure is added to the dom that
includes a <input type="text"> and that <input> is given focus. Note
that <input> elements do not need a @role since their semantics is
determined by their @type attribute. The screen reader communicates
that the widget is now a text field, and can respond to the user typing
When the user hits return, the text they have typed is grabbed, the
structure that contains the <input type="text"> is deleted from the dom,
and the widget whose @role is "button" has its display property set back
to normal, and its label is set to the text that the user typed.
Even though I have misgivings with calling the widget a "button" in its
inactive state, it's intriguing that this set of operations actually
works with screen readers. For that matter, it works with sighted
users, they not seeing what is actually going on under the hood.
With respect to my misgivings, I think the problem lies with aria. If I
were to describe dijit's InlineEditbox, I would do it this way:
- it's a text field,
- it can be toggled between two states, namely
-- inactive, where its contents are readable but not changeable, and
-- active, where its contents are readable and changeable.
Research into the aria specs and best practices have led me to think
that aria cannot represent the situation as I've described it. There is
a "toggle" property, but it is solely for buttons. In particular, you
cannot toggle a text field. There is an @aria-checked property that
might apply (and it's sort like a "toggle"), but more research is needed.
'This is not war -- this is pest control!'
- "Doomsday", Dalek Leader -
More information about the fluid-work