πŸ€„

Accessibility Checklist: Development

Automated

All issues that axe labels "Violation" or "Best Practices" have been reported.
Issues labeled "Needs Review" have been assessed and reported or dismissed appropriately.
Relevant Yale Criteria
All img tags must have alt attributes.
If a form field asks for information about the user and if there is an appropriate HTML autocomplete attribute, include that autocomplete attribute.
Links should always be easily identifiable through non-color means, including both default and hover states. The easiest and most conventional way to signify links is underlining.
Do not have audio that plays automatically on the page. When providing audio, also provide an easy way to disable the audio and adjust the volume.
Avoid using tab index values greater than 0.
Provide a lang attribute on the page's html element.
When a visual label is present for an interactive element (e.g. link or form control), the accessible name of the element should contain the visual label.
Validate all page HTML, and avoid significant validation / parsing errors.
Make sure each web page has a title tag that is descriptive, informative, and unique.
Ensure that on each page, headings, landmark labels, and form labels are unique unless the structure provides adequate differentiation between them.

Manual

Keyboard Operation

Is the element with keyboard focus visually clear and distinct?
Do all links, form inputs, interactive controls, buttons, and other focusable elements receive focus?
Is the focus always visible? It should not disappear because it focuses on hidden, out-of-page elements.
Can interactive elements be operated by keyboard alone?
When interacting with elements that add new content, such as a dialog, all of the following:
In general, were you able to tab away from all elements you could tab into (no keyboard traps)?
If the page uses custom keyboard controls, do they not interfere with browser or screen reader shortcuts? (If there are no custom controls, this question and all children automatically pass.)
Original Yale Criteria
All functionality should be available to a keyboard without requiring specific timing of keystrokes
Ensure that any mouse-related effects configured through JS also have keyboard-accessible equivalents.
Ensure keyboard focus is never trapped on an element without an obvious way to move focus out of the element. Make sure the user can move focus to and from all focusable elements using a keyboard only.
In general, avoid using scripts to remove focus from an element until the user moves focus manually.
Avoid implementing access keys. When access keys and other keyboard shortcuts are implemented, they must not interfere with existing browser and screen reader provided shortcuts.
If a keyboard shortcut uses only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then the user must be able to disable the shortcut, remap the shortcut, or limit the shortcut to only when a particular interactive element has focus.
Create a logical tab order through links, form controls, and interactive objects.
When inserting content into the DOM, insert the content immediately after the triggering element, or use scripting to manage focus in an intuitive way. When triggering dialogs and menus, make sure those elements follow their trigger in the focus order in an intuitive way. When content is dismissed or removed, place focus back on the trigger.
Provide keyboard focus styles that are highly visible, and make sure that a visible element has focus at all times when using a keyboard. Do not rely on browser default focus styles.

Verifying Alternative Text

For each image, any of the following...
For each link...
Original Yale Criteria
If short alt text is sufficient to describe an image, provide the short text via the image's alt attribute.
If a short text alternative is not sufficient to describe an image (such as in a chart, graph, or diagram), provide short text via the image's alt attribute, and include a long description in nearby text.
Images that are decorative, used for formatting, or contain content already conveyed in text have a null alt attribute, are implemented as CSS background images, or use the "presentation" role
If an image or icon is used as a button or link, the image has a text alternative sufficient to describe the purpose of the button or link.
The purpose of each link can be determined from the link text alone, or from the link text and the containing paragraph, list item, or table cell, or the link text and the title attribute.
If the visible text alone is not sufficient to convey meaning, use advanced techniques to provide additional meaning, such as ARIA attributes, screen reader only text, or the title attribute.

Presentation of Content

Common Components:

Is a link to Skip to the Main Content the first focusable link on the page? It is okay if it's not always visible, it just needs to be present and focusable.
Do components repeated across several pages appear in the same relative order, and have consistent labels?
Does a navigation menu show links in the same order, on every page it appears in?
Does the layout avoid using whitespace characters?
Can the text be resized without loss of content or functionality?
Do accessible names for UI elements match the visual labels? They must contain the visual label, and match as closely as possible.

Specific Content, Graphics:

Have we avoided images of text? Cases like logos are okay.
Are there no items on the page that automatically move/blink/scroll/update ("animate")? This includes carousels.
If any content flashes, is it less than 3 times per second?
Have we avoided conveying information solely through icons or symbols?

Specific Content, Text:

Do instructions avoid sensory characteristics? Are we making sure we aren't relying on shape, color, size, visual location, orientation, or sound?
Are links to the same destination consolidated when possible? For instance, if adjacent images and text link to the same place, they are a single link element instead of separate links. (This makes for smoother keyboard navigation and also decreases the number of links that a screen reader announces.)

Specific Content, Hover and Focus:

For content that appears on hover and focus, all of the following:
Original Yale Criteria
Minimize the number of adjacent links to the same destination by combining adjacent images and text into a single link, rather than creating a separate link for each element.
Avoid using whitespace characters for layout purposes.
When the color of words, backgrounds, or other content is used to convey information, also include the information in text.
Ensure that there is no loss of content or functionality when text resizes.
Avoid images of text, except in cases such as logos.
For content that appears on hover and focus: the content should be dismissible with the escape key; the content itself can be hovered over; and the content remains available unless it is dismissed, it is no longer relevant, or the user removes hover and focus.
To the extent possible, content that appears on hover or focus should not obscure other content, unless it presents a form input error. or can be dismissed with the escape key.
Provide a link to skip to the main content as the first focusable link on the page.
Do not provide any content that flashes more than three times in any 1-second period.
Items on the page should not automatically move, blink, scroll, or update, including carousels. If content does automatically move, blink, scroll, or update, provide a way to pause, stop, or hide the moving, blinking, scrolling, or updating.
When components are repeated across web page, they should appear in the same relative order with regard to other repeated components on each web page where they appear.
When a navigation menu is presented on multiple pages, the links should appear in the same order on each page.
When components have the same functionality across several web pages, the components are labeled consistently on each page.
Make sure that instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.
Do not convey information solely through icons or symbols.
The accessible name for a UI element must contain any visual label for the element. Accessible names for UI elements should match visual labels as closely as possible.

Landmarks, Headings, Semantics, and Source

Is the source order laid out in a meaningful, logical way? The page should make sense even with styles turned off.
Do frames and iframes have descriptive titles?
Do <article> and <section> elements have a <heading>?
Are ARIA landmarks and labels used to identify page regions?
Are tooltips using corresponding ARIA practices?
Are we succeeding at the following semantic HTML checks:
Original Yale Criteria
Frames and iframes have descriptive titles.
Use semantic markup to designate headings, lists, figures, emphasized text, etc. Use generic <div> elements only when an element has no semantic meaning
Make sure <article> and <section> elements have a <heading> in most cases.
Reserve tables for tabular data, use table headers appropriately, and use table captions.
When the appearance of text conveys meaning, also use appropriate semantic markup.
Avoid emulating links and buttons. Use the a and button tags appropriately. Avoid using a tags for buttons. Avoid using div, span, etc. tags for links or buttons.
Use ARIA landmarks and labels to identify regions of a page.
Ensure that the source order presents content meaningfully. When the page is viewed without styles, all content on the page should still appear in a meaningful and logical order.
For tooltips, follow corresponding ARIA authoring practice.

Forms

Are form labels for inputs, all of the following...
Are required fields, all of the following...
Are instructions provided at the beginning of the form or set of fields that describes the necessary input?
Does any inline help text use aria-describedby to associate the text with the input?
Are form errors, all of the following...
If the form has a serious real-world consequence (financial data, legal agreements, test data, a transaction), are there easy ways to confirm, correct, or reverse user actions?
Original Yale Criteria
Required fields and fields with errors must include some non-color way to identify them.
Programmatically indicate required fields using the required or aria-required attributes. Also, visually indicate required fields in the form's instructions or form labels.
Make errors easy to discover, identify, and correct.
Identify errors using aria-invalid.
Use semantic, descriptive labels for inputs. Visually position labels in a consistent way that makes associating labels with form controls easy. Do not rely on placeholder text in lieu of an HTML label.
Provide text instructions at the beginning of a form or set of fields that describes the necessary input.
When providing inline help text, use aria-describedby to associate the help text with the input.
If an input error is detected and if suggestions for correction are known, provide suggestions for fixing the submission.
Provide easy ways to confirm, correct, or reverse a user action where a mistake would cause a serious real-world consequence (e.g. submitting financial data, entering into a legal agreement, submitting test data, or making a transaction).

Widgets & Operation

Does any task have a time limit? If they do, all of the following...
Are there no functions that use down-events? We should use events like onclick instead.
If there are functions triggered on an up-event, can they be aborted or undone?
When the focus changes is there no change in context? This could be a change in page content, spawning a new window, submitting a form, moving focus, or any other disorienting change.
When a user inputs information or interacts with a control, is there no change in context? This could be a change in page content, spawning a new window, submitting a form, moving focus, or any other disorienting change.
Whenever possible, are we preferring HTML roles, states, and properties over ARIA?
Whenever possible, are we using native HTML elements over custom widgets?
If a status message is conveyed, are we using an ARIA live region or ARIA alert?
Original Yale Criteria
Do not require time limits to complete tasks unless absolutely necessary. If a time limit is necessary, the time limit should be at least 20 hours, or it can be extended, adjusted, or disabled.
Avoid triggering functionality on down-events, such as onmousedown. Use events such as onclick instead.
If a function is triggered on an up-event (e.g. onmouseup), provide a way to abort or undo the function.
When the focus change, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user.
When a user inputs information or interacts with a control, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user. If an input causes such a change, the user must be informed ahead of time.
Avoid creating custom widgets when HTML elements already exist. For example, use a and button tags appropriately.
When creating a custom interactive widget, use ARIA labels, descriptions, roles, states, and properties to expose information about the component.
Use ARIA to enhance accessibility only when HTML is not sufficient. Use caution when providing ARIA roles, states, and properties.
When conveying a status message, use ARIA live regions or ARIA alerts to announce the message to screen reader users.

Dynamic Content

If content is dynamically added to the page...
Can areas with dynamic content be navigated by keyboard? Is it intuitive? Are you capable of reaching all widgets on the page by keyboard alone?

CSS and Styling Practices

Are text, text boxes, and text containers defined in relative units, not pixels?
Are there responsive stylesheets so content can be displayed at 320px wide without horizontal scrolling? It is okay if content such as maps or data tables, that require two dimensions, require scrolling.
Original Yale Criteria
Define texts and text containers in relative units (percents, ems, rems) rather than in pixels.
Provide responsive stylesheets such that content can be displayed at 320px wide without horizontal scrolling. (Content which must be displayed in two dimensions, such as maps and data tables, may have horizontal scrolling.)
Avoid using pixels for defining the height and spacing (e.g. height, line height, etc) of text boxes.

Mobile & Touch

Is all functionality available in both portrait and landscape mode?
Are there no multi-point or path-based gestures required, like pinching, swiping, or dragging?
Are there no motion based triggers?
Original Yale Criteria
Do not require multipoint or path-based gestures (e.g. pinching, swiping, dragging) for functionality unless the gesture is essential to the functionality.
Avoid activating functionality through motion (e.g. shaking a phone). If motion triggers functionality, provide a way to disable the motion trigger, and provide an alternative way to activate the functionality.
All content and functionality should be available regardless of whether a mobile device is oriented vertically or horizontally, unless the orientation of the device is absolutely essential.