| Project: | Edit |
| Version: | 8.x-1.x-dev |
| Component: | Accessibility |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | a11y, needs accessibility review |
Issue Summary
Problem/Motivation
Activating edit mode through the Edit module shifts the user from a viewing experience to an interaction experience. The user interacts with the content no longer as a consumer, but as an editor. For this reason, the components that respond to tabbing navigation (pressing the tab key to jump from one interactable component to the next) must change to reflect an editing workflow rather than a content consumption workflow.
Proposed resolution
When a user activates edit mode, re-flow the page tabbing composition and order. The core overlay module has an example of this process in the Drupal.overlay.makeDocumentUntabbable and Drupal.overlay.makeDocumentTabbable methods.
Remaining tasks
Propose a patch.
User interface changes
Keyboard users will note that upon entering edit mode, that tab index of the page's components will change. Only editable fields and toolbar controls will be accessible from the keyboard.
API changes
None.
Comments
#1
This are the two issues I've run into during the first day of development. I'm working to resolve these.
1) Getting a list of all the predicate elements from create.js is difficult. Create has the concept of a subject analogous to a node, and a predicate, analogous to a field in that node. The edit DOM service has a method findSubjectElements that will return all the subject elements (wrapped in jQuery), but the findPredicateElements method requires that an single jQuery element be passed in. So to get the predicates, one must call findPredicateElements on each item found by findSubjectElements and push the results into a global list. Not efficient or dynamic, but I've got a workable solution in place at the moment.
2) The markup around an editable predicate is a set of divs. Divs are not included in the set of elements highlighted by tabbing through the DOM. Getting a div to show up in this list is proving difficult. Add a screen reader into the mix and ARIA markup and it gets crazy. This is my biggest challenge right now.
#2
#3
I went and jammed key press management into app.js. It's really not pretty, but it works in principle.
Next steps
I based this patch on patch 31 from #1824500-31: In-place editing for Fields
#4
I set up a testing site. These are the details:
URL: http://edit.qemistry.us/
user: tester
password: tester
#5
Wow :) This works great - asked the team over Skype to chime in.
#6
I just did a quick accessibility test without a mouse and it works quite well. I haven't seen how or if it is using ARIA, but it would definitely help to see that this is added.
#7
mgifford, I haven't gone through and added ARIA markup yet. That's today's goal. I did the initial pass without audio just to get the JavaScript working. The second pass will be to make it usable.
One question I have is "Should focus move automatically to the first editable page element (a div that wraps one or more form elements) when the state of the page changes from view to edit"? Currently I'm severely constraining the scope of the reachable elements on the page as one passes through different modes of editing -- edit mode, editing a single entity, confirming discard of changes.
After this next patch, I'll need feedback on whether folks using the UI without audio have a good sense of what state the application is in, what their options are and how to get between the states.
#8
This patch should satisfy this issue. The only difference from #3 is the addition of comments.
I'm moving further a11y work to #1851092: When entering edit mode, inform users through the aria-live aural update interface about the state of page.
The goal this week is to get a solid basis for interacting with edit through keyboard input for the initial commit of the feature. Then, once in 8.x, we'll have the opportunity to collect a wider range of feedback and improve the experience faster.
#9
Committed. This is so cool. I changed an image through in-place editing without using my touchpad :D
jessebeach++
http://drupalcode.org/project/edit.git/commit/6843d86
#10