Page MenuHomePhabricator

Review accessibility requirements
Open, Needs TriagePublic3 Estimated Story Points


General Task

We should define accessibility criteria that are the most important for us in the feature development of the Tech Wishes project. Our general approach throughout the Wikimedia projects is to follow WCAG 2.1 Level AA. See this helpful list of the WCAG. You can find a spreadsheet collecting our thoughts here

Original Task

Investigation to find out to what degree the new UI meets accessibility criteria - specifically, on visual and physical impairments:

    • Support for Screenreader
  • Use a screen reader to step through the interface and it's worklow
    • Support for keyboard navigation
  • Try to solve an edit conflict with the keyboard only
    • Support for impaired color vision
  • Check out some tools to test color vision (German - last two items in table) (English)


Things we can do:

Event Timeline

WMDE-Fisch set the point value for this task to 5.Feb 10 2020, 11:18 AM

I went through the workflow using the WAVE analyzer, and it flagged a few things:

  • The textareas are missing a form label, both the text in common and text to edit boxes.
  • Radio buttons are not enclosed in a fieldset.
  • Text in the disabled textarea has low contrast (light gray on white).
  • The save "Cancel" button has low contrast (red on gray).
  • Beta feature notice has a link text that doesn't make sense out of context: "on this page". Instead, we could link "leave feedback". Same with the other popup after simulating resolution, we link "here" when we could alternatively link "provide us with your feedback".

More notes, while using the Orca screen reader:

  • Help popups don't receive focus and are not read aloud.
  • Help popups may have z-index issues:

  • There are no cues linking the "latest revision" and "your revision" columns with the radio buttons or textboxes.
  • I know how to evaluate the radio button -> pencil icon -> edit text -> check box workflow, other than to say that it seems really difficult to navigate with a screen reader.

I'm testing using NVDA (free, Windows, recently took over as the most popular screen reader) and the workflow isn't as difficult as I had expected. The lack of labels is still an issue, but it's nearly possible to use. Additional issues I noticed:

  • When editing a textbox, the <tab> key jumps to the next textbox, but it would be more useful to jump from the textbox content to the check-mark button to save my edited wikitext. The tab index of the check-mark and discard buttons are actually lower than the textbox.
  • T245119: There may be a bad interaction with VisualEditor. I went through the conflict workflow, the only noticeable weirdness is that I intentionally did not click a check-mark button to save my changes. Publishing changes worked as expected, but when I returned to the page "Read" view, I saw a "restoring changes" notice. Page text was still edited as expected. However, when I click "Edit" again, VE asked if I want to restore a previous edit, and clicking "Yes" caused the text to be reverted to its state prior to the conflict workflow (my initial edits were present, but not my conflict-resolution edits).
  • Popups are not read by NVDA.
  • Guided tour indicators are not focusable.
  • The focusable elements act like they are in two groups. The text boxes are in the same group as linked help text and the "cancel" button. But the edit summary and "publish changes" button are in a different group. It turns out, they are all tabbable but the tab indexes wrap around the document at the dividing point between these quasi-groups.
awight changed the point value for this task from 5 to 0.
awight changed the point value for this task from 0 to 3.
awight added a subscriber: awight.