Interviewee: “I have 508 and ADA experience.”
Interviewer: “What is 508 and ADA and how did you implement it?”
Interviewee: “They are standards used to make websites accessible, and we used ARIA tags.”
The answer is basically correct, but on a base level. Although started as a U.S. Federal Government requirement for related government websites, accessibility is now widely accepted as an internet-wide requirement across a wide swath of websites in many industries. Section 508 does not stand alone; there are two equally strong cousins: Web Content Accessibility Guidelines (WCAG) and Americans with Disabilities Act (ADA). Many people use 508, ADA, and WCAG interchangeably as if the same; however, this is not accurate. There are subtle and not so subtle differences between them, causing a lot of confusion in discussion and description. Below is a high-level synopsis of each and the differences and similarities between them all.
Section 508 was initiated in 1986 as an amendment to the Rehabilitation Act of 1973. However, after a lack of support and enforcement, it was rewritten in 1998. As stated above, 508 is a U.S. Federal Government mandate that affects all Federal websites and private websites that are under contract with a federal organization and/or receive federal funding. This has since trickled down to the state, county, and city level.
Examples of 508 (on a website level):
• Assistive technology like Braille readers and screen readers (ex. JAWS),
• Closed-captions for audio/video and multi-media files,
• Text description of visual elements when applicable (ex. Adding a text description to a photo of the building),
• Ensuring the website is keyboard accessible when needed (ex. Page elements can be accessed via the keyboard Tab key and the page structure is logical and in order of layout in the DOM – Document Object Model),
Americans with Disabilities Act of 1990 (ADA)
Although it was officially made effective in 1990, the bill was actually introduced in 1988. It was created as a civil rights bill to end discrimination and provide fair and equal rights to those with disabilities in many areas of life, including employment. ADA started in the physical world for employment, public services, telecommunications etc. Although “cyberspace” was not seen initially as a “public place” (Access Now, Inc. v. Southwest Airlines Co., ca. 2002, ruled that the airline website was not a “place of public accommodation”), this view began to change in the late 2000s. In the past twelve years, both Target and Nike among others have been successfully sued for ADA website violations.
Web Content Accessibility Guidelines (WCAG)
Unlike Section 508 which is U.S. based, WCAG is a global standard and is a higher level than 508. Published in 2008, it was incorporated into use by the W3C (World Wide Web Consortium) in 2018. WCAG are guidelines and recommendations used to make websites, including websites of international governments, for both desktop and mobile devices more accessible mainly for individuals with disabilities. WCAG 2 includes four principles: perceivable, operable, understandable, and robust. Each of these has testable success criteria, which are organized by three levels (A, AA, AAA). With ‘A’ being the minimum level of conformance, ‘AA’ satisfying all Level A and Level AA, and Level ‘AAA’ satisfying all of A, AA and AAA, although AAA is not mandatory site-wide (since some features cannot be AAA). As of 2017, Section 508 has adopted 17 of the WCAG 2’s success criteria.
The way I see it is—508 and WCAG are U.S. and international accessibility guidelines primarily for cyberspace and technology, while ADA is to allow those with disabilities to have access to the same everyday services and employment as the general public.
Voice Controls (current and future Accessibility)
Although it has been around a while and fast growing, voice control is still in its infancy. Many of us are familiar with the Amazon Echo (Alexa), Hey Google (Google Home) and Apple’s Siri and use these technologies in our daily lives. In late 2018, Adobe added Voice Prototyping to their free application, Adobe XD, which allows design and prototyping that is navigable by voice commands. Although not yet fully possible for standard websites, voice commands are popular for Native Apps like Siri and standalone devices to perform everyday task. In 2012, the W3C introduced a Web Speech API specification to allow and develop speech recognition in browsers. As of today, that spec is still a working draft and not natively supported in any browser (although Chrome and Firefox have speech ‘add-ons’). Chrome is ahead of the game by using its own speech recognition engines. It is only a matter of time before Voice becomes native to all browsers, offering a huge breakthrough in the disabled community by making it easier to navigate, search, email, and more. This new technology will add more work and time for development, including planning, testing & QA, and UI/UX, development, and requiring greater knowledge across all project team members. Preparing for the future is never easy, but the future waits for no one, so it’s best to be prepared!
Tune in again as we plan to continue to delve into more informative blogs on accessibility in the near future on the Artemis Blog.