This overview/guide takes 10 minutes to read.
WCAG stands for Web Content Accessibility Guidelines.
WAS stands for Web Accessibility Standards.
Both have the same fundamental components of accessibility.
WCAG is commonly referenced by courts and WAS is a simpler, easier to understand version of WCAG.
Here is the official WAS PDF.
WCAG is way too long to copy and paste but below is a simplified, plain English overview of WCAG:
1. Non-Text Media Alternatives
· Alt Text: Add alt text to all meaningful images on your website.
· Closed Captioning: All videos on your website must have closed captioning (thankfully YouTube videos can be edited to include CC).
· Text Transcripts: Insert a text transcript beneath all video-only and audio-only files.
· Audio descriptions: Insert audio descriptions into pauses of a video.
· No Images of Text: All text must be readable by a screen reader.
2. No or Limited Automatic Content
· Anything that activates on your website (such as an add, video, audio, pop-up, blinking ad, scrolling text, etc.) without being prompted by the user must be able to be paused, hidden, or stopped.
· Static Website Forms: Forms (sign ups, subscriptions, surveys, etc.) must be fully controllable by the user.
3. Keyboard Accessible
· You must be able to fully access your site without a mouse, by using only the arrow or tab buttons.
4. Intuitive Website
· Language and Title Tags: Set a language for your website and provide clear titles for each page.
· Skip to Content: Users must be able to a page’s primary content.
· Consistent Navigation and Flow: Your website’s structure and page set up needs to be predictable and logical (Facebook is the perfect example of consistency and predictability).
· Descriptive Links and Headers: Be obvious in linking to or setting up content so that users know what to expect. In other words, be very obvious in wording your headers, and anchor text/text surrounding your links.
· Labeled Elements: Programmatically label form fields and frames.
· Multiple Ways to Access Content: Provide multiple ways to navigate through your website. Examples: sitemap, search bar, related pages links, header menu, footer links, etc.
· Clear Forms: Make forms simple and easy to fill out.
· Clean Code: Your website must be coded properly and free of errors (e.g. 200, 300, 400, 500 error pages).
5. Font and Text Requirements
· Color Ratio: All font should contrast from its background color at a 4.5:1 minimum threshold.
· Scalable: Text should be able to be resized or zoomed in up to 200% without any loss of functionality.
The American Foundation for the Blind incorporates these elements into their site and optimally provides a way to change visual appearance at the top of each page.
6. Time Limitations
· There should be no time constraints on your website unless absolutely necessary.
The main differences between WAS and WCAG are:
- WCAG allows for automatic pop-ups, auto-playing videos and audio whereas WAS does not
- WCAG calls for extensive production for video alternatives whereas WAS does not.
- WAS is more binary, it’s easier to tell whether you meet a WAS requirement
- WAS is quicker, simpler, and easier to read and understand
W3C (creators of WCAG) organizes the above guidelines into four categories: perceivable, operable, understandable, and robust (POUR).
While that’s a nice acronym, the most important thing to remember when remediating or updating your website is that the functioning, elements, and content must be accessible to everyone including the visually impaired, hearing impaired, those with cognitive disabilities, and those with physical disabilities.
ADA website compliance and web accessibility are two terms that are used interchangeably but they are distinct from one another.
ADA stands for the Americans with Disabilities Act which prohibits discrimination on the basis of disability. Courts are construing Title III of the ADA to mean that websites must be accessible. Thus, with ADA website compliance, we’re referring to the law.
Web accessibility refers to making your digital offerings accessible (website, apps, documents, presentations, etc.).
WCAG 2.0 AA is a lengthy set of guidelines so the ADA checklist summary above won’t cover every last detail and exception, just the key, general takeaways.
One very important note is to remember that the WCAG guidelines for accessibility are NOT the law. WCAG 2.0 has been strongly referenced by the Department of Justice and courts in interpreting whether a website is accessible but it is NOT the law.
What this means is if you don’t meet every last success criterion it doesn’t necessarily mean your website is inaccessible.
Another note is that the new WCAG 2.1 guidelines (released in June 2018) build on the foundation that is 2.0; they extend upon the existing guidelines and success criterion.
2.1 is about enhancing and optimizing your accessibility. If your website only complies with 2.0, it doesn’t mean it’s inaccessible. Most companies are completely caught off guard by accounting for access to disabled – this is what’s being litigated across the US right now – so you’re by no means behind if you haven’t integrated all of the new updates.
I mentioned legal requirements above. While there aren’t technically requirements (yet), we do know about some of the highly recommended best practices by way of some consent decrees (basically settlements) entered into by the Department of Justice (DOJ) and private companies found to have inaccessible websites.
Quickly, here are the basics:
- Appoint a web accessibility coordinator
- Hire a qualified, independent consultant
- Conduct web accessibility training twice a year
- Adopt an accessibility policy page
- Invite and solicit feedback
For smaller businesses and organizations, the cost won’t make sense to have a web accessibility coordinator but for larger entities such as corporations, appointing one individual to see all digital accessibility is beneficial.
If you want to get technical, there is no black letter law that says websites must be ADA compliant. However, that’s not a debate you want to have in district court.
As an attorney, I always advocate what I call “legal prevention” which means that you avoid legal entanglement when at all possible. In this instance, we can reasonably argue on the merits as to whether your website needs to be ADA compliant (unless you’re a governmental entity under Section 508 of the Rehabilitation Act or a recipient of federal funding under 504 – accessibility is required here).
Section 508 is an amendment (1998) to the Rehabilitation Act that required government agencies to make electronic and information technology (AKA websites) accessible to those with disabilities. However, this was not a mandate for private companies.
508 followed the Americans with Disabilities Act (1990) which, in Title III of the act, the ADA requires that businesses, state and local governments and nonprofit services providers make accommodations for the disabled public to access the same services as patrons who are not disabled.
The ADA prohibits discrimination on the basis of disability and says that places of public accommodation (including private commercial enterprises) need to make accommodations for the disabled (42 U.S.C. § 12182). Importantly, a place of public accommodation, per 42 U.S.C. § 12181(7), amounts to a privately operated facility whose operations affect commerce. However, since the ADA came pre Internet era, the ADA didn’t contemplate or mention websites or apps.
In 2010, the DOJ issued an Advanced Notice of Proposed Rulemaking (ANPRM) called the Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities and Public Accommodations. An ANPRM is not law but a published notice in the Federal Register used by an agency to feel out its proposal and get feedback/comments before making it a rule; It’s a prudent move by federal agencies to try and get everything right before making a law.
The DOJ’s 2010 ANPRM made it clear that a rule for web accessibility was coming and asked whether WCAG 2.0 AA success criterion should be used or whether the existing 508 standards were best.
Although no formal rule was published, in March of 2014, the DOJ began entering consent decrees (basically settlements) with private companies using the WCAG 2.0 AA guidelines as standards for website accessibility. Click here to see the first consent decree against HR Block.
Piggybacking on these consent decrees, private law firms have been increasingly (and ever more aggressively) sending demand letters to corporations (e.g. Amazon, Target, Hershey’s, Bank of America, Bed Bath & Beyond, Hulu, Charles Schwab, Safeway, CNN, etc.) threatening lawsuit if demands weren’t met. Most companies choose to settle vs. a legal battle but some including Dominos Pizza and Winn Dixie have gone all the way to litigation.
In Robles v. Dominos Pizza LLC (Case No. 42 CV 16-06599 SJO (C.D. Cal. Mar. 20, 2017)), a federal court in California dismissed a class action lawsuit against Dominos, accepting the defandants due process defense. In a nutshell, the court found Dominos does have to make accessibility accommodations but because the plaintiff was trying to hold them to technical standards that weren’t promulgated by law, the case was dismissed.
In the landmark Carlos Gil v. Winn-Dixie Stores, Inc., Civil Action No. 16–23020 (S.D. Fla.) (first ADA website compliance case to go to trial), U.S. District Judge Robert Scola ruled against Winn-Dixie, finding that their website was indeed a place of public accommodation and that WCAG 2.0 guidelines were the de facto standard.
With US District Courts making incongruent decisions without actual law, the DOJ needed to step up and lay down formal regulations.
The Department of Justice was set to announce formal regulations for ADA website compliance in 2018 but those plans were scrapped when the Trump DOJ took over and nixed the Obama administration DOJ’s plans.
This is where the current legal situation lies.
Most corporate entities and companies are settling in non-public settlements. Plaintiff’s attorneys and law firms have swarmed like locusts in attacking the deepest pockets they can threaten.
I highly recommend small businesses, companies, corporations, organizations, etc. to take the proactive approach to web compliance and get started.
For further guidance in reducing exposure to lawsuit and becoming ADA compliant, The ADA Book (available at ADABook.com) is a tremendous resource (written by me).
How much does it cost to make your website accessible?
It depends based on the complexity of your website and who you hire to address accessibility.
Your cost might be as little as $500 for a simple blog or as much as $500,000+ for a major corporate website.
ADA website compliance is the legal side and accessibility is the technical/developmental side.
To be legally in the clear, you need to be ADA (Americans with Disabilities Act) compliant.
To be ADA compliant, you need to have an accessible website.
What are the prices for products/services?
You can hire an independent contractor on Freelancer or Upwork.
You can expect to pay $500 – $7,500+ depending on the website. To save money, you need to have detailed specifications of exactly what you need done and you must oversee the project.
You can hire a rock solid web developer for $15-20/hour. If they have WCAG 2.0 or accessibility knowledge, you’re going to pay more.
If you hire an agency that specializes in accessibility to retrofit your website, you’re looking at $5,000 – $50,000+.
The way you can save money with hiring an expert in accessible web development is to handle the manual remediation internally. Whether it’s you or your “web team”, if you can take care of all of your alt text and closed captioning, it’s going to save you money vs. having a developer or agency do it for you.
AudioEye automated software and manual remediation probably starts at $6,000 – $10,000 a year. That’s a recurring cost. And notice I said starts at. Price varies based on website. Trained live accessible phone, chat, and email support included.
Accessibe automated software starts at $490 annually. This is not a viable route for accessibility as the main component of their offering is installing a toolbar on your website which is redundant with what most screen readers offer.
For mid tier websites like small credit unions, banks, hotels, restaurants, etc. you can expect a bill of about $10,000 – $50,000+. Financial institutions can expect to pay more simply because of the security involved and the number of forms used. Restaurants are going to pay on the lower end.
Another cost tidbit: The more you’re able to interchange website elements at scale, the easier and cheaper it will be to make your website accessible.
For example, if you have a 1,000 page website and have the ability to swap out widgets or change links for hundreds of pages at a time, it’s going to save you some serious money. Think of it as being able to edit on a macro level, take a broad view, so to speak.
What about automated scanning tools?
Accessibility checkers are a nifty way of determining some of the ways your website is lacking. I recommend trying a few different scans to get a solid feel of where you need improvement.
WAVE is the most popular tool.
Tenon.io by Karl Groves is a premium automated checker but it’s a good one and cost effective.
I always advise not to pay for scanning services and reports from vendors. These can be extremely expensive (thousands of dollars) and not provide much more information than the free scans.
The “More Accessible” Trap
Look out for things (WordPress accessibility plugins, WP themes, services, etc.) that say they are “more accessible”.
WordPress themes (and themes for other CMS platforms like Drupal) commonly have the generic “more accessible” and “WCAG 2.0” tags attached to them but you have to be extremely careful about buying them because these are more aspirational claims than reality. Typically you’ll get a boost of accessible elements on your website but buying an accessible theme – premium or free – will not take care of everything for you.
This about the phrase “more accessible” – what does that even mean?
It can mean anything.
It can mean one accessibility component is addressed or many have – we don’t know.
When researching products or services, you need to find outexactly what they do and what criteria they make your website meet.
When it comes to accessibility, demand specificity. Almost every vendor will say they meet WCAG 2.0 but you need to find out exactly how they do and do not. And it’s okay that they don’t. Virtually zero vendors can cross off every bullet point, but you need to be thorough so you know exactly where you’re deficient so you can shore that up.
For example, WIX and Square Space (online website creation software) hedge on whether their websites are accessible.
Here’s another example I personally experienced:
I was specifically searching for an accessible live chat plugin for ADABook.com and I stumbled upon Olark.com. Olark claims accessibility with a specific page but then backtracks with very tepid language:
“We aim to adhere to the WCAG 2.0 accessibility guidelines for the code that our customers install on their websites. Our code is written so that the chatbox is navigable by keyboard using screen reader software.”
That’s nice but keyboard navigability is just one bullet point. Before I install a third party plugin or widget, I want to know, are you completely accessible or are you not. I contacted their support via email and live chat. Here is my email and Olark’s reply:
Having fully accessible live chat is critical for me. I choose [sic] Olark live chat because Olark is one of the few who specifically embraces accessibility but after installing the Olark plugin today and reading through the policy found here:
I wanted to learn more about how Olark chat is accessible beyond keyboard navigation. Can you tell me specifically what WCAG 2.0 success criterion Olark has satisfied?
Unfortunately, I don’t have that documentation to share. I can tell you that we’ve implemented the chatbox in a way that it’s accessible to a screen reader and we’ve enabled a high-contrast mode for the agent console, so far. Accessibility is important to us, but it will be something we’re continually working on.
Are there any specific features you’d like us to put in requests for? I’d be happy to get those requests in for you!
By the way, this is not to take points off for Olark because they were the ONLY live chat plugin I saw that even talked about accessibility. Chances are 80% of live chat plugins haven’t even thought of accessibility.
Hire a Web Accessibility Consultant
What solution is right for your needs and your budget?
How can I have someone look over my deal with a vendor and make sure it’ll make me ADA compliant?
What is the best all-in-one solution?
Where exactly do I start with accessibility?
First, I highly recommend you pick up The ADA Book. It’s written by me and takes you through a step-by-step blueprint of how to prevent a demand letter or lawsuit while you become accessible.
Second, if you need help with your project, you can hire me as a web accessibility consultant.
Beyond the optics of hiring an independent consultant (the DOJ actually stipulates in multiple settlement agreements that companies hire a consultant as part of the settlement so it looks good to have on record that you hired one), there are several practical benefits. A consultant can:
- Perform a manual audit on your website
- Create a web accessibility plan
- Help you deal with vendors, evaluate products and services
- Educate your company on how to be accessible
- Relay status and next steps to executives, your coordinator
- Convey what needs to be done to web developers
- Institute a training program for your coordinator, web accessibility team
- Alert you of changes in accessibility, new best practices
- Answer your questions
- Conduct annual audits
My name is Kris Rivenburgh. If you have a question, you are welcome to email me at firstname.lastname@example.org. You can find out how to reduce your chances of receiving an ADA Website Compliance lawsuit at ADABook.com.