enhancing screen reader ux of inline edit

[Alison Benjamin]

Good evening,

I did a quick walkthrough of the inline edit demo with a Jaws user. Because
of peripheral incompatibility - we needed to test on my computer as I have
the appropriate version of JAWS and the user's keyboard couldn't hookup to
my laptop - we skipped doing a more formal usability test.  However, we
played around with the component together and I learned something about
Inline Edit behavior I missed before:

FF3
- after an edit is saved, "undo" is read
- but the specific edit a user has made, along with the sentence it is
embedded in, is not read back to the user - what is being undone?
- using the arrow keys, it is possible to go back and read the sentence
where the edit was made
- but, JAWS will not read  the newly saved edit (although visually it's
clear the edit is saved).

IE8
- after an edit is saved, the original editable text is read (not the edit
made); "undo" isn't read (maybe a IE/live region issue).
- using the arrows can get JAWS to read the change made
- going back into edit mode works
- after the edit is saved, once more, the original text that was there when
the page is loaded is read, and "undo" isn't read
- but using the arrows can get JAWS to read the latest change made.

I think some of this oddness can be attributed to a JAWS buffer problem,
which must be manually refreshed. Justin has also suggested experimenting
more with live regions.  Please feel free to try and replicate this
behaviour or give me suggestions for directions to go next.

I created this ticket which has a small patch, based on some suggestions
from the user:
http://issues.fluidproject.org/browse/FLUID-3421

Thanks,
Alison B

On Wed, Dec 2, 2009 at 9:22 AM, Justin Obara <obara.justin at gmail.com> wrote:

> Thanks for all the work on this Alison, and I think you have it all
> covered.
>
> - Justin
> On 2009-12-01, at 4:04 PM, Alison Benjamin wrote:
>
> > Hello
> >
> > A little bit of background, I have flip-flopped a bit over what ARIA role
> an inline edit should have. ARIA role of button for the inline edit is
> actually best... because having the view and edit mode be the same makes the
> screen reader suggest that you can edit in view mode (when you can't).
> Anyway, Laurie and I must have missed this problem when I suggested the role
> being a textbox.  Thanks Justin for pointing this out! Now that's settled,
> so
> >
> > -following the advice of dojo, I added a title="editable button" to the
> class that contains the inline edit selector
> > -worked with two different JAWS configurations to test
> >     Config manager > set options > HTML options > links: "use title" and
> ...> links: "use screen text"
> >
> > Results:
> > - FF3 reads titles, IE8 does not (??)
> > - NVDA & FF3 reads titles.
> >
> > details:
> > FF3/JAWS 10
> > -Navigating with arrow keys, user hears:
> > "Blockquote. The quick brown fox jumped over the lazy dogs [BUTTON] and
> then dot dot dot. "
> > - tabbing and shift tabbing to the inline edit reads the title I give,
> "editable button"
> >
> > IE8/JAWS 10
> > -Navigating with arrow keys, user hears:
> > "Blockquote. The quick brown fox jumped over the lazy dogs [BUTTON] and
> then dot dot dot.
> > - shift tabbing and tabbing to inline edit reads "over the lazy dogs
> [BUTTON]"." i.e.: regardless of JAWS' configuration, the title added is not
> read. ???
> >
> > Next steps:
> > - user testing
> > - enhance Fluid's inline edit demos with titles so they're UX test-ready
> & close FLUID-2652.
> > - What is a meaningful title attribute for an inline edit? Some
> possibilities: "Editable button". "Editable text". I'll be asking this to
> the testers.
> > - update API so end users account for need for titles?
> > - graceful degredation for browsers/ATs that don't support ARIA?
> >
> > Any other suggestions or issues? Justin did I miss anything?
> >
> > Thanks,
> > Alison
> >
> >
> > _______________________________________________________
> > fluid-work mailing list - fluid-work at fluidproject.org
> > To unsubscribe, change settings or access archives,
> > see http://fluidproject.org/mailman/listinfo/fluid-work
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20091208/146e242b/attachment.html>