Web Accessibility & WCAG Compliance Checks

computer screens with warning and alert messages

Web accessibility often seems overwhelming, but it doesn’t have to be. There are some simple WCAG compliance checks and fixes that you can do now to increase your website’s accessibility. Although this is not a definitive list of the Web Content Accessibility Guidelines (WCAG), completing the following easy checks and applying repairs where can give you an idea of your website’s overall accessibility.

Pro tip: While testing your website for accessibility, you will notice that many checks overlap. For example, when testing visible keyboard focus, you will also verify that the focus indicator provides sufficient color contrast. Since accessibility testing can be time consuming, testing for both of these success criteria at the same time helps to reduce the time that your team spends on the testing process.

Alternative text (“alt text”)

Alt text is used by those who cannot see an image to understand its content and purpose. For example, screen readers read an image’s alt text to blind users. Additionally, when a user disables images on a website, the alt text displays.

The goal of alt text is to provide an equivalent experience for users who cannot see images, illustrations, charts, etc. Alt text should be descriptive but not too verbose. To help with your description, consider describing the image as if you are describing it to someone over the phone. 

Linked images must always include the purpose of the link. Some screen reader users will navigate a page by links. Including the purpose of the link informs them to know where the link will take them and will suffice for meeting WCAG’s 2.4.4 Link Purpose requirement.

Some images are purely decorative and do not add valuable information that needs a description. When an image’s purpose is purely decorative, the image must still have an alt attribute, but the attribute’s value will be blank (alt=””). A few examples of decorative images include

  • Section separators such as decorative lines
  • Images described in nearby text such as a caption or other paragraph or heading text
  • Designs added for ambiance such as a stock photo of books in an article about books
  • Icons with text such as a magnifying glass next to the word “search”

How to check alt text

In addition to using an automated scan tool to check for the presence of alt text, you will also need to manually test alt text for accuracy, since artificial intelligence (AI) cannot determine the purpose of the image. Here are few examples of how to test alt text on images:

  1. Use the free web developer extension for Chrome or FireFox. Find “Display Alt Text” under the Images menu tab.
    web developer tools option in images menu to display display alt attributes
    The extension displays an image’s alt text next to the image.
    image alt text displayed using web developer tool
    Review the description for accuracy.
  2. In both Chrome and Firefox browsers, mouse users can right-click on an image and select Inspect. The browser’s DevTools will display the page’s HTML. View the alt attribute of the image’s HMTL element, and verify its accuracy.
    alt text displayed in HTML image element
    View the HTML of the page in the Safari browser by selecting Connect Web Inspector from the Developer menu.
    Safari menu with developer selected and Connect Web Inspector highlighted
    If you do not see the Develop menu, you may need to activate it. To do this, select Safari > Preferences > Advanced, and confirm that the option to “Show Develop menu in menu bar” is selected.
  3. Listen to the page with a screen reader to hear each image’s alt text.

Animations

WCAG success criteria 2.2.2: Pause, Stop, Hide requires that moving, blinking, and scrolling content provides a way for users to pause, stop, or hide the content. This applies to moving content that 

  1. Starts automatically
  2. Lasts more than five seconds
  3. Is presented in parallel with other content

The most common place where we see web pages fail the pause, stop, or hide requirement is with carousels. Carousels that automatically scroll through content must include controls such as a pause/play button that allow users to pause the carousel in order to provide enough time to view the content of each slide.

Another example of animations that affect accessibility includes flashing or blinking content. Content that flashes too quickly may cause seizures in people with photosensitive epilepsy. Blinking or flashing content should not flash more than three times in one second.

How to check animations

To test animations, simply view each web page of the website to look for moving, blinking, or scrolling content, and verify the following:

  1. Users can pause, stop, or hide the moving content.
  2. All controls are accessible using a mouse, keyboard, and touch controls.
  3. All controls are labeled with accurate descriptions.

Color Contrast

Providing sufficient color contrast between text and its background, including images of text, allows users with low vision or visual color deficiencies to read the content of your website. WCAG’s 1.4.3 Contrast (Minimum) success criteria requires a visual presentation of at least a 4.5:1 ratio between text and its background.

The following exceptions do not require a 4.5:1 color contrast ratio:

  1. Large text
    Text that is 18.5px and bold or larger or 24px when the text is not bold requires a 3.5:1.
  2. Incidental
    Inactive user interface components, such as a link that is hidden until it receives focus or text that is purely decorative, do not have a contrast requirement.
  3. Logotypes
    Logo and brand names do not have contrast requirements.

How to check color contrast

We recommend using a combination of manual and automated techniques to test color contrast ratios. The following techniques are all successful ways to check color contrast:

  1. If you are a mouse user, use browser DevTools by right-clicking on the text and select inspect. Select the color icon for the text that you want to test. As long as the CSS declares both the text and the background color of the element, DevTools will display the contrast ratio.
    Chrome dev tools displaying contrast ratio for text and background color
  2. Automated checkers cannot determine the color of images so when there is an image used as the background for text, use a tool such as the ColorPick Eyedropper for Chrome or Firefox browsers to select the background color. In order to ensure that sufficient contrast is provided for all areas of the background image, we recommend selecting various areas of the image including colors that appear to provide the least amount of contrast.
    color picker selecting color in background image
    Enter the foreground and background colors in a color contrast checker tool such as one listed on W3C’s Web Accessibility Evaluation Tools List to test contrast ratios.
  3. For text that includes a text-shadow, test the color of the text against the text-shadow.
    color picker selecting text shadow of text on background image
    Note that in order to use the text-shadow to meet color contrast, the shadow must be at least 1px wide.

Keyboard accessibility and keyboard focus

WCAG’s Guideline 2.1: Keyboard Accessible requires all functionality to be available when using only a keyboard. This includes elements such as links, forms, and media controls. Keyboard accessibility is vital to your website’s overall accessibility and benefits a wide range of people including screen reader users or users who cannot use a mouse due to things such as hand tremors or temporary or permanent injuries. 

In addition to accessing everything using only a keyboard, WCAG 2.4.7 Focus Visible requires that users must also be able to determine where their keyboard focus is at all times. There are a variety of techniques to accomplish this; however, the most basic technique used to provide keyboard focus is a focus outline declared in the website’s stylesheet.

How to check keyboard accessibility

Put your mouse aside and do not use it during keyboard testing. Use the Tab key on your keyboard and tab through the active elements on each page. Shift+Tab allows you to tab backwards. Arrow keys allow you to move within elements such as drop-downs lists and menu bars. Use the Spacebar or Enter key to select items.

Test the following:

  1. Confirm that you can access every interactive element including buttons, links, form controls, and media controls.
  2. Confirm that you see a visible focus indicator as you land on each active element such as an outline or underline that was not visible prior to the element receiving focus.
    focus outline on submenu link element
    Additionally, be sure that the visible focus indicator provides sufficient color contrast against its surrounding color.
  3. Verify that keyboard focus does not get trapped in any area that the user cannot exit using only the keyboard.

Page titles

WCAG 2.4.2 Page Titled requires all web pages to have titles that describe their topic or purpose. A screen reader will identify the current page by the page title. Don’t get this one confused with the main (H1) visual title that you should have on each page. 

The page title is contained in the <title> tag located within the <head> tag of each page. Page titles are the titles that you see in browser tabs and are the first thing that screen readers say when a user visits a new web page. This especially helps visually impaired users to orient themselves on a website.

Page titles also display in search results. 

Google search results displaying page title

How to check page titles

Check each page of the website to verify that a page title is present using one of the following techniques:

  1. Browser tabs display title text. Verify that the browser tab contains text describes the purpose of the page.
    title displayed in Chrome browser tab
  2. Look at the page’s source code for a non-empty <title> element as a child of the <head> element.
    title element in HTML source code
  3. Use a screen reader to listen to the page. Screen readers will announce the page title prior to reading the content of the page.

In addition to verifying that a title exists, verify that the title accurately describes the content of the page and that each page has a unique title.

Video and audio content

WCAG Guideline 1.2: Time-based media requires that all multimedia content such as videos and podcasts is provided to all users including those who are visually or hearing impaired. Time based media includes content such as videos and podcasts. Examples of providing access to video and audio content include captions, text transcripts, and audio descriptions.

Many video players such as the one provided by YouTube offer assistance with this requirement by providing automatic captions. However, do not depend solely on automated options. Automatic captions are typically not accurate enough to provide equal access. If you use automated captioning tools, verify that the captions are accurate and edit them as needed.

Text transcripts are a great way to provide access to audio content such as podcasts. In addition to voiced content, the text transcript must include a description of important sounds. We recommend providing text transcripts at the beginning of the audio content to ensure that users are aware that the transcript exists.

How to check video and audio content

For all video and audio content, verify the presence of an alternative format such as captions or text transcripts. Additionally, ensure that the captions or text transcripts are accurate and accessible to all users including keyboard-only users.

PDF accessibility

In addition to providing accessible HTML content, businesses and organizations who link to PDF documents must also ensure that PDFs are accessible. If your website provides links to PDF documents, ensure that all PDF documents provide things such as accessible tagging structures, sufficient color contrast, and document titles. 

The best way to create accessible PDF documents is to start with the original document that was created in a program such as those provided by Microsoft including Word, Excel, and PowerPoint. Once the document is converted to a PDF, Adobe Acrobat Pro provides a way for users to add additional required accessibility. 

How to check PDF accessibility

Testing PDF documents for accessibility is similar to testing web pages for accessibility in that you need to include testing for a variety of criteria including color contrast, heading structure, keyboard navigation, and descriptive link text.

Complete the following quick accessibility checks on each PDF document.

  1. Start with automated testing using Adobe Acrobat Pro’s Accessibility Checker.
  2. Repair each defect listed in the automated report.
    PDF accessibility check tool link in Adobe Acrobat Pro
  3. Manually verify that all colors provide sufficient color contrast.
  4. View the document’s tagging structure to verify that tags are provided in the correct order.
  5. Read the document with a screen reader such as NVDA (free) or JAWS. We recommend that you do not rely on Adobe’s read aloud feature for screen reader testing as this is not the screen reader that most disabled individuals rely on.

If you need assistance completing PDF remediation, Be Accessible offers for PDF remediation services as well as PDF accessibility training

Complete WCAG Compliance Check

Completing the quick checks listed here provides a very general idea of your website’s accessibility. For the most accurate results, include users with various abilities in your testing process. Web accessibility is about real people, and we recommend that you use real user feedback as you develop and test your website’s accessibility. 

To ensure that your digital content is accessible to everyone, complete full WCAG accessibility testing. Additionally, ensure that your developers and designers complete web accessibility training so that you can maintain web accessibility with each website update.

Avatar for David Gevorkian

By David Gevorkian

David Gevorkian started Be Accessible because of his passion for delivering exceptional customer service. Prior to Be Accessible, he spent much of his early career working for financial institutions in sales, treasury, and product management. David earned his Master’s in Business Administration from Salve Regina University in Newport, Rhode Island. He discovered a common need for web and mobile accessibility during his previous roles, and as a result, he created Be Accessible to make accessibility in reach for any type of business. David is a strong advocate for creating aesthetic and accessible products usable by all people across the world.

Contact Us

Please complete all fields.

Recent Posts

doctor viewing test results

Digital Accessibility in Healthcare

Yes, digital accessibility is imperative in the healthcare industry! Find out why it matters and how it costs to ensure equal experience to everyone.

Read more about Digital Accessibility in Healthcare
Laptop computer with web statistics information in the screen.

Web Accessibility Laws and Legislation

More often than not, a website is the first impression for potential customers. Because of this, it’s no surprise that today, web design is a $38.3 billion industry.

Read more about Web Accessibility Laws and Legislation
employees checking website for WCAG 2.2 compliance

What’s new in WCAG 2.2

Version 2.2 of the Web Content Accessibility Guidelines (WCAG) is here! Find our checklist for new success criteria and the guidelines of the latest version.

Read more about What’s new in WCAG 2.2