Accessibility Checklist: Development


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


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 tab order intuitive?
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?
Do interactive elements follow keyboard control rules: Tab to element, Enter or Space to activate, arrow keys to select items within the element?
When interacting with elements that add new content, such as a dialog, all of the following:
Does keyboard focus move into the new content?
When keyboard focus is within a dialog, can you close the content using the keyboard?
Does your focus stay strictly within the dialog?
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.)
If the controls are alphanumeric, punctuation, or symbols, can the controls be disabled, remapped, or limited in scope to relevant elements?
Original Yale Criteria

Verifying Alternative Text

For each image, any of the following...
...is it purely decorative? Does it have either: a null alt attribute, the "presentation" role, or is a background image via CSS?

To clarify: null alt attribute is alt="" and not just the lack of an alt attribute


If the image is purely decorative, and, yes, it has one of those three qualities (null alt, presentation, or is a bg image), then the image is fine and passes. What this is actually asking is if the image has no content/information in it, and thus screen readers should be given markup instructions to ignore it.

...is a short description sufficient? Is the short description in the alt text?
...does it require a longer description? Is the long description in nearby text? Does the alt text have a short description?
...is it being used as a button or link? Is there a text alternative that clearly describes its purpose?
For each link...
...is its purpose understandable from the link text alone?
...if it's not, is the link text, a title attribute, or ARIA attribute adequately descriptive?
...if it's not, can it be understood from the paragraph, list item, or table cell it's in?
Original Yale Criteria

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 there are items that automatically animate, is there a way to pause, stop, or hide the animating?
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?
Is there a text equivalent for content that uses color to convey information?
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:
Can we dismiss the content with the escape key?
Does the content not obscure other content? It's okay if it does if it can be dismissed with the escape key, or if would cause a form input error.
Can we hover over the content itself?
Does the content remain until dismissed, the user manually removes hover/focus, or it loses relevancy?
Original Yale Criteria

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:
Are we using semantic markup for headings, lists, figures, emphasized text, etc?
Is <div> only used if an element has no semantic meaning?
Are we using real links and buttons using <a> and <button>?
Are we using HTML tables only for tabular data?
If text's appearance conveys meaning, are we using appropriate semantic markup?
Original Yale Criteria


Are form labels for inputs, all of the following...
...semantic, descriptive, and programmatically associated with the input?
...visually positioned in a consistent, easy-to-associate way?
...present in more ways than just placeholder text? A placeholder is insufficient labeling.
Are required fields, all of the following...
...visually indicated, in a manner that does not require color?
...programmatically indicated using required or aria-required attributes?
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...
...identified using aria-invalid?
...given suggestions for how to fix, if possible?
...generally easy to discover, identify, and correct?
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

Widgets & Operation

Does any task have a time limit? If they do, all of the following...
...is it absolutely necessary?
...is it at least 20 hours, or it can be extended, adjusted, or disabled?
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.
If such a change in context happens, is the user informed ahead of time?
Whenever possible, are we preferring HTML roles, states, and properties over ARIA?
Whenever possible, are we using native HTML elements over custom widgets?
If we are using a custom interactive widget, are ARIA labels, descriptions, roles, states, and properties used to inform about the component?
If a status message is conveyed, are we using an ARIA live region or ARIA alert?
Original Yale Criteria

Dynamic Content

If content is dynamically added to the page...
...does the new content appear right after the element that made it appear?
If not, is the user made aware new content was added and where it is?
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

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?
If there are, can they be disabled and is there an alternate way to control?
Original Yale Criteria