508c vs WCAG - Comparing Web Accessibility Laws, Guidelines, & Standards
Creating a website that is accessible to users can be frustrating. Confusing legalese, varying terms, and competing guidelines make it difficult to identify what your website should be aiming for. Certain requirements within accessibility might also appear to be unobtainable or overkill resulting in site managers abandoning accessibility efforts entirely. The following post will outline the differences between the primary guidelines in existence, namely 508c and WCAG, and clear up misconceptions about them. The post will also look at how you can go about ensuring that your website achieves a happy medium between accessible and maintainable.
508c is an addendum to the Rehabilitation Act, which prevents discrimination in government run and funded programs against those with disabilities. 508c dictates how all forms of information technology must conform so that they can be used by disabled individuals. 508c also governs items like fax machines and government software in addition to websites. While many of the 508 compliance items that are intended to make your website accessible are intuitive, a number of them are less obvious such as having your site be navigable by keyboard for those that lack the muscle control to use a mouse, or not having videos or imagery that can trigger seizures.
One often overlooked requirement of 508c is that the back-end of your site must be created to the same level of accessibility as your front-end. A few of the lawsuits involving non-compliance with 508c have not come from site users but from site administrators or content authors who discovered, once hired, that they could not do their jobs. It is also often mistakenly assumed that 508 has various levels of compliance. However, it's a boolean - you either hit it or you don't. The confusion here stems from another set of guidelines - the Web Consortium Accessibility Guidelines (WCAG), which do have varying compliance levels and can often be more helpful when making your solution accessible.
508c tends to have a few other problems with using it as your primary set of guidelines. The law is concise (less then a page) but vague, mostly so that it can continue to apply for years. The government-defined standards, which help to further clarify the law and are legally enforceable, are more concrete but still written in what is generally hard to interpret language that does not lend itself to testing. 508c as a concept and as a law is written so as to be enforceable for government contracts and programs but it's not an easy to follow set of guidelines to make your website accessible.
The WCAG (or rather WCAG 2.0 as it is on its second iteration) is a more in-depth set of guidelines surrounding accessibility that have been defined by the World Wide Web Consortium (WC3), also known as the organization that brought you HTML5 and CSS3. The WCAG guidelines are more usable than the 508c standards as they encompass just the web, and are written specifically to be testable and have an audience entirely of site developers, administrators, and content creators (as opposed to legislators and lawyers). The WCAG is also more frequently updated to reflect current technologies. 508c is celebrating its 18th anniversary and continues to reference web technologies that haven't been used since Geocitie's peak, a problem that generally doesn't exist within WCAG as the group creating it also creates and defines HTML standards and practices.
Another key difference is that WCAG has varying levels of conformance from A (lowest) to AAA (highest). To meet these levels a website must conform to all testable statements for that particular level and all levels below it. These statements can easily be found on the WCAG webpage which has handy filters to allow you to easily see the standards that must be met at a particular level. The WCAG also includes an in-depth guide on how to meet these various standards as well as approaches that will cause failure. From our experience, most pages that are, at minimum, WCAG AA compliant will also meet 508 compliance. However, they should always be double checked against the written standards of each set of guidelines.
Which Guidelines Should I Be Following?
If you are part of an organization receiving varying types of government funding, you will be required by law to be 508 compliant. This means that your solution's front and back-end must meet the guidelines, you will have to fill out a Voluntary Product Accessibility Template (VPAT), and will most likely have to undergo testing to ensure that you conform, including having your legal department look over your site. As 508c is a specific law, enforcement of these guidelines is taken seriously. If your company is not legally required to meet 508 compliance, then you should not attempt to claim conformance as it can open your site up to lawsuits and other issues.
If you are required to follow 508c, you can still use the WCAG for help with testing and future proofing. The 508c guidelines are being updated, though when exactly this update will take place is unknown. The good news is you can easily future proof your site and avoid any rework down the line by following WCAG AA guidelines, as these are what the new 508c guidelines will be based on.
Ideally, all websites should aim to meet at least the A level of WCAG as it's likely that a portion of your site visitors might have a disability. My own interest in this topic comes from working closely with three different color blind co-workers in a company of about 150 people. Not surprising as it affects one in twelve men. By meeting WCAG A level, at a minimum, you will open up your site to many more users while also adhering to web best practices.
Many companies when choosing to become compliant will make the mistake of trying to make their entire site AAA level compliant. However, this is actually not recommended by the WC3 as certain types of content are, by their nature, unable to meet that level of conformance. For example, guideline 3.1.5 Reading Level, which requires content to be written at the lower secondary education level - impossible or impractical to achieve for certain sites. Or guideline 2.1.3 Keyboard (No Exception), which requires that the entire site must be keyboard navigable - a difficult task for certain types of interactive content like games or data visualizations. Reaching AAA may also be beyond the financial constraints of some organizations such as requiring sign language translators to be included in all pre-recorded video.
A smarter solution is having the entirety of the site be level A with specific pages being AA and AAA, where achievable. Also note that the WCAG guidelines allow for a page to reach partial conformance, especially in areas where 3rd party content on the site can not be guaranteed. For example, if your site publishes an RSS feed, noting that content contained within the feed may not conform to level-specific guidelines will allow the rest of your page to conform.
In conclusion, accessibility should be a goal that every website strives for, not only to be good global web citizen but also to allow products, messages, and content to reach a wider range of users. By having accessible web content you gain a leg up over competitors that may not be striving for the same standard, while also creating a well structured semantic site that follows today's best practices.