One step at a time

We often get asked about how we integrate accessibility into our processes. It’s fairly straightforward for us, because we’re already doing it. But what about people that want to start adding accessibility into their mix? How should they go about adding in pieces? One Step at a Time.

I had a great meeting and conversation on Monday with with a designer that was visiting Ottawa. She asked me a lot of great questions—one of which was “How can I start offering accessibility services to my clients? How do I build it into what I’m already doing?”

Okay, maybe she didn’t ask it quite like that, but it’s how I want to remember it, so give me that, at least, okay?

We weren’t talking about getting started with the concepts and principles of accessibility. That’s pretty straightforward and from our conversation she had a decent grasp of those concepts and the need for accessibility. We’re talking about integrating accessibility into your own work, no matter what it is that you do.

As web craftspeople, we touch almost all aspects of a project. It can easily become overwhelming to think of everything that we need to take into account for accessibility. So much so, that it can become a complete bottleneck to actually making any progress with accessibility.

Start with one thing

Thinking about it a bit more, I had to tell her that the most sane way to get more accessibility into your work is to start with one thing. Choose to do everything, and you may end up accomplishing nothing.

Many of us are soloists. Generalists. Others are specialists or one of many other -ists. You leave your mark on whatever it is that you do. It could be writing and content strategy, visual design, information architecture, mapping out process flows, or even just getting stuck in, up to the elbows in code.

Regardless of your role on a team, or—as a soloist—the particular hat you’re wearing at any given time, accessibility needs to be part of what you’re considering. Ultimately, if we consider accessibility everywhere, we’d be in an ideal scenario. We’d know that accessibility was taken into account at the content, design, implementation and strategic levels. I know that isn’t always feasible. Reality is that even if you can’t consider it everywhere, you can consider it in one place or on one task where you hadn’t before. Do so, and you’re doing better work, period.

What can you do?

If you’re working on content, do a jargon hunt and explain terms that need it. Look for directionality (“click the link to the left”) and content associations that are dependent on layout. Think about accessibility statements and accessibility help as part of the content.

If you’re wireframing or envisioning process flows, consider how you’re going to communicate the “state” of the system to someone that can’t see. What are the requirements for people that can’t hear for that tutorial video you’re thinking of adding?

If you’re coding, think of how someone that exclusively uses the keyboard will activate that über widget you’re building. What about someone that is filling out that form and can only type 1 keystroke every 3 or 4 seconds because they’re using a mouth wand?

If you’re designing a visual, think about what your intent is. What are you trying to communicate with that visual, and sort out in your head how you’ll express that someone that can’t see the visual—even if it is something as simple as a navigation state.

No, this is not an exhaustive list. But if you consider just one more accessibility angle than you did before, you’re moving in the right direction. That’s what I told Andrea when we met on Monday. It’s what I’d tell you, too.

Ask yourself: Which one step can I take to add more accessibility into the work I’m already doing?

Other good reads…

Recorded live at the Agile Midwest conference on October 12, Elle’s talk about lean accessibility and inclusive design in agile workflows was included in the Technically Speaking podcast. Give it a listen here!

The React JavaScript library is a great way to create reusable modular components that can be shared among projects. But how do you ensure your React apps are usable by all kinds of people? Scott takes us through a detailed and timely tutorial on creating accessible React apps.

This is part one of a series of articles that will take you through the basics of mobile accessibility for Android and iPhone, and help you conduct an accessibility assessment on the mobile device of your choice. This week, we’ll start off by comparing TalkBack and VoiceOver screen reader software. Next, we’ll cover the basics of mobile accessibility for fonts and colours, then mobile switch controls, followed by a testing method for mobile for each popular operating system. Welcome aboard, and we hope you enjoy the ride!

Love letters? Get ours straight to your inbox

Sign up for occasional Simply Accessible news and special deals.We’ll never spam or sell your information. You can unsubscribe at any time by clicking the unsubscribe link at the bottom of our emails. If you have any questions, please contact us.