FLUID-2652: JAWS announces that an inline edit area is a button

Description

A protocol for accessing and using the inline edit area must be made available to a JAWS user:

• JAWS announces that an inline edit area is a button.
• 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.

"Redo" "Undo" buttons also need to be accessible to a screen reader.

Environments

MacBook running JAWS 10 on XP with VMWare
Windows XP / JAWS 10

Attachments

• FLUID-2652.txt
• FLUID-2652-InlineEditAreaButton.txt
• FLUID-2652IoCImplementation.txt
• FLUID-2652IoCImplementationPart2.txt
• FLUID-2652IoCWithComments.txt
• textEditButtonFocus.txt

Comments

• Alison Benjamin commented 2009-05-11T13:56:35.000-0400

  Here are instructions on how to replicate this bug with JAWS 10 & IE 7.

  1. Tab into the "Section Info" frame

  2. Tab to first Inline Edit area. JAWS reads: "Astronomy 7 A P 001 LEC Button"

  3. Press ENTER to enter Inline Edit field. Note: this is an unintuitive action for a JAWS user: they assume the "button" is not editable. JAWS reads: "Enter sections edit Astronomy 7 A P 001 LEC type in text"

  4. Type in "Hello". Press ENTER to save. JAWS reads "ENTER Astronomy 7 A P 001 LEC Button". Note that the change made in Step 3 ("Hello") is not read, and that JAWS does not announce that a save has been made.

  5. Refresh the JAWS virtual buffer (press INSERT-ESC). JAWS reads: "Screen updated," but the change made in Step 3 is not read. Press TAB and the SHIFT-TAB to refocus onto the Inline Edit to get JAWS to read the changes made. JAWS reads: "Shift tab hello button".

  Issues:
  Instructions needed:
  -how to enter the inline edit field
  -how to save an edit

  Notifications needed:
  -user should be notified of change is saved
  -user may need to know Virtual Buffer needs to be refreshed to see changes.

• Justin Obara commented 2009-05-14T14:05:38.000-0400

  a11y issue

• Michelle D'Souza commented 2009-09-15T12:36:24.000-0400

  I've committed the patch so that user tests can be run with this fix. I think the 'hiddenForScreenReaderUsers' CSS class should be made part of FSS.

• Justin Obara commented 2009-11-06T16:22:24.000-0500

  using FF 3.5

  In JAWS it will sometimes read the editable text followed by "button, use space bar to activate". At other times it will just read the text followed by "button".

  In NVDA it will read the text and announce that it is a button and is clickable. It also reads the undo and redo buttons as "u" and "r" respectively.

• Justin Obara commented 2009-11-24T14:06:04.000-0500

  Code Review Comments: FLUID-2652b.text
  ==================================

  So in this incarnation, the view and edit mode are read the same way. This may be confusing and may not suggest to the user how to switch modes. You have probably put more thought into this than I have though, so it would be interesting to know what some pros and cons are with this implementation versus others.

• Colin Clark commented 2010-03-30T19:26:35.000-0400

  Justin and Alison, can you comment on where we're at with this issue?

• Justin Obara commented 2010-09-03T12:33:09.233-0400

  At the dev meeting on Sept 1, 2010 we talked about a couple of accessibility issues. At that time it was decided to do the following for this issue.

  1. Pick a meaningful role and use aria-describedby to further explain the interaction

  2. Embed a toggle button after the editable text--text no longer gets focused, but the toggle button does instead. Text is still given "focused" style. The toggle button element will need enough of a label to make sense to the user

  The toggle button can be invisible. It will be actionable by the keyboard, and will place focus styling on the text when tabbed to. The text itself will be actionable by the mouse, but not the keyboard.

  http://old.nabble.com/accessibility-issues-to-think-about-to29522497.html

  I believe we will try to code up both options and test with a user.

• Justin Obara commented 2010-09-09T13:51:44.314-0400

  For Infusion 1.3 we will start by doing option 2 from previous comment.

• Mike Lam commented 2010-09-22T12:28:55.267-0400

  Adds a toggle button to the end of the container in order to comply with the screen reader. We spoke with Antranig regarding the use of IoC to handle our accessibility options. IoC is not included in this patch, however, this may be a good point to make a decision on its usage.

• Mike Lam commented 2010-09-24T15:57:20.910-0400

  Patch FLUID-2652IoCImplementationPart2.txt was added for better naming conventions of the new functions and variables.

• Antranig Basman commented 2010-09-24T16:59:25.066-0400

  Hi - this patch looks pretty good. However, the configuration of the "blurHandlerBinder" needs to be broken out so that the various integrations (for example, selection dropdown or rich text) can make use of the core implementation by just contributing additional "dead man's blur" elements.

• Justin Obara commented 2010-10-04T15:38:04.963-0400

  "Bug Parade Infusion 1.3"

• Mike Lam commented 2010-10-07T10:48:52.855-0400

  Appended an image button to the end of the inline edit container. The inline edit is now more screen reader friendly as the button is given an ARIA role of button and the inline edit container is given an ARIA tooltip.

• Justin Obara commented 2010-11-10T12:03:48.070-0500

  Moved the textEditButtonFocus.txt patch from FLUID-3821

• Justin Obara commented 2010-11-10T12:14:53.862-0500

  Committed Mike's patch ( textEditButtonFocus.txt ) which fixes the focus issue when leaving edit mode.

• Michelle D'Souza commented 2010-12-01T17:01:47.738-0500

  I code reviewed this with a whole group of Inline Edit JIRA issues for 1.3 and it is fine.