Accessibility – Avoiding A Lawsuit – An Overview for Stakeholders and Developers
Accessibility is all about providing people who have impairments with equal ability to access information, products and services. For developers, accessibility means providing websites, web tools, and software interfaces that are designed and coded so that people with impairments can use them.
ADA = Americans with Disabilities Act
National Association of the Deaf v. Harvard; NAD v. MIT
On November 8, 2019, NAD and individual Plaintiffs C. Wayne Dore, Christy Smith and Lee Nettles reached a settlement with Harvard University requiring a robust regime of captioning for its publicly available online content. (Full Story)
While the universities tried to dismiss the cases originally, in 2019 the plaintiffs and Harvard reached an agreement. The settlement required the University to add high-quality captions or transcripts to all of the video and audio content available publicly online.
The agreement included videos that are live-streamed and content on third-party platforms like YouTube. Harvard also was responsible for the Class Counsel’s motion for $1,575,000 in attorneys’ costs and fees.
Just about every business has an online presence these days, however, not all are paying close enough attention to how people with disabilities experience their website. As of 2020, The Internet hosts more than 400 million active websites.1 Any of those websites that do business in the United States are legally required to provide equal accessibility to all people following Title III of the Americans with Disabilities Act.
Source: CREEC | Civil Rights Education And Enforcement Center & Essential Accessibility
With the realization that accessibility compliance is a great advantage for your company and customers, and with the increase in ADA activist lawsuits across the country, it is important to have a clear understanding why web tools and applications should be compatible with assistive technologies used by people with impairments. Some of the most common ways of meeting compliance are making sure screen readers, Braille terminals, screen magnification and speech recognition applications have clean access to your systems. Other ways would be to meet expectations for subtitles and captioning when needed. In this article we will cover why accessibility is important, compliance standards, WCAG guidelines, ARIA guidelines, and validation and screen reader tools.
Websites And Interfaces Should Be Accessible.
Websites, apps, and interfaces all should be accessible, including video and audio. Videos need closed captioning and transcription. Podcasts should be transcribed. Even company documents, including Word, Excel and PowerPoint files, emails, and PDF files,need to meet your employees’ needs.
Impairments that need to be considered, may include:
Visual
Mobility
Auditory
Cognitive
Why Accessibility
Matters
Legal Exposure and Equal User Experience
Although legal exposure is a valid concern—users can sue companies for inaccessible websites and apps just as they can sue over inaccessible buildings and facilities—there are positive reasons to maintain accessibility. Accessibility lets your organization provide a more equal user experience, helping you reach the broadest customer and stakeholder base possible. Consider that:
- More than five percent of people worldwide have a hearing impairment.
- 15 million people in the U.S. have a vision impairment.
- 41 percent of videos online do not include sound or captions and are incomprehensible to hearing or visually impaired users.
In addition, accessibility can improve search engine optimization (SEO) and is often appreciated by users without impairments, such as older users who desire larger text.
Accessibility
Compliance Standards
W3C Web Accessibility Initiative (WAI)
The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) provides standards to ensure web and app accessibility. Most important are:
NOTE: Section 5 of the Federal Rehabilitation Act also covers accessibility. However, if you comply with the WCAG (AA) and ARIA guidelines you also will be section 5 compliant.
The POUR acronym
The WCAG guidelines support principles are summed up by the acronym POUR, which stands for Perceivable, Operable, Understandable and Robust. Websites and applications should be:
- Perceivable – providing alternatives for non-text and time-based media (such as captioning or transcripts for videos, and text for images), compatibility with different devices and browsers, and generally making it easier to see and hear content.
- Operable – providing ways for users to interact via keyboard, without a mouse, and including the ability to slow down or run at various speeds. Sites should be very navigable and not cause seizures or physical reactions.
- Understandable – done in readable, simple language, avoiding complex terminology unless required by the subject matter. Content should appear and operate in predictable ways – from top to bottom and left to right (or right to left in countries where people read that way). Build pages and sites to help the user avoid mistakes.
- Robust – meaning the site or app can be interpreted by a wide variety of user agents, including assistive technologies.
These four main high-level guiding principles that are used in functional accessibility design and development are commonly referred to as the POUR acronym and are meant to improve the lives of people with disabilities, expand business markets, and help to avoid lawsuits and bad press coverage.
ARIA
Accessible Rich Internet Applications
What is ARIA
ARIA stands for Accessible Rich Internet Applications and is a set of attributes you can add to your HTML to help define elements (i.e. content and images) so users working with assistive technologies (AT) can access the information. Some ARIA examples of this include:
- Roles – roles define what an element is or does. An example of this might look like
Role Example: <nav role-“navigation”></nav>
- Properties – properties can provide more semantics. Some examples of this might look like:
Global Example: aria-describedby=”info”
Widget Example: aria-hidden=”true”
Live Region Example: aria-live=”polite”
Relationship Example: aria-colspan=”2″
- States – states define “a state” an element is in . An example of this might look like:
State Example: aria-disabled=”true”
ARIA guidelines are categorized by Roles, Properties and States. Roles define what an element is or does. If the role says “navigation,” for example, it will allow screen readers to announce to the user that they are viewing a navigational element.
ARIA Global Attributes
ARIA properties and roles consist of global attributes that can be applied to all elements, and include specialized ones for widgets, live regions, and relationships. Examples of each include:
- Global Property – an example of a global property would be a field on screen that is described from a text paragraph. The “described by” element would cause the paragraph to be read out to the user.
- Live Regions – live regions are a property used for things that refresh on the screen frequently, such as news feeds or stock quotes, to notify a visually impaired user when the area changes.
- Relationship Property – the relationship property is ideal for use with tables, announcing to the user contextual row and column header names so user knows what row/column category they are inside
ARIA Global Attributes (states & properties) provide specific information about an object and help form a description of the roles nature. This all falls into the category of WAI-ARIA, which is a specification written by the W3C. ARIA defines a set of additional HTML attributes that can be tagged onto various elements and gives the code additional semantics to help improve accessibility for the user.
The Current State of Accessibility
• 97.8% of home pages had detectable WCAG 2 failures
• 85% had low contrast
• 68% were missing alternative text for images
• 58% had empty links
• 52% were missing form labels
• 33% were missing document language
• 25% had empty buttons
These are all significant barriers to accessibility. The good news is that most of these items can be discovered using free tools. And once found, such problems are easy to fix. Correct them and you’ll be well on the way to web accessibility.
Developers also fall short on accessibility. A recent Front-End Tooling Survey of 3,005 developers found that when it comes to accessibility testing:
• 63% of developers don’t use any validation tools (they just review their code)
• Only 22% use a color contrast checker
• Only 15% use a screen reader for people with vision issues
• Only 9% use WAVE, the leading validation tool for accessibility
Market-Leading
Tools
Validation Tools
Clearly, developers need to adopt and use a standard set of validation tools for accessibility. Blackslate Software evaluated three of the market-leading tools – WAVE, Deque aXe, and Google Lighthouse—all of which are available at no cost—and found WAVE to be the clear winner.
Each tool was run through the W3C WAI test website (test bed) with known issues and errors intentionally built into the test pages. Findings:
- WAVE – The WAVE validation tool is easy to use, clearly summarizes errors and warnings, and provides element and error highlighting, showing the exact code where each error resides. You can build a process around it for testing every feature of a website for accessibility.(LINK)
- Deque aXe – Deque aXe goes a bit further and assesses the severity/impact of the errors it reports, but it was harder to use than WAVE and identified fewer issues.(LINK)
- Google Lighthouse – Google Lighthouse found the least errors, i.e. it was the least effective of the three tools tested.
Screen Reader Tools
It’s important to adopt a standard screen reader for accessibility compliance. Screen readers make websites and applications audible for users who are visually impaired. According to a recent WebAIM survey, the most popular screen reader applications are NVDA followed by JAWS. The most used screen reader/browser combinations are:
- JAWS – with Chrome
- NVDA – with Firefox
- NVDA – with Chrome
- JAWS – with Internet Explorer
We recommend NVDA because it performs well, has reliable updates and costs nothing. JAWS has a free version but it doesn’t run for long without requiring a reboot. A more robust version of JAWS is available for purchase (about $1,000), but in our experience JAWS upgrades too often come with errors and omissions.
Set Accessibility Compliance From The Beginning
Start with accessibility compliance up front, rather than trying to retrofit it later. This will save you time and money.
Good document structure is critical for screen readers, SEO, and even for users who don’t have impairments. Be mindful of how you organize headings, page regions, ARIA landmarks, and tab/focus order.
Always use proper HTML5 syntax and controls—they are your first line of defense. If you can’t find an HTML5 element or attribute, then go to ARIA and other accessible means. The website https://www.html5accessibility.com lists which new HTML5 features are accessibly supported by major browsers.
Five Points To Consider:
Keep Headers In Order
Keep Regions in Order
"Focus"
Tabs Should Move From Top To Bottom
"Skip Navigation"
The Most Robust Tool For Automation Validation
WAVE
Validation Tools
We recommend WAVE as the most robust tool for automated validation. However it’s important to do both automated and manual validation and testing. Many issues won’t be caught automatically, such as:
- Inaccessible dropdown menu
- Insufficient visual cues
- Inaccessible CAPTCHA
- Inaccessible form validation
- Inaccessible modal window
- Inaccessible carousel
- Missing accessible table markup
- Missing abbreviation tags
- Image with incorrect/inadequate text alternative
- Link not visually distinct
- Reading sequence not meaningful
- List not marked up as such
If you publish these types of errors, they won’t be accessible to users with impairments. Manual testing, in addition to using the tools, will ensure all errors are caught.
For screen reader technology, we recommend NVDA, which is free and quite reliable. If your users use a different screen reader, such as JAWS or Voiceover, then use that one. Keep in mind:
- Screen readers are linear – the default is top to bottom, left to right. They will read the DOM and the HTML in the order it is presented.
- Screen readers have many configuration settings and customization options.
- Visually impaired users are adept at listening to accelerated readouts and memorizing keyboard shortcuts.
When testing for screen reader, try doing it without using your mouse (only your keyboard). To experience it fully, use a blindfold!
Conclusion
Accessibility
Accessibility compliance can require extra effort in design and testing. This is particularly true with video, which requires captions for the hearing impaired and transcripts for the visually impaired. For closed captioning and transcription, it makes sense to leverage third-party services.
Finally, although accessibility is generally desirable, not every website or application must be accessible, particularly those whose target audience by definition does not have impairments (for example, police officers in the field). Ultimately, the choice to provide or not provide accessibility is up to each organization, preferably with input from legal counsel.
The Fastest Way To Build Software Is “Right” The First Time!
Understanding your industry is one thing. Understanding the technology you are using is another. When you read studies that tell you that 75% of projects are doomed from the beginning, it has to make you pause before signing your name to the outcome.
Consider letting our proven professionals take a look at your project. They’ve seen what can go wrong and know how to avoid costly errors.
We build custom software from start to finish. We plug into your environment with the proven expertise you need for us to work independently or in co-development. And, we bring the soft-skills that make the task enjoyable, and the experience to leave your team stronger and ready to take over.
We Bring You…
Team-Complete™ Development
Soft-Skills For A Winning Experience
Sometimes the most critical person in the room is the one with a calm voice and the knowledge to select the right words. Bringing a development team together or presenting a clear concept for stakeholders can make all the difference between success or failure. Blackslate Software consultants are at the top of their field. They navigate challenging decisions, guide with a confident voice, and know when to get out of the way.