Accessibility plan for Edit module

Issue Summary

Problem/Motivation

We had a huuuuuuuuuuuuuuge discussion on accessibility of the inline editing capability from Spark at the Toronto Accessibility sprint. Here's the outcome of that:

In general, when approaching accessibility, there are two personas you're concerned with:

1) Keyboard-only users, who can see what's going on but don't have a pointing device.
2) Screenreader users, who are keyboard-only users, but without the benefit of being able to see what's going on.

So we need to think of this in terms of what both of those audiences would want to do, without stabbing themselves in the face 500 times. :) So let's step through the flow. I've *bolded the things that need to change, and/or need special accessibility attention.

1. Browsing through the site, arriving at a page, spotting a typo (nothing special accessibility-wise).
2. Tab through to the "Edit" toolbar item at the top (we're assuming here that we're moving to Jesse's toolbar design rather than how Edit module works right now) and hit Enter.
3. This expands the tray, which should show a *Quick edit mode toggle (which should become a "button" type with Aria style of "pressed" when it is toggled on ... we should remove "View" here because then the difference between Edit module's "View" and Node module's "View" is unclear and confusing). Hit Enter to turn it on.
4. This overlays a white sheen as it does now, and outlines the things on the page that are editable. *We need to style these differently than they are currently, e.g. a dashed outline. Right now they look like all elements have focus and they do not. This is confusing.
5. *Tabbing from this point only tabs between editables (and then eventually back to the toolbar + quick edit toggle). So you should not be able to tab around to links inside the node body, for example, or on non-editable sidebars, when "Quick edit mode" is on.
6. *As I tab through in a screenreader, I'll hear something like: "Title field. Editable. Press Enter to edit." (TODO: How to implement this?)
7. If I hit Enter, the window opens up with the contents of whatever in it. Here there are three different behaviours, depending on the type of field:
   • For a "show me a widget" field, *put the cursor on the first focusable element. Currently, this is the Save button (well, currently, it's the Label but *the Label should not be focusable, but probably eventually this will be the Cancel button when we move Save to the top (?). This is important so that screen reader users can discover that Save/Cancel exists.
   • For a "content editable" field (plain textfield), or a WYSIWYG field, the cursor should be positioned in just before the first character of the text. However, if you click into the field with a pointing device, it should continue to position the cursor directly where you clicked, as it does now.
8. If I shift-tab from the place I'm at now, *the dialog closes, and I'm back to my pre-existing editable having focus. A screen reader user should hear something like *Title field dialog closed. as this happens. This is equivalent to clicking somewhere off the window for a pointing device.
9. Similarly, if I tab through all possible fields, without changing any of the field values, *the dialog closes, and the next editable (e.g. Body) now has focus. Once again, a screen reader user hears something like *Title field dialog closed. as this happens. This is equivalent to clicking somewhere off the window for a pointing device.
10. If I tab through into one of the fields on the window and edit its contents, and then tab out (either by shift+tabbing several times or tab-tabbing several times) I will get a modal dialog that warns me about unsaved changes, and either a "Discard changes" or "Save" option (same as it works now — assuming the modal is accessible, this is fine accessibility-wise). *We'll have to revisit this if/when we move to a single save button + draft revisions option.
11. For just editing, you tab through, change values, tab through, change values. To save, you either tab once more and invoke the modal dialog that warns you about dropping your changes, OR you shift+tab to go back up to the save button and click it. I noted that this seems a bit odd to rely on the "exception" behaviour for inline editing, and questioned whether we should repeat the save/cancel buttons at the bottom again, but Everett said this is the kind of detail we should test later on once it's committed and tweak from there.

A few technical challenges:

- ARIA has roles like "has pop-up" but not like "is editable." We'll need to figure out a way to explain to people what's happening.
- Need to be able to make things that are normally focusable non-focusable so you can tab between editables.We'll have to leave those elements there with the presentation role, but strip out all of their children dynamically.
- Everett also said that since Drupal 7, where we had to be careful about using more advanced accessibility features such as ARIA roles, but people will have had 3-4 years to upgrade their technology. So in the same way we don't support IE 6 and 7 in D8, we can say we don't support screen readers that don't support ARIA roles, as long as we're dealing with "advanced" editing like this, and not the basic "Edit tab on the Node page" editing.

Proposed resolution

We'll address this issue in three ways:

1. Make the activation and deactivation of edit mode a one-click operation.
2. Provide appropriate feedback through auditory means to the user so that the state of the page is expressed sufficiently.
3. Create a logical tabbing structure in edit mode so that non-sited and keyboard-only users aren't traversing through unrelated parts of the page.

Remaining tasks

#1851046: Edit mode should be activated when clicking the Edit toolbar tab
#1851092: When entering edit mode, inform users through the aria-live aural update interface about the state of page
#1851074: Isolate tabbable fields/links to editable fields and Edit module control components when edit mode is enabled
#1851144: Use <button> for elements that are buttons

User interface changes

TBD.

API changes

None.