IA as Inclusive Design

Presented at Euro IA 2018

Most of us know that accessibility is important, and some of us are responsible for delivering accessible sites or products, but as a discipline, we’re still figuring out what truly inclusive experiences might look like. Poor information architecture is a huge accessibility problem, but automated accessibility tools can’t check for it, frameworks can’t fix it, and adhering to the letter of WCAG criteria doesn’t make experiences usable, intuitive, or useful to people with different access needs.

Really being inclusive in our design means integrating structural accessibility concerns with the other IA work we do, and starting earlier in the design process, instead of leaving it to developers to design as they code. I’ll go through four specific challenges for designers that will help you build structures that turn your experience into one that makes sense to humans, regardless of their abilities.

Deck

Resources

Video

Sarah Barrett – IA as Inclusive Design from World IA Day Switzerland on Vimeo.

Transcript

So, I’m hoping that you’re all here because you already know that accessibility is important. Right?

And thank you for being here and knowing that, because accessibility can feel kind of fraught – like you’re about to say or do the wrong thing and be a jerk at any moment. And you probably will, I certainly will during this presentation, and please let me know what I can do better afterwards. I like to think of that discomfort as the discomfort of examined privilege, and work through it. Because we shouldn’t have to be comfortable to engage, right?

We all know that we have to engage, because accessibility is frequently a regulatory requirement, but also increasingly a huge legal liability- there were more than 700 lawsuits in the US last year alone, and nobody wants that kind of PR nightmare.

Also, making our sites and products accessible means opening them up to more customers, since, according to the World Health Organization, 15% of people worldwide have some kind of a disability.

A huge number of people need our sites to be accessible, and we certainly can’t do less for them than we do for IE 6 users, right? We do so much work to make sure sites still render for legacy browsers, which are incidentally .02% of visitors to Docs.Microsoft.com, and probably lower if “Microsoft.com” isn’t literally in your URL. To make this point even more strongly, there are still fewer users coming to us with ANY version of Internet Explorer than have a disability. None of us would ever ignore that whole segment of users.

On top of all that, it’s the right thing to do, at a very basic level, because it’s wrong to exclude people from public life, and we’re all empathetic enough to know that. Incidentally, Anne Gibson’s “An A to Z of accessibility issues” is a great way to build that empathy muscle and will point out some great places to start addressing accessibility on your sites.

You’ll hear me talk about both accessibility and “inclusive design,” which might be a new term. It’s a design methodology that focuses on recognizing when people are being excluded, designing for people with permanent disabilities as a way to improve experiences for everyone, and putting people with diverse needs and experiences at the center of the design process, so we can learn from that diversity. When you design this way, technical accessibility should be one of the outcomes, but it’s not the exclusive point.

So, accessibility is important. But I’m lucky enough to be a full-time information architect, and discussions about it never involved me because I don’t pick colors or images, I don’t code anything. It was very tempting to think that accessibility was important for other people, like the devs and designers, but as soon as I started actually reading the standards and empirical studies of people with access needs, it became clear that we are letting ourselves off the hook.

I have bad news and I have good news. The bad news is that IA is often a huge accessibility problem.

It’s a general maxim in IA that navigational structures should be broad and shallow, rather than deep and narrow. In a recent study of people who use screen readers, researchers found that blind users generally take two to four times as long to accomplish a task as sighted users do, this can certainly improve, but it’s the expected multiplier. When navigation is deep and narrow, it takes everybody longer to accomplish tasks, but it means that blind users now need nearly 8 times as long as sighted users do. That’s a very long time, but it also means that poorly constructed navigation is disproportionately hindering people who use screen readers.

Another study from a few years ago focused on how people with dyslexia experience the web. As a note, I said earlier that the WHO estimates 15% of people worldwide have a disability, that doesn’t include many issues that are considered less severe, like dyslexia, which is estimated to affect up to 20% of the general population. In that study, a full half of the problems users encountered were IA problems, like information not being in the page where users expected it to be, navigation elements not helping users find what they were seeking, too much information on page, and issues of content hierarchy. These are familiar IA problems, but they are also barriers to access when people bring diverse contexts to them.

Which finally brings us to the good news, which is that is that this means that accessibility is an IA problem. That might not sound like great news, but it means we can help. And we need to help, because the current toolset isn’t getting us all the way there.

Most of this is because when we usually talk about accessibility, we talk about adherence to standards, or success criteria as WCAG calls them. And those standards are great, but they vary enormously in size and complexity. Some are relatively simple, if expensive, like “provide captions for all pre-recorded media.” Others are wide-ranging, like “When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.” I have a hard time thinking of a case when sequence of content doesn’t affect its meaning, but getting to consensus on a priority order for content through a page is something I often do multiple iterations on in the content modeling phase, with input from research and the business strategy. The actual requirement of the criterion is narrower, it just wants you to put things in a line for focus orders, but in order for this to be really helpful, you have to think about the structure of the information.

And we see that difference between just following the letter of the law and its spirit in empirical studies, because it’s the difference between technical accessibility and usability. In that same study with dyslexic users, they found that adherence to WCAG standards was a predictor of how many problems users would find on the site, but not a strong one. Sites that conformed to stronger accessibility standards tended to have fewer problems than those that didn’t conform to any, but there’s a ton of variation here.  Accessibility criteria certainly help, but they don’t do the whole job for us.

We can certainly use other methods, like automated tools like pa11y or Keros, that check against these criteria. And they’re great, use them, but they check against about 30% of the standards, and they tend to be those simpler, binary criteria, like is alt text present or not.

I also hear people say sometimes that they don’t need to worry about accessibility because the web framework they have takes care of that for them. This is false. A framework can absolutely help (or hinder) you, and yours should be accessible, but you still need to make decisions that ensure your site is set up logically and intuitively.

Lastly, some of the best advice I see is to include people with different kinds of access needs in your user research and usability testing. Yes, do this! It works together, though, with unifying the structural ways we think about sites and content for IA and for accessibility.

To get at that unification, and to start making IA an integral part of a design process, in addition to including people with access needs in research, I have four challenges for you, all of which you can start doing without hiring anyone or getting additional funding:

  1. Do the accessibility training your developers do. You might have to ask them for links. Accessibility isn’t considered “recommended training” for my role, and it didn’t show up by itself, which is a whole other issue. If you don’t have a dedicated team that you work with, this Udacity course is quite good and takes you through it. I want you to do the dev-focused courses instead of the design ones not because I think designers should code, but because devs are often asked to make a lot of the same structural decisions we do, like about the priority order of elements on a page. Look for places where they’re recreating decisions you have made as part of the IA process and places where you could make their lives easier.
  2. Read the WCAG standards, which describe the success criteria for meeting different levels of accessibility. The training that you’ve done before translates these success criteria into what the trainers think devs need to know about them, but that’s not geared toward IAs, so go back and look at the original source. There are huge IA implications in many of them, and think about how you can start applying them in your work. I’ve linked two different videos here, which are quick overviews with examples of each of the standards. They use the actual wording of the success criteria, but I found them much easier to understand than the text-based version.
  3. So, once you’ve done the training and you have your own notes on what’s implicit in the success criteria, find one thing you can start adding to the page description diagrams or wireframes you do. An obvious one is to define the tab order through a page, which helps people with motor impairments who don’t use a mouse, screen reader users, and is a good starting point for mobile, also. ARIA landmarks are also a good thing to include here, if your team is using them, or start having notes about supplemental labeling for screen readers. But this is where that training comes in useful, because you’ll have an idea of what’s most likely to be helpful to your team.
  4. Finally, the smallest but sometimes scariest: Practice saying “This is an accessibility issue” when something is. You might be surprised at the reaction you get. I love my team, but frequently when I raise something as an IA issue, I hear “We know, but …” When I raise something as an accessibility issue, I get a pause, and then a question: “How so?” It doesn’t mean I get my way, but I get a conversation. And that’s because for my engineering team, at least, accessibility is a core priority, it’s a thing we’re evaluated on. “IA” on its own, is never going to be a top priority, for completely valid reasons.

And honestly, that’s fine. As I’ve dug into this, I have found that every single IA-related thing that we should for accessibility would also improve the experience for every single person who uses the site. Prioritizing content. Making sure things work logically. Establishing intuitive rules. These are all things we should be doing anyway.

I’m the only IA in my organization, so I do a lot of explaining what it is and why it matters. The idea I frequently come back to is that the UX designers define paths for our users and optimize for completing certain tasks. It’s my job to stitch those paths together into a world that makes sense, so when people depart from the standard paths, everything still works.

Technical accessibility is essential, we need to make sure we check those boxes. But so much of what makes sites really usable and intelligible across access needs is good information architecture. If we merge those implicit requirements in accessibility standards with the IA we damn well know we should be doing, we can build better worlds that include everyone.