UX accessibility must move beyond developers - Karen Hawkins on how to turn digital accessibility into a team practice

As diginomica pushes further into UX accessibility, a few lessons jump out:

• accessibility is not just a legal obligation - it's a sensibility and a discipline.
• accessibility factors into every digital feature or design decision you make.
• the more accessible your digital assets are, the better the UX is for all.
• the work is never done, and there is always more to learn - and implement.

A PR pitch from eSSENTIAL Accessibility caught my eye. Why? Because:

When it comes to ensuring websites or digital products are accessible, most companies, tend to lay all of the responsibility on the shoulders of developers. This approach is inefficient, ineffective, and puts an unfair burden on one part of the team.

So what's a better approach? eSSENTIAL Accessibility (EA) calls this "shifting left." Their meaning?

Incorporate digital accessibility at every stage of the product development process, including design and project planning.

Turning UX accessibility into a discipline

That was enough to spark a video discussion with Karen Hawkins, Head of Accessible UX Design with eSSENTIAL Accessibility. How did Hawkins become a certified accessibility professional? Hawkins was a UX designer, when events changed things. She told me about one mentor in particular:

She basically grabbed me by the shoulders, figuratively, and said, 'But Karen, you're the user experience designer; you need to design for all of these experiences, right? Not just what you're used to.' So that was the catalyst for me.

Now Hawkins does this full-time:

I love teaching people about designing with accessibility in mind. There aren't a lot of creatives that truly get how to do that... I started at EA as the trainer, and I transitioned to being our subject matter expert in design accessibility.

I told Hawkins that accessibility has been humbling to take on (I took over the management of diginomica's web assets a year ago). Yes, it was exciting to add audio mode and dyslexia mode to diginomica. But in my view, taking accessibility seriously is just as much about the nitty-gritty. That means analyzing everything on a page - everything your audience might consume.

I might think a new feature is important - and maybe it is - but what I really need to do is relabel every missing or inadequately labeled image on our site with more descriptive alt text tags (for diginomica, this is a manual process we are still finishing; I suppose in the future, "AI" might be able to help automate some of that, but we are doing this by hand, and are about 80% done as of this writing).

Our Drupal development partner, Brainsum, has pressed into a slew of very specific, smaller accessibility projects. Every feature on our site is subject to scrutiny. Example: can your site be navigated by only a keyboard, without a mouse? For diginomica, the answer is not yet, but soon.  Hawkins responded:

That's just it. It's an experience. A screen reader experience is accessing those image tags. Well, that is the usability of their experience - do they actually get it?

Accessibility at every stage in the product lifecycle

When we launched diginomica nine years ago, we hadn't yet elevated accessibility to the top of our development priorities, as it sits today. Over the last three years working together, I think Brainsum has embraced the pursuit of industry leadership on web accessibility. I'd like to think we are now pushing each other, in a good way - because what we had was not enough. From our launch, diginomica was always mobile-conscious, if not mobile-first, and we wanted UX simplicity. But at times, we fell prey to the feature rush that any startup can get into.

Putting accessible UX into action

Going back and fixing architectural/accessibility issues after the fact is not ideal. For web sites (or apps) of massive scale, it can be a serious/expensive problem. I'm sure most organizations - including ours - can benefit from EA's advice to:

Embed accessibility at every stage of the product development lifecycle, and make it everyone’s responsibility (i.e., project managers, UX designers, graphic designers, copywriters, developers and QA testers).

So, I asked Hawkins, how does an organization get to that point? Hawkins used the example of color contrast, which is typically the purview of the user interface designer. The user experience designer might not take contrast into account:

We can take the Web Content Accessibility Guidelines, and we can map all of the responsibilities...  It only makes sense that we start designing with accessibility in mind, right? Because we could design something not thinking about accessibility or other usability principles, and ship it off further downstream.

Teams aren't used to thinking about all of those accessibility requirements because if you just knew what they were, you'd want to incorporate them into your daily workflows.

Hawkins recommends "accessibility checkpoints":

Another thing that's lacking is checkpoints, where we can inject accessibility into the software or product development life cycles. We're putting in these checks and balances to make sure that for every role, and at every stage in the process, we're designing and creating as much as we can with accessibility in mind.

Going back and re-architecting for accessibility is not an ideal practice. So when you're launching a new digital asset, what's a better approach? Hawkins says: start with the planning phase.

I would even bring it further upstream to the planning stage. Especially if you're new to this, the reality is it's going to take you a little bit longer, because you do need to learn some things, and you're probably going to make some mistakes along the way.

So bake in a little extra time, for consultation and/or education. That consultation might be with external parties. The best is pulling in downstream participants, aka developers, and our content people - pulling them further upstream, into the initial ideation phases. Then we can have a number of different voices and perspectives contributing to ideation.

Hawkins breaks down a brand refresh or digital launch to "foundational elements," the atoms and molecules of design. Get those right, and what you build with those components should be more accessible:

It's very logical that your foundational elements are as accessible as possible, these foundational elements being colors, but also typography, small atoms and molecules, like your buttons and your links and your text boxes - they get used everywhere. There's that whole concept of atomic design - you build small things, put them into larger organisms, and build those components into two full pages.

So if your atoms and molecules themselves aren't accessible in all states, buttons, for instance: hover state, focus state, active state, selected state, click state - people always forget all the different states, but you have to think about the lifecycle of this particular atom or molecule. And you have to think about all the different cases that will be used. So laying that foundation is super important. If you do that in your style guide, you're ahead of the game.

Pulling designers and developers into the planning/ideation stages is important. Then you follow it through:

I'm also talking about bringing UX, UI and content downstream, when dev is building, checking in, and ensuring that this is the experience you were looking for.

My take

Covering all aspects of UX accessibility in one post isn't possible. I've linked to a number of resources in this piece. eSSSENTIAL Accessibility has plenty of UX accessibility resources also.

Accessibility as a discipline is not an easy practice. But the result - a better UX for all visitors - is well worth the effort. Speaking from diginomica's view, ambitious projects like dyslexia mode are well worth doing. Finding the right external partners and experts can inject energy - and help with the checkpoints Hawkins advises. With that in mind, I recommend:

• Avoid overwhelm by tackling one project at a time, and building accessibility momentum.
• Make sure those "atomic" building blocks are accessible before you create new features.
• Make sure you have a framework for these smaller projects, and how they fit into the whole (perhaps with an external scorecard or checklist to guide you).
• Consult external experts and resources, particularly in regard to your legal exposure and project checkpoints.
• Take on ambitious accessibility projects to energize the team. This provides a balance with the nitty-gritty of fixing alt text fields and other manual accessibility tasks (automating these tasks is fair game, just make sure the automation is providing relevant tagging and labeling).

Taking these issues seriously is now expected, but that doesn't mean they can't be fun and energizing. That's where Hawkins' advice on diverse teams comes into play. Diverse teams will tell you where you're going wrong - and challenge your UX assumptions. That dialogue might be difficult at times. There is a much better chance of delighting your audiences on the other side.