The University of Chicago

Resources for Designers & 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 Designers & 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.

Accessibility top 10 checklist for designers & 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.

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.

3. Does the site design provide sufficient color contrast?

Use sufficient color contrast in your website designs and evaluate color combinations with a tool such as the WebAIM Contrast Checker. If designing within The University of Chicago color system, please reference this contrast grid of accessible UChicago color combinations. (Note: Due to technical reasons, this color grid lists Maroon (#800000) on Greystone (#A6A6A6) as compliant; however this is the only combination on the grid that does not meet minimum contrast guidelines and should be avoided.)

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.

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.

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.

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.

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.

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.