WAI-ARIA and Fluid Inline Edit

Joseph Scheuhammer clown at utoronto.ca
Wed Jul 2 18:21:28 UTC 2008


Jonathan wrote:

> I think Joseph is doing some investigation into
> this.
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 
into it.

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.

-- 
;;;;joseph

'This is not war -- this is pest control!'
      - "Doomsday", Dalek Leader -




More information about the fluid-work mailing list