Settings Tray Accessibility: Improve tabbing

This probably needs some clarification.
Should the tabbing only be restricted to contextual links during "editing mode"? When I first enter editing mode my tabbing is indeed restricted to context links, but this may be changed by #2784577: Outside-in Accessibility: Ensure the tray is easily found in screen readers
When I refresh the page I am still in "editing" mode but I am still able to tab among the admin menu and my tabbing is not restricted to context links. Is this part the bug?

Just tested this with the ChromeVox screenreader while tabbing.

I can confirm tabbing is now restricted to contextual links when in editing mode as planned.

However it took some time to figure out how to open the inside out dialog. And it is troublesome to do.

Steps to take:
1) Activate edit mode
2) Tab through contextual links buttons
3) Press enter to show the contextual links
4) Tab until you hit 'Quick edit'.
5) Press enter on the 'Quick edit' link.

For someone using a screen reader this is not at all a 'quick' edit.

I wanted to quickly configure some block settings, so in edit mode the first thing I did was choosing the 'Configure block' link.
However both that link as any other link in the contextual links list (that is not 'Quick edit') navigates away from the current page.
That I didn't pick the 'quick edit' link is probably because I was already known with the Quick edit module which is different from Outside in.
So the link name is bit confusing for site builders, but for end users it seems ok!

The easiest (small) improvement I see here is: making sure that the 'Quick edit' option is always the first item in the contextual links. The second improvement would be to indicate somehow which links navigate away from the current page.

Even better would be that in edit mode, when tabbing (through the blocks) you actually tab through two links per block:
the first being Quick edit, the second being the contextual links link, that gives you the option to show all other edit links that navigate away from the page (advanced links).
This would also be more in line with what you do as a non-disable person, because they can just click the dotted outlined block directly.
In non edit mode, it would be oke to show the 'Quick edit' link again in the contextual links list per block.

Since this issue is marked as 'must have' I think we could close this issue and use my input for a separate issue which proposes some ux/u11y improvements.

Off topic: it seems from a quick test that Quick Edit (not the link but the module) is not at all accessible.

So, #2784567: List "Quick edit" before "Configure" in contextual links while in Edit mode actually fixes the most pressing concerns.
We will now use this issue to improve tabbing even more.

I reviewed the tabbing.

My analysis:

1. First tab target is still "skip to main content". Good.
2. Second tab target is no longer "Manage" (pointing to /admin) but "Edit", to trigger Contextual Links' edit mode. This may be okay, but it certainly would cause a change for existing users. It likely makes more sense though.
3. Therefore this also still uses Contextual Links' tabbing constraints. This makes sense, because Settings Tray is merely progressively enhancing Contextual Links — it's building on that existing infrastructure. However, that also means you're tabbing to contextual links' gears, if you open one of those, you get the contextual links, and if you trigger a "Quick edit" link on a block, you'll get the Settings Tray. This means you're NOT tabbing over all blocks. This is okay, and desirable, because otherwise we'd be breaking contextual links. The only alternative is to NOT piggyback on Contextual Links' "edit" toolbar tab, and instead add our own. Which would be confusing. So this (the inability to tab across all blocks) is the right compromise I think.
4. Upon triggering "Quick Edit", the Settings Tray dialog opens, and focus automatically shifts to the Settings Tray dialog. This is great (we get this for free because jQuery UI Dialogs put a lot of effort in accessibility).
5. Tabbing to the "Advanced block options" link has a barely discernuble :focus style, which means that as a sighted keyboard user, it's very hard to not lose a sense of location.
6. Tabbing is automatically constrained to just the Settings Tray dialog — yay! If I keep pressing the tab key, I cycle through all form items and the "close" button of the Settings Tray.
7. However, when I close the Settings Tray dialog, my previous location is lost/forgotten — I'm back at the root of the page, and have to tab back all the way to where I was before I triggered the "Quick Edit" contextual link.

Only points 5 and 7 need further attention. I think Normal priority is appropriate. As far as tabbing is concerned, I think the Settings Tray module actually meets the accessibility gate! There's room for improvement, but overall, it works fine.

@dmsmidt:

Even better would be that in edit mode, when tabbing (through the blocks) you actually tab through two links per block:
the first being Quick edit, the second being the contextual links link, that gives you the option to show all other edit links that navigate away from the page (advanced links).

I like the idea.

This would require a change in the Contextual Links module so that it provides the necessary infrastructure: it'd then be up to that module to mark each label as "in-place" or not. Also note that it's possible for modules to add contextual links on the fly, such as Quick Edit, so it'd also require Quick Edit to correctly identify itself as such.
That would not work, because in your proposal there can only ever be one contextual link that performs in-place editing. Otherwise, you'd end up not with two tab targets per contextual region, but 1 for all "external" links plus 1 per "in-place" link.

This would actually be a change that would need to happen in the Contextual Links module — because you'd need to inform Contextual Links that when it initializes its tabbing manager, that there may be additional in-place targets for a particular contextual region. Oh, and those in-place targets may not yet be known, so you'll end up with a race condition (contextual regions are known immediately, since they're marked in HTML, but quick_edit.module adds its links after page load time, after consulting with the server whether the current user is allowed to edit the entities on the page).

So I think what you're proposing needs a follow-up. #9.5 and #9.7 are totally doable in this issue, but what you're proposing is far more complex: it requires changes in 3 modules, and needs to deal with race conditions.

Off topic: it seems from a quick test that Quick Edit (not the link but the module) is not at all accessible.

You're right: #1844220: Make in-place editing keyboard and aurally accessible 😥

Changing to new settings_tray.module component. @drpal thanks for script help! :)

Created #2915759: :focus is is hard to see for links in the off-canvas dialog for the #9.5

Hopefully that issue will just be CSS changes.

Also created #2915762: Return to tab position when exiting dialog opened from contextual link for #9.7
This might be general issue with dialogs and not specific to Settings Tray

I have created a related issue #2919147: When edit mode is enabled new page loads will not have Contextual tabbing constrained
This affects Settings Tray but is Contextual module issue.

Looking back at @dmsmidt's suggestion in #7 that @Wim Leers also like in #10

Even better would be that in edit mode, when tabbing (through the blocks) you actually tab through two links per block:
the first being Quick edit, the second being the contextual links link, that gives you the option to show all other edit links that navigate away from the page (advanced links).

At first I liked the idea but after working on some related tabbing issue that I split off from this issue and trying out the keyboard navigation with a screenreader I think this idea might not be an improvement.(though I very new to this so...)

Let's look at the example of trying to "Quick Edit" the 15th block in the tab sequence in edit mode.

Current Situation

1. Tab 15x to get the 15th block = 15 keystrokes
2. Then to trigger "Quick Edit" link = Enter(to get to contextual link list) + Tab (to select first link) + Enter (to trigger link) = 3 keystrokes

= 18 keystrokes (blocknum + 3 )

With 2 links per block

1. Tab 29x to get the 15th block = 29 keystrokes
2. Then to trigger "Quick edit"(on block itself) = Enter (to trigger link) = 1 keystroke

= 30 keystrokes (blocknum * 2)

So starting with block 4 in the tab order the current way would be less keystrokes, 7 vs 8

I see your point. Do you have another idea to make it clear which links navigate away from the page? Visually it is more obvious.

Just a crazy different idea, could we create a totally different flow for screenreader? Say we add an invisible select list for selecting a block to quick edit. This would be an item in the tab flow before the contextual links, so the 15th block would use 17 keystrokes.
1) enter to activate select (block to quick edit)
2) arrow down until 15th block
3) enter to activate tray

To reach all other contextual links we keep the current logic and it is only one extra tab away.

I'm not up to date on how the new layout features work, but maybe we could combine efforts in tackling accessible navigation. The last demo I saw could use some extra love.

@dmsmidt I don't know about this area to know if the hidden select element is good idea or something that is done other places. It would be kind of link the "Skip to main content" link which is not shown visually until you tab to it. It looks like we use a combination of the classes skip-link, focusable, and visually-hidden for that link. So we could do something link that where becomes visible only when you tab to it.

The "skip to main content" link is not focusable when in "Editing" mode so we would in a sense be replacing the invisible select with that.

Another problem right now is the only way we can make it focusable is in Edit mode is to also add the .contextual class to the select. This is because of how Contextual module invokes the tabbing manager. Also the tabbing constraint message from the contextual module will no longer be accurate. We are running to this same problem here: #2773601-69: Display "You are now in edit mode" prompt when user enters edit mode

So we would need changes to the contextual at the very least to make the message correct.

An update on #2919147: When edit mode is enabled new page loads will not have Contextual tabbing constrained. This bug affects the contextual module even without Settings Tray enabled. For example if you click "Configure Block" and come back to the page.

Also #2915762: Return to tab position when exiting dialog opened from contextual link is a Contextual problem it only surfaced because we found #2764931: Contextual links don't work with 'use-ajax' links(committed to 8.5.x)

I think fixing these 2 problems in the Contextual module, which were found in this issue 🎉, will improve the keyboard navigation experience a lot for Settings Tray but also other uses of Contextual links.

Updated summary reflect new steps for keyboard navigation since #2784567: List "Quick edit" before "Configure" in contextual links while in Edit mode

Closing this issue because all issue have been address or are being address in other issues

From @Wim Leers' review in #9

He only called out 2 points that needed to be fix

5. Tabbing to the "Advanced block options" link has a barely discernuble :focus style, which means that as a sighted keyboard user, it's very hard to not lose a sense of location.

Fixed in #2915759: :focus is is hard to see for links in the off-canvas dialog

And

7. However, when I close the Settings Tray dialog, my previous location is lost/forgotten — I'm back at the root of the page, and have to tab back all the way to where I was before I triggered the "Quick Edit" contextual link.

This is Contextual module issue and it is being addressed in #2915762: Return to tab position when exiting dialog opened from contextual link (review needed there!)

In #7 @dmsmidt suggested

Even better would be that in edit mode, when tabbing (through the blocks) you actually tab through two links per block:
the first being Quick edit, the second being the contextual links link, that gives you the option to show all other edit links that navigate away from the page (advanced links).

But I addressed why that would increase in tab keying in #16

The only other suggest was from @dmsmidt in #17 but that would

create a totally different flow for screenreader?

And since we have something that works now I would suggest that we should create new issue to explore that one if anyone is interested.

thanks @dmsmidt, @webchick, @Wim Leers, @crasx for the work on this! I think the keyboard navigation is already improved and will be more once the rest of the issues created from here are fixed 🎉

The 2 other issue to follow for accessibility relating to Settings Tray are
#2928409: [META] Accessibility issues for Settings Tray
#2919837: Accessibility Issues with Off-Canvas dialog