JAWS announces that an inline edit area is a button

[Joseph Scheuhammer]

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" ...>

where,
- 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.

-- 
;;;;joseph

'What did one snowman say to the other snowman?'
             - "Adrift", D. Hume -