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:
What do I mean by those?
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 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:
That’s valid HTML, but in most cases, if not all, a real button would be better here:
So what if the people carrying out your project just don’t know how to do it better?
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.
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.
- Begin digging deeper into accessibility.
- Learn more about designing accessible user experiences with A Web for Everyone. DigitalGov also has resources on making videos accessible.
- Begin integrating accessibility testing into your processes early and often, from design to development. It’s easier than you think.
David A. Kennedy is a former contractor for the Consumer Financial Protection Bureau.
Have feedback or questions? Send us an email at firstname.lastname@example.org