Page MenuHomePhabricator

[Spike] Determine best approach for focusing from the sidebar button into the sidebar
Open, MediumPublic0 Estimated Story PointsSpike

Description

Question we are trying to answer

In T261802, we moved the sidebar out of the header (where it was adjacent to the sidebar button) and into the .mw-workspace-container. Although this move helped with the search in header work (T249363) and will likely be necessary when we make the header sticky, it had at least one disadvantage. Because the DOM order changed, users are no longer able to tab (or use another focus management technique) directly from the sidebar button into the sidebar. Currently, they are forced to tab through the header contents before reaching the sidebar.

What is the best approach to bring this behavior back? We might have to use JavaScript to achieve this.

Acceptance Criteria

  • A POC patch is made demonstrating the proposed approach

Sign-Off Criteria

  • Create a task for the implementation using the proposed approach as a reference

Related Objects

StatusSubtypeAssignedTask
ResolvedGoalovasileva
OpenNone
Resolvedovasileva
ResolvedSpikeovasileva
ResolvedSpikephuedx
Resolvedovasileva
OpenSpikeNone
OpenSpikeJdrewniak
ResolvedSpikeovasileva
Resolvedovasileva
ResolvedBUG REPORTmatmarex
Resolvedovasileva
ResolvedJdlrobson
Resolvedphuedx
Resolvednray
ResolvedMayakp.wiki
ResolvedMayakp.wiki
Stalledovasileva
OpenNone
ResolvedEdtadros
OpenNone
OpenNone

Event Timeline

nray created this task.Sep 14 2020, 10:38 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 14 2020, 10:38 PM
nray updated the task description. (Show Details)Sep 14 2020, 10:39 PM
nray updated the task description. (Show Details)Sep 14 2020, 11:44 PM
Jdlrobson added a subscriber: Jdlrobson.

Spikes are analysis so moving this to upcoming for scheduling.

Jdlrobson triaged this task as Medium priority.Sep 17 2020, 11:06 PM
Jdrewniak added a comment.EditedMon, Sep 28, 11:34 AM

The technique of modifying focused elements with JS is typically called focus trapping (or looping). There's a good writeup on medium of the general implementation here: Focus Trapping for Accessibility (A11Y) . It generally involves checking which element is focused and changing the next focused element during a keydown event.

What I hadn't realized before is that this trick doesn't work on mobile! This is because keyboard events aren't emitted on mobile.

iOS & Android aren't our primary concern since Vector is a desktop skin, but it would be nice to make this as mobile friendly as possible. As an alternative, the author of the above article suggests that instead of switching the focused element, you mark all other elements you don't want focused with aria-hidden=true.

Another option would be to manage all the tabindex values ourselves (or at least the first three). We could hardcode some tabindex values to positive integers like:

  1. jump-to-content link tabindex="1"
  2. menu button tabindex="2"
  3. sidebar menu tabindex="3"

I did a quick check to see what happens when the sidebar is closed in that scenario, and it seems like it is skipped correctly, even with a positive tabindex value.