Why COVID-19 contact tracing apps *must* be accessible
People with disabilities should benefit from emergency software. They also WANT to participate. Contact tracing won’t work without them.
Photo by Proxyclick Visitor Management System on Unsplash
COVID-19 coronavirus: Tracing app ‘unusable’ for the blind and those with low vision
No one in accessibility was surprised by this headline. The contact tracing app launched last week in New Zealand cannot be used by people with disabilities. Here are the reasons why people in the accessibility field aren’t shocked:
41 out of 50 Unemployment sites in the US are inaccessible, even though accessibility is required by law, and people with disabilities are always disproportionately impacted in unemployment situations. We are frequently the first to be let go, we are let go in larger numbers, we stay unemployed for longer, and we don’t have as much financial cushion as those without disabilities.
By definition, an untagged PDF file is never accessible. Despite this, the CDC and WHO continue to release untagged PDF files. This is even though people like Dax Castro are fixing the untagged PDF files and sending them back to the authors. The corrected versions are not being validated or released.
PG&E’s Public Safety Power Shutoffs web pages last summer were completely inaccessible.
I tried out “Safe Travels Hawaii” on voiceover on an iPhone and it took me all of 2 minutes to find five complete blockers in the long and convoluted account registration process. For example, you can’t get the date picker to pop up when you have the voiceover turned on. I guess Hawaii doesn’t want disabled visitors.
Here’s the center of the issue — if your contract tracing app/website is not accessible:
High-risk people with disabilities won’t be able to benefit from knowing what places to avoid.
18 % of the potential user base won’t be able to contribute to building the tracing dataset. This means people with disabilities are occasionally going out and not being able to indicate where they have been. That’s a large number of people to be ignoring.
Those two points effectively mean that inaccessibility defeats all intended purposes of a contact tracing app.
What makes a contact tracing website or native app accessible?
This is general commentary, not specifically discussing any contact tracing app in particular. Here are some things that would be minimally necessary to create a fully accessible contract tracing website or native app.
Step 1: Accessibility Statement
Reason: An accessibility statement shows that the creators have thought about accessibility and tried to implement things in an accessible manner, within any constraints identified in the statement.
Minimum: There needs to be an accessibility statement of some kind.
Best Practice: The accessibility statement should include an accessible way of reporting bugs. And then actually follow up on the bugs. If I had a nickel for every accessibility bug I’ve reported where I never received follow-up, I could retire.
Step 2: Accessible Registration
Reason: If a user who needs to utilize assistive technology can’t register, that’s a non-starter.
Minimum: Accessible forms and error handling, including grouping, instructions, and visual labeling, needs to be followed.
Best Practice: Allowing users to register to utilize social media logins is more straightforward for people with disabilities. That approach imports data the user with a disability has already entered, so emails and contact information does not require re-entry.
Step 3: Accessible Cookie/Privacy/Terms
Reason: You likely can’t enforce a contract that was unable to be read by a user with a disability.
Minimum: Need to be fully announced by screen readers, magnifiable, and checkboxes to accept must announce role, state, and value. There is already one lawsuit alleging digital trespass because a user with a disability couldn’t perceive the terms.
Best Practice: Implement your accessible cookie, security, privacy, and user terms using webviews so that you don’t have to re-release the app every time you update one of the legal documents.
Step 4: Accessible location finding
Reason: Graphical views of maps, which frequently come from third parties, are often inaccessible.
Minimum: You can default to an inaccessible graphical view, but at a minimum, you need a list view that provides the same information as the graphical view in a text-only format.
Best Practices:
“Find the nearest check-in point near me” — Don’t make the user enter the address of where they are currently, they might not even know, and it isn’t always easy to find out.
Beacons — use directional beacons like those provided by Right Hear to direct people in an accessible manner to physical check-in points.
Personalization — Once the user has switched to a text view, the next time they bring the app up, remember that and put them in the text view by default. You can do this with cookies, or associating these usage details with the user’s login.
Step 5: Accessible QR code scanning
Reason: If there are QR codes that are part of the contact tracing process, they need to be accessible, or people with disabilities won’t be able to participate in the scanning portion of the app.
Minimum: Access QR codes, including alt-text explaining the destination or action, as necessary
Best Practice: Mobile check deposit is a great parallel to accessible QR code scanning. Bank of America and Chase both have native apps that allow customers to deposit checks without being able to see or touch the phone. That covers additional best practice behaviors such as hints for alignment between the camera and the thing being photographed, auto-capture, use of flash, etc.
Step 6: Accessible documentation
Reason: If an app/website comes with documentation, people with disabilities need equal access to that documentation.
Minimum: One form of documentation is fully accessible. Inaccessible documentation needs to redirect people to the accessible form of documentation in its first line.
Best Practice: All forms of documentation are WCAG 2.1 Level AA and/or PDF/UA accessible.
Step 7: Accessible help/bug reporting process/support
Reason: People don’t just interact with software in a vacuum. They participate in a comprehensive software experience.
Minimum: Any help, customer support, or documentation that is part of this experience must also be accessible to claim an equal and meaningful experience for people with disabilities. Surveys and email communications too.
Best Practice: Support reps should be educated on working with customers with disabilities.
Step 8: Native Apps should operate in both portrait and landscape modes, and auto-rotate when the phone orientation shifts
Reason: How many times have you been totally annoyed when you have accidentally rotated your phone and the app stayed put? Now think of that from the perspective of someone who has limited or no dexterity. When your phone is in a fixed frame, and the app doesn’t rotate, you may not be able to use it
Minimum: Come up in the mode that the phone is oriented in and rotate if the device is rotated.
No one is saying “Delay emergency releases to make things accessible” What we, in the accessibility community, are mainly saying is:
People with disabilities are people that matter. They should be included in any emergency communications and software releases.
If an organization bakes accessibility into all of its processes, there is no “do it fast or do it right” decision. The right thing, accessibility, will always happen from the get-go, even in emergencies when time is of the essence.