enhancing screen reader ux of inline edit

[Alison Benjamin]

I like your suggestion Jess, I will do that.

On Wed, Dec 9, 2009 at 9:26 AM, Jess Mitchell <jessmitchell at gmail.com>wrote:

> Awesome stuff Alison.
>
> I'm wondering if an approach we can take on the wiki Accessibility page is
> to list the JIRA #s next to each component?  what do you think?  So, the
> JIRA you've created here would be listed under inline-edit and perhaps you
> could put a very few details about what inline edit does already from a JAWS
> user perspective.  too much?
>
> J
>
> On Dec 8, 2009, at 9:51 PM, Alison Benjamin wrote:
>
> 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
>>
>>
> _______________________________________________________
> 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/20091209/681d49e9/attachment.html>