User:DWalden (WMF)/A11y playbook draft3

Introduction
Imagine a world in which every single human being can freely share in the sum of all knowledge. About 15% of the world's population lives with some form of disability. Therefore, the Quality and Test Engineering team, along with the development teams, must ensure people with disabilities are able to interact with Wikimedia products.

"Web accessibility methods ensure that people with impairments or disabilities can perceive, understand, navigate, interact with, and contribute to the products we all create. Just as importantly, many methods improve general usability, resulting in easier-to-use interfaces that are Perceivable, Operable, Understandable and Robust for everyone."

The WMF Design Style Guide and Principles
The Wikimedia Design Style Guide ensures a consistent look and behavior for our products. Our interfaces are our brand. These principles and guidelines aim to help designers and developers with their Wikimedia projects, as part of the Foundation or in a volunteer capacity. The style guide features unique focus areas like accessibility, internationalization, and localization.

Also, according to Wikimedia's Accessibility Statement, the Foundation aims to support WCAG 2.1 AA guidelines. Make sure you read them carefully and incorporate them to your daily testing procedures.

Inclusive Product Development
Accessibility forms part of the Inclusive Product Development guidelines. The guidelines include factors typically outside accessibility testing, such as bandwidth, mobile responsiveness, platforms, internationalisation, but you can decide whether you want to include these as part of your accessibility testing.

Techniques
There are different strategies to testing accessibility. In this section we’ll outline 5 approaches.


 * 1) Coverage-based
 * 2) Coverage based on items in WCAG21
 * 3) Coverage based on types of disability
 * 4) Risk-based
 * 5) Which functionality is likely to cause users the most problems?
 * 6) For an/each area, identify what kinds of accessibility issues it will most likely have
 * 7) For an/each WCAG21 item, identify which areas are mostly likely to have that particular issue
 * 8) Activity-based
 * 9) Follow a script or checklist depending on the activity or product you are testing.
 * 10) * e.g. https://www.w3.org/WAI/test-evaluate/preliminary/
 * 11) * e.g. Testing checklist for Abstract Wikipedia
 * 12) * e.g. https://www.a11yproject.com/checklist/
 * 13) Run accessibility checking tools (e.g. aXe, WAVE)
 * 14) Perform exploratory testing (possibly using assistive technologies, e.g. screen readers)
 * 15) Test as particular personas
 * 16) * e.g. https://www.w3.org/WAI/people-use-web/user-stories/ and https://www.w3.org/WAI/people-use-web/abilities-barriers/
 * 17) Evaluation-based
 * 18) Automated accessibility checks (e.g. aXe, perhaps run in CI)
 * 19) Comparison with WCAG21 guidelines (quickref) and techniques
 * 20) People-based
 * 21) Testing by end-users
 * 22) Testing by accessibility experts

VisualEditor watchlist functionality
When saving an edit with VisualEditor, the user has an option to add it to their watchlist for a particular amount of time. It had been mentioned that the UI controls which allow a user to do this might have accessibility problems. I wanted to do some accessibility testing following the playbook above. I give a report below, identifying the techniques I used.



I only had a limited amount of time to test this. Therefore, I took a focused approach.

First, I used Firefox’s default accessibility checker (available via devtools). This found two issues related to the watchlist elements, but I consider them to be false positives (the failure was “Clickable elements must be focusable and should have interactive semantics”, but I believe we are following all the recommendations mentioned there). This is using technique 4.1 "automated accessibility checks".

Then, I used the aXe Firefox extension. This found no accessibility issues with the watchlist elements. Again, following technique 4.1 "automated accessibility checks".

I then took a risk-based approach to identify the accessibility issues the functionality is most likely to have (technique 2.2 "for an/each area, identify what kinds of accessibility issues it will most likely have"). I thought being able to access the UI controls using only a keyboard and having those controls read correctly by a screen reader were most likely.

For keyboard only use, I tested interacting using only a keyboard (technique 3.4 "test as particular personas", taking on the persona of a user who cannot use a mouse). I found I could do everything with a keyboard I could do with a mouse. The tabbing order was logical. I was able to achieve my task.

For screen readers, I checked that we were following the correct WCAG21 guidelines (technique 4.2 "comparison with WCAG21 guidelines and techniques"). I assumed that guideline 1.1 (Text Alternatives) was the correct guideline we should be following to make it possible for screen readers to read our UI. I identified that the checkbox (“Watch this page”) is using technique H44 and using a element to identify it. The dropdown is following technique ARIA9, using elements with the attribute “aria-labelledby”. These are marked by WCAG as techniques “sufficient” to ensure we have successfully met guideline 1.1.

To make sure, I could have installed a screen reader and checked that it read the UI controls correctly, but I did not deem it necessary.

Colour contrast of IPInfo tool
See T309828. Use of technique 4.2 ("comparison with WCAG21 guidelines and techniques") and WCAG21 technique G18.

Could also have used technique 3.2 ("run accessibility checking tools") as accessibility checking tools like aXe can find content with insufficient colour contrast.

Phonos
See Help:Extension:Phonos/QA/Accessibility.

Tools

 * aXe
 * Browser extensions: Chrome, Firefox

Documentation and useful links

 * https://www.w3.org/TR/WCAG21/
 * https://www.w3.org/WAI/WCAG21/quickref/
 * https://www.w3.org/TR/WCAG-EM/#reading
 * https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/
 * https://ukhomeoffice.github.io/accessibility-posters/posters/accessibility-posters.pdf
 * https://en.wikipedia.org/wiki/User:Montehurd/accessibility
 * https://design.wikimedia.org/style-guide/design-principles_accessibility.html
 * https://doc.wikimedia.org/codex/main/style-guide/accessibility.html
 * https://www.mediawiki.org/wiki/Accessibility_guide_for_developers