The ABCs of Accessible Design: Why and How to Implement Accessibility into Your UX Workflows.
That accessibility document for your developers is not cutting it these days.
Behind every beautifully designed screen and interface lies a stark reality — those who are inadvertently left on the sidelines of the whole experience.
Imagine a world where the simple act of navigating a website becomes an insurmountable challenge, where the joy of discovery is overshadowed by frustration, and the power of information is difficult to obtain.
For many, this is not a hypothetical scenario but a daily struggle. In our increasingly digital age, there exists a significant population that remains locked out of the full web experience, unable to tap into its potential due to barriers that are often overlooked.
Overlooked to save alleged. “Time, money, and frustration” in corporate environments.
But since 2008 when the Department of Justice considered ADA applicable to government and business websites, everything has slowly, but surely been changing for the better in the United States and around the World.
Large lawsuits have included the likes of Target, Harvard, and Netflix. But that was not exclusive, thousands of small businesses with online presence have been sent to court for website and software ADA violations.
I have seen it with my own two eyes. While I was working on a website hosted on a commonly used e-commerce software platform, in use with a third-party template and third-party apps, we were sued for ADA compliance violations.
Legal challenges are very much real. However, it is not the only reason accessibility is important. Accessibility is about expanding user bases so everybody can experience the web.
As we go through the ABCs of Accessibility, keep in mind these 3 questions to think about along the way:
How do we make discoverability joyful for everyone?
How do we convince stakeholders of accesiblity needs?
What does an efficent process look like in UX Design?
A. All Things Should be Accessible All the Time for All Abilities.
People, including stakeholders, often ask the question:
What needs to be accessible?
The answer is… all things and everything.
Websites? Yes. Apps? Yes. Software? Yes. PDF Files? Yes. Videos? Yes. Images? Yes. Interactions? Yes.
So, when a stakeholder asks you, “Does our website need to be accessible?”
You should be asking back, “Is the sky blue?” If people are using the website, everyone should be able to use the website. And it’s easiest when we think about accessibility from the start before it's too late. Otherwise, we’ll be facing a bad experience for customers/users, negative sentiment about the company, and possibly even hefty lawsuits and fines.
Accessibility is not an optional feature or an afterthought — it is a fundamental requirement for creating inclusive, equitable, and user-friendly digital experiences. By prioritizing accessibility from the very beginning, we ensure that everyone, regardless of their abilities, can fully engage with websites, apps, software, and all digital content.
So, the next time someone questions whether accessibility is necessary, remind them: Inclusivity isn’t a choice — it’s a necessity.
Equality
Accessible websites and software provide equal opportunities for individuals with disabilities to access information and services and participate in various activities online. This helps bridge the digital divide and ensures that everyone, regardless of their abilities, can enjoy the benefits of the digital age.
This is why government and educational institutions are leading the way to make sure everyone has access to all the benefits and information related to government and educational programs (.gov and .edu). The government must follow ADA compliance concerning web accessibility. Just as government buildings must have ramps or elevators, websites must be navigable.
Legal Compliance
Many countries have laws and regulations in place that mandate accessibility for digital content and services. Adhering to these legal requirements is not only ethical but also protects organizations from potential legal consequences.
Between 2018 and 2023 over 20,000 lawsuits were filed related to web accessibility issues, including companies I worked for. These lawsuits ranged from companies with under $1 million in Revenue to those with Billions in Revenue. In fact, in my experience, certain law firms target companies with a small likelihood of funding legal counsel. Forcing companies to settle for outlandish amounts.
Would a law firm rather sue Netflix and battle their heavily funded and well-armed legal teams or a small startup with revenue in the low millions? The answer is that the startup will always be an easier battle than Netflix.
These lawsuits are not all predatory law firms (although many are) but also people who legitimately have trouble accessing web content they may need or want.
Everything we create on the internet should be accessible.
Legally speaking, are there exceptions? Yes. But when it comes to business and government actively neglecting or ignoring accessibility in design, that is discrimination. Not to use too harsh of terms, but it is also unethical and illegal in every sense of the term.
Business and Market Expansion
By making products and services accessible, businesses can reach a broader audience, including people with disabilities. This expands their customer base and can lead to increased revenue. Moreover, it enhances the organization’s reputation as socially responsible and inclusive.
B. Build with Accessibility in Mind, Not as a Burden.
When I was working on an e-commerce website for a startup, I was tasked with SEO. One of the leading SEO requirements is a solid site structure (headers) and alternate text (alt-text). So I made that my work.
Accessibility, of course, was an additional reason to do this work, but by doing so, the robots at Google who choose search engine results rewarded you, and in turn, drove sales.
Most companies don’t see accessibility as a profitable task to undertake, but instead a burden. I’ve heard one too many product owners who want to skip over accessibility to make things happen quicker.
Now, large companies have digital accessibility specialists, a role that will likely become more widespread in the coming years. We are quickly seeing large organizations take this proactive step as web accessibility spans and will flow into medium-sized organizations.
Seeing accessibility as a burden puts a company's product or services at an even larger burden of equality of accessibility and legal trouble.
Understand Accessibility Standards
Currently, WCAG 2.0 is the standard for digital accessibility. A and AA standards are often required by law. ADA law will integrate these standards, and AAA is often referred to as extra credit. Check with local laws.
Standards are often being updated and implemented, making accessibility a moving target throughout the digital space. Especially when it comes to government and educational institutions. Now, standards are flooding into the private sector as well, but even most government and educational sites aren’t fully accessible.
Continuous Improvement
Actively building with accessibility works amazingly, but auditing also needs to be implemented for ever-changing content and bugs within the site. It is not about becoming accessible once and never looking at it again. As I mentioned, standards change, and new issues on your website can pop up every day. Staying on top of issues can decrease risk and increase usability at any point in time. Staying on top and always improving should always be the goal. Take time out of the day or work week to check in and fix any quick issues and plan for more complex issues.
C. Collaborate, Communicate, and Check your Choices.
The key to accessibility is active communication with accessibility experts in and outside your team. Active communication with product owners, product managers, product designers, and developers.
Check choices by using color contrasters, including in Figma and black and white or green and purple colorblind filters in software or through extensions in browsers.
Check your work using screen readers yourself, or you could even hire an expert.
Testing for Accessibility
There are many ways to test for accessibility. The two most common ways to check a website or software for accessibility are manual auditing and software-assisted auditing.
Software-assisted is the most popular and is now offered by hundreds of software and agency companies. These software-assisted audits crawl sites and look for problems in source code that are related to accessibility, such as structure, alternative names, labels, and order.
It is commonly referenced that automated accessibility audits are nowhere near enough to catch all WCAG compliance issues. In fact, according to Siteimprove, they and similar competitors such as WAVE only catch 30–40% of accessibility issues as outlined by the WCAG standard.
So, if you are aiming for WCAG compliance, automated audits on their own are not enough.
Manual audits require a subject matter expert to manually go through each page with a screen reader or with solely a keyboard to identify what crawlers can’t identify. Such as video captions, correct skip links, display and order of information, as well as inaccessible imagery and other items that can only be recognized by a human user.
Manual audits also bring humanity to the website. If the tab order makes no sense in the context of the page or even if the whole page turns out to be just lorem ipsum gibberish, a human can flag it. Whereas an automated audit may not.
A third less talked about option is Functional testing. During functional testing, experts — typically people with disabilities — will use assistive technologies to navigate your digital experience the way a user would. For example, to audit an e-commerce site, a functional tester might try to browse for a product, add it to their cart, and complete the checkout process. Or, to audit a banking platform, they might try to log in and check their balance.
Whereas both automated and manual testing focus on conformance with specific WCAG criteria, functional testing focuses on the user experience of people with disabilities. This type, although rarely used, is probably the best way to test for usability.
Keyboard Navigation
Keyboard navigation is one of the key elements of manually auditing software. Keyboard navigation is used by people who are unable to use a mouse, such as the blind.
Beyond keyboard navigation are other machines used by people with drastic physical disabilities, including scroll wheels or sticks. Where users may not be able to use a keyboard or mouse.
Semantic HTML
Semantic HTML is one of the key components that are caught by software-assisted auditing. Neat and properly formatted HTML helps screen readers and tabbing order correctly go through a website.
Semantic HTML is often one of the most underlooked elements of accessibility design, but it tells web browsers, screen readers, and users what the heck is going on. Semantic HTML refers to properly using HTML in the way it was intended to be used. Footers are used as footers. Headers as headers. Navigation as navigation. Lists as lists, body content as <p>, this does wonders for accessibility and saves a ton of backtracking.
You can learn more about semantics here: https://www.w3schools.com/html/html5_semantic_elements.asp
Semantic HTML looks like this:
D. Define and Document for Developers
The best way to check accessibility doesn’t go awry is to define how the website or software should be coded for your developers. This is what we did when we wanted to build world-class apps for Fortune 500s.
Yes, it takes a lot of time and resources. We are talking about months of project time and teams of over 1–3 people.
The hard truth is that giving someone a 20-page document about how accessibility should be done in code is not going to make sure it gets implemented properly. No one is going to read that, let’s be real, and on top of that you have to take it in and do research while implementing. The truth is when developers implement, they know their best practices but accessibility is bound to be missed in some issues. Some tab order is going to be a guess, and some labels will be missed. Some headers and alt-text might even get missed.
Working with an accessibility expert by defining the code and highlighting it in a design of how accessibility should work and be developed is how it should be done. Developers should have no excuse when they are given the answers.
Educate Your Team with Training
I agree that this is one of the most difficult parts of the process. Ensure that everyone involved in the project understands the importance of accessibility and how to implement it. Tell the team to sweat the details and take training, still, you may need to tell them about tab orders, headers, and page elements (such as aria-labels) where applicable.
When tickets go to developers, such as the common JIRA ticket simply attach the accessibility documentation in addition to the other requirements and make sure you’re available for any questions. All of the documentation, however, should be in HTML/CSS/Javascript terms and, therefore, be easy for developers to understand and integrate.
Document Practices:
Keep records of accessibility guidelines and best practices for future reference.
Collaborate across teams to help others understand accessibility and implement it across the company.
Check out this template to highlight and define accessibility for developers within your Figma files:
The Process should look like this: Design Screens with accessibility in mind, Get Approval, Annotate, develop, QA, and then deploy.
Then scheduled maintenance: The grind never stops. Make sure you are keeping up with new laws and accessibility best practices as they come out and actively maintain them through site crawls, manual audits, and QA.
Links
A11Y Kits I’ve used for Fortune 500 projects: https://www.figma.com/community/file/953682768192596304
CVS Health A11Y kit: https://www.figma.com/community/file/1311421011482282592
Government section 508: https://www.section508.gov/
W3C Standards oftern referred to: https://www.w3.org/TR/wcag-3.0/
Website lawsuit information: https://accessibe.com/blog/knowledgebase/ada-website-lawsuits
Ross Dillon is an Experience Designer and Strategist who has aided in accessibility projects for Fortune 500s, Major Health Systems, and Startups.
