Accessibility Checklist for Front-End Developers

Accessible front-end development ensures people with different abilities can access, understand, and navigate web content, regardless of how they’re accessing it. Front-end developers collaborate with other members of a cross-functional team to implement a robust user experience.

Keyboard Access

  1. Use the keyboard to navigate through the page using the tab key.
  2. Make sure you can reach all interactive elements and trigger them with the spacebar, enter key, or arrow keys.
    • Use semantic HTML elements that are accessible by default (For example: buttons, labeled inputs, etc). If you must use divs for interactions, ensure they are focusable and labeled appropriately.
  3. Check to see that focus is always visible and appears in logical order.
  4. Make sure that no content gets focused offscreen or is hidden from view.
  5. Check to see that the page includes a skip navigation link (if navigation is present before the main content). This will allow users to skip past navigation to reach the page’s main content.

Screen reader

  1. Use a screen reader to make sure you can land on controls and that they’re announcing things as they should.
  2. Determine whether the HTML document has a language attribute so that screen readers will read it with the correct accent and pronunciation. For example: .
  3. If forms are present, make sure the screen reader reads labels and instructions.
  4. Make sure that all links are properly descriptive. For example, the link text “Read More” provides no context about where the user will go if they click it, while “Read more about dinosaurs” describes what’s on the other side of the link.

Headings

  • Headings briefly describe the section it introduces. Headings represent an outline of the content.
  • Use h1–h6 to define your section headings, where h1 is the highest section level and h6 is the lowest.
  • Avoid skipping heading levels: Always start with h1, use h2 next, and so on.
  • Use only one h1 per page for the page title.
    *While HTML5 allows you to reset headings to h1 on new section elements, some screen reader users will have difficulty discerning the structure of pages with multiple h1s. For this reason, it’s best to include only one h1 per page.

Page structure

  1. Use sectioning elements to create a broad outline of your page content; examples of these elements include header, nav, main, and footer. Use content sectioning elements like section, article, and aside to organize the document content into logical pieces.
  2. Add role=”banner” to your masthead and role=”contentinfo” to your page footer once per page to define landmark elements.

Images

  1. Include meaningful information describing each image in the alt text.
  2. Use null (empty) alt text when text describing the image is already on the page (alt=””).
  3. Don’t start the alt text with Image of or Photo of – the screen reader already announces that images are images.
  4. If the image is decorative and you don’t want the screen reader to announce it at all, use null (empty) alt text (alt=””) or CSS background images.

Color and contrast

  1. Use a color contrast tool and test that the contrast between the text and background is greater than or equal to 4.5:1.
  2. Use an automated tool to quickly scan for color contrast problems.
  3. Don’t use color alone to convey meaning. Use icons, text, and other visual elements to reinforce the meaning of the content.

Automated testing

  1. Quick check: Use a tool to quickly check for common errors in your browser. You can use HTML CodeSniffer, aXe, Lighthouse Accessibility Audit, Accessibility Insights, or WAVE.
  2. Build process: Integrate a tool like axe-core, jsx-a11y, Lighthouse Audits, or AccessLint.js into your project to programmatically add accessibility tests and catch errors as you build out your website.
  3. Continuous integration: Use a tool like AccessLint to find accessibility issues in your GitHub pull requests.
  4. Simulate impairments: Use tools to simulate color blindness, low vision, zoom, low contrast, high contrast, and more.

You can also view our other digital accessibility checklists:

Reference: Accesibility.digital.gov

In:

One response to “Accessibility Checklist for Front-End Developers”