What people should know BEFORE writing articles or creating products about accessibility

Woman wearing bracelets and a brown sweater typing on a laptop on a wooden table
So many people are writing or developing products around this hot tech topic right now. Many of them are getting it very wrong.

I read a lot of articles about accessibility. Some of them (and not just the ones I write) are very, very good. Others are cringe-worthy. These are the signs that I use to determine which to read to the end and which to close the browser tab on partway through.

The author/product developer does not have access to lived experience

It’s never enough to “comply” with whatever WCAG standard you have chosen to follow. People who work in accessibility who want to be good at it must understand how people with disabilities process interactions flows and data to make it usable.

Example: If slide text announces in a training deck, but then the software forces the user to read through the text again to get to the “next” button, that’s a problem. It’s technically compliant but inefficient and unusable.

Unless you have the lived experience of being a screen reader user or have worked closely with screen reader users for an extended period, you might miss this issue. That is why it is so important to involve people with lived experience in learning about accessibility. You must interact and get feedback from people with the lived experience of having a disability or multiple disabilities. In this case, more is ALWAYS better. This interaction is no different from any other dimension of diversity, inclusion, or belonging.

Moreover, you can’t write or develop something, then retrofit in lived experience. Hiring a blind person (or multiple blind people) after a product has been created is not a valid approach to accessibility. Lived experience must be involved from the outset.

The author/product developer fails to understand disability intersectionality.

I looked at the mobile web interface for one of the web overlay tools recently. I don’t use mobile a lot because of my level of vision loss; there isn’t a lot of screen real estate to work with. This particular overlay had some good profiles (which frankly could use some fine-tuning, but it’s an OK starting place). But, it DOESN’T allow for multiple profiles to be set simultaneously.

I can select a vision loss profile, OR I can select a motion-sensitive profile, but I can’t have both.

Hello, I am both?

That is one of the main reasons why W3C never mentions specific diagnoses or disabilities in the WCAG standards. Disabilities are intersectional. When you have one disability (especially an autoimmune-based one), you will likely get MORE than one disability. That indisputable fact completely invalidates the approach taken by this overlay in mobile web.

Some authors understand the intersectionality between different types of disabilities but fail to understand the intersectionality between disability, gender, LGBTQ+ status, and poverty.

  • People with disabilities frequently don’t have the money or support to buy new devices that will work better for their disabilities.
  • People with disabilities frequently don’t have the money, time, or emotional energy to try the next greatest treatment for their condition.
  • The lack of accessible tools in education and the workplace, combined with healthcare being tied to employment in the US, keeps American people with disabilities from breaking free from the disability/poverty cycle.

The more historically excluded categories a person with a disability identifies with, the greater the discrimination that individual will face.

The author/product developer uses outdated language regarding disability

If I see an out-of-favor term used (such as suffering, wheelchair-bound, impaired), the first thing I do is check where the author is located. If it isn’t obvious from the article and I don’t know the author, I will go so far as to look them up on LinkedIn. If they are in a developing nation, I might give them a pass.

Language in the EU, APJ, and North America, however, has evolved significantly. People first language (or identity first) is essential. Labels like “low functioning” or “high functioning” are binary, discriminatory, and ableist. They stigmatize the individuals being labeled and convey nothing about strengths that individual might possess.

The author/product developer treats disability as if it were a single thing and not a spectrum.

Neurodiversity is not “a thing.”

Neurodiversity is a category describing a vast group of issues including but not limited to autism, dyslexia, dyscalculia, dysgraphia, ADHD, and Tourette’s Syndrome, to name a few.

Each of these conditions has an entire spectrum of its own. For example:

  • The impact of ADHD on one’s living and work activities can be mild, moderate, or severe.
  • ADHD can be diagnosed in childhood or as an adult.
  • Some people with ADHD take medication, others don’t.

Each of these elements alters how the user with ADHD interacts with a product. The product has to work for ALL the users, no matter what their answers are to those questions. Simulation is never a great approach to understanding disability (see my comments about lived experience above). Simulating neurodiverse states is impossible.

The author/product developer treats a particular disability as “more” or “less” important.

Good accessibility does not benefit a screen reader user at the expense of a keyboard-only user.

Good accessibility managers don’t spend their entire budget to make a product work for people with hearing loss but ignore switch users.

Excluding any group of individuals with disabilities is ableist and wrong. A rising disability inclusion tide needs to raise ALL the boats, not just the boats of a small subsection of people with disabilities.

The author/product developer uses “headcount” to make disability inclusion decisions

“How many people is this going to benefit anyway?” is a complaint I hear a lot from people who don’t understand that accessibility is a civil right.

Counting heads is the wrong approach.

Flip the narrative and ask yourself:

  • How many people am I discriminating against if I don’t make something accessible?
  • How much business am I losing because the people I am discriminating against are shopping at my competitor?

The author/product preys on prevalent fears and myths surrounding disability.

There are too many myths and misconceptions about disability to count. Incorrect assumptions about disability are frequently triggered by fear, ignorance, or prejudice — sometimes all three. Promoting an article or product through continuous negative disability imagery is ableist because it creates barriers for people with a disability to be treated equally.

Any article or product hinting that all the reader/user has to think about is ten things to get accessibility right is delusional and misleading.

Accessibility is a program not a project.

  • If you work from a checklist, that’s a project.
  • If your accessibility efforts have an end date, that’s a project.
  • If you believe the mistruths promoted by overlay companies in Internet ads and soon coming to primetime television, and think they are going to solve your accessibility issues, that’s not only a project, it’s an invalid project.

Accessibility might be a hot blog topic or sales opportunity to you, but it is the chance to live an equal life to some of us. You are doing people with disabilities a disservice when you write an article or create a product that does not take full equity into account.