This is an excellent discussion. It sounds like designating the Inline
Edit as a textbox role could make the most sense.
Also, the Use Case Storyboard for Inline Edit
(http://wiki.fluidproject.org/display/fluid/Simple+Text+Inline+Edit+Storyboard)
calls for a couple of things that could help. One is the announcement
"click item to edit" after the editable line receives focus and is read,
the other is identifying the type of information to be removed when
focus moves to the Remove button, i.e., "Remove this *section*."
Could these additions help solve the problems? As you mention, helpful
information should be contextual and proximate.
Mike
Alison Benjamin wrote:
Hi,
Another issue that's come out of testing with JAWS users is that the
inline edit area is a button. The jira is:
http://issues.fluidproject.org/browse/FLUID-2652 The problems are:
- JAWS announces that an inline edit area is a button. Only *after* a
user presses ENTER does JAWS announce that you can type in text.
- no indication about how to make or save an edit
- no indication that an edit is successful
- the JAWS virtual buffer needs to be refreshed or the user will not
be able to see the changes made.
To my mind, two things are going on here. Firstly, there is the issue
of whether the Inline Edit should have a button role or a textbox
role. (This issue was also discussed in this thread last year:
http://www.mail-archive.com/[email protected]/msg00866.html
and button was used. )
A button is not a user input (http://www.w3.org/TR/wai-aria/#button)
but it supports the "aria-pressed" state which could be promising. On
the other hand a textbox (http://www.w3.org/TR/wai-aria/#textbox)
could have the "aria-readonly" property set to false.
The other issue is how a user gets information about how to use the
Inline Edit. For example if it's a button the user does not expect
that clicking on it will mean an editable area will occur. Maybe there
is a way to hide information about how to interact with Inline Edit. A
user doesn't necessarily want to read instructions before they
interact with a page. Ideally as they use the page, it should become
apparent how they can interact with it.
Alison
------------------------------------------------------------------------
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work