While emphasizing the “why” of digital accessibility, Microassist CTO and noted accessibility advocate Hiram Kuykendall also provided web and application developers over an hour’s worth of web accessibility resources and instruction during Austin Adobe User Group’s (AAUG’s) June meeting. Below, I’ll cover a bit of the overview he gave, as well as point to accessibility resources developers will find helpful as they build and test their projects.
In addition to his work for Microassist, Hiram is a board member for Knowbility, a non-profit whose mission is promoting equal access to information technology for people with disabilities. Knowbility’s upcoming OpenAIR hackathon, which provides training on accessibility in a fun, competitive event, was a key driver for the AAUG’s presentation.
Why build accessible websites and apps?
Litigation
Hiram began his talk by outlining why making online and other digital content accessible to those with disabilities is relevant to web designers and app developers. There are a host of laws designed to ensure such content is accessible—that is, that the content and the navigation are usable by those who may use special tools or methods to access digital content. According to the law firm Seyfarth Shaw, 61 lawsuits were filed across 5 states over website accessibility needs in 2015. Most of these suits never made it to trial. Instead, as part of a settlement, the website owner agreed to remediate the site to make it accessible. Hiram pointed out that these accessibility suits aren’t solely targeted at large corporations, and that any business or group that serves the public can be asked to remediate their website.
Universal benefits
Beyond the potential threat of a lawsuit, there are other reasons to think about web accessibility. Many people who are not disabled make use of accessibility technologies: Many older people use screen magnifiers. Using a screen reader allows you to listen to long text documents so you can multitask. Following the color contrast guidelines ensures your site or app can be seen and used in bright light. These points and more lend credence to Hiram’s point that accessibility works best when it works for everyone.
Digital inclusion
And of course, there’s the primary reason behind accessible web and app development: It enables those who are blind or have visual impairments, or who are deaf or hard of hearing, or who have mobility or cognitive challenges, to enjoy, access, and otherwise participate in the digital modern world we live in.
When to address accessibility
For someone new to accessibility, building a site or app and then going back over everything and making it accessible may seem overwhelming. Hiram’s advice is to build the site or app with accessibility in mind from the ground up. He also provided several accessibility resources and tips on how to do that.
Three elements of a modern, accessible website: guidelines, alt text, and ARIA tags
Accessibility guidelines
For developers who are completely new to developing with access in mind, there are several great accessibility resources to help begin understanding what is needed. The first resource is the Web Content Accessibility Guidelines (WCAG) website. Additionally, the Web Accessibility Initiative Accessible Rich Internet Applications (WAI-ARIA) outlines a set of practices that make your content more accessible to screen readers.
The WCAG and ARIA guidelines work together to provide a list of coding and other recommendations that will make your site or app accessible for people with disabilities. Many guidelines are fairly straightforward to implement by someone with a basic understanding of web languages. Others are more involved, which is why I recommend following the recording of Hiram’s presentation for the many step-by-step examples he provided (an accessible PDF of his slides is also available).
Describing images with Alt text
For this talk, Hiram focused on accessibility for the visually impaired. There are many things content developers can do to make their site or app easier for blind and low-visions users to interact with and navigate. Chief among them is using short alternative descriptions, or “alt text,” for graphic elements. In general, this alt text is not displayed visually as part of the website. Instead, because many visually impaired users rely on screen reader software to read page content out loud, this alt text provides a way for screen readers to relay meaningful information from non-readable image content. Such descriptions could describe a step in a process, data points on a chart, or a location on a map. If there is no alt text included, screen readers will read the file path of the image, which isn’t helpful for a blind user. Also, if a site or app has graphical elements that provide no additional meaningful information and are solely there for design, developers can add blank alt text or alt=”” so screen readers skip over the image entirely.
Providing ARIA landmarks to orient users on a page
Another technique he discussed was using ARIA labels to add landmarks to your content. Again, ARIA labels aren’t typically displayed in the visible design of the site. They do, however, provide key indicators for moving around a page, just as physical landmarks provide indicators on how to orient within a physical space. For example, think of a typical navigation menu. By using the ARIA label within the code portion, you are providing screen reader users a landmark they can access quickly without having to listen to all of the text on the site to find the navigation area. Landmarks are an especially rich area that can help screen reader users move through your content and find what they want to use. Since a developer is already specifying div and role tags for the html when building the page, it is an easy matter to add an ARIA label.
Helpful accessibility testing tools
Finally, Hiram recommends developers attempt to use their products with a screen reader. Doing this will helps creators understand the content from a user perspective and what they can do to make it more accessible for the visually impaired.
He pointed the group to several tools that will help developers as they embark on making their content more accessible:
- Bookmarklets — Developed by Paul J. Adams, these are small JavaScript programs that can be placed in the bookmarks bar for any browser. The bookmarklets will help you identify items on your page that need to be made accessible.
- Google Accessibility Toolbar — Adds an accessibility audit and sidebar pane to the Elements tab of your Chrome Developer Tools.
- Juicy Studio Accessibility Toolbar for Firefox— Gives developers tools to review the accessible content on their sites.
- NVDA Screen Reader — A free screen reader, so you can hear exactly what the user will hear when visiting your page. This screen reader is free to download and use, but donations are accepted.
- Jaws Screen Reader — An alternative to the NVDA screen reader. Free for a trial period then requires purchase.
- Voiceover — A native feature in Apple products that functions as a screen reader.
Future accessibility events
Hiram will be returning to the AAUG to discuss designing for other disabilities like hearing and mobility impairments. While there is no date for these discussions yet, you can check back here or contact the Austin Adobe Users Group directly.
Additional accessibility resources
Microassist has been at the forefront of developing accessible digital tools for more than 20 years. What began with accessible elearning has evolved to include web and applications development, accessibility auditing, testing, and remediation, and much more. To learn more about accessibility, please review some of the articles below. For more on our accessibility offerings, please reach out to our sales team for help and information.
- Staff bio: Hiram Kuykendall, Microassist Chief Technology Officer
- Accessibility in Elearning: Why It’s Worth It
- Is Your Website Discriminatory? Many Are. [Free Paper]
- PowerPoint 2013 Tip: Checking the Accessibility of a Presentation
Contact our Learning Developers
Need to discuss developing e-learning? Creating curriculum for classroom training? Auditing and remediating e-learning for accessibility? Our learning developers would be glad to help.