JAWS announces that an inline edit area is a button
Michael S Elledge
elledge at msu.edu
Tue May 12 20:59:35 UTC 2009
Thanks for the clarification. It sounds like bringing it up to the PFWG
makes sense. I'm not the expert, though, so I'll yield to whatever Colin
It does seem like a solution that we can't implement for awhile, though.
Is that correct?
Joseph Scheuhammer wrote:
> Hi all,
> Colin wrote:
>> At heart, the problem is that ARIA doesn't provide a suitable role
>> for the kind of interaction provided by Inline Edit.
> It goes beyond ARIA. There (probably) isn't an "Inline Edit" role
> in any of the a11y APIs. So, even if the role was added to ARIA, it
> wouldn't do at lot of good until a11y APIs caught up.
> The reason for the "probably" is that there *may* be such a thing.
> Consider that a11y APIs were created first for desktop apps. Desktop
> icons have a label that acts like an inline edit. It's inert until
> the user clicks (double clicks) on it, and then becomes active
> editable text. Loss of focus or a "return" keystroke accepts any
> changes, and the label returns to its inert state.
> What do a11y APIs have to say about that label? I'll take a look at
> some point.
> As a first pass, given that there isn't an inline edit role, how does
> this look:
> <div role="textbox" aria-readonly="true" aria-pressed="false"
> aria-labelledby="labelId" ...>
> - readonly + not-pressed indicate that it's in its inactive state.
> - clicking on or pressing return switches to aria-readonly="false" +
> aria-pressed="true"; users can edit the contents.
> - clicking away, or pressing return, switches it back to its readonly
> not-pressed state.
> Note that aria-pressed is a property of role="button" and was
> introduced to handle toggle buttons. At present it isn't a property
> of role="textbox". But, it kind of captures the dual state of an
> inline edit box.
> I'm willing to take the suggestion to the PFWG if there isn't an
> obvious flaw in this approach.
More information about the fluid-work