Background on Accessibility
W3C defines standards for Accessibility. The latest is WCAG 2.1 (Web Content Accessibility Guidelines) There aren’t specific standards for Mobile, but W3C is very clear that the WCAG 2.1 standards also apply to mobile apps.
https://www.w3.org/WAI/WCAG21/quickref/
There are 3 levels of accessibility that can be achieved: A, AA and AAA (lowest to highest).
We haven’t defined targets for Accessibility yet. As things stand, it looks like we fall well short of the A standard, which looks like an issue. The A standard is the minimum requirement to be able to claim to be WCAG compliant - if you don’t achieve this, you can’t claim to be “Accessible” in any real sense.
Some reference points, arguing that we need to do better on Accessibility:
The Johns Hopkins paper on Ethics in DCT explicitly calls out “A commitment to equity means a commitment to ensuring that the benefits and burdens of DCTT are distributed fairly.” It does not explicitly mention Accessibility, but I believe that this implies we must make efforts to make the product accessible to disabled people.
The NHSX app in the UK was deemed partially compliant at AA level (official NHS policy is to hit AA level) https://covid19.nhs.uk/accessibility.html, and has been criticized for that shortcoming.
I have had one tester leave thr project on the basis that we weren’t taking Accessibility seriously enough (thoguh whether he ever had a serious intention to contribute is not clear).
Accessibility Goals
Since we are starting from zero on Accessibility, I propose the following immediate goals:
Identify how we currently fall short of WCAG Level A
Fix immediately (i.e. MVP1 or soon after) all “easy” fixes for WCAG Level A
Create & schedule stories for anything in WCAG Level A that is not easy to fix, and set a timeline for Level A compliance
Begin analysis of what it will take to get to Level AA.
This test report moves us towards 1 & 2 but does not complete either of those goals.
Google Accessibility Scanner
Google Accessibility Scanner is an App that can be installed on Android to assess the Accessibility of another app.
On each screen, you can invoke the Accessibility Scanner, and it will indicate what elements on the screen fail to meet Accessibility standards.
Accessibility Scanner is clear that it is not a substitute for full WCAG compliance testing, but it does help to identify some key issues.
I’m not familiar with Accessibility Testing, but this seemed like an easy way to start with item 1. above (partial) and generate a set of things we could look at under 2.
So I installed it, ran it over all screens in the current app & documented the results here.
Results
See below for all the data collected. This is a summary of the key themes of Accessibility feedback we got from this testing.
Principle | Category | Issues | Suggested action |
|---|---|---|---|
1.1.1 Text alternatives for non-text content | A | Back arrow, Hamburger menu, Remove HA button don;'t have ““item labels” | Fix them! |
No explicit principle (but arguably impacts 1.1.1 again) | A | A couple of duplicate “Item Descriptions” | Fix them |
None | N/A | Multiple clickable items in a single location | Seems likely to be a bug - investigate |
1.4.3 Contrast | AA | Highly variable color palette | Consider standardizing on higher contrast colours in palette |
2.5.5 Touch Target Size | AAA | Some touch target objects smaller than ideal | Consider fixing, but lower priority than other issues flagged. |
Jira Bugs
I’ve not raised any of these items as Jira bugs yet. I’m happy to do so, but wanted to get a quick review of the content of this doc, and overall goals on Accessibility before raising anything in Jira.
Missing Item Labels
Missing “item label” for screen readers on several objects
The “Back” arrow in the top left of many screens
The “Hamburger” menu
The “Remove Health Authority” button (to make matters worse that also seems to have disappeared completely in the build I was testing!).
This is a violation of the very first principle, category A:
”1.1.1 All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.”
This seems like an easy fix that we should make.
Duplicate Item Descriptions
Two instances of this.
If we have duplicate descriptions, this seems like something we should address.
I don’t see an explicit WGAC guideline that this violates but it seems obviously unhelpful to have duplicate descroptions.
Multiple Clickable Items
Multiple clickable items in a single location.
I’m not sure what to make of this one. Is there something superfluous in the underlying model of the page? I can’t see in what way there are 2 clickable items here.
I don’t see an actual Accessibility problem here.
But seems worth a quick look to see whether there is a problem behind this?
Text Contrast
Several places where the Accessibility Scanner’s view is that we don’t have enough contrast
This looks OK to me, but I’m not familiar with specific problems some users may have here.
This relates to AA principle 1.4.3Contrast (Minimum)
“Level AA
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:”
Some observations:
For the Next button during onboarding. The shade of Blue on the Next button #6979F8 is different (lighter) than on most other screens (e.g. on the main screen I see #5464EA, and on the top of the Exposure Notification screen I see #4051D8). The darker blues create aenough contrast. The lighter doesn’t. Can we standardize on one of the darker blues?
For the Exposure history numbers, we seem to be using an off-white background, and again a fairly light blue ink. Can we increase contrast here?
“Skip this step” and “I accept the licensing agreement” both seem to be in off-white. Can we move to white to sharpen the contrast?
“No known contact” is probably suffering from the animation + the timign when I grabbed the screenshot. For this we can probably invoke this sub-clause for “large scale” text. “Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;”. On this screen (at this moment of capture) I believe we have a contrast of 3.8:1. https://contrast-ratio.com/#%23ffffff-on-%236A79E8
Touch Target Size
I believe this is covered by AAA principle: 2.5.5Target Size
“Level AAA(Added in 2.1)
The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:”
Google Accessibility desig guidelines recommend 48dp x 48dp, for a physical size of approx 9mm
The “Remove Health Authority” button looks too small mbut it also looks like there is a bug where we have lost that icon altogether - we should fix that.
For the other items there is not obviously a size problem, but if we were willing to make them a bit bigger that might aid Accessibility & remove these warnings.
