How to avoid Twitter’s latest accessibility mistakes

Good accessibility programs include things that go above and beyond just compliance with the WCAG guidelines

In June of 2020, I wrote about Twitter’s attempt to rely entirely on volunteers for accessibility testing, culmunating in a public outcry over the release of an inaccessible voice tweets feature which couldn’t be used by people with hearing loss.

Since then, Twitter built an accessibility team, and even scored 100 % on the Disability:IN Disability Equality Index survey, though it is unclear to me how they achieved this score with no accessibility team for more than half of 2020. Despite these achievements, Twitter recently rescinded an update over complaints from users of headaches and eyestrain.

Here’s how your organization can avoid this.

How can websites cause physical harm?

First of all, everyone needs to understand that it is absolutely possible for websites to be constructed in such a way to cause physical harm.

  1. Animation and multimedia flashing can trigger epileptic seizures. Pseudoflashing (black and white optical illusions) that don’t actually move but appear to be moving can do the same. Someone who seizes might fall which can cause a skull fracture. This is literally the only WCAG guideline where failing to follow it can result in someone’s death.
  2. Font changes and certain contrast can trigger eyestrain and headaches.
  3. Certain types of motion, such as parallax and optical illusions, can make some people motion sick.

Once website changes and automatically updating native apps are released, there is no turning back for the users unless the organization rolls the changes back. They have to stop using the site/app. Furthermore, some of the physical harm is caused within a split second of the first glance — they don’t require repeat or long exposure for the adverse results to occur. I had this happen myself when I accidentally did a search on stock.adobe.com that brought up an optical illusion in the results. Though I immediately looked away, it triggered a four hour headache. I asked Adobe more than a year ago to flag these images behind a “do you really want to see this?” dialog, however, nothing has changed.

While these adverse reactions are all low probabilities of occurance, the best thing to do is construct a website where these issues can be avoided.

Accessibility is not “one-sized fits all”

Once someone who worked with me on an accessibility team wanted a change that would have improved the behavior for blind users at the expense of sighted keyboard only users.

It doesn’t have to be that way.

Accessibility is only a zero-sum game when accessibility leaders fail to lead.

The more control you can put in the hands of the users, the better. Changes that are “all or nothing” can harm some users, while being an improvement for others. Most disabilities are on a spectrum and thus, solutions should be too. Rather than make changes that are all or nothing when rolling out new features that might be controversial, they should be implemented in a way where the users can customize them to their own needs. This customization approach should be used at a minimum for:

  • Haptics
  • Fonts
  • Contrast
  • Motion

Then you need to test, test, test, and test some more — with users with REAL disabilities.

YOU CANNOT SIMULATE NEURODIVERSE CONDITIONS!!!

I cannot scream that loud enough. Simulating other disabilities is not optimal, but is a frequently accepted solution on many accessibility teams. The most recent WebAIM Web Accessibility Practioners survey indicated that less than 30 % of respondents consider themselves disabled. I’ve seen accessibility teams with no disabled members, which is both shameful and a disaster waiting to happen.

Here are just a couple of reasons why simulating disabilities in general doesn’t work:

  1. I know how to use six different screen readers but I don’t use them the same way someone who is legally blind does. I have the bias of being able to see. Likewise, anyone can zoom a screen to 400 %, but without the lived experience of someone with vision loss, they won’t use the 400 % zoomed data the same way I do.
  2. Disability is about way more than one limitation from a medical condition. Disability frequently comes with fatigue, chronic pain, and inability to focus. It can come with non-medical but no less relevant influences such as time pressure and lower socio economic circumstances. These “add ons” to disability are one of the things that lived experience with a disability provides that mere assistive technology knowledge does not.

That being said, 70 % of accessibility testers don’t have disabilities. You can pretend that you can’t see, can’t hear, have a hand tremor. It won’t give you the same results as testing with a person who is not pretending, but it should at least get some if not most of the barriers removed. You can never pretend to think differently. It just doesn’t work that way.

What did Twitter get right?

What Twitter did get right is:

  1. Discuss the issue publicly.
  2. Solicit feedback from users.
  3. Reverse the update quickly, before any more harm was done.

In 2020 in a very similar case, yarn retailer Ravelry:

  1. Ignored complaints about website accessibility after a design upgrade.
  2. Blocked discussions on their website about the accessibility problems by closing threads where the issues were being discussed.
  3. Sent responses to complainants implying that they were lying about their experiences with the website redesign.
  4. Took seven months to release updates that addressed the issues.

One woman said she had a six month migraine after using the Ravelry site after the initial design changes. Ravelry got a lot of bad publicity and lost a lot of goodwill over this series of missteps.

What can organizations do to avoid repeating these mistakes?

  1. View WCAG not as a end goal, but as a floor. WCAG compliance is one milestone along your organization’s accessibility journey. WCAG compliance is not the end of the journey, because accessibility is a program not a project.
  2. Include as many people with disabilities as possible on your accessibility team.
  3. Do usability testing of major website, mobile app, and documentation changes with as many people with disabilities as possible. Make sure you cover the *spectrum* of each disability. Someone with hearing loss who uses aids will not have the same user experience as someone who does not. Someone with vision loss that is congenital will have different levels of assistive technology mastery than someone with recent vision loss.
  4. Leverage and COMPENSATE your employee resource group membership to review the changes before they roll out. Listen to what they have to say. Even if these individuals don’t have time to participate, they should be able to recommend groups where your organization can hire people with disabilities to thoroughly review the product and provide feedback.

But above all, listen to your users.