Accessibility is part of UX (it isn’t a swear word)

People often go a bit wobbly when accessibility is mentioned. Visions of text only websites, monochrome designs and static content swirl in their heads. Teeth are gritted, excuses are prepared, and battle conditions ensue. The reality is that accessibility is simply a key part of UX. A truly outstanding digital experience is a fusion of accessibility, usability, creativity and technology. The trick is to weave those things together, and to do that successfully there needs to be a cross pollination of skills and expertise. The good news is that accessibility is usability under a magnifying glass. If you’re thinking about great usability, the chances are that you’re already thinking about great accessibility too.

Meaningful reading order

It’s a curiosity of web design that the visual order of content doesn’t have to match the order of content in the underlying HTML code. With the separation of HTML (for structure) and CSS (for visual design) it became possible to change the visual arrangement of content without disturbing the underlying HTML. This is handy for web developers because they can easily make cosmetic changes to a web page without rewriting the HTML code. Used wisely, it’s also something that can be used to create web pages that work well for both sighted and non sighted people. Most people don’t know that HTML exists, let alone that it’s the key to the way their browser controls the structure of information on the page. That’s the way it should be of course. Providing the page is laid out in a logical way, most people will experience the site without giving the slightest thought to what’s going on under the hood. For blind people who use screen readers to access their computers, the HTML is a bit more important. Screen readers pay almost no attention to the way a page looks, but they do care a lot about the way it’s structured. Where as a sighted person might read the flow of content from top left to bottom right, a screen reader will read the content in the order it’s presented in the HTML. Let’s take a typical page with a header, footer, left hand navigation, main content column, and right hand related column. It’s a common page layout because it makes sense visually. A sighted person can focus on the area of the page they’re interested in, and (assuming they use a mouse) can click on the relevant bit.

A screen reader user on the other hand would have to move through the header and the left hand navigation, before reaching the main content column. Screen readers can only focus on one thing at a time, so they have to move through the page in order and that order is governed by the HTML. Rearranging the page so that the header was immediately followed by the main content column, then the navigation and related information columns, would make things much more convenient for screen reader users. Visually this layout wouldn’t be nearly so convenient for sighted people because it breaks with the common convention of a left hand navigation.

Here’s where the clever bit comes in. When a web page is created, you can do both. You can have an HTML content order that works for screen reader users and a visual content order that works for everyone else. The two don’t have to match, but they should both make sense in their own right. You’d never make the footer the first bit of content someone encountered of course, whether they could see the page or not. So what does this mean for UX practitioners? The way content is ordered in your wireframes will influence the way it’s ordered when the page is translated into HTML code. Don’t worry, you don’t need to become a fully fledged web developer, but it’s a good idea to understand the different ways people will engage with the content on the page and to bear in mind that the process of translating a wireframe into code may mean the resulting experience for a screen reader user is very different from that of a sighted person.

Consistent navigation and layout

When you create wireframes for a website, consistency will already be on your UX radar. What you may not know is that you’ll also be thinking about an important aspect of accessibility as well. When you evaluate a website with people with disabilities it’s common to find that mild challenges for other people become tremendously magnified for people with disabilities. For example, a slight pause on a link might indicate the text isn’t helpful to someone. When that pause becomes a sustained break in the task for a person with a reading disability, suddenly the problem becomes much more evident. Consistency is one of those areas where this magnification effect is very noticeable. Putting elements (such as the logo or search facility) in the same place on every page makes it easier for everyone to locate and identify them.

Moving things around arbitrarily tends to confuse most of us after all, and confusion rarely leads to a good experience. For a partially sighted person using screen magnification, that kind of confusion can become a real problem. When the area of the screen you’re focused on is magnified multiple times you don’t take in the whole screen at a glance. A common strategy is to look for key landmarks on a page that you can orient yourself by. Knowing the navigation is on the top part of the page makes it easy to move the magnified area to the extreme edge of the window, and then you know immediately where you are. Unless of course the navigation has vanished or been moved elsewhere on the page.

Interaction consistency is also important for much the same reason. Each time you add a widget to a wireframe it should behave the same way that it does everywhere else on the site. Changing the way someone is expected to interact with something takes us right back to general confusion for everyone. For someone with a cognitive disability that affects their ability to learn new skills, that kind of confusion is a complete showstopper. Each time they encounter a particular widget (such as a search facility or content filter), they’re forced to learn a whole new way of interacting with it.  Ensuring that things look and behave consistently each time they’re used makes the experience possible (as well as enjoyable) for people in these groups.

Form controls

If you’re creating high fidelity wireframes, another thing to consider is form and widget controls. It might sound obvious, but forms should have submit buttons and widgets should have controls. Let’s take a drop down form field with a range of navigation options in it. Technically speaking the form doesn’t need a submit button. A mouse user might click on the field, scroll down through the options and release their mouse button to make their selection. At that point the chosen web page would load automatically in their browser. For someone with a mobility impairment who doesn’t use a mouse, things get a bit more complicated. Opening the drop down list of options isn’t a problem, but without a submit button the form has to work automatically. That means that as soon as keyboard focus lands on an option, the selected page will load in the browser. Too bad if you wanted anything other than the first option in the list. By including a submit button in your wireframes, you’re putting people in complete control of the action.

Including a submit button with an appropriate label is also helpful for people on the Autistic spectrum. In some cases it might not be possible for someone on the Autistic spectrum to complete a task unless there is a very clear call to action. A search form with no submit button, or with a submit button labelled “Go!” (go where exactly?), can make it next to impossible to complete the task. Making room in your wireframes for widget controls is also a good idea. A revolving carousel for example. We all find constantly moving content distracting on occasion, or we notice it just in time for it to vanish out of sight. Few of us have the patience to wait for it to reappear. For someone with a learning disability it can be a monumental effort to try and read the content before it disappears. People on the Autistic spectrum may find the constantly moving content enough of a distraction that they have to leave the page entirely. Neither is a great experience. Including pause/play, next slide and previous slide controls puts people back in charge of the way they consume information.

Descriptive link phrases

Clear and concise link text is another key UX consideration, whether the links form part of the Information Architecture (IA) or sit within a piece of content. From an accessibility point of view it’s even more important to choose link texts that are helpful.

Many screen readers include the option to list all the links on a page, effectively removing them from the surrounding content. No distinction is made between links from the IA or links from body content. For this approach to work, link texts need to be understandable in their own right. A list containing 15 “More…” links completely undermines the task. Something similar happens for screen magnifier users. When a link is magnified multiple times it can take up most of the available viewing space. This makes it difficult to associate the link with its surrounding content. Unless the link text acts as an effective sign post, it takes some effort to explore the nearby content to discover where the link might actually lead.

Conclusion

It may be that you’re wondering whether this level of granularity is really within the realm of a UX practitioner. The reality is that the best practice you put in place now will influence the creative designers and developers that take your wireframes and evolve them into the finished website. Accessibility is a journey and that journey starts as soon as a UX practitioner first considers how a web page might be used, what it might contain, and how it might be presented. This article originally appeared in the print copy of UX Magazine.