Achieving website accessibility can sometimes feel like you are trying to hit a moving target. New guidelines are consistently being established and there is no single industry standard for measuring accessibility. In addition, unless you are a federal agency or someone who receives federal funding, it is up to you to define your accessibility benchmarks.
The reality is that as we continue to learn more about how people use the web, the rules will keep to changing. However, there are several widely accepted definitions, organizations, best practices, and guidelines that you should know about to help you—or your organization—create standards for your work.
The World Wide Web Consortium (W3C) and the Web Accessibility Initiative (WAI) are the world’s leading authorities on web accessibility standards.
W3C is an international collective of organizations and individuals who are working to develop general web standards. One of the W3C’s initiatives is WAI or the Web Accessibility Initiative. WAI consists of stakeholders and working groups who are specifically pursuing accessibility across the web.
The W3C defines web accessibility as websites, tools, and technologies that are designed and developed so people with disabilities can perceive, understand, navigate, and contribute to the Web. W3C and WAI have produced a number of guidelines and technical specifications to help anyone create more accessible websites, applications, and content. The most used and referenced document is the Web Content Accessibility Guidelines (WCAG).
The Web Content Accessibility Guidelines are a set of are stable, referenceable, technical standards that explain how to make web content more accessible. The guidelines are organized around the four principles of accessibility. These say that if content is not perceivable, operable, understandable, and robust, users with disabilities will not be able to use the Web. In addition, each guideline has one or more technology neutral and testable success criteria, along with recommendations for how to meet those criteria.
If you have looked at the WCAG recently, you will notice that there are currently two versions: 2.0 and 2.1. WCAG 2.0 was published in 2008 and WCAG 2.1 was published in 2018. Essentially, 2.1 is 2.0 plus 17 additional success criteria. These criteria were added to address mobile accessibility, people with low vision, and people with cognitive or developmental disabilities.
Both versions of WCAG are acceptable, but W3C always encourages people to use the latest version.
Each criteria within WCAG is assigned a level of conformance, either A, AA, or AAA. Level A criteria are the easiest and most critical to meet. Most of the time, if the Level A criteria are not met, content will not be accessible—even with assistive technology. Level AA is achieved when all Level A and Level AA criteria are met. These are a little more difficult to meet and often have design, development, and content implications. Level AAA is the most stringent level of conformance. At this level, your site must meet almost all the criteria outlined in WCAG. Most websites will not meet AAA conformance. Design options are also significantly more limited when accommodating Level AAA. These restrictions should be acknowledged early in your design process to avoid wasted efforts or awkward adjustments.
Another thing to remember is that there is no such thing as partial conformance. If you meet all the Level A criteria, but only some of the Level AA criteria, your site is Level A conformant.
This does not mean that if you cannot meet all the AA or AAA criteria, you should not try to meet at least some of them. A site that meets any of the criteria is more accessible than a site that meets none.
In general, the recommendation is to aim for WCAG 2.1 AA conformance.
A Voluntary Product Accessibility Template (VPAT) is a way of documenting how your technology conforms to the revised Section 508 requirements, the European Union’s accessibility requirements, or WCAG 2.1. It is commonly produced by government contractors during the procurement process. However, VPAT can be used by anyone as a formal way to document the criteria your product meets and how.
Besides the moral, social, and business reasons for making accessible sites, there are several legal requirements that could apply to an organization.
Section 508 refers to an amendment to the Rehabilitation Act of 1973 that requires federal agencies to make their electronic and information technology accessible to people with disabilities. This means that when any federal agency develops, procures, maintains, or uses electronic and information technology it must “give disabled employees and members of the public access to information comparable to the access available to others.”
In 2018, a refresh of Section 255 of the Communications Act and Section 508 went into effect. This update helped to align the two sections with other accessibility guidelines and standards, namely the Web Content Accessibility Guidelines 2.0 Level AA.
Unless you are a federal agency, Section 508 does not apply to you. However, this does not mean you are not legally required to have an accessible website. Section 504 of the Rehabilitation Act of 1973 "prohibits discrimination based on disability by federal agencies and recipients of federal assistance.” This means that if you are an entity that receives federal funding such as a federal-funded non-profit, public higher education institution, or public K-12 school, your website must be accessible.
The Americans with Disabilities Act (ADA) is a piece of legislation that “prohibits discrimination and guarantees that people with disabilities have the same opportunities as everyone else to participate in the mainstream of American life.” Under Title III of the ADA any entity considered a “place of public accommodation” is required to provide equal access to people with disabilities. While this does not explicitly apply to websites, some courts have ruled that websites of businesses can be considered public accommodations and are thus subject to provide reasonable accommodations.
This has made the Web’s relationship with the ADA very tricky. Currently, no technical standards for accessibility have been stated or adopted for Title III of the ADA, so there is no real way to have an ADA compliant website. In addition, the definition of “public accommodation” is so murky that when the ADA is cited in a lawsuit it is up to the discretion of the individual court to decide if the requirements apply.
To make things more complicated, Title II of the ADA requires state and local government websites meet specific accessibility standards.
It is also important to know that regulations requiring federal website to meet WCAG 2.0 AA standards were supposed to go into effect on January 2018. However, this did not happen. With the ADA’s application to the Web is likely to remain vague, the Department of Justice (DOJ), many courts, and accessibility professionals have suggested using WCAG 2.0 AA as the benchmark to avoid possible lawsuits.
If you or your organization is contractually obligated to produce an accessible website or if you have an internal goal for making something accessible, you need to define what constitutes accessible. Is it passing a specific automated test with a minimum score? Is it completing a VPAT to prove a certain level of conformance? How do you handle third-party content or features? No matter what the standards are, everyone needs to be on the same page. Developing an accessibility policy is great place to start.
Although there are criteria to meet and a way to document what you are doing, there is no industry standard to test if you are meeting the criteria or if your product is usable. There are a number of reputable automated testing products that can test most of the criteria, but they cannot test all of them. In addition, automated tests can produce false positives and flag you for things that are technically passing.
In no way does this mean you should not use an automated test. These tests are extremely helpful at pointing out why you might be failing to meet certain criteria and can also give you options for how to fix the error. However, this means that you should also always have a manual tester. Having someone attempt to use the product as someone with a disability or someone who uses an assistive technology can produce some of the most helpful improvements. It is key to remember that accessibility is ultimately not about a score on a scan, but about how well people can perceive, understand, navigate, and contribute to your site and the Web.
No matter what standards you adhere to, it comes down to showing a good-faith effort to being as accessible as possible. The easiest way to do this is to have a publicly visible accessibility statement. These allow you to explain your stance on accessibility, show examples of how you are working towards better accessibility, and to provide contact information or next steps if anyone encounters an issue.
When considering creating accessible websites, many organizations – and rightfully so – will ask about the potential impact upon project budgets. To avoid costly changes, the recommendation is to start building accessibility best-practices into your organization’s design, development, and content teams so that accessibility is a core piece of all projects from beginning to end.
Another suggestion is to explore if your organization can accommodate assigning one person as the accessibility lead. This would allow you to have a dedicated person to take the lead on researching trends in accessible design and development and to answer any questions for other team members.
This introduction does not cover all the nuances of web accessibility. Nothing will substitute for reading the actual documentation and making sure that you are keeping up with any revisions.