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. 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.
Wait, what? What’s WCAG 2.0?
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 WCAG 2.0 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. We wanted to test ourselves: could we retrofit an existing site to be WCAG 2.0 AA compliant? One of the sites we tested was CRDFGlobal.org, an independent nonprofit organization that promotes international scientific and technical collaboration through grants, technical resources, training, and services. We had done the initial build of the site, but accessibility hadn’t been a focus at the time. Now we wanted to layer a deeper level of it in.
The base HTML we’d build was very solid and well structured, and semantically architected to support both content accessibility and SEO. So those fundamentals were already in place. So were basic best practices like skip links, active/focus states and alt text for site imagery.
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.
Ultimately we found two automated tools to be the most helpful.
- Tenon.io – this site has an API available, but we just used their web-based tool to run our audits. The visual results are clean and easy for developers to digest, and the export let us quickly create meaningful tickets in our project management system so we could integrate these changes into the support workflow. And overall, this found the most issues with our site.
- aXe JavaScript API – this API has a Chrome Plugin available that we found yielded solid initial results without a lot of false positives we were seeing with other auditing tools.
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.
As a result of these efforts, the site is more broadly accessible, more easily navigable, and ensures that every researcher has greater access to funding opportunities that enable them to collaborate with their international peers as they work towards solutions to our most pressing global scientific challenges.
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, 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. As for going deeper… here are just 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
