So accessibility is one of those words that mean a lot, and sometimes doesn’t mean anything at all.

What do I mean?

In terms of “accessibility in tech”, like binding expectations of WCAG 2.0 and the United States Section 508, accessibility tends to mean equivalent access to information. Can someone with disabilities make a purchase on a store website or platform, for example, or find the newest post on a blog? But as designers and website creators, we cannot design for every single condition, or design for what we do not know. Which brings me to reductio ad absurdum: when informed about guidelines for menus and changing contexts, someone got frustrated, swung their argument the other extreme, and told me: “Well, why can’t we just have a screen before the person gets to the content, asking them what condition they have??”

Due to privacy laws and issues around diagnoses, ability, and social expectations, that gets complicated really fast – and often unlawful. Like I said, reductio ad absurdum: bringing things to a inflated, absurd conclusion.

But access to information does not always mean the website in question is inclusive.
Some websites only have site maps as a nod to accessibility. For a long time, some sites used a text-only page, stripped of any formatting at all, as their “accessible option” buried in the footer of the website or underneath a couple of levels of navigation. Some websites code their menus with “mouseclick” functions and ignore keyboard or other accessory use entirely. If the person does not have a mouse, or pointer equivalent, they might not be able to navigate the site at all. (This may also apply to the use of tablets and smartphones, though tablets and smartphones have additional considerations.) 

This is a bit like saying your building is accessible, when the nearest restroom stall to accommodate a wheelchair is on the third floor and there are no elevators. Of course, to many abled people, putting in a ramp to standards (i.e., have the ramp actually be functional for wheelchairs – the correct range of incline, etc) or refurbishing the building to include an elevator, seems too expensive and too much effort for very little gain. They don’t personally need a ramp or a larger bathroom – they might even see it as just a matter of convenience, or luxury, and not need.

Inclusive design, by contrast, takes the principles and includes them from the start. 

When inclusive design is used from the start, there is less perception of “extra work” – it’s part of the process already. Inclusive design leaves room for change, but also does not relegate parts of the population to one walled-off section of the website and then saying that the work is done.

What can you do to make design more inclusive?

Much of user experience issues really relate to one property: active listening.

I like analytics. Eye tracking software and applications have their place. And applications like Google Analytics can help us figure out where people might leave in frustration, and give us information on what browsers, what devices they use. But if someone says: “This font is difficult for me to read”, listen to them. Believe them. Ask what might be better. If someone says “I can’t tell if this is a button or not”, take a look at it and don’t discount the person out of hand.

Ask questions, but respect your users as people.

Technology and numbers aren’t always this impartial, universal thing. Humans create technological advances: humans decide what is worth measuring, and why, and which measurements are deemed acceptable. But the human factor is often relegated to the marketing division or a call center bank – and often with side helpings of sexism, insults to any sort of intelligence or wisdom, lack of adequate career planning, and more. This only widens the gap between developers/engineers and anyone else, and furthers resentment that has practical and real consequences.

Respect experiences. Respect intersectionality.