Answering FAQs About Digital Accessibility

Glen Walker
Reading time: minutes

Here’s what you need to know about WCAG, compliance, and how to get started with accessibility testing

Over the last few years, as Applause continues to provide accessibility testing services, organizations increasingly ask us how they can best assess their digital properties against key accessibility standards. These inquiries seek to understand why digital accessibility is critically important, how their organization can best conform to guidelines and/or regulations, and the value of automated accessibility testing tools.

This blog post answers several frequently asked questions about digital accessibility. We welcome you to reach out with any additional questions.

Why is digital accessibility important to my organization?

Accessibility is critical to enable organizations to improve the experience for all users, broaden their market and strengthen their brand image.

Digital accessibility is about making websites and applications useful for the widest and most diverse audiences. This includes making digital properties accessible for people with disabilities. According to the CDC, 61 million adults in the United States — or 26% of adults — live with a disability of some form. While some disabilities are visible, many others are not, such as color blindness.

Digital accessibility is about making websites and applications useful for the widest and most diverse audiences.

As the world becomes more reliant on digital properties — an evolution currently being sped up by the ongoing COVID-19 pandemic — people with disabilities will take their business away from organizations that don’t provide accessible experiences. For businesses, this can represent lost sales in addition to the risk of being branded as inaccessible and uncaring about the experiences of people with disabilities.

A few specific examples of the ways that organizations can provide accessible experiences for people with disabilities are ensuring that:

  • Color contrasts are not a problem for users with lower vision, discolored eye lenses or color-deficient vision (aka color blindness)
  • Users can navigate the site without the use of a mouse
  • People with dyslexia can access easy-to-read fonts or can change the font
  • Buttons and links can be selected by people with hand tremors

How can accessibility help an organization, outside of making experiences accessible for people with disabilities?

While accessibility is often considered in the context of people with disabilities, it is actually impactful for all users. For example, having clear and correct closed captioning within a video on your websites can make it easier for anyone in a noisy environment (gym, airport, convention center, etc.) to engage with the content — not just people with hearing disabilities.

In addition, when your website is accessible, all your users can benefit from the enhanced user experience provided by more navigation options, sharper color contrasts, clear decoding of icons, buttons, links, input fields and images. These are all elements that will benefit everyone, and show a company’s efforts toward being inclusive.

Finally, doing what’s right for all users may also protect you against potential assertions of legal claims, damaging brand image and resulting in costly fees to defend. There were more than 11,000 federal web accessibility lawsuits in 2019, according to an analysis by international legal firm Seyfarth Shaw. The United States Supreme Court’s 2019 decision on a lawsuit involving Domino’s Pizza indicates that online businesses may be subject to legal claims if the user can demonstrate that such sites are not providing experiences that are accessible to people with disabilities.

What does ‘ADA testing’ or ‘508 testing’ really mean?

The Americans with Disabilities Act (ADA) was passed in 1990, and is a civil rights law that prohibits discrimination against individuals in all areas of public life, including jobs, school, transportation, and all public and private places that are open to the general public. The ADA makes it illegal for any government entity or business to provide goods and services to the general public without ensuring that the entities are accessible by people with disabilities.

In large part because it was passed before the internet was widely used, the ADA largely applies to physical accessibility, such as having a ramp for people with a wheelchair to enter a physical building. While digital accessibility lawsuits are often filed under the ADA, there are not specific statutes listed under the ADA that relate to digital accessibility, which creates gray areas. When it comes to the ADA and digital accessibility, it is better for organizations to err on the side of caution and make themselves as accessible as possible.

Section 508 is part of the United States’ Rehabilitation Act of 1973, and requires federal agencies to make their electronic and IT assets accessible to people with disabilities. This law specifically applies to organizations that are selling to government agencies.

If your customers are outside the U.S., there are other government guidelines to consider. For example, the Accessibility for Ontarians with Disabilities Act has deadlines at the end of 2020 that require many organizations and businesses operating in Ontario to become accessible or risk financial penalties.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines, and are published by the Web Accessibility Initiative. The goal of WCAG is to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations and governments internationally.

WCAG has 13 guidelines that are organized under four principles: perceivable, operable, understandable and robust. For each guideline, there are testable success criteria, which have three levels: A, AA and AAA. The criteria is cumulative — to conform to Level AA, you must also conform to Level A, and to conform to Level AAA, you must also conform to Levels A and AA.

According to WCAG, it is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

The most recent version is WCAG 2.1, which was published in June 2018. According to the Web Accessibility Initiative, WCAG 2.2 is scheduled to be published in early 2021.

What is the difference between compliance and conformance?

This is a key distinction to make as you set goals for accessibility. A lack of compliance can mean legal consequences for an organization, while failing to conform — to a WCAG guideline, for example — means an organization is falling short of non-legally binding guidelines.

To use an example outside of accessibility, in the United States, if a driver goes above the mandated speed limit that is outlined on a white sign, he or she is not complying with the law — this could lead to legal consequences, such as a ticket or even loss of license in extreme cases.

However, an example of non-conformance is advisory speed limits, which are marked by a yellow sign and often associated with a curve in the road. These advisory speed limits recommend drivers lower their speed, but they are not specifically enforced by tickets.

Coming back to accessibility, a company selling to a government agency that offers an inaccessible experience could be at risk of non-compliance with Section 508 and could potentially face financial penalties. However, WCAG is a guideline, so there are no direct legal repercussions in terms of financial penalties from the government, or another body, if your websites don’t conform to WCAG. Keep in mind, though, that your organization could be at greater risk of a potential lawsuit under the ADA for being inaccessible if your websites do not conform to WCAG.

Your organization could be at greater risk of a potential lawsuit under the ADA for being inaccessible if your websites do not conform to WCAG

How conformant is my organization’s website?

Conformance is a yes/no question — you are either conformant or you are not. An accessibility review shows you how many WCAG checkpoints your organization passed or failed, and how many critical/high/medium/low issues that were found.

You can somewhat “measure” improvement by the number of accessibility bugs that testers find — if the number of bugs goes down, hopefully that means your business is getting closer to conformance. However, the number of WCAG failures is not an indication of how accessible your organization’s website is. A site that fails 50% of WCAG checkpoints might still be pretty accessible, while a site that ‘only’ fails 5% of WCAG checkpoints might have a lot of blockers and be very inaccessible.

How should I approach accessibility testing?

If this is your organization’s first time doing accessibility testing for existing websites and products, take small steps at first. If you try to test all your digital properties at once, you could be inundated with bugs. For a first pass, choose 20-30 pages that you think are important to your customers’ journey.

After testing, fix all the high-severity bugs (and retest to make sure they’re fixed correctly), then decide if medium-severity bugs should be fixed next, or if an assessment of another 20-30 pages would be better

For new websites and digital properties, you should take a different approach. Embrace accessibility during the design process — review designs for accessibility issues and annotate the designs to prevent accessibility issues when the designs are handed off to developers.

In addition to testing, consider incorporating accessibility training for your design, development, marketing and legal/contracts teams. Marketing email campaigns should be written with accessibility principles in mind, and third-party contracts with design firms or development shops should contain accessibility language in the contract.

What type of device coverage do I need in my test plan for accessibility testing? Is it the same as for functional testing?

This depends on the testing budget. At a minimum, testing desktop on Firefox with the NVDA screen reader can catch a majority of accessibility issues.

However, if time and budget permits, you can add testing on a mobile device. If possible, to have the best coverage, conduct all of the following testing leveraging different tools, devices and OSes:

  • VoiceOver on iOS
  • Talkback on Android
  • JAWS screen reader on desktop with Chrome
  • VoiceOver on Mac with Safari

How do automated accessibility testing tools work?

Automated accessibility tools can serve as a starting point for accessibility testing. An automated accessibility tool — including the Applause Accessibility Tool — can identify violations to accessibility web guidelines, such as whether elements have alternate text or if audio elements have captions.

One unique feature of the Applause Accessibility Tool is that it can provide either a code change that the developer can automatically apply, or highlights the issue for manual correction.

However, even the best automated accessibility tool can only identify around one-quarter of accessibility-related issues. Many WCAG checkpoints are subjective — such as “does the heading describe the purpose of the section?” — and a program can not make those kinds of determinations. These are areas that can only be uncovered by manual testers.

How can I build accessibility into my software delivery lifecycle if it is a manual process?

The sooner you incorporate accessibility into the timeline, the better. When you find issues later on, they become more expensive to fix.

During the design process, review all wireframes and other mockups with accessibility in mind. However, remember that this requires that the design team is educated on accessibility principles.

When you find accessibility issues later on in the development lifecycle, they become more expensive to fix.

Next, educate the development team so they use accessibility principles in implementing the designs. The first step with accessible implementation is to use as much native semantic html as possible, such as real <button> elements or <h2> elements. Some nightly accessibility testing jobs can be run with automated testing tools, but as noted earlier, only about 25% of issues can be found in this manner. Any issues found by a nightly job are better than not checking for issues at all. You could even build in the accessibility scan at “check in” time so that code is not propagated to production if it has errors in the scan.

The key is to think about accessibility all throughout the lifecycle and not consider it an “add on” check at the very end.

How can I ensure that media content is accessible?

Section 1.2 of WCAG covers media guidelines, specifically transcripts, captions and audio descriptions.

Transcripts and captions should contain a verbatim account of everything that is spoken, identify who the speaker is (by name, if known, or it could just say “different speaker” so that the user knows someone else is talking), and contain other important sounds such as applause, laughter, questions from the audience, music, etc.

Audio descriptions are like having a narrator explain what is going on or like reading a descriptive book. Audio descriptions should contain descriptions of:

  • Sounds
  • The setting or background
  • Any action sequences
  • Facial expressions
  • Any text or graphics that are displayed

As an organization, how can we build out our internal accessibility practice?

The key word to remember here is training. Start by sending some of your design, development and testing teams to training. During normal circumstances, onsite training is generally the more effective option, but given the current pandemic, online training can suffice.

Hire (or train) someone to be the main point of contact for accessibility. Look for someone who understands accessibility and has experience in the area.

You also need “buy in” from upper management. It’s helpful when VPs are on board and understand the business benefits of accessibility. Treat accessibility like internationalization and security. It has to be built into the software and not added on at the end.

Finally, practice reviewing your products for accessibility issues. At first, it’s helpful to hire a company that can perform the review. As your organization reviews the feedback, your organization should study the results of the testing very carefully and see if you can mimic those results. Then try a test of a small set of pages early in the development process and train staff to avoid these types of errors in the future product development. Over time, this will build in accessibility awareness into the product development process overall.

How can Applause help me with my accessibility testing?

Applause has accessibility experts located around the globe who conduct assessments of websites and digital properties against WCAG 2.1, Section 508 and other accessibility guidelines. Applause provides a list of failures prioritized by severity level, along with detailed bug reports containing screenshots, videos and remediation recommendations when possible.

While Applause does not test for specific disabilities, conducting testing against just one WCAG checkpoint can be beneficial to a variety of disabilities. For example, testing against WCAG checkpoint 1.4.3 for minimum contrast can uncover issues that would impact people with discolored lenses, dyslexic readers and can help when using a mobile device outside in bright sunlight.

Applause tests with a screen reader and uses keyboard navigation, which can catch many violations. Using a screen reader makes it easy to spot and understand problems, although the use of the screen reader does not mean Applause tests exclusively for visual impairment issues.

How long does an assessment take?

On average, it takes about two weeks to test 30 pages of a website or native app. There are several factors that can impact the turnaround time, including:

  • Number of pages
  • Complexity of the pages
  • Number of screen readers
  • Testing a public site or beta/pre-production site
  • Need for credentials
  • Need for VPN
  • Restrictions on testers' location
  • Need to make purchases
  • Need to open new accounts

These questions are just the starting point to better understanding digital accessibility and how to best apply accessibility testing. Accessibility is a nuanced topic, and many organizations need expert guidance as they seek to make their digital properties more accessible. Our team is ready to answer your questions.

You might also be interested in: