IxDF: Accessibility

When you are able bodied and have use of all the senses, it’s extremely easy to take it for granted. If you’ve read my About section, or any of my posts on LinkedIn, you’ll know that I’m passionate about designing accessible digital spaces for everyone. I want to ensure, as much as possible, that anything I design or touch is usable by the larger group. And since I spent a lot of time in pharma designing for seniors whose vision was often poor, I’m familiar with how simple it can be to integrate accessibility into my daily professional life.

It is not the mountain or hurdle that it might seem, as long as it is handled from the beginning and not the end. And the last thing I ever want to do is design two separate experiences. My design and work should be accessible from the beginning. People with disabilities or impairments shouldn’t get a different experience, it should be the same one, as fully robust and functional without exception.

Let’s think about this graphic by Craig Abbott, the Head of Accessibility at DWP Digital:

A chart categorizing disabilities into Permanent, Temporary, and Situational under four sections: Touch, See, Hear, and Speak, with icons representing each condition.

There are many similar graphics and charts that circulate around. All the major players have one. So how exactly do I focus on these things and make websites and digital experiences more accessible?

According to the class I took from Interaction Design Foundation there’s a few key points:

• Empathy
  Once you understand and empathize with various types of impairment, you can take a look at what others use to navigate the web and their phones. This plays into the “user interview” bullet, but for me it was more about learning what already existed, what worked well, what didn’t, and working to truly understand the barriers that this user group experienced.

• ARIA
  A big part of making experiences accessible is to incorporate proper ARIA tags, which is what many assistive devices use to read a page and navigate it. Without this inherent navigation, users can experience a much more difficult time making their way around a website or app. They might even miss crucial information, or their device might skip something entirely.

• Alt Tags
  Similar to ARIA, this is just the step of ensuring everything is labelled and legible for assistive devices. However there is an art to crafting Alt tags, and the course goes into great detail on what is considered a valuable alt Alt tag for users.

• User interviews
  This is probably the largest and most important point: talk to your users. You’re probably going to do this anyway, so make sure to include people from all different user groups and not just your primary target persona or you’ll find yourself with quite a slim pool and narrow mindset. This could cause greater problems down the road when you need to fix the site for compliance instead of being compliant from the beginning.

Less obvious but no less important were things like color contrast, font size, tabbing, formatting tables and images, and a brief touch on the AR/VR space.

Okay, so how do I tackle this as the designer on the team?

It’s twofold:

• Talk to my devs/engineers

• Run user tests

The first might sound obvious, but I’ve always been surprised at how little people communicate with their engineers and developers. I may understand HTML, CSS, and some JS, but I am not a front end dev. I’m not even close to back end at all. And I’m not the person who will need to implement many of the things that make a site accessible, like the ARIA tags. So the very first thing is talking to dev, ensuring scope availability, and then laying out next steps.

Are we doing a full audit? Is this a new product? Is this an update? Once the project is understood, we can assess what measurements need to be taken. Running a user test can be costly, but might be necessary and will save us in the long run. If it’s necessary, what specifically should we be testing? At what stage should we test? The current condition? The site with proper tagging? I’d suggest both, for thoroughness, but if our budget is tight then maybe middle. Fix what can be fixed and is obvious, then bring in the user to run the test and go from there.

And this is all something that I feel dev gets a say in. They should see the questions we’re asking. See the recordings of the test. Get a report of the results. I should not go into a silo and come out with a list of changes they don’t see the purpose of.

Again, sounds obvious out loud, but timelines and budgets aren’t always in favor of process. Okay, so we’re short on time, but we’re failing WCAG compliance (which, with California’s new regulations, will result in a lawsuit that nobody wants.) What, then, is priority?

In that scenario, I would most likely rely on digital tools to generate reports and fix the most obvious things as quickly as possible, while scheduling a user test for down the line, budget permitting. In this case, it’s still especially important to work closely with dev to ensure the changes get done quickly and properly.

TLDR; talk to your devs!