Web accessibility is the process of ensuring that all of your website’s users are able to have access to and properly interact with your website’s content. Making a site accessible means you are maximizing your website’s architecture, layout, content, and build processes to be able to reach as many users as possible, and to make their experience as equal as anyone else’s. But why should you take on the added work of making your website accessible.
Reason 01 to Implement Web Accessibility: Loss of Users and Potential Profit
According to the CDC, there is currently 61 million people in the US with a disability. That means that 26% of our US population is disabled. Those statistics mean that as a designer or developer, if you are not accounting for web accessibility in your projects, 1 out of every 4 of your users won’t be able to use your website. That’s a huge portion of your user base, and for an e-commerce platform, a 26% decrease in your user base affects your bottom line – a direct 26% potential monetary profit loss.
Reason 02 to Implement Web Accessibility: Potential Lawsuits
But not even considering the monetary matters at hand, there are also possible legality issues at play for non-accessible websites. Under the Americans with Disabilities Act, there have been additions (specifically in Title II and Title III) that now protect people from being discriminated on based on their disability via electronic communications. This means that your website (depending on its sector) may or may not be liable to a lawsuit if it falls under certain sectors (such as government or education sites) or if it is an e-commerce store (with with a physical location).
Reason 03 to Implement Web Accessibility: Moral Duties
So now considering the fact that not implementing web accessibility in your websites could mean a potential loss of users, loss of potential revenue, and introduce you to a possibility of potential lawsuits, know that implementing web accessibility is definitely the smart thing to do, business-wise. Or if you’re like me and are just a good person, you know that not only is it the smart thing to do, but the right thing to do for our fellow site users to all be able to access these online experiences equally without bias or discrimination.
Who sets the guidelines for web accessibility?
Before we start talk about the how to implement web accessibility, let’s first start with who is behind this initiative. There’s quite a few acronyms for the organizations, projects, and guidelines themselves, so let’s break those down first.
- W3C – The World Wide Web consortium (W3C) is the organization that sets standards for web accessibility compliance.
- WAI – The W3C’s initiative for creating the guidelines is called the Web Accessibility Initiative (WAI).
- WCAG – The actual accessibility guidelines themselves are called the Web Content Accessibility Guidelines (WCAG).
- There are multiple incremental versions of the WCAG, with each version expanding on the last. The latest version is WCAG 2.1, as of June 2018.
- A new WCAG 2.2 release is expected for 2021.
How are the guidelines measured?
The accessibility guidelines are ordered under four principles, referred to as POUR. There are four principles that organize the many guidelines set by the W3C. Essentially, to be accessible a website must be:
- P – Perceivable – users must be able to perceive the information being presented. It can’t be invisible to all of their senses.
- O – Operable – users must be able to operate the interface. The interface cannot require interaction that a user cannot perform.
- U – Understandable – the content or operation of the user interface cannot be beyond a user’s understanding.
- R – Robust – the content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
What levels of accessibility can I achieve?
There are three levels of web accessibility that you can achieve. Each level assumes you covered all the guidelines from the previous levels before advancing to the next one.
- A Level: The baseline for all websites to adhere by. Easiest level of difficulty to implement, with less guidelines to follow.
- AA Level: Includes A-level guidelines, plus many more detailed design-specific guidelines. Mid-level of difficulty to implement.
- AAA Level: Includes all previous levels’ guidelines plus more advanced details that now include animations and content.
What are the types of user disability limitations should I account for as a designer or developer?
The 61 million people in the US with disabilities don’t all have the same disability type. This means that implementing web-accessibility in a project is not a one-stop solve-all solution. The types of disabilities that can hinder a user’s access to the information on your website comes in many forms, including but not limited to:
- Loss of Vision: There are over seven different types of color blindness (such as protanopia, deuteranopia, and tritanopia) and four different levels of visual impairment that can effect how a user views (or doesn’t view) your website that should be considered.
- Loss of Mobility: For users with slow mobility responses, significant loss of mobility, or even the complete absence of limbs, it’s more difficult to navigate websites with traditional methods of mice and keyboards.
- Loss of Voice: users that have lost their voice may have a hindered experience when using voice command software, such as Siri, Alexa, or even live in-game chat conversations.
- Cognitive Disabilities: There are many types of mental disabilities that can inhibit a user’s perception of the content on your web page. Think of traditional disabilities such as autism, ADHD, OCD, but also less-thought of cognitive disabilities such as foreign language barriers that may reduce a user’s ability to fully understand your website’s content.
As designers and developers, we need to make sure we design experiences with all these users’ limitations in mind. Considering the magnitude of users you are accounting for, the large variety of disabilities you should account for, and the intricacies of meeting the W3C’s accessibility guidelines, I consider the most important rule for web accessibility is that web accessibility is not an after-thought.
Implementing web accessibility is a multi-role interdisciplinary process that must be carefully thought out at the start of a project, not post-launch. Designers need to set up developers for success by choosing appropriate colors, fonts, and layouts. Developers need to use user-friendly development practices and clean, accessible, and navigable code. Content creators need to write clear, and concise copy that is easily understandable by most users. As you can see, accessibility is a team-wide effort, but with a little up-front effort and cross-discipline communication, it can be achieved. Because of this, I’ve broken down some top tips for making websites accessible, per role:
Implementing Web Accessibility as a Designer
Designers have very clear-cut guidelines in the WCAG 2.1 list that dictates very clearly the rules to achieve A, AA, or AAA level accessibility. Here are some of the changes you can make to your design workflows today to make your sites more web accessibility friendly:
- A Level:
- Use a contrast ratio of 3:1 on all text content.
- Ensure color is not the only means to convey information, such as the color red used on form error messages.
- AA Level:
- Use a contrast ratio of 4.5:1 on all text content.
- Do not rasterize text onto an image, use actual text-based content to display that information in a way that screen-readers can interpret them.
- AAA Level:
- Use a contrast ratio of 7:1 on all text content.
- The max-width of content is no more than 80 characters.
- Do not justify text, to make it easier to read.
- Set line spacing to at least 1.5 relative units, and paragraph spacing should be at least 1.5 times the line-spacing.
- The minimum size for a tappable element should be at least 44px x 44px to meet the minimum tappable area.
Web Accessibility for Content Creators
Any content creator also has guidelines in the WCAG 2.1 list that that can help them achieve A, AA, or AAA level accessibility. Here are some of the top tips to make your sites more web accessibility friendly:
- A Level:
- All web pages must have titles.
- Provide captions for any pre-recorded audio content (such as podcasts, videos, and live streams).
- Provide labels or instructions whenever asking for user input.
- AA Level:
- All content should be able to be determined by a translator, with the exclusion of proper names and technical terms.
- All links should have descriptive text that tells the user what they’re clicking on before the click it.
- Provide captions for any pre-recorded and live audio content (such as podcasts, videos, and live streams).
- AAA Level:
- All abbreviations have their expanded form ready in order to be picked up by translators.
- Any idioms or jargon should have a way to be translated to other languages.
- The reading level of the content should not pass a lower secondary reading level.
- Sign language is provided for all pre-recorded audio content (such as podcasts, videos, and replays of live streams).
Web Accessibility for Developers
A lot of the web accessibility starting points for developers is to implement the standards set up by designers, such as: ensuring fonts have minimum sizes and color for contrast, making sure foreground and background elements have enough contrast, etc. But there are also a lot of development-specific guidelines, such as:
- A Level:
- Write good, clean code. By this I mean ensure all opened tags are closed. Nest elements appropriately. Make sure any page ID’s are unique to one element per page.
- Prove alternative text for all non-text based content (such as alt tags on images, svgs, and graphics)
- In concern to animations and videos, for any moving, blinking or scrolling information that auto plays, lasts more than five seconds, there must be an option to pause or stop.
- For forms, provide a name, role, and value for all fields. If any errors are found in a form, describe the error to the user.
- AA Level:
- Develop responsive views for both portrait and landscape so that content is accessible on any device’s orientation.
- Allow text to be resized up to 200% without any issues or additional tools.
- AAA Level:
- Ensure all content functionality is accessible through the keyboard.
- Allow users to stop any animations on the site if desired. Animations can not contain three flashes more than three times in a second.
- If a user is in an authenticated session and they lose their activity, the user should be able to log back in and continue their progress.
While developing, you can also test your progress with the use of in-development NPM packages and browser extensions. One of my favorites is A11y Checker. A11y Checker is an NPM package that can be built into development workflows. It shows you errors with your locally developed page’s accessibility live in the console window while you’re first developing your web pages locally. It’s a great checker to use before you push your code base live.
Testing Web Accessibility
Once a website is launched, there a quite a few awesome tools to check its accessibility rating in its live environment.
Google Lighthouse is a chrome extension (and a built-in chrome inspector dev tool) built by Google to test site performance, SEO, and most importantly, accessibility. The accessibility tab allows you to get a site accessibility rating of 1-100 that tests everything from color contrast, the usage of ARIA labels, and navigation tab indexing.
Wave is a chrome extension that reports accessibility issues and reports errors directly in the browser inspector window. This means that once your site is live, you can use it to asses your accessibility implementations, making it great for QA checks and progressive enhancements.
This is an alternative chrome extension built by Microsoft that checks against 50+ WCAG guidelines and promises full WCAG 2.0 AA compliance with all error check fixes. They also offer a 5-minute ‘Fast Pass’ check for developers for high priority checklist items. It also offers full exported reports of all errors, and even checks for tabbing errors, which most checkers often don’t offer.
If the above tools aren’t enough, the W3C’s WAI actually has listed dozens of tools that check compliance at all phases, as provided and recommended by the W3C themselves, so there’s more than enough accessibility checkers to go around, based on your project needs!
Resources to Keep Learning:
If you’re interested in more resources, here are some of my favorite talks, courses, articles, and resources on web accessibility I’ve encountered over the years:
The W3C’s Web Accessibility Guidelines:
- The quick reference guide to all W3C guidelines, organized by compliance levels A-AAA
- The full WCAG 2.1 guideline documentation
Favorite Web Accessibility Tools:
Favorite Web Accessibility Conference Talks:
- Helena Sue’s Web Accessibility 101 talk at DrupalCon New Orleans 2016
- Adobe Max 2020 accessibility talk by Cat Noone, CEO of Stark
Favorite Web Accessibility Courses:
Favorite Web Accessibility Articles:
- Pablo Stanley’s ‘Designing for accessibility is not that hard’ on UXPin
- Google’s Guide to designing for accessibility