Web Accessibility

Summary of ADA Web Compliance

The Information & Communication Technology (ICT) Standards & Guidelines / “Final Rule” placed a deadline for web compliance to be met by January 18, 2018 (Federal Register). The following will address who the deadlines applies to and how to achieve web compliance.

Section 508

Section 508 of the Rehabilitation Act of 1973 “establishes requirements for electronic and information technology developed, maintained, procured, or used by the Federal government. Section 508 requires Federal electronic and information technology to be accessible to people with disabilities, including employees and members of the public.” [A Guide to Disability Rights Laws (July 2009). https://www.ada.gov/cguide.htm]

As technology advanced over time the Americans with Disabilities Acts of 1990 (ADA) was created to help further ensure users with disabilities had protections against discrimination and reasonable accommodations to public resources.

ADA compliance is not specific to websites or technology, but is rather a general set of rules to reduce discrimination against those with mental and physical disabilities. As the internet quickly evolved so to was there a need to create more specific standards to how it was accessible for those with disabilities. In other words, what Section 508 generally covered needed more specific requirements.

The “Final Rule” was published on January 18, 2017 and required compliance to Section 508 by January 18, 2018.

Section 504

Section 504 and Section 508 share the same goal of eliminating discrimination based on disabilities. Section 504 more broadly places requirements on “programs and activities” that are Federally Funded, whereas Section 508 is more specific to Federal “electronic and information technology.” For more information I recommend visiting the U.S. Department of Health & Human Services (HHS) page here: https://www.hhs.gov/civil-rights/for-individuals/disability/index.html

“Even when Section 508 doesn’t apply, many non-federal websites are still required to be accessible under other laws, such as Section 504 of the Rehabilitation Act of 1973, or state or local laws.” [Do Section 508 Accessibility Standards Apply to My Website (December 12, 2017)]

Web Content Accessibility Guidelines (WCAG)

The Web Content Accessibility Guidelines (WCAG) was published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C).

WCAG can be thought of as an effort or a guide to follow in efforts to help ensure Section 508 compliance requirements are being fulfilled (in many cases it goes beyond what is needed). For reference, here is a Comparison Table of Section 508 to WCAG 2.0). It’s specifically focused on hardware, software, websites and multimedia (i.e. videos, PDF files, etc.).

There are currently two primary versions of WCAG that are used when considering web accessibility:

• WCAG 2.0 (published December 11, 2008)
• WCAG 2.1 (published June 5, 2018)

“WCAG 2.0 and WCAG 2.1 are both existing standards. WCAG 2.1 does not deprecate or supersede WCAG 2.0. W3C encourages you to use the most recent version of WCAG when developing or updating content or accessibility policies”. [https://www.w3.org/WAI/standards-guidelines/wcag/]

If your website does business in other countries it is also worth mentioning that WCAG 2.0 is approved as an International Organization for Standardization (ISO). [https://www.w3.org/WAI/standards-guidelines/wcag/faq/#iso]

Levels of Compliance (A, AA, AAA)

There are 3 levels of compliance: A, AA, AAA.

Currently, meeting WCAG 2.0 A and AA standards satisfy the requirements of Section 508. It is still recommended to follow WCAG 2.1 (simply because it’s the latest version) and it is also recommended to follow any AAA requirements that are not too burdensome (some may be adopted as requirements in the future).

California’s State Regulations

State requirements can create new standards or increase the level of requirements from what would otherwise be only a recommendation.

As an example, the California Department of Education (CDE) lists their requirements and exceptions, though they are largely based on the existing standards. “There are three interrelated [California] government code sections that inform state policy on digital accessibility.” [CA State Digital Accessibility Laws, https://www.dor.ca.gov/Home/Laws]

1. California Government Code Section 11546.7 (from AB 434)
2. California Government Code Section 7405
3. California Government Code Section 11135

In summary, Section 11546.7 establishes that the Chief Information Office (CIO) will issue a certification on the home page of each state agency/entity (as specified). The certification is based on the page meeting Section 7405 (compliance to Section 508) and Section 11135 (prohibits discrimination).

The Recommendation

If you are a government agency or a government funded program the most recommended approach is to seek compliance to WCAG 2.1 A an AA standards as a minimum to satisfy Section 508. These standards are specific to technology.

If you do not fit into either of those categories you may still want to consider compliance.

“Section 508 may not apply to your website, but other laws likely do, so your website should be accessible. Most accessibility standards are moving toward WCAG 2.0 standards to best meet the needs of people with disabilities. Whether or not federal regulation apply to your website, designing for all users is a best practice, and will help your organization more effectively meet the needs of all your customers.” [Do Section 508 Accessibility Standards Apply to My Website, The Bottom Line (December 12, 2017)]

Achieving Compliance

As previously discussed, WCAG 2.0 and 2.1 already meet and/or exceeds Section 508 requirements. Compliance to those requirements will be our focus moving forward. A and AA are the only levels that are necessary for compliance currently, though we will still consider some AAA requirements.

Requirements Overview

The guidelines and success criteria require web content to be Perceivable, Operable, Understandable and Robust (POUR). The W3 offers a Quick Reference guide that organizes the requirements into the POUR categories. The guidelines provide examples and links to help provide developers details, which are organized into three types: satisfy, advisory, and fail.

WAI-ARIA

The Web Accessibility Initiative (WAI), through the general guidance of the W3C, seeks to establish standards for Accessible Rich Internet Applications (ARIA). This is often referred to as WAI-ARIA. “Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities.” This is primarily done for screen readers, though could be carried over as more technologies adapt these standards.

In application, the process includes assigned established “roles” for html elements. Some elements have predefined roles through html5, such as the <header> and <footer> for example. For more information on how WAI-ARIA plays a role in html see the W3C’s WAI-ARIA-1.1 article on ARIA in HTML.

Methodology

The Web Accessibility Conformance Methodology (WCAG-EM) 1.0 “provides guidance on evaluating how well websites conform to the WCAG 2.0”. It’s important to note that “This methodology does not in any way add to or change the requirements defined by the normative WCAG 2.0 standard…”, which leaves the methodology as a recommendation, but not a requirement for achieving compliance.

Compliance Claims

The W3 states clearly in the WCAG 2.0 Guidelines that “Conformance claims are not required,” though there are details that must be provided if a claim is made. One of those details is important to point out, which is the claim’s date. The date is significant because the site could be edited after the claim was issued and result in a compliance issue.

Ongoing Compliance

If your website continues to be edited after it is made compliant there is a good chance that an accessibility issue will arise. It could be as simple as forgetting to place alternate text on an image, though there’s certainly plenty more ways that it could happen.

Compliancy’s aim is to mitigate risk (failing to meet Section 508) and to provide the most amount of users with the best possible experience. There are often many Search Engine Optimization (SEO) benefits related to the guidelines and many changes are often very simple to make.

Compliance Auditing

There are great tools online that assist in auditing a website for a significant amount of the guidelines’ requirements. As useful as they are it’s important to point out that they do not catch all compliance issues and it’s recommended that manual inspections be conducted as well. There are also many tools and software that are used by the disabled, which are important to use when auditing.

Auditing Tools

I’m very certain this list could be added to and that many other accessibility professionals have other preferred tools. Though this list is small, these are tools are generally well respected.

• WAVE Web Accessibility Evaluation Tool (A Visual Auditing Tool)
• WebAim (Section 508 and WCAG 2 Checklists, they also offer a Color Contrast Tool)
• ACCHeck (Auditing Report Tool)
• Tenon (Auditing Report Tool – very comprehensive)

Although it is not required to audit a site using every tool that is used by those who have disabilities, it is still regarded a best practiced to use one or more so that a simulated experience is conducted. Screen readers are one of the more common tools (used primarily by those with visual disabilities) and include VoiceOver, NV Access (NVDA), JAWS. There are many more screen readers available, but those are among the most commonly used.

Comprehensive Reporting

If you do decide to follow the WCAG-EM methodology for Reporting you can use their WCAG-EM Report Tool. My personal goal when creating an audit is to build it with the developers in mind. Anything that can better assist the development team find and understand the accessibility issue is usually both appreciated and can help ensure the right issue is fixed.