Digital Accessibility Compliance for Websites (Ultimate Guide)

Digital Accessibility Compliance for Websites (Ultimate Guide)

Here’s what you’ll find in this Digital Accessibility Compliance guide:

  • What is Digital Accessibility Compliance? Why is it important?
  • Vulnerability to Lawsuits
  • What are the Web Content Accessibility Guidelines (WCAG)?
  • What is Section 508?
  • Creating an Accessibility Plan
  • 10 common Digital Accessibility Compliance issues
  • Your next steps

What Is Digital Accessibility Compliance? Why Is It Important?

There is no denying the importance the Internet plays in today’s world. We rely on the Web to do an ever growing list of tasks such as shopping, staying in touch with friends and family, finding a new job, and finding the answers to our questions.

As a result, web traffic is more important now than ever before for organizations and businesses.

Digital accessibility refers to the capacity of digital media – such as websites, mobile applications, and other digital properties – to be easily understood and navigated by a wide range of individuals, especially those with visual, auditory, motor, and/or cognitive disabilities.

Many people are surprised to learn just how important digital accessibility is in today’s increasingly online environment.

For example, there are currently 57 million Americans living with a recognized disability, and an estimated 9 out of every 10 websites are not currently accessible for these individuals.

Not only does this pose a problem for those who struggle to navigate the vast majority of the Internet, but also for the organizations who have created significant barriers impeding this large audience from engaging with their brand.

71% of people with disabilities immediately leave a site upon realizing that it is not accessible to them.

We believe that we are moving toward a world in which accessibility will be as important a consideration when building a website as mobile responsiveness and SEO are now.

By making your website accessible, you will ensure that a wider range of users are able to take full advantage of your products and services and can fully engage with your organization.

In this guide, we will discuss your exposure to litigation, the guidelines and regulations you need to be aware of, and the steps you should take to make your web properties more accessible for everyone.

Vulnerability To Lawsuits

Title III of the Americans with Disabilities Act (ADA) prohibits discrimination on the basis of disability in the activities of places of public accomodations.

Originally, this meant having physical accommodations such as marked accessible parking spaces, wheelchair ramps, counters of a certain height, accessible bathrooms, etc.

Recently, courts have shifted this definition to include digital properties in addition to physical ones. As a result, this has greatly expanded the legal exposure of businesses and organizations across the country.

In each of the last two years, the number of website accessibility lawsuits filed in federal court under Title III of the Americans with Disability Act has more than doubled.

In 2016, there were 262 of these lawsuits. That number exploded to 814 in 2017 and 2,258 in 2018.

Many expect this trend to continue in 2019 and beyond.

The industries that have historically been the biggest focus of accessibility litigation include the retail, food service, hospitality, financial, and entertainment industries.

We have helped businesses in the middle of pending litigation and have seen first-hand the stress and costs that being sued incurs.

That is why we strongly encourage a proactive approach to accessibility compliance.

Taking the initiative to make your website digitally accessible is much more desirable and much less expensive than doing so reactively in response to a lawsuit.

That means starting the process of updating your site to meet WCAG 2.1 guidelines as soon as possible and implementing a plan to ensure your site stays in compliance.

What Are the Web Content Accessibility Guidelines (WCAG)?

Developed by the World Wide Web Consortium (W3C) as part of their Web Accessibility Initiative, the WCAG guidelines are considered the go-to standard when it comes to digital accessibility.

WCAG 2.1 guidelines address vision, color perception, cognition, manual dexterity, screen reading technology and other issues related to altered abilities.

Every guideline address at least one of the four principles of WCAG. Those principles are:

  • Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
  • Operable – User interface components and navigation must be operable.
  • Understandable – Information and the operation of user interface must be understandable.
  • Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Additionally, each WCAG guideline is given one of three different levels of compliance:

  • Level A – addresses the most basic accessibility issues and functionality
  • Level AA – addresses the biggest and most common accessibility issues
  • Level AAA – reserved for the most complex and specific accessibility issues

We encourage organizations to meet Level AA compliance as that is the most common standard used by governments, and in the majority of settled digital accessibility lawsuits in the US, it is the level of compliance to which courts have ordered defendants to update their websites.

In order to achieve Level AA compliance, you must comply with all guidelines marked Level AA in addition to all those marked Level A.

While we are intimately familiar with WCAG, we understand that it can pose a major challenge to those new to accessibility as they can be very hard to understand – even for experienced web developers.

We still remember what it was like when we first read them ourselves. Needless to say, there is a steep learning curve involved.

You can read a detailed breakdown of the 10 WCAG guidelines we most often deal with on client’s websites further in this digital accessibility compliance guide below.

What Is Section 508?

A 1998 amendment to Section 508 of the Rehabilitation Act of 1973 requires certain accessibility standards be met for federal agencies and all websites and applications developed using federal funds.

Section 508 is an older, less extensive accessibility standard than WCAG, and all Section 508 requirements are included within WCAG.

That means by complying with WCAG 2.1 Level AA, you will also automatically be in compliance with Section 508.

In most cases, Section 508 is not something that organizations need to worry about provided enough attention is given to WCAG 2.1.

Creating An Accessibility Plan

The first step in getting your website digitally accessible is determining which issues your site currently has.

We recommend seeing if your site is in violation of any of the 10 WCAG guidelines listed in detail below. Chances are your website does not meet several of these guidelines in addition to a potential host of others.

Make this task easier on yourself and your website development team by using a trusted third party tool such as ADAComply to scan your website and determine what accessibility updates your site needs.

LEARN MORE ABOUT ADACOMPLY SOFTWARE

Once you understand the issues plaguing your site, it’s time to come up with an accessibility plan.

You need to decide whether you want to handle remediation internally or hire accessibility professionals to do it for you.

If you’d prefer to handle your accessibility in-house, you also have the option to get your site audited by accessibility professionals.

Whether you use ADAComply software or get a professional audit, you will then have detailed reports that document your site’s accessibility issues and provides insight on how each issue needs to be addressed.

You can then take those reports and hand them over to your development team to make the necessary changes.

Whether you decide to outsource this critical work or not, you will want to consider getting your site officially certified as being compliant once all accessibility issues on your site have been addressed.

If you want to protect your business from litigation, certification is the best way to achieve complete peace of mind.

It’s extremely important to also develop policies that account for digital accessibility when adding new content to your website.

Websites are not static, and everyone who works on your website needs to be properly educated on how to ensure accessibility when changes and updates are made.

10 Common Digital Accessibility Compliance Issues

  • Color Contrasting
    WCAG 1.4.3 Contrast (Minimum) — Level AA

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the large text, incidental text, and logotypes.

  • Providing Descriptive Labels – WCAG 2.4.6 — Level AA

Headings and labels describe topic or purpose.

  • Alt Text for Links and Images – WCAG 1.1.1 Non-text Content — Level A

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols, or simpler language.

  • Using Tables – WCAG 1.3.1 Info and Relationships — Level A

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

  • Keyboard Only Navigation – WCAG 2.1.1 Keyboard — Level A

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

  • Focus Indicators – WCAG 2.4.7 Focus Visible — Level AA

Any keyboard-operable user interface has a mode of operation where the keyboard focus indicator is visible.

  • “ ” Characters – WCAG 1.3.2 Meaningful Sequence — Level A

F32: Failure of Success Criterion 1.3.2 due to using white space characters to control spacing within a word.

  • Small Sized Font – WCAG 1.4.4 Resize text — Level AA

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

  • Lack of Semantic HTML – WCAG 2.4.6 Headings and Labels — Level AA and 2.4.10 Section Headings — Level AAA

Headings and labels describe topic or purpose.

  • Captions (Prerecorded) – WCAG 1.2.2 Time-based Media — Level A

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

Detailed Breakdown of Each Compliance Issues

1. Color Contrasting – WCAG 1.4.3 Contrast (Minimum) — Level AA

Guideline specifications:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Comments:

Many visually impaired people rely on high-contrast to be able to read the content on a website. Colored text over colored backgrounds rarely creates enough contrast for it to be readable. To meet WCAG, text and interactive elements should have a color contrast ratio of at least 4.5:1, except for large text, which must have a contrast ratio of at least 3:1. This ensures that viewers who cannot see the full color spectrum are able to read the text.

Where to look for this issue:

If using a white background, prioritize dark text colors. If using a colored background, prioritize dark colors and pair with white text. Try to avoid colored text over a colored background when possible.

2. Providing Descriptive Labels – WCAG 2.4.6 — Level AA

Guideline specifications:

Headings and labels describe topic or purpose.

Sufficient Techniques for Success Criterion 2.4.6

G130: Providing descriptive headings
G131: Providing descriptive labels
Note: Headings and labels must be programmatically determined, per Success Criterion 1.3.1.

Advisory Techniques for Success Criterion 2.4.6

Using unique section headings in a Web Page.
Starting section headings with unique information.

Comments:

This guideline is very general and most websites naturally do a good job of including unique headings that describe the content in each section of a page. However, this guideline is most often violated with interactive objects on websites such as contact forms.

You must provide labels to identify the actions that a user must take when completing a form – elements such as text fields, checkboxes, radio buttons and drop-down menus. Every single input needs to have a label or text nearby that is readable by a screen reader and explains the action. If the descriptive text is not wrapped in a label element, make sure to include an “aria-labelledby” attribute.

For instance, let’s say you have a simple newsletter subscribe form on your site that solely asks for a user’s email. The input field should be wrapped in a label element that includes a text description of what information a user should insert there (i.e. “Your Email”).

Where to look for this issue:

Make sure that every interactive element on your site that’s not a link or a button uses native HTML, “aria-labelledby”, or “aria-label” to declare the purpose of the element.

3. Lack of Alt Text for Links and Images – WCAG 1.1.1 Non-text Content — Level A

Guideline specifications:

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
  • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
  • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Comments:

A blind or visually impaired person can use a screen reader to hear a description of the images on your site, but only if a description is provided. Alt text should be used to provide a description for images.

Every image that conveys information or meaning to users must include an alt attribute. If the image provides no informative value – such as Images that are purely decorative – they can have a blank alt attribute (i.e. alt=””).

Otherwise, alt-text must be provided with a description of the image.

Where to look for this issue:

Check any and all photos and images on your site. Many times, especially with a new site, a developer or designer will start adding images that include alt-text, but an intern or someone else might not know to do this. Some of your images may have alt text and some might not.

4. Using Tables – 1.3.1 Info and Relationships — Level A

Guideline specifications:

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Comments:

The purpose of this guideline is to make sure that when information and relationships are implied visually, they are also preserved when the presentation format changes (i.e. someone uses a screen reader to navigate the page).

This guideline is very broad and therefore can be applied to a wide variety of different occurrences.

Web designers and developers often use visual cues to provide emphasis or meaning.

For example, the required fields of a contact form might be marked with a red asterisk. When this happens, the relationship between the asterisk and the field must be provided either programmatically or by descriptive text.

In this example, descriptive text needs to be provided such as: “Fields marked with an asterisk must be filled out.” This allows those using screen readers to clearly understand the relationship between the asterisks and the contact form fields.

One of the biggest challenges with this guideline is with the use of tables. Tables should only be used to present organized data that is related in some way. If a table is needed, it needs to be marked up with well-defined headers, rows and cells so that a screen reader can properly understand how the content of a cell relates to the cell’s row and column.

Where to look for this issue:

Pay special attention to areas of your site where visual cues are used. When creating tables, make sure to use the “table” element with the child elements “tr” (table row), “th” (table head), and “td” (table data/cell) to make these relationships perceivable.

5. Keyboard Only Navigation – 2.1.1 Keyboard — Level A

Guideline specifications:

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes…

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Comments:

People who are blind cannot use devices like a mouse, and people with low vision may not be able to see a pointer on a screen.

Ensuring keyboard control for all functionality on a website such as navigating within and across pages allows assistive devices with keyboard interfaces to perform the same functions as a mouse.

Where to look for this issue:

This is an overall website functionality and development issue. If the developer who created your site did not build the site with keyboard navigation in mind, chances are your site will not be completely navigable in this way. To implement this technique, first determine what functionality is available to users.

Check this basic functionality: Can you navigate through the links, buttons, input fields, and interactable objects on a page by pressing the tab key?

Note: If your site’s nav has a multitude of links, you may want to consider adding the option to skip to main content for keyboard users.

6. Focus Indicators – 2.4.7 Focus Visible — Level AA

Guideline specifications:

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Comments:

This guideline makes clear that a sighted keyboard user must be provided with a visual indicator of the element that currently has keyboard focus.

It must be visibly obvious what element is selected when tabbing through a page. Please note that whatever focus indicator you choose must meet the 4.5:1 color contrast ratio.

Where to look for this issue:

Try navigating pages on your site using only your keyboard. If you notice that some elements don’t receive focus when selected, have your web developer fix this issue by using CSS. This, like many accessibility issues, can be achieved in a few different ways.

7. “ ” Characters – 1.3.2 Meaningful Sequence — Level A

Guideline specifications:

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

Comments:

Using the spacebar or tab keys to create whitespace for styling a text element creates the character “ ” which can often change the meaning of a word or phrase when read by a screen reader.

Where to look for this issue:

This is a styling issue. Check for examples where someone tried to style a word by inserting spaces in between each letters for effect.

“H E L L O” instead of “HELLO” for instance. In this case, the code will look like “<h2>H&nbsp;E&nbsp;L&nbsp;L&nbsp;O</h2>” and a screen reader will read it as: “H”, “E”, “L”, “L”, “O” rather than “HELLO”.

Adding space where it shouldn’t be can change the meaning of some words or phrases when they are translated by screen readers. Prioritize using CSS for styling.

8. Small Sized Font – 1.4.4 Resize text — Level AA

Guideline specifications:

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Comments:

Most browsers allow users with low vision to shrink or enlarge font size according to their preferences. Screen enlargement software also can accomplish this task. However, it is important that your design accommodates the increased size without changing the readability or functionality.

Where to look for this issue:

This could be a site-wide issue and can be fixed in a few different ways.

The key to implementing a fix for this issue is to ensure your page can accommodate larger text without breaking the design of the page. Build your content with this potential increase in text size in mind similarly to how you would construct your site with mobile in mind.

Note: 11pt font (15 px) is the recommended minimum size.

9. Lack of Semantic HTML – 2.4.6 Headings and Labels — Level AA and 2.4.10 Section Headings — Level AAA

Guideline specifications:

Headings and labels describe topic or purpose.

Comments:

Use semantic HTML such as <main>, <aside>, the headers tags <h1> through <h6> and <article> to structure elements according to their meaning.

For instance with proper semantic HTML, a user can tell the difference between a page’s header, navigation, and content. Descriptive headings identify sections of the content in relation to the Web page as a whole and to other sections within the same page. Descriptive headings help users find specific content and orient themselves as they search for specific content.

Where to look for this issue:

Check your site’s code for labels and headings within the web content. Make sure to use descriptive headings that identify the purpose of the content that follows.

10. Time-based Media – Captions (Prerecorded) – WCAG 1.2.2 — Content Level A and Audio Description or Media Alternative (Prerecorded) – WCAG 1.2.3 — Content Level A

Guideline specifications:

1.2.2: Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)

1.2.3: An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)

Comments:

This guideline is intended to make sure that information provided through synchronized media (video with audio) is available to all users. This can be accomplished through providing captions and a text transcript of the video OR by providing captions and an audio description of the video.

Note: The transcript or audio description must include more than just dialogue. They must also identify who is speaking and include non-speech information such sound-effects and a description of what is happening in the video.

Where to look for this issue:

Make sure that all video on your site have text alternatives in the form of captions and a text transcript OR captions and an audio description. If you are an embedding a video from sites such as YouTube, captions may already exist and be provided.

An accessible video will include either captions and a transcript OR captions and an audio description.

Your Next Steps

Now that you have read this guide, you are better familiar with digital accessibility and the challenges it presents to businesses today.

If you’re not sure how to tackle this big issue on your own, leave a comment in the section right below.

We will respond to you within one business day to find a time when we can talk about the specific issues and needs of your website and your business.

Leave a Reply

avatar