Hey all, On 12-May-09, at 11:36 AM, Michael S Elledge wrote:
This is an excellent discussion. It sounds like designating the Inline Edit as a textbox role could make the most sense.
I don't think this is a such a clear-cut issue. At heart, the problem is that ARIA doesn't provide a suitable role for the kind of interaction provided by Inline Edit. Here are the characteristics it has:
1. It's activatable. You click it--or hit Enter or Spacebar on it--and it will do something. 2. It's alternately viewable and editable. In some cases, it represents a form field in which you can edit text.
Neither the button nor the read-only textfield roles encompass both of these behaviours. With a button role, there's no indication of what happens when you actually activate the button. With a text field role, there's no indication that you have to do something to make it editable.
Ultimately, this is a limitation of the role-based approach used by MSAA, ARIA, and assistive technologies. In the long run, I'd like to see the assistive technology APIs use a "characteristic-based" style, in which you can mark up a user interface with the various interaction styles it uses. But this is way off in the future. In the meantime, perhaps the button role is the best compromise, along with some instructional text (aria-labelledby, maybe?) to explain the interaction to the user.
Colin --- Colin Clark Technical Lead, Fluid Project Adaptive Technology Resource Centre, University of Toronto http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
