Your Information Architecture is an Accessibility Problem
You may not have an information architect on your team, but you definitely have information architecture in your experience. Information architecture (IA) isn’t commonly associated with accessibility, but a review of the literature shows that’s a huge mistake. By leaving accessibility out of IA (and IA out of accessibility) we’re leaving tools on the table and defaulting toward exclusionary experiences.
I hope the majority of people reading this are reading an article about accessibility because they have already bought into the idea that accessibility is important. If you have a hard time making the case, it’s easy to cite statistics on how even if accessibility isn’t a regulatory requirement on the websites you work on, it’s increasingly a huge legal liability. There were more than 2000 lawsuits over inaccessible websites in the US in 2020 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.
15% of people, a huge percentage, need our sites to be accessible. This number can nearly double depending on how you count and whether you include invisible disabilities like dyslexia.
I sometimes hear the argument that we can’t do extra work for a minority of users. If you hear that at work, I would encourage you to ask how much time the company spends ensuring you support legacy browsers and seeing what percentage of your traffic comes from those browsers. I looked at our numbers for Docs.microsoft.com, the main site I work on, and IE6 and 7 made up 0.02% of our traffic. It is probably lower for your site 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. Very few teams would make the decision to ignore that segment of users entirely, even though it can add at least to 30% to development time.
Aside from all of these utilitarian arguments, it is a human rights issue. Making our experiences accessible is the right thing to do; it is wrong to exclude people from public life.
So, accessibility is important, but why are we talking about IA and accessibility? Accessibility is usually seen as a problem for people who code and people who pick colors, not information architects. I have bad news: Your IA is almost certainly a huge accessibility problem. By leaving accessibility out of IA (and IA out of accessibility), we are building deeply inaccessible, exclusionary structures.
As an example: It’s a general maxim in IA that navigational structures should usually be broad and shallow, rather than deep and narrow.
Poor IA decisions don’t impact all our users equally, though.
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.
While blind users usually require 2–4 times as long to accomplish a task as sighted users do, that multiplier jumps to 8x when navigation is deep and narrow. 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. Dyslexia affects an estimated 20% of the population. In this study, a full half of the problems dyslexic 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 the page
- Inconsistent content hierarchy
These are familiar and solvable information architecture problems, but they are also barriers to access for a huge portion of the population. Over and over again, the literature finds that common information architecture problems are barriers to access. If you work on websites, I can almost guarantee that your site has these issues. Nearly every site does.
That brings us to the good news, however: Accessibility is an IA problem. That means we can help. We need to help, because there’s not a good alternative to buckling down and doing this work.
The tools available to us to make experiences more accessible have improved immensely over the past few years. Tools, however, don’t solve all our accessibility problems because they’re mostly focused on compliance with standards, or success criteria as WCAG calls them. The 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 order, but in order for this to be really helpful, you have to think about the structure of the information.
That difference between following the letter of the law and its spirit shows up in empirical studies, because it’s the difference between technical accessibility and usability. In that same study with dyslexic users, the researchers found that adherence to WCAG standards was a weak predictor of how many problems users would find on the site. Studies with blind users have made the same observation. Sites that conformed to stronger accessibility standards had close to the same number of problems as those that didn’t conform to any. Accessibility criteria certainly help, but they don’t do the whole job for us.
Additionally, we can certainly use other methods, like automated tools like pa11y or Keros, that check against these criteria. They’re great, I suggest that you use them, but they check against about 30% of the standards, and the standards they check against tend to be simpler criteria, like whether alt text is present or not.
I also hear people say sometimes that they don’t need to do accessibility work because the web framework they have takes care of that for them. This is never the case. 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. This is great advice, and I wholeheartedly endorse it. We’re making efforts in this direction on my team. It works together, though, with unifying the structural ways we think about sites and content for information architecture and for accessibility.
Accepting IA as an accessibility problem and accessibility as an IA problem means prioritizing doing IA as part of web design and development work. There’s nothing in the literature that suggests we need to do something radically different than follow best practices laid out in the classic books of the discipline, like Information Architecture (Morville, Rosenfeld, and Arango), How to Make Sense of Any Mess (Covert), Everyday Information Architecture (Martin) or Information Architecture: Blueprints for the Web (Wodtke and Govella). We just need to do it.
If it feels scary to start applying your IA skills to a new area, I have four challenges to ease you into it:
- Do the accessibility training your development team is required to do. If you don’t work with your own development team or if they don’t have required training, there are good accessibility courses online. I suggest doing the developer-focused courses rather than the designer-focused ones because developers are required to make the same structural decisions we do, like the priority order of elements in a page. Look for places where they’re recreating decisions you have made as part of the IA process and places where you can make their lives easier.
- Read the guidelines. (Or watch a great video explaining them in action.) The training you did in the previous step translates these success criteria into what those trainers think developers need to know about them, but that’s not going to be explicitly geared toward information architecture. Once you have that framework, you can go back and look at the original source. Many of them have huge IA implications, and you can consider how you might start applying them in your work.
- Find one thing to add to your IA artifacts. Once you’ve done the training and have your own ideas about the implicit requirements of the success criteria, find one thing you can start adding to a deliverable your team is already comfortable getting from you. If you do page description diagrams, define a tab order through them, which will help people with motor impairments and screen reader users. If you do wireframes, consider identifying ARIA landmarks or supplemental labeling for screen readers. The goal of this step is to make a small change that is useful to your team.
- Practice saying “This is an accessibility issue.” Most of the time, we don’t design bad information architecture because we don’t know any better. We make compromises and lose arguments. We have too little time and too many legacy constraints. Frequently, when I raise something as an IA issue, the feature team answers “We know, but …” because IA itself is never a priority. When I raise something as an accessibility issue, I usually get a pause and then a question: “How so?” I don’t always get my way, but I do get a conversation.
Technical accessibility is essential, but so much of what makes sites really usable and intelligible across access needs is good information architecture. I have found that every single IA-related thing that we should do 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. Anyone who has done any amount of IA knows that these are things they should be doing. Please take this as a call to go do them.
