The 508-compliance process is very important, but for a long time, the job of making documents 508-compliant was perceived as onerous, labor-intensive, and imperfect. However, recent developments have improved and eased the process greatly.
The phrase 508 compliance, which means compliance with the Section 508 Amendment to the Rehabilitation Act of 1973, resulted from a 1998 law that requires Federal agencies to make their online information and documents accessible to people with disabilities. Compliance on the Web is often achieved by proper coding, including captioning videos or adding descriptive text to visual images. This process allows users with disabilities to use assistive technologies to interpret online content. Every contractor working with the Federal Government includes 508 compliance as part of its Web or multimedia work.
We know that information technology continually evolves, seemingly at a faster and faster pace, and the 508-compliance process is no different, as a new Web standard has been introduced to improve accessibility for disabled users and to make 508 compliance more effective for them.
The new standard is officially called Web Accessibility Initiative – Accessible Rich Internet Applications; it is commonly referred to as ARIA. ARIA was released in March 2014 by the World Wide Web Consortium as part of HTML5, the latest standardized markup language for presenting content on the Web.
ARIA is part of the new language of the Web—a technical specification that details how to increase the accessibility of Web pages. ARIA holds many advantages, one of those being the ability to hide and show content that can be invisible to people with disabilities (who use assistive technologies) but can be visible to everyone else. For example, with the wide use of icon sets, pseudo image-font-types aren’t enclosed in the image <img> element tag and, therefore, do not use attributes like alternative text (i.e., <img alt="some text">), which describes the image in text form.
Because each icon should be in an icon set accompanied by descriptive text, there is some redundancy in adding descriptive text to the element tag containing the code to call the icon. This process can lead to it being read twice by a screen reader, which can be annoying to the user. Furthermore, the icon isn’t in the element tag but is usually called through a css class or id, unlike the image element with the reference to the image file right inside the element tag through the use of the src attribute.
If you add aria-hidden=”True” to an appropriate element tag like span, the icon would be ignored by a screen reader but would still be visible to non-screen-reader users. Moreover, if you cannot include a descriptive text for your icon, and it’s purely decorative, using aria-hidden=”True” is a good way to comply with Section 508 standards and still be considerate of people with disabilities.
I greatly appreciate the ARIA Web standard and encourage its use. ARIA is only in its first release and will evolve, including working with accessibility APIs. ARIA wasn’t intended to change browser behavior, but there is now a standard set of specific techniques for accessibility in HTML5. That’s a good thing!