Accessibility Is (Not) Scary

Feb 20, 2015
Internet accessibility concept

The word accessibility breeds misconceptions.

Why? Because accessibility is something that scares you.

Accessibility is hard. Accessibility needs people with specialized expertise. Accessibility problems often depend on the context of the website or Web application in question. Accessibility takes time. Accessibility is a legal mandate. Accessibility is a moral obligation.

These statements are both true and misconceptions. The misconceptions happen when you try to solve accessibility problems with just accessibility solutions. In that world, accessibility becomes this “requirement” or “list” that you tack on or create to make it more manageable. You try to corral accessibility into some stage in your process, but it doesn’t quite fit in anywhere. Because it’s everywhere. Making those misconceptions disappear happens when you focus on the people and processes around accessibility. Then, it becomes something you can do.

The impetus for most accessibility successes or failures falls into one or more of these three topics:

  • Decisions
  • People
  • Details

What do I mean by those?

Decisions

Decisions represent turning points or the foundation of your accessibility process. They’re usually strategy-related, and become points of no return. An example of a decision like this? Creating a separate, accessible website that’s different from your main website. It might seem like a good idea to isolate the challenge of accessibility into one website. But then you have two codebases, two sets of content and a myriad of “differences” to track and maintain. Not good.

People

People make accessibility happen, but what if they don’t know the how or the why? Many Web workers just haven’t experienced accessibility first hand. They don’t know much about it, much less how to implement it in their projects. Take this classic example of making a button within a Web application. Let’s say that button saves a state of work. A Web developer might do this:

<a href="#">Button</a>

That’s valid HTML, but in most cases, if not all, a real button would be better here:

<button>Real Button</button>

So what if the people carrying out your project just don’t know how to do it better?

Details

In accessibility, details matter. In any given project, at least a thousand exist. If you don’t keep constant, intelligent pressure on them, they can get lost and ruin your efforts. Color contrast serves as a good example. Ensuring proper color contrast requires minding details like brand, color palettes, contrast guidelines, regular testing and more.

Question Everything
Red question mark key

You might be thinking that all three of these points intersect. You’re right. People make decisions and track details, after all. What do we do about that? Ask good questions.

Don Norman, a well-known design and usability expert said:

What makes something simple or complex? It’s not the number of dials or controls or how many features it has: It is whether the person using the device has a good conceptual model of how it operates.

The truth in this extends beyond users. Often we, the people who design and build, don’t have a good conceptual model of how our project works. We’re too busy managing changing priorities, timelines and business requirements. We know that won’t change. But we can change how we look at those changes and the decisions, people and details within our work.

At each turning point, you should ask yourself, “How is this going to work?” Start the conversation with yourself and others. There are no bad questions or answers. Only the ones that never get asked or voiced. Find out how accessibility happens in your organization. Accessibility is not scary, and it’s something you can do.

What’s Next?

David A. Kennedy is a former contractor for the Consumer Financial Protection Bureau.

Originally posted by David A. Kennedy on Feb 20, 2015
Feb 20, 2015