Page MenuHomePhabricator

[Spike] How does the sticky header work for screen reader users?
Closed, ResolvedPublic3 Estimated Story PointsSpike

Description

In https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/715629/6/includes/templates/skin.mustache#102 regarding the existing placement of the sticky header at the bottom of the page @nray said:

I'm wondering if accessibility takes a hit if we do this. Consider a user landing on a page, scrolling down to trigger the sticky header and then hitting tab. They might expect to be able to tab through the sticky header first, but now it will be last.

We should review:

  • How this feature would work via keyboard (adding tabindex attributes?)
  • Should the sticky header be tabbable and what order should it be tabbable?
  • Where in the DOM the sticky header is located.
  • Whether a sticky header is useful to screen readers, and if not should it be hidden.

Question to answer

  • What level of accessibility should be provided for this feature?
  • How should the sticky header behave to screen readers?
  • What changes are required to the existing HTML to support this?

Spike outcome

The decision should be documented in the Vector codebase inside the template via a Mustache template. If this is significant work (more than a move/inline comment) please create a new task capturing the work required.

Acceptance Criteria

  • Sticky header is not accessible to screenreaders on desktop via keyboard
  • Sticky header is not accessible via tabbing
  • Sticky header elements are not tabbable in general

QA Results - Beta

ACStatusDetails
1T290201#7452820
2T290201#7452820
3T290201#7466944

QA Results - Prod

ACStatusDetails
1T290201#7497653
2T290201#7497653
3T290201#7497653

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptSep 1 2021, 8:32 PM

I'm wondering if accessibility takes a hit if we do this. Consider a user landing on a page, scrolling down to trigger the sticky header and then hitting tab.

Just a note, a screenreader probably does none of these things (a keyboard user might, but that's another type of accessibility)

Desktop screenreader:

  • screenreader will announce current position in the DOM
  • user will use navigation actions (tab, TOC, a landmark menu, and/or various keyboard combos with the arrow keys) to skip through the dom. The dom position is read out after each 'navigation' action. (DOM order matters a lot here and generally should follow display order. Actually a good simulation is to disable CSS)
  • scrolling doesn't really exist (the current position will automatically try to scroll the page to bring that point in view), but some users (with some vision) might scroll using a mouse.
  • as long as the element isn't display:none'ed, its part of the dom and you can generally navigate to it.

Mobile screenreader:

  • screenreader will announce current screen/window
  • user moves thumb accross the screen and screenreader announces what is underneath the thumb.
  • user uses gestures to scroll, click, swipe, drag etc
Jdrewniak removed the point value for this task.
Jdrewniak set the point value for this task to 3.

I've tried my best to answer all the questions above:

How should the sticky header behave to screen readers?

The header should be hidden to screenreaders, which can already access the content via landmark roles, element type, and other navigation methods. Making it accessible would just add more duplicated content for a user to sort through. In the very rare case of a mobile user navigating Desktop Vector with a screenreader via touch, the sticky header would also prevent the screen reader from announcing content underneath the header. Hiding the header can be achieved by adding an aria-hidden attribute

How this feature would work via keyboard? Should the sticky header be tabbable and what order should it be tabbable?

Because we are using aria-hidden, the sticky header can't contain focusable elements (1, 2). This isn't really a concern for users navigating by keyboard/tab because the content is duplicated and not very useful to access via tab anyway (you would have to tab through the entire page to access the header, and moving the header up in the tab order would also be bad).

This means we need to add tab-index="-1" to be added to all the links/buttons in the sticky header. For the majority of links/buttons, this can be done with a small change to the Button.mustache template. Because the user menu is copied, that has to be handled separately, likely in stickyHeader.js

Where in the DOM the sticky header is located.

Since it will be removed from the tab order and hidden to screen readers, the header can remain located at the end of the HTML. I'd say its preferable to the top of the DOM in case CSS doesn't load.

bwang removed bwang as the assignee of this task.Sep 21 2021, 4:34 PM
bwang added a subscriber: bwang.

Change 722650 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Update sticky header to be hidden to screen readers and not tabbable

https://gerrit.wikimedia.org/r/722650

The header should be hidden to screenreaders, which can already access the content via landmark roles, element type, and other navigation methods. Making it accessible would just add more duplicated content for a user to sort through.

I agree with this assessment. Currently, the sticky header will contain the following items:

  • logo (homepage link)
  • Article title
  • search
  • notifications/alerts
  • language links
  • edit button
  • personal menu

All of which are accessible via other means on the page. The sticky header will mostly serve as a shortcut to these actions as well as a navigational aid (by showing the title when scrolling down the page). In the future though, we should be mindful not to add features to the sticky header that aren't already available elsewhere on the page.

@Jdrewniak fyi we've removed notifications/alerts from the user menu in the sticky header

cjming added a subscriber: cjming.
nray reassigned this task from nray to Jdrewniak.

Change 722650 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Update sticky header to be hidden to screen readers and not tabbable

https://gerrit.wikimedia.org/r/722650

Edtadros added a subscriber: Edtadros.

@nray, I'm unclear on the test criteria. I've read through the notes. I'm not able to access the sticky header using the keyboard for navigation with VO (I'm very green with VO). I was able to however read some of the elements on the sticky header with VO if I used the mouse.

Screen Recording 2021-10-08 at 5.59.20 AM.mov.gif (970×860 px, 1 MB)
it's a long gif, took me a while to get the keystrokes right, so you'll see a long pause initially.

@Edtadros sorry about that. @bwang Would you be up for providing the desired QA steps here as well as answering Edward's question above about the mouse access (I'm honestly not sure how problematic that is)?

@Edtadros I updated the description with some AC, sorry forgot to include those. It's fine that the elements are read with the mouse, that isn't really a common way to navigate and it's a bit unavoidable. It might be more of a concern on mobile because more mobile screenreaders navigate via touch, but the sticky header is disabled for that so its fine.

I did a quick run through locally, and it looks like the edit icons are still tabbable, which should be a quick fix. Since @cjming worked on that last it might make sense to assign this to her.

Hey @cjming, It looks like the edit button is tabbable. Checkout T290201#7412198, more than a few seconds after I click on the search button, I'm able to tab to the edit button.

Change 730355 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[mediawiki/skins/Vector@master] Make edit icons in sticky header untabbable for VO/screen readers.

https://gerrit.wikimedia.org/r/730355

Change 730355 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Make edit icons in sticky header untabbable for VO/screen readers.

https://gerrit.wikimedia.org/r/730355

hi @Edtadros - this is ready to test again -- edit buttons in sticky header should now be untabbable (is this a word?)

Test Result - Beta

Status: ❓Need Clarification
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: Sticky header is not accessible to screenreaders on desktop via keyboard
I tried in vain to get the focus onto the sticky header with VO.

✅ AC2: Sticky header is not accessible via tabbing
Same as above

❓AC3: Sticky header elements are not tabbable in general
@cjming, I can tab from the search edit field to the search button which is expected, but after that, I click on the user menu and I am able to tab through the menu items. I'm not sure if that is expected behavior. Both require mouse-clicking on the element in the sidebar to get focus.

Screen Recording 2021-10-22 at 5.53.52 PM.mov.gif (1×1 px, 901 KB)

Test Result - Prod

Status: ✅ Pass
Environment: enwiki
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: Sticky header is not accessible to screenreaders on desktop via keyboard
I tried in vain to get the focus onto the sticky header with VO.

✅ AC2: Sticky header is not accessible via tabbing
Same as above

✅ AC3: Sticky header elements are not tabbable in general
Same as above.