Web accessibility checklist
Person using a braille screen reader. Captured by Sigmund - unsplash.com/@sigmund

Web accessibility checklist

Accessibility (a11y for short) constantly evolves and new best practices are established yearly. Here I’ve compiled a list of issues that can be detected by free and paid tools, or a simple manual check, but in any case issues that would need to be resolved for achieving compliance by WCAG (Web Content Accessibility Guidelines). You are welcome to use the following as a checklist for making a11y audits or as inspiration for your work breakdown structure on a new project.

Table of contents

  1. In your <head>
  2. Structure and landmarks
  3. Images, video and audio
  4. Forms
  5. Validation
  6. Mobile
  7. Interactive elements
  8. Others

In your <head>

Often omitted segment of a11y is what you do and don’t do in the head section.

  • Correct doctype on the first line identifying which HTML version is used.

It makes sure that screen readers will correctly interpret the different html tags and their roles. <!DOCTYPE html> for HTML5

  • Have lang attribute on the html tag (e.g., lang=”dk”)

It tells screen readers in what language the document is so they can set proper pronunciation. Remember to add this attribute to any paragraph or text element that might differ from the base document language.

  • Include correct charset to avoid weird looking characters (e.g., <meta charset=“utf-8”>)
  • <meta http-equiv="X-UA-Compatible" content="IE=edge">

Users won’t switch browsers, they’ll switch sites. This meta tag makes sure that things look and function their best for the few who might still use IE.

  • Have a meaningful and unique text for your <title> tag on each page

It attracts users, serves as a ranking factor and improves visibility, as it’s described by Mangools

  • Have a meaningful <meta description=””>?

This is a short (160 character) description of your page. It appears in search results as well as when your website is shared on social media. People might find it difficult to find out what your site is about and if it’s relevant to them, if the description is missing or not well thought out.

  • Set an initial scale for the viewport with <meta name="viewport" content="width=device-width, initial-scale=1.0">

You might end up with a badly scaled version of your website for mobile, if you are missing this tag with the suggested attributes above.

  • Make sure you haven’t used maximum-scale=1 or user-scalable=no. In your <meta name=”viewport” …>

Those attributes can be found sometimes on old websites, where code has been copied over without much thought. Unfortunately they take the users’ possibility to zoom in and out.

Structure and landmarks

With HTML 5, we received a vast selection of new tags that made it redundant to write class names as “footer”, “header”, “main”, “nav”, “aside”. Class names never meant anything to screen readers unless we had a role attribute as well. Few were adding those roles and that was a big accessibility challenge, as roles form a page’s landmarks for easier navigation with AT (assistive technology). HTML 5 changed that, as screen readers would know that <nav> has the role of navigation, <footer> of footer, <main> is main. However, not all roles have an HTML 5 alternative (For example role=“search” which should be used on your search form), so you should still have them occasionally. On MDN Web Docs you can find a detailed list of various roles with short descriptions and more on landmarks.

  • Make sure that you follow a logical headings order

It’s advised to have only one h1 per page, (unless you use HTML5) that is best to match the page <title> and be placed as high as possible inside the <main> tag. Following title after h1 can only be h2. That h2 can be followed by another h2 or a h3 and so on to h6. You can skip heading levels when going up in order (e.g., <h5> to <h2>) but not the other way around. Broken order of headings will trigger warnings in most accessibility tools as screen readers depend on that order to give the users a quick scan of the page’s content.

  • There are no paragraphs styled as titles

You lose on semantics and accessibility when not using headings from 1 to 6.

  • Provide a “Skip to content” link

Make a “Skip to content” link as a first element in your markup that is visible on Tab key or read by a screen reader. It should link to your <main> tag and it will help people using screen readers to avoid having to listen through your entire header and navigation each time they visit a sub page. If you want to learn more how to implement it check out the following articles by CSS-tricks: How to create a “Skip to content” link,?A deep dive on skipping to cContent.

  • Tables must have table headers and possibly caption
  • Significant HTML validation/parsing errors are avoided
  • Link text conveys meaning?

Avoid writing “Click here”, “here”, “Read more” and similar as some AT (assistive technologies) use links for presenting a list of where the user can go to. Those links are displayed without the context, and if they don’t convey any meaning, they will be useless to the user. Alternatively, you can provide more descriptive text though an aria-label attribute. More details on this can be found in Cognitive accessibility article on MDN Web Docs

  • Provide multiple ways for people to find information (e.g., through main navigation, table of content, site map, search)

Images, video and audio

We touched on some of those in the previous article (Web accessibility and the 4 major disability categories - [link to article once published]), but let’s get more specific.

Images

  • All images should have an alt attribute

The attribute can be left empty if the image serves only a decorative role. Else, you should write a short description of what’s visible. For example, if there are 3 people on the beach - write that, if there is a kitten in the picnic basket - write that. Avoid writing “Picture of …”, “Photo of …” as the AT (assistive technology) would already announce “Image” and continue with the provided alternative text. Provide description for background images if you find it necessary. This can be accomplished by using a visually hidden span tag with the descriptive text of the image.

  • Use longdesc for images of graphics, pie charts and tables

Maybe you have images of tables, maybe they are nicely designed and hard to recreate with CSS, maybe there are time restraints on what you can do. In any case, you can use longdesc to link to another file or element with ID on the same page where you recreate what’s in those images. For example a pie-chart can be coded as a simple table, that you visually hide from other users. A11y test tools won’t detect that you have an image of a table and you need to provide a longdesc, so this is definitely something you need to check manually.

Check W3C if you want to learn more about longdesc - HTML5 Image Description Extension (longdesc).

<SVG>

  • Add role=”img”, <title> and <desc> for SVGs that are not included as src in img or not nested in an anchor or button tag. Add aria-labelledby and aria-describedby that refer to the title and desc

Often we have a text input with a search icon next to it. However, if that icon is implemented as a svg tag and there isn’t a title or desc tags inside it, the user has no chance to figure out what’s going on if they navigate through a screen reader (for this scenario you can also add aria-label="Search" to the wrapping button).?

Audio

  • Audio media should have captions and transcripts

It’s preferable to contain text about sounds, music, and emotions, besides what’s spoken. Adding a download button for the transcript is a plus. The audio tag doesn’t provide WebVTT support by default. You can add additional libraries for it, but a valid workaround recommended by Ian Devlin is to use a video tag? instead -? WebVTT and Audio

  • Video
  • Video should have captions and transcripts (just like audio)

The captions shouldn’t obstruct anything important from the video.

  • Avoid autoplay

It’s rarely what the user needs. If you do have to use it, please follow MDN Docs Web guidelines - Autoplay guide for media and Web Audio APIs.

  • Add seizure warnings and prevent videos (and GIFs) from autoplaying if they are known to cause such events

Forms

  • Set focus to input field when clicking labels
  • Use logical field types as it helps a lot, especially on mobile (e.g., email, number, password, tel, url)
  • Set autocomplete attributes to save the user time (The HTML autocomplete attribute)
  • Reduce the amount of data you collect by removing everything that is not required

Besides potential privacy concerns, the more data you ask for from the user, the higher chance you would have for them to make mistakes, to get bored, tired and drop out. Ask only for what’s most important.

  • Combine fields. Combine first and last name in one field; address in one line; country code and phone in one field
  • Place labels directly above fields

This is proven to be the fastest and least confusing way for people to fill in forms

  • Placeholder attributes shouldn’t be used as labels

Use placeholder for instructions on how to fill inputs (for example, to indicate the correct date format). You can also use aria-describedby to link to another element below the input, with further instructions (e.g., “Passwords must contain at least 8 characters”)

  • Use fieldset and legend to group elements as shipping address, billing address, contact information
  • All fields are keyboard accessible and it’s clear which is the current field the user has focus on
  • Use additional confirmation dialog boxes or checkboxes for the user to confirm actions as deletion of data or execution of financial transactions
  • Instructions do not rely solely upon shape, size, or visual location (e.g., "Click the square icon to continue" or "Instructions are in the right-hand column")
  • Instructions do not rely upon sound (e.g., "A beeping sound indicates you may continue.")
  • Use aria-disabled instead of the disabled attribute for buttons, as this would allow focus and a tooltip.

Even better, don’t use disabled buttons for forms. Instead let the user click them and get the communication through error messages why they can’t continue.

Validation

  • Make sure that color is not the only indicator of state - use icons and text, too
  • Set aria-invalid=”true” when fields are invalid and add an explanation how to resolve them
  • Change focus to the top of the form where you can display a list of all inputs that are invalid and need correction
  • Announce successful form submission through element with role=”alert” and aria-live

ARIA live regions documentation?

Additional information: Usable and Accessible Form Validation and Error Recovery

Mobile

  • Minimum target size is recommended not to be smaller than 44 x 44 px. (Adaptivity and Layout - General Layout Considerations)
  • Keep user input (typing) to a minimum
  • Provide correct resolution images and possibly use SVGs
  • Provide “scroll to top” link
  • Provide sufficient space between elements to avoid accidental selection of the wrong button/link

Interactive elements

  • Interactive elements which are not active or are off the screen need to have aria-hidden=”true” to avoid screen readers reading them?

This is particularly true for tabs, accordions and modals.. visibility: hidden or display: none; could also be used.

  • Utilize aria-selected for elements that indicate user choice - active tab, active accordion element. Set the attribute to false for the collapsed, or inactive elements
  • Tab triggers should have aria-controls attributes linking to the element on the page they correlate to. The value of the aria-controls has to be the same as the ID of the tab block.
  • Use role=”tab” for your tab components and aria-setsize and aria-posinset to indicate their count
  • Use aria-expanded for your accordion elements as well as (mobile) menu

Add aria-current=”page” to your current page in the breadcrumbs navigation.?

AT (assistive technologies) know to indicate to the user that this is the current page

  • Links should be visually different from regular text in a way that’s not relying only on color
  • Indicate through text (can be visually hidden) and/or icon if a link is to?be opened in a new tab, or if a link downloads a file

Others

  • Use aria-label to explain what’s expected from links as those wrapping a close X button or the page logo if there is no other text (e.g., aria-label=“Back to front page”, aria-label=“Close modal”)
  • Add aria-live attribute to any elements that might update dynamically (e.g., live chat, shopping basket)
  • Make it easy for the user to find where they currently are on the website. Achieve this through using breadcrumbs and meaningful text in the title tag
  • Add a glossary for any jargon, unusual words or abbreviations. It can be done both inline (using the <abbr> tag) or at the bottom of the page
  • Disable animations through using prefers-reduced-motion media query

This helps people with vestibular motion disorders navigate your website safely (More on prefers-reduced-motion from Mozilla)

  • Users can disable non-essential animation and movement that is triggered by user interaction
  • No page content flashes more than 3 times per second unless that flashing content is sufficiently small and the flashes are of low contrast and do not contain too much red
  • Create meaningful pagination that is not just a sequence of numbers

Wrap it in a nav tag with aria-label=”Pagination navigation”. Each item can have aria-label=”Go to page 1” on the anchor tag.

  • Color contrast for any text is at least 3.0 (AA) or 4.5 (AAA). Same with text over images.

Contrast requirement for large text (18pt and larger) or bold text from 14pt is reduced to 3:1 as it’s easier to read. Additional details can be found on the following links: Developer Mozilla Color contrast, WebAIM on Contrast and Color Accessibility.

  • Allow the user to pause, adjust or extend any system set time limits for interactions
  • Polyfills are used for addressing features not implemented yet in older browsers
  • Tools for auto-prefixing css are used to avoid cross-browser styling inconsistencies

-----------

Have I missed anything? Please, share it in the comments and I will make sure to add it.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了