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 -
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
