JAWS announces that an inline edit area is a button

[Michael S Elledge]

Hi Joseph--

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 
recommends.  :^)

It does seem like a solution that we can't implement for awhile, though. 
Is that correct?

Mike

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