Confused by web accessibility? Don’t know where to start? Below is our Web Accessibility 101 guide. This should help you with the tools and high-level explanations of what to look for to make your site accessible online. We also have another post about the specific definitions and acronyms used in web accessibility.
What do we mean by Web Accessibility?
At the highest level, web accessibility means that all the information and functionality on your website is accessible to any person, regardless of their individual needs and challenges. Sites that are well-designed and developed make it possible for everyone to be included in the exchange of information online.
What is “Section 508,” and why does it matter to me?
When people talk about “Section 508,” they are referring to Section 508 of the Rehabilitation Act of 1973. It’s a mouthful, so we tend to shorten it. It’s the section of this Act that focuses on US requirements for making government electronic systems usable and accessible for people with disabilities. All federal government institutions are required to be compliant with Section 508.
In practice, though, many people use “Section 508” as a catchphrase to refer to anything related to compliance with the Americans with Disabilities Act (ADA). Section III of this Act protects the rights of users with disabilities with regards to websites and digital media. These rules apply to broader state and local government, businesses, and non-profits. Legally, disabled users have a right to access any service online that is accessible to the able-bodied public. Just like the requirement that businesses have ADA-compliant physical locations, a website has to be compliant as well.
Section 508 (and the related Section 255 of the Communications Act of 1934) has received much-needed refresh as of January 18, 2017 (as of May 2025, this is still the most recent update). You can read all about the changes on the Access Board website. As a part of the refresh, they have fully incorporated the WCAG 2.0 A and AA guidelines as a basis for the revised standards.
In 2024, WCAG 2.1 was released. All websites that Kanopi currently audits adhere to WCAG 2.1.
Wait, what? What’s WCAG?
The W3C’s Web Content Accessibility Guidelines, or WCAG, is the most fundamental set of accessibility recommendations for the web. The difference is that these guidelines are only that — a recommendation — and not historically a mandate. But with the refresh, they are the most straightforward answer to how to get your website up to ADA and Section 508 compliance.
The WCAG group accessibility features into three levels of compliance. In order of least to most accessible are A, AA, and AAA. At Kanopi, we focus on meeting level AA compliance with the most recent release of WCAG standards for our clients; that’s a safe benchmark for universities and progressive organizations who are focused on comprehensively supporting their users. And now, as of the beginning of the year, it’s the mandate for governmental compliance.
Do I really have that many users who need this kind of support? Why is it important?
When we think about users with special needs and disabilities, it’s easy to focus on the most extreme cases, and feel like these users are such a small percentage of the population that the likelihood that they will visit your website is likewise small. But according to the CDC, 22% of the population in the US have a disability today. Any of us may experience a disability in our lifetime. The reality is that many able users or users with situational disabilities also benefit from a well-constructed, accessible site. Keyboard warriors. People with tired eyes and screen fatigue. People using a device one-handed. Search engines. Users with lousy bandwidth. Maximizing your site’s accessibility maximizes the reach of your message. And with all the noise on the internet, that’s a great thing.
How challenging are these kinds of things to fix?
Kanopi recently undertook the challenge of performing accessibility audits on several of our support client sites. One of the sites we tested was Colorado Health Foundation, a statewide philanthropic organization dedicated to improving the health and well-being of all Coloradans. While accessibility wasn’t the only focus of our work together, it was critical that the site be accessible for all Coloradans.
The previous site was inaccessible for keyboard users. Upgrading the site architecture to a more recent version of Drupal was an important step, allowing us to improve tab navigation and heading structure.
Many of the enhancements our support team implemented are invisible to sighted users. The biggest visual challenge we faced was adjusting the color palette of the website to still adhere to the brand guidelines for look and feel, but to support a high enough contrast ratio to be usable to people with vision impairments. Our designers presented some subtle alternatives that still adhered closely to the active site experience, and we worked directly with the client to get to an adjusted palette that worked for both the brand image and the site’s audience.
So what was our first step to get this to a more compliant state? There are numerous tools available to run automated checks on a site to see where the gaps are in your accessibility accommodation, and this is the approach we took to our initial testing. Every audit we ran turned up something different. And even after resolving those issues, no automated tool is a replacement for extensive human review on any voice browser, text browser, keyboard, or other alternative browsing platform you can get your hands on. There are challenges that an automated review simply won’t find. In a review of a number of automated testing tools, Gov.uk found that these options only picked up an average of 71% of the accessibility problems on a given page.
As a result of these efforts, the site is more broadly accessible, more easily navigable, and ensures that every user has greater access to healthcare needs. The updated site now scores 95/100 on Lighthouse, with improved fonts, tab navigation, and meaningful links.
What about external code that I use on my site that comes from other vendors, like analytics platforms or social media?
You’d be surprised, and probably shocked, how many vendors out there choose not to make their products accessible. Or they are simply not aware of the barriers they create for end users on their partners’ sites. Kanopi is not only a seasoned development agency, but we do a lot of deep user experience work for our clients as well. Before you build something, you need to be sure it’s the right something, and that it meets the needs and goals of your target audience. As a part of our user experience research, we’ll frequently opt to send out a simple questionnaire. It can be as basic as just a popup that says “What are you looking for today?” and that alone will yield a wealth of insights into what users really need from your web presence.
There are a number of tools we use for these types of surveys. In working with the San Francisco Public Library (SFPL), we wanted to prompt users to fill out a few questions about their reasons for visiting the site and their experiences while there. We also needed to have support for multiple languages for survey respondents. So we used one of our standard set of tools that fit the criteria for the questionnaire.
The SFPL has a deep commitment to accessibility and making information available to everyone. It turns out that the popup tool we were using made the site unusable for anyone who was using alternative or assistive navigation and tools. There was no way for these users to opt out of the survey or get past it.
As soon as we received feedback from our clients on behalf of these users, we pivoted. We adjusted our questions to use SurveyMonkey and Google Forms, which are both fully compliant and accessible options. When we went to our initial survey vendor with our concerns and to advocate for a more accessible tool, we were met with a brick wall. Accessibility wasn’t a priority for them, and it wasn’t an item that they had on their roadmap. It was disheartening. But now we have greater insight into the weaknesses of the platform. We have found the right tools to use to ensure we reach as many of our clients users as possible. And the decision whether or not to keep disabled users in mind will have an ultimate effect on the bottom line for all parties involved.
What kinds of tools can I use to assess the compliance of my website?
Ultimately, these issues are much easier to build in during the initial site development process than they are to fix after launch. That’s why working with a skilled and knowledgeable team is so important if you’re looking at redesigning and rebuilding your site. The good news though is that there is a wealth of tools out there for supporting anyone beginning their journey to creating a more accessible online experience.
One very simple check you can do is to just turn off CSS on your site and see how the content flows and how readable and structured it is. If you want to go deep into testing your site, we have a comprehensive list here of all the ways you can test your site for accessibility compliance. But below is a list of a few options for you to check out if you’d like to see how your site currently performs for disabled users.
Screen Readers
Checklists
- Vox Product Accessibility Guidelines
- A11y Project Web Accessibility Checklist
- Web Accessibility Evaluation Tools List
- WebAIM: WebAIM’s WCAG 2.0 Checklist – for HTML documents
