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


Members fund testing for the Drupal project. Drupal Association Learn more


jessebeach’s picture

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.

Wim Leers’s picture

Component: Code » Accessibility
jessebeach’s picture

Status: Active » Needs work
8.31 KB

I went and jammed key press management into app.js. It's really not pretty, but it works in principle.

Next steps

  1. Move the behaviors into the Backbone app properly.
  2. Add aria roles, states and properties where appropriate.
  3. Test with keyboard/non-sighted users and tweak.

I based this patch on patch 31 from #1824500-31: In-place editing for Fields

jessebeach’s picture

I set up a testing site. These are the details:

user: tester
password: tester

Bojhan’s picture

Wow :) This works great - asked the team over Skype to chime in.

mgifford’s picture

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.

jessebeach’s picture

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.

jessebeach’s picture

Status: Needs work » Needs review
8.42 KB

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.

Wim Leers’s picture

Status: Needs review » Fixed

Committed. This is so cool. I changed an image through in-place editing without using my touchpad :D


jessebeach’s picture

Status: Fixed » Closed (fixed)
Liam Morland’s picture

Issue tags: -a11y +accessibility
rooby’s picture

Version: 8.x-1.x-dev » 7.x-1.x-dev
Issue summary: View changes
Status: Closed (fixed) » Patch (to be ported)

Is there any chance this accessibility stuff can be backported to D7?

Currently if I tab to the quick edit link and press enter my focus returns to the beginning of the page and I cannot tab to the individual editable fields that are in edit mode (my tabbing just skips over the whole editable part).

Wim Leers’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Patch (to be ported) » Closed (fixed)

#12: Yes, there is. But the above is the ancient, rough implementation. We landed the Drupal.tabbingManager in D8 core, but Edit in D8 needs to be updated to use it again after the latest refactor: #1844220: Make in-place editing keyboard and aurally accessible. Once that issue has landed, we'll backport it to the D7 backport of Edit.