Design Checklist for Accessibility

These are highlights of some of the most important concepts. Push yourself to think beyond the bare minimum, to create designs that people with disabilities actually like, and that they find useful and well-suited to their needs.

Page Title

• Page title (the browser title for the page; not the main content heading or <h1>) describes the topic or purpose of the page?

Headings

• Text that looks and acts like a heading are marked as a heading.
• Heading levels are in their correct hierarchical order. Headings are not used for their visual styling.

Navigation

• Method provided to skip repetitive navigation and go to the main content. Two of the main techniques including providing HTML/ARIA landmarks (e.g. header, navigation, main, footer), and "skip navigation" links.
• Reading and focus order as determined by the code is logical and intuitive.

Links

• Link text clearly describe the purpose or destination of the link.

Color/Contrast

• Information conveyed by means other than just color. (example: using color and text to indicate that a form field has an error)
• Text has a minimum color contrast against its background of at least 4.5 to 1 (3 to 1 for large text).
• Link text is distinguishable from non-link text by more than just color.
• Actionable elements have visible focus when non-mouse users Tab or Arrow to them?

Responsive Design

• Users with low vision can magnify or zoom in on the content in any browser on any device.
• Design is optimized for all zoom states. Horizontal scrolling is eliminated.

Images

• Alternative text for informative images provide the same information as the image.
• Alternative text for actionable images identify the link destination or purpose.
• Complex images explained fully in the page content with a short alternative text description.
• Decorative images have blank alternative text.
• Plain text used instead of text embedded in images. (exceptions: logos and decorative text images)

Tables

• Data tables have a name and title caption, and columns and/or rows or properly identified in the markup.
• Complex tables are simplified to minimize or eliminate the need for compound column or row headers.

Forms

• All form fields have visible label.
• All form labels are descriptive and instructive. All information a user needs to fill out the form is available on the page.
• All form labels and instructions are immediately adjacent to their form element. Users should easily connect the form element with its label and/or instructions?
• All controls are in close proximity to the content they are controlling. (example: Edit and Delete buttons next to the content they modify)
• Error messages provide enough information for users to correct their error.

Dynamic Content

• Users are made aware of content that is dynamically inserted on a page or new content come right after the element that caused it to appear.
• All keyboard-only and touch screen interactions follow expected patterns so users know how to interact with all widgets on the page.
• Design success and failure feedback into all interactions. Users when activating scripted functionality (buttons, form submissions, etc.), must know whether the action was successful or not, through a success/error message, the obvious activation of a feature (e.g. a video starts to play after the user activates the "play" button), etc. The feedback must be available to sighted users, screen reader users, and all other user categories.

Custom Widgets

• Design use standard HTML widgets (links, buttons, form elements, controls, etc.).
• Custom widgets have full keyboard support, and are compliant with WAI-ARIA authoring practices.

Touch Devices

• Touch target size of main links and buttons are large enough and far enough apart from each other to activate easily with a finger.
• Alternative ways to activate any custom swipe actions or gestures are provided. Note that when a screen reader is activated on a touch device, it overrides all custom swipe actions and gestures.