When you think of accessibility, you might picture a user with a visual or hearing impairment. But the reality is that there are a multitude of disabilities with variations spanning auditory, cognitive, neurological, or physical. All of these must be taken into account when designers set out to create a new digital product or experience.
Accessibility is important for users because they need to access and accomplish tasks that they set out to perform on your website or in your product. When organizations don't have a dedicated accessibility team, the UX team needs to be the advocate.
Despite the rise of accessibility as a topic of conversation in UX, some of the most widely used apps are still guilty of being inaccessible. By properly planning and designing for all users, you're moving accessibility forward as a discipline.
It can be easy for designers to view accessibility as a constraint. But it's better to think of it as creating the broader experience, one that all of your users will benefit from.
It's so common for disabled users to encounter frustrations when they interact with the web or other applications. The extra effort you make to take these people's needs into account will be greatly appreciated and potentially life-changing. Besides the human empathy component, your attention to detail will help to create brand loyalists out of users who genuinely know you're looking out for them.
Sometimes the team gets stuck in their day-to-day routine and the focus is on getting things built and shipped. When working with a mixture of roles on a team, not everyone may know the ins and outs of accessibility.
Accessible experiences need to be created because the internet is now an integral part of modern life. It’s important that all users have equal access to content. No matter what the content type—education, shopping, health, social, etc.— all measures should be taken to make it accessible. When the team realizes the importance of accessibility, they'll do the work that it will take to release a product that's accessible.
What should be in the accessibility plan? Should the plan include everything? The answers to these questions will vary depending on your project and team. There are levels of ADA compliance but we will mention some basic aspects to keep in mind during the process.
These serve as a great starting point during the prototyping phase. Be sure to do some research on the different levels of accessibility before making the official plan.
Here are some basic questions to think about when planning your experience and doing the design work:
There are a few things that should be assessed during the design phase. While prototyping, it’s good to keep these in mind. It makes sense to design for accessibility right at the beginning rather than having to go back and adapt things later.
This is easy to overlook when prototyping. Often we get wrapped up in the visual and what looks good. It’s important before making a final decision on color for various design elements that it passes a contrast check.
Typography needs to be large enough and have enough contrast with the background to ensure that users can read it. Images and icons also need to be distinguishable. Things like status icons should rely on shape, rather than color, to be recognizable.
The Stark plugin works wonders for this. Check things as you go along to determine whether it will fail or pass a contrast check.
First, it’s good to make sure that a focus style exists. There is a browser default that is most common. When you think of focus states, you probably recall a blue outline on a form field, navigation and other links. This can be styled differently so it's more noticeable. If you decide to get rid of the blue outlines, make sure to replace them with something else that stands out.
Notice how the University of Michigan’s Accessibility website has a very prominent focus state? This is shown in the header, "web accessibility" is highlighted.
It’s important to use semantic HTML5 markup. Depending on your job description, this may not be something UX is responsible for putting into production. However, having a working knowledge of this will help even if you’re not working directly with the HTML. Semantic HTML is an important starting point toward good accessibility practices.
When a screen reader scans a web page, it gets information about the content and page structure. JavaScript is often used, but keep in mind that CSS styling and JavaScript is ignored by a screen reader. It’s going in page order as it reads to the user.
There’s no need to reinvent the HTML wheel. In fact, it’s best if you don’t. Stick to the default html tags and headings. When you inspect web pages, you see tags like <header>, <nav>, <main>, <article>, <footer>, and more. Tables should contain actual table data—not just a way to layout a page. Using tags improperly will confuse both the user and screen reader because it follows a particular way to read the elements on a web page.
Headings are very important as well. There’s a reason why there are 6 header tags. This range gives the user an idea of the content hierarchy. You may find that It helps to indicate this in your mockups.
Be sure to use one H1 per page, and in many cases this matches the page title. This gives the user an idea of what the content is all about. Be consistent with heading levels (the <h2> is more important than the <h3>).
By default, any actions a user may need to perform should be able to be carried out by using a keyboard only. Accessing the content by tabbing becomes very important because not all users access the web with a mouse (this is relevant to non-touch devices).
Users with motor disabilities will navigate with the Tab key. Links and buttons will be accessed using the Enter key. This is why the focus state is important. The user will need to see where they currently are.
For visually impaired users, images that are non-decorative need ALT tags. This explains to the user the content of the image. Images that are decorative, rather than content related, can have an empty ALT tag. That way the user is not slowed down with content that is unnecessary. No matter what the image, it’s important to know that if there is a missing ALT tag, the screen reader will read the image’s URL, which is not a good experience.
It can take some doing to make videos truly accessible. Users need a way to quickly pause videos and animations. For those who rely on reading, closed captioning is necessary for them to get the full experience. If a transcript is available, that’s a great feature to have.
It’s best to give the user control to play the video. Videos that play automatically can be problematic to some users. For example, screen reader users may not be able to hear their screen reader over the video.
Animations can be designed to be accessible. In fact, they often enhance the experience and benefit the accessibility initiative. Animations can help convey that an action was successful, something failed, or any other way to get the users attention when appropriate is a great way to utilize them.
Care should be taken when designing animations. Animations that are mild are preferred. When designing animations, always think about the relative size of movement to the screen. Consider this for various device sizes.
Small animations like animated icons, hover states, expanding search bars, etc. most likely won’t cause an issue. However, bold animations that cover a good percentage of the screen may not be a pleasant experience for some users. They may feel dizzy, disoriented, and even sick if animations trigger a reaction.
"Scrolljacking" is a fairly common animation. When the scrolling action behaves differently than what a user expects, it might cause issues for some users. If it’s combined with other animations, this could be even more problematic.
UX has an important role in accessibility, it’s vital that ever user can access the web. Hopefully these accessibility tips will help designers plan for accessibility in the very beginning stages of a project rather than treating it as an afterthought.