Recently, accessibility in tech has been a hot topic. We are currently at peak popularity for terms like “WCAG” and “A11Y” in search engines. Certainly, the rise of web accessibility lawsuits plays a part in this increased interest, but with COVID-19 we are faced with using more online tools now than ever before. As UX designers, it is our responsibility to make our experiences as usable as possible, which also means considering inclusive design needs.
Inclusive design is about serving all types of people, and being exceptionally aware of our biases when creating designs. If you’re doing it right, you’re building a product that is usable for people from all backgrounds, including people with disabilities. The truth is, inclusive design is just better design.
I’ve been a UX designer since 2012, and I’ve been emphasizing inclusivity in my work since the very beginning of my career. My thesis for my undergraduate degree was a (poorly made) animation on the value of universal design. Inclusive design is also my focus in my Master’s, in which I am studying digital accessibility. Inclusive design, specifically accessibility, is something that I enjoy learning about because it’s this magical combination of great design and tearing down systemic biases.
That being said, there has been a learning curve for me, and there is for many of us. Accessibility is a part of UX, but it isn’t always taught to be. Some of us learn the basics but don’t know how to go beyond them or how to implement accessible design in our processes. Often times, accessibility is pushed out of our MVP work and put into a “future state” phase, never to be addressed. If you haven’t spent time learning about accessible UX, you’re not alone, but now is a great time to get started.
Over the past few years, I have worked on multiple teams to establish better accessibility standards and procedures, and I want to help others do the same. In this post, I want to acknowledge some of the things I hear from designers every day about accessibility. I hope I can provide some clarity so we can all be empowered to build more accessible work and sell accessibility to leadership.
Yup! If you are in the United States or EU (as well as many other places) I’m talking to you. To be sure, you can look at web accessibility laws and policies as they relate to the areas you are serving. For U.S. readers, take some time to learn about these:
The Americans with Disabilities Act (ADA)
The Americans with Disabilities Act, or ADA, essentially states that if a business is a “public place of accommodation,” then overall accessibility — digital or otherwise — is expected. As the web and smart devices become integrated as crucial parts of our society, it is essential to make them accessible. What is amazing about this is that the ADA was established back in 1990, which means that accessibility in our work isn’t some new trend, it’s been a necessity for over 30 years.
Section 508 of the Rehabilitation Act
Section 508 of the Rehabilitation Act requires the federal government to take accessibility into account when procuring websites, telephones, copiers, computers, hardware, and software. While Section 508 was initially established in 1973, it was updated in 1998 to specifically include electronic and IT considerations. Even though Section 508 applies only to federal government entities, to sell to the federal government, private entities have to offer accessible products and services. This means that if your business wants to work with the federal government, they are obligated to accessible.
Some other notable web accessibility regulations in the U.S.:
Regardless, the legal obligation isn’t the primary reason we should be building websites, apps, and products that are accessible. Accessibility is a human right, and fortunately, we live in a time that makes accessibility exceptionally easy to do. It shouldn’t take a law to motivate us to build better work. I encourage you to take an empathetic approach when it comes to accessibility. Yes, the law matters, but we as designers are capable of going beyond the bare minimum and can build great work if we try.
Disclaimer: The legal information provided here is presented for informational purposes only, and should not be construed as authorized legal advice.
Accessibility is a lot easier to do than you might think and cheaper than the alternatives: doubling back on work, lawsuits, bad UX, and a poor reputation. There are many different ways to measure easy vs. hard: skills needed, the time required, the difficulty of the task, and so on. Considering accessibility from the beginning saves time, money and effort later on while also building a better user experience.
Retrofitting web experiences to be accessible is far more expensive than it is to build them accessibly in the first place. 20% of components written without regard to accessibility, will need to be rewritten, which can cost a lot. The good news is that if you are working on redesigning a product, this can be repaired as you go. We never consider our products and experiences to be “done,” so there will likely be many opportunities to fix your components anyways.
As we also discussed, avoiding accessibility is a legal liability. That shouldn’t be the main reason you consider accessibility, but it is undoubtedly a reason your organization will. So it’s important to leverage this information when selling the importance of accessibility to leadership.
In 2018, the number of federal website accessibility lawsuits nearly tripled to more than 2,250. I expect that number is going to remain steady or continue to rise, due to the prevalence of web usage and the increasing number of services moving online. Not only are people using the web more, but we are required to do so to live in today’s society. If your company is served a lawsuit, the cost can be high, especially if the lawsuit goes to court, and most especially if the court rules against you. Why bother with all of that hassle when it takes fewer resources to be accessible in the first place?
On the other side of the coin, accessibility is related to considerable improvements in overall usability, and increased user satisfaction. The global market of people with disabilities is over 1 billion, with a spending power of more than $6 trillion. Many tools designed specifically for people with disabilities, such as email and voice controls, have shown to be successful with a broader audience as well. While accessibility has different considerations than general usability, the application of accessibility standards is related to increased profits and improved results.
While accessibility can’t be done with the simple click of a button, the cost of implementing it in your experiences is far exceeded by its savings and return on investment.
Yes, you definitely do. There is no way of knowing exactly how many of your users have disabilities, but this is also a hard number to quantify. Not all disabilities affect a person’s ability to use the internet, and disabilities can have different levels of severity. People can gain or lose a disability at any given time, and many people with disabilities do not register them. For a general reference, people with disabilities make up about 20% of the population at any given time.
I’ve had people ask me if they can use Google Analytics to find out what users have screen reading applications, and I am glad to say it’s impossible. If someone was running a physical store and wanted to know if they should ask every customer coming in if they had disabilities, no one would think that was appropriate.
People asking for this data usually mean well, but the harsh reality is that this data can also be used as a way to de-prioritize accessibility. It’s also nearly impossible to gather this type of data considering that we can’t measure the people who would use our product but can’t. For example, let’s say you are working on an application that has no responsive behavior and someone says: “We don’t need a responsive site because our data shows that only 10% of our users are on screens less than 1024px.” That data may be accurate, but how can we quantify a user’s need for a product that already doesn’t serve that need? We can’t know if users would like to have a mobile-friendly based on what already exists if what exists excludes them.
The reality is, our data around accessibility needs are often biased and not compelling enough alone. It’s more important to explain how accessibility is non-negotiable. Without accessibility, people with disabilities can’t use web sites, and that can have a dramatically negative impact on their lives. Again, I want to remind you that all of us, especially now, are required to use tools remotely. Imagine how difficult it would be to be excluded from the tools you need to use every day. Anyone can acquire a disability at any moment in time, and other people live with temporary and situation disabilities. When it comes to advocating for better work, there are different quantifiable ways to validate it’s worth it. If you have to sell the value of accessibility to leadership, you can find many other (better) ways to do so, such as:
You can also go about talking through the importance of accessibility by talking about real experiences people with disabilities have. One example that has been on my mind with so many of us working remotely is the lack of automated real-time captioning available via video meeting software. Every time you ask someone with a hearing impairment to join a Zoom call, you may be unintentionally marginalizing them. These differences that you may not notice make all of the difference to someone who needs them.
I’m always surprised when designers say accessible designs are ugly and/or boring because the reality is that most accessible design solutions are invisible. People tend to believe accessibility in UX is only about things like color contrast or typography choices, when in reality, it goes into content strategy, architecture, code, and so much more. There are many opportunities for your work to stand out when it’s accessible.
In fact, accessible design actually tends to look better. No one wants royal blue links on a black background anyways! Did you really expect anyone could read that 10px #f4f4f4 text?
UX design isn’t just about being creative anyways. It’s about finding wicked problems and solving them. I know many people drawn to UX have a love for art, photography, and graphic design, so keep in mind that there are still plenty of opportunities to make creative and exploratory work while being accessible. Feel free to push the limit, but validate your work with research and testing. Many amazing products and experiences are beautiful and accessible all at once, while also solving problems.
It’s also important to note that you should be sure to build one experience for all of your users, rather than segregating experiences that are “accessible” from your primary platform. When we build accessibility into our work, it not only can be fantastically creative but also highly usable. Our responsibility is to build better products that work for the people that use them, which is the best job in the world if you ask me. Designs for people with disabilities can be just as beautiful (or as ugly) as designs for anyone else. That part is up to you.
It’s never too late to start building a more accessible product. As mentioned, we want to include accessibility at the beginning of a product’s life, and through every product cycle, but it’s never too late to fix it. Accessibility is not going away. As long as there are people, there will be a need for accessible design.
You may already include baseline accessibility standards into your product. If you want to build more accessible products, I recommend a grassroots approach to start.
Here are some grassroots approaches to get started:
If you’re a designer:
- Find allies in your team and the organization, create or join a taskforce that regularly meets and decides on action items.
- Find a sponsor in a leadership position to advocate for establishing accessibility standards across your organization. Having top-level buy-in is essential for setting accessibility expectations within a company.
- Make time to ensure you are meeting design requirements and discussing them with other designers in your organization to help them do the same. If you have a design system, start with accessibility there, and you will find you have quick results.
- Work with your lead to communicate issues you see and find ways to raise those concerns to leadership.
If you’re a design lead:
- Work with product owners to include accessible business requirements and acceptance criteria into epics, and stories
- Work with development to ensure your designs are being built with accessibility in mind. Establish good relationships with your development team to keep communication open. It’s also helpful to get development teams on tools like Pa11y.
- Ask QA if they are following accessible testing requirements, or get them started using Axe Pro Beta so they can learn some basic automated and manual testing techniques. Work with leadership to establish the standards necessary going forward.
- Give your team resources and training during work hours, and give them the tools necessary to succeed.
- Hire people who specialize in accessibility, and provide them with enough authority within the company to make a real difference.
- Hire people with disabilities, as it’s much easier to understand accessibility when you see the effect directly on people you know and interact with. Note: If you are hiring people with disabilities, ensure that you have the infrastructure in place to support them, from HR and ERGs to physical building accessibility.
If anyone tells you that there’s no way to measure the accessibility of our work, they are wrong. If you are looking to understand how accessible your work is, refer to the official WCAG 2.1 specification for the full list of success criteria and A to AAA standards.
For reference, A to AAA standards indicate the level of compliance in your experience where Level A refers to the lowest level of accessibility conformance, and Level AAA refers to the highest level of conformance.
The truth is, there is no single tool that can tell you what level of compliance your site or product has. Each atom, molecule, organism, and page needs to be evaluated, so it’s impossible to build a tool that can assess your entire experience. Much like user experience design itself, it requires critical thinking and evaluation skills that automated tools alone are not capable of.
If you’d like to know what overall standard your site meets, you will need to hire a consultancy to audit it and evaluate how accessible it is. But before you or your team decides to do this, I would recommend intentionally setting an internal standard and meeting it. Most organizations set AA as their internal standard because it is both achievable and meaningful without being too burdensome on developers.
Sorry, but not really, no. Accessibility requires more than a checklist to do well. Think of accessibility the same way you think of user experience design: lists can offer some best-practices, but every experience will require unique problem-solving skills and evaluative testing. This involves understanding people’s needs and challenges better than they do themselves, and testing solutions… do y’all know anyone who can do that kind of work? 😏 I already mentioned the WCAG list, but if you’re looking for something that’s easier to digest, start with these instead:
- WCAG Quick Reference Guide: This is my preference for web accessibility checklists because it includes everything we need to consider and an explanation about it. However, I know this list is pretty daunting for some so as an alternative…
- A11Y Checklist: This is an excellent resource for folks who are looking to have something a little easier to check through, or who want to get more comfortable with accessibility practices before they go further.
Again, take these lists merely as starting points and not as a catch-all accessibility solution. True accessibility needs to be baked into every part of your product lifecycle and evaluated by people.
Being interested in building more accessible work is the first step and an important one! You don’t have to be an accessibility specialist to learn the basics. There are many ways to get started, but I would recommend you immerse yourself in some tutorials and readings to get familiar. Don’t be afraid to start building better work now even if it means you’re changing your process; processes are intended to be replaced. Here are some resources to get started.
Readings
- Accessibility for Everyone-Laura Kalbag: I love this book because it essentially lays out all of the WCAG guidelines in a digestible way. The book is quite brief but explains the essential elements of web accessibility quite well.
- Web for Everyone — Designing Accessible User Experiences — by Sarah Horton & Whitney Quesenbery is another book that is well-known across our industry as an introduction to inclusive design.
- Designing for Real Life — by Sara Wachter-Boettcher and Eric Meyer
- Sara Soueidan’s blog: Sara Souedian has been a true inspiration to me in this space. I saw her speak at Smashing Conf San Francisco 2019 and I was blown away by how easy accessible client-side development can be. She is a great resource to front-end devs.
Tools
- Stark Colorblindness Simulator for Sketch, this is is a helpful tool to check color contrast in the context of your designs. Figma has some great tools as well.
- Color Contrast Checker from WebAIM. This one is one of my personal favorites because it’s detailed and shows you the contrast rating of objects in real-time, by size and by usage.
- axe plugin for automated accessibility code review from Deque. The axe plugin is another staple I like because it spends a lot of time explaining what you are looking at, why it isn’t accessible, how severe an issue is and ways to fix it. The beta tool also allows you to generate a heuristic analysis and export it, which is something I’ve used many times.
- Lighthouse automated code review from Google is another tool that I’ve heard people having great success with. Unlike axe, it also analyzes for performance, SEO, and much more. When you use inspect in Chrome just select the “audit” tab to use it.
- WAVE Toolbar — Chrome Extension (Mac/Win/Linux) is another tool that evaluates code, it can be a little simpler to use than axe or Lighthouse. It also does a good job of clearly indicating the location of accessibility issues on a page.
- Silktide Disability simulator — Chrome Extension, this is really helpful for building empathy with people who have disabilities and how they interact with the web. It definitely doesn’t go into a huge amount of detail or specifics in terms of particular needs and disabilities, but it can be helpful to get started.
- NoCoffee — Chrome Extension (Mac/Win/Linux) is a tool that has more advanced disability simulations, specifically around vision impairments.
- If you really want to get familiar with screen readers, try out VoiceOver (Mac, iOS) or NVDA (Win/Linux). I’d recommend taking a couple of hours just experimenting with these and their hotkeys. Try to do what you would normally do, except use these tools. At first, you can start off using as a supplement to your normal experience, but when you get comfortable I’d also recommend trying to use them without relying on your vision to navigate to better understand how they work.
Corporate Resources
I recommend using these as a way to show your leadership teams that industry heavy hitters are taking accessibility seriously. I’ve had success showing stakeholders these resources to help them understand the value of accessibility from an organizational perspective.