Web Accessibility Evaluation Guide

WAVE

• Install the WAVE Chrome, Firefox, or Edge browser extension. An online version of WAVE is available at wave.webaim.org, but the WAVE extension is recommended for comprehensive testing, especially of dynamic or non-public web pages.
• Use the Details panel to review all items. Click on an icon in the panel to highlight it in the page.
  • Error icons indicate items that should be fixed. Other icons prompt further evaluation.
  • Use the checkboxes in the details panel to hide groups of icons.
• Click an icon in the page or use the Reference panel to get more information.
• Turn off Styles to simplify the page view and to check the reading order for screen readers.
• Click on the Code button at the bottom of the page to reveal the relevant code.

Other Tools and Resources

• WebAIM's WCAG 2 Checklist
• Screen reader testing
  • WebAIM tutorials for JAWS, NVDA, and VoiceOver
• Browser Developer Tools
  • Examine page code and identify an element's accessible name and other accessibility properties.
• Disable ad blockers, password/form fillers, and other extensions that may change the default presentation of the page.

Images and alternative text

• , , , , , – Identify images that are missing alternative text.
• , , , , – Confirm that an image's alternative text (in green next to the icon) presents its content and/or function.
  • - The alternative text is likely insufficient or contains extraneous information.
  • - A nearby image has the same alternative text.
  • – Alternative text should be succinct and typically should not repeat information in nearby text or images.
  • – If aria-label is used to add alternative text to images, ensure it is equivalent and that it is on an element that supports ARIA labels (e.g., <img> or <span role="img">).
  • – If an image has a title attribute but no alt value, be sure the title value is equivalent and consider replacing it with an alt attribute.
• If an interface component (link, button, etc.) presents text (or images of text), ensure that its accessible name (label, alternative text, aria-label, etc.) includes the visible text.
• If the image is too complex for a succinct alt attribute value, confirm that there is an equivalent text alternative (e.g., a table) in addition to the alt attribute, either inline or via a link.
  • , – The longdesc attribute should not be used.
• Images that do not have associated WAVE icons are likely added with CSS. If they present content, use the Code panel, test in a screen reader, or inspect in browser developer tools to ensure that alternative text is present.
  • , – Empty links and buttons may indicate CSS images with no alt text
• , – Search for images that are decorative or that present information that is already in nearby text. Make sure they have alt="" or are defined with CSS.
• - If a <figure> is present, make sure it is being implemented correctly.
• Look for images of text where the same visual presentation can be made using real text.

Regions and headings

Use the Structure panel in WAVE to examine regions/landmarks and headings.

• , , , , , , – Review regions or equivalent ARIA landmarks.
  • The page header, main content, footer, navigation areas, and search forms (if present) are identified as regions AND are correctly nested.
  • – Other important regions are identified.
  • - If a region type appears more than once (e.g., more than one <nav>), it can be distinctly labeled using aria-label or aria-labelledby.
• , , , , , – Confirm that headings describe the content that follows. If not, they should not be headings.
  • , – Confirm that there is an <h1> that describes the page content. It should usually be within the <main> region.
  • – If headings skip levels (e.g., <h2> to <h4> with no <h3> in between), identify the correct heading structure.
  • – Headings and regions must not be empty.
• – Search for text that functions as a heading but needs to be tagged <h1> through <h6>.
• – Search for sections that should have headings but do not.

Forms

• , - Ensure form controls have descriptive, correctly-associated labels and that <label> is used when possible.
  • If a form control gains focus or is activated when its label text is clicked with a mouse, then it is likely that the text is a correctly-associated <label>.
• , - If a label is not visible, check for a hidden label, aria-label, or title attribute.
• – If a <select> menu does not have a <label>, confirm that the default option presents the purpose of the menu.
• , , , - Use the Code panel to explore broken labels.
• , , - Look for <fieldset>/<legend> where a higher-level description for a group of form fields is needed.
• Ensure that required fields are visually apparent and are presented to a screen reader through at least one of the following: label/accessible name, aria-required, or the required attribute.
• Trigger form errors and then test error feedback using the WAVE browser extension.
• – Ensure that descriptions and inline error messages are associated to the correct form control using aria-describedby.
• Ensure that redundant entry is avoided. Generally, information that a user must re-enter to complete a single-session process must be auto-populated or available for the user to select.
• Ensure that no cognitive function test is required (such as password or a puzzle) for authentication unless it can be bypassed, or completed with assistance by some other mechanism, or uses object recognition or identification of user-provided non-text content.

Tables

• , , , – Ensure data table row and column headers are defined and given the correct scope attribute value ("col" or "row").
  • Header cells must not be empty.
  • Layout tables must not have headers.
• , - If text describes the table, ensure it is a <caption>.
• – If a table is being used for layout, check reading order. Layout tables are discouraged and will cause problems in responsive layouts and when zooming the page.

Resize Content

• In Chrome, press Ctrl (command on Mac) and:
  • + (= sign) to zoom in (larger)
  • - to zoom out (smaller)
  • 0 to reset to 100%
• Test that the page is readable and that no content is lost up to 200%.
• Adjust the viewport to 1280 pixels wide and then zoom from 100% to 400%. At each zoom level, ensure information is not lost.
  • No horizontal scrolling is allowed unless required for the content—e.g., a data table or map that is wider than the page (WCAG 2.1 requirement).
  • Test that dialogs, accordions, tooltips, and menus are usable at up to 400%.
• Run the Text Spacing Bookmarklet. Ensure no loss of content or functionality occurs when text spacing is adjusted.
• Increase text size to 130-150% (recommended, but not a WCAG requirement) and check for loss of content. In Firefox, choose View > Zoom > Zoom Text Only.

Contrast

• - WAVE identifies text with less than 4.5:1 contrast, or less than 3:1 for “large” text (defined as ≥24px, or ≥18.67px if bold).
  • Use tools in the Contrast panel to see the ratio, find a compliant color combination, and preview this combination in the page.
  • The WebAIM Contrast Checker can also be used to test other color combinations.
• Use the ColorZilla eyedropper or the eyedropper tool in the WAVE sidebar color picker to find the color value in text in images and background colors not detected in WAVE (background images, gradients, transparency).
• Test 3:1 contrast of:
  • graphical objects, such as icons, that are required to understand content.
  • user interface components, including custom form control borders.
  • keyboard focus indicators/outlines.
• Use browser developer tools to test contrast of controls in different states (e.g., :hover).

Color use

• Look for information that is only presented through color.
  • If links are identified using only color (i.e., they are not underlined), use the link contrast checker to verify at least 3:1 contrast between link and body text, and check that there is a non-color change on mouse hover and keyboard focus.
  • If color change is the only identifier of keyboard focus, ensure at least 3:1 contrast between the default state and the focused state.

Links

• – Look for ambiguous link text like "click here." Descriptive links are best, though WCAG allows ambiguous links if the link's description is provided nearby, such as in the same sentence or in a preceding heading.
• – If adjacent links go to the same URL, see if they can be combined into a single link.
• – Investigate same-page links that do not have a valid target.
• – Underlined text should usually be reserved for links.
• Check that links and buttons are used correctly. Links take you to a new page or place and buttons perform an action.

Navigation

• Navigate the page using only the keyboard:
  • Tab: Navigate interactive elements (links, buttons, form controls, etc.).
  • Shift + Tab: Navigate backwards.
  • Enter: Activate links or buttons, submit most forms.
  • Spacebar: Activate checkboxes and buttons, expand a select menu, scroll the window.
  • Arrow keys: Navigate within elements that are one "tab stop" (radio buttons, select/dropdown menus, sliders, tab panels, autocomplete, tree menus, etc.).
  • Esc: Close or collapse.
• Confirm every focusable element is visible and not obscured when navigated to and has a keyboard focus indicator/outline with at least 3:1 contrast.
• Review the keyboard navigation order and ensure it is logical and intuitive. It should generally align with the logical visual order.
  • - Positive tabindex values (e.g., tabindex="1") are never appropriate.
• , - Look for interactions that require a mouse (e.g., rollover menus) or are not intuitive with a keyboard.
  • For tooltips and dialogs that appear on mouse hover and keyboard focus, be sure they stay open when hovering over the new content and that they stay open until dismissed—either with the Esc key or moving off the element.
• Look for interactions that rely on pointer gestures or dragging movements. Ensure that the functionality can also be performed with a single-point activation, such as activating a button.
• Look for interactions triggered by motion actuation, such as shaking or panning a mobile device or waving to a camera. Ensure that these triggers can be disabled and that equivalent functionality is provided via standard controls like buttons.
• Look for events that trigger on "down" events. Unless the interaction falls into a narrow set of exceptions, action must trigger on the "up" event, and the user must be able to abort or undo the action performed.
• , , – Search for a link to skip to the main content. If the "skip" link is hidden, ensure it becomes visible when it receives keyboard focus. Activate it and then hit Tab again to confirm focus is properly set to the main content.
• Check size and spacing of pointer targets. They must be at least 24 × 24 pixels in size unless they meet a narrow set of exceptions.
• If there is a responsive design, test mouse and keyboard accessibility of all views (e.g., mobile menus).

ARIA

• (and all other ARIA icons) - Check for appropriate use of ARIA roles, states, and properties (presented in green text).
• , , – ARIA labels override form <label>s, alt attributes, link text, etc. Use WAVE, browser developer tools, or test in a screen reader to ensure proper accessible name is presented.
• , – Test ARIA widgets with a screen reader and keyboard and ensure they match ARIA design patterns.
  • - Test dialogs, menus, and other things that "pop" open.
    • Focus is set to the dialog when it appears.
    • You can navigate forward and backward with the keyboard within the dialog.
    • Modal dialogs (those that require user action) maintain keyboard focus until dismissed.
    • Non-modal dialogs (those that do not require user action) close when focus leaves the dialog.
    • If a visible "close" button is present, it is keyboard-accessible and properly labeled.
    • Pressing Esc closes the open content.
    • When it closes, focus returns to a logical place.
  • , – Navigate menubars with ←/→ and vertical menus with ↑/↓. Esc collapses menus.
  • – tabindex values of 0 and -1 are used appropriately to manage keyboard focus.
• – Be sure ARIA attributes update correctly when there are dynamic changes.
• – Status messages and other changing content is presented correctly to screen readers.
• Look for elements in need of ARIA (e.g., a collapsible area in need of aria-expanded).
• – Anything hidden with ARIA is either hidden from all users (e.g., display:none) or is redundant AND is not interactive.
• - Make sure ARIA buttons have clear keyboard focus and can be activated with Enter and Spacebar. Consider replacing with a true button (e.g., <button>, <input type="button">).

Other principles

• - Ensure the page <title> describes the page and generally corresponds to the <h1>.
• , – Confirm that the correct language is identified for the page (e.g., <html lang="en">) and for content areas in a different language.
• , , – Confirm that lists are used correctly (<ol> for order or hierarchy, <ul> for parallel/interchangeable items, <dl> for name/value pairs).
  • – Search for text that should be marked up as a list.
• Ensure that Contact and Help links are presented consistently throughout the site.
• – If the title attribute repeats information in the link, button, or image alt text, a screen reader may read this content twice. See if the redundant title text can be removed.
• - Identify pages that time out or refresh without offering a chance to extend the session.
• , , – Ensure multimedia is accessible.
  • Multimedia has captions, and they are equivalent.
  • Audio- or video-only content is transcribed.
  • Important visual content is presented in the default audio or in audio descriptions.
  • Media player controls are keyboard accessible.
• Ensure media and other content cannot cause a seizure.
• , – Check that text is easy to read.