Accessibility for Developers
Some of the most common accessibility errors are easily detectable and tend to appear multiple times per page. Simply addressing these few issues will have a significant positive impact on web accessibility. Tackle the most serious barriers and critical content first, and avoid common accessibility errors. References to success criteria in the Accessibility Top 10 Checklist for Developers below link to the relevant WCAG 2.1 guidelines. A variety of free training videos are also available to help you learn more about digital accessibility.
- A11y Top 10 Checklist for Developers
- Accessible Code Patterns and Libraries
- Web Accessibility for Designers
A11y Top 10 Checklist for Developers
1. Is your HTML markup well-structured and semantic?
Write proper, semantic code. Use start and end tags, nest elements according to specification, and keep IDs unique.
- Learn more about Success Criterion 4.1.1 Parsing.
2. Can all interactive elements be selected and activated using the keyboard?
Test your website by navigating it with only a keyboard. Anything that can be done with a mouse must also be doable with a keyboard. Pay particular attention to search bars and submenus; never rely on hover or other mouse-specific event handlers to interact with elements on the page.
- Learn more about Success Criterion 2.1 Keyboard Accessible.
3. Does the site design provide sufficient color contrast?
- Learn more about Success Criterion 1.4.3: Contrast.
4. Are links clearly identified?
Color alone is almost never sufficient to distinguish a link from the surrounding text. The link color must have sufficient contrast not only with the page background, but also with the surrounding text. If those contrast requirements can’t be met, links should be styled with a secondary visual indicator, such as an underline or bottom border.
- Learn more about: Success Criterion 1.4.1: Use of Color
5. Is there a visible indicator when interactive elements have keyboard focus?
Any element that can receive focus (e.g. links, buttons, custom interactive controls, etc.) should have a visible focus indicator. By default, this is an outline surrounding the element in focus. Do not deliberately hide or remove the default focus indicator with CSS. If you choose to customize the focus indicator, be mindful of color contrast ratios when a focused element appears on certain background colors.
- Learn more about Success Criterion 2.4.7 Focus Visible.
6. Does the order in which interactive elements receive focus follow a logical sequence?
DOM order should match visual order. Organize interactive elements logically to preserve meaning and structure when they are being traversed with a keyboard. If content is added dynamically into the DOM, place it immediately after the triggering event.
- Learn more about Success Criterion 2.4.3: Focus Order.
7. Do page layouts adapt to different window widths and can text be resized?
Ensure all text on your website can be resized up to 200% without loss of content. Layouts should reflow up to 400% zoom without loss of content or having to scroll horizontally. If you design responsively and your site supports mobile device viewing, it should accommodate 400% zoom. Scalability should never be disabled.
8. Do all form elements have an accessible descriptive name?
Ensure there are descriptive labels marking each input element and input group. Names and labels should be programmatically associated with their corresponding input or group. If a form label is visually hidden, use aria-label and aria-labelledby to provide additional information for screen readers.
- Learn more about Success Criterion 4.1.2. Name, Role, Value.
9. Are required form fields clearly identified?
Identify required form fields. If your form has a mix of required and non-required fields, add the aria-required=”true” attribute to each input that is required. This will identify them as required to screen reader users.
- Learn more about Success Criterion 1.3.1 Info and Relationships.
10. Do images and icons have appropriate text alternatives?
When building web pages and components, or developing CMS templates, make sure to accommodate alt text for all non-decorative images. When images are used for decoration, include an empty alt=”” attribute.
- Learn more about Success Criterion 1.1.1: Non-Text Content.