Testing Starter Guide

Accessibility Audit Checklist

To start the testing process, download the Accessibility Audit Checklist spreadsheet. This tool will help you evaluate Keyboard Testing, Visual Testing, and Non-Visual Testing. The second sheet of the spreadsheet contains a detailed starter guide with instructions. Those instructions are replicated on this page as well.

Do you need Help or have Questions?

The OCIO Digital Accessibility team has all the resources to assist you with both Non-Visual and Visual Testing, so please feel free to reach out. If you have any questions or concerns about Accessibility Testing, don’t hesitate to contact us at OCIO.DigitalAccessibility@nebraska.gov or open a request on the Service Portal at https://serviceportal.ne.gov/

Visual Tests

  1. Set your display resolution or browser window to 1280 px wide. This can be done in the developer tools of your browser (Press F12). The height doesn't matter. Then make sure it’s in responsive mode. This is usually a phone icon.

    • The browser for this doesn’t matter. It’s the same across Chrome, Firefox, and Edge to get to the developer tools.

  2. Press left Alt + left Shift + PrtSc (Print Screen). If prompted to turn on High Contrast, click Yes. Windows will activate a theme with a black background, white text, and blue or yellow links. (If High Contrast does not activate, check Windows Control Panel > Ease of Access Center > Make the computer easier to see > Turn on or off High Contrast.)

    • Keep in mind, this setting changes everything in Windows to a high contrast theme, not just your page’s content in a browser.

  3. Change your browser's zoom level to 200% by using the keyboard shortcut CTRL+Plus Sign to increase the zoom level or CTRL+Minus Sign to decrease the zoom level.

  4. Browse to the screen to be tested.

  5. Visually review all elements of the screen except logos, decorative (meaningless) images, or images of text that duplicate text provided elsewhere on the screen. Check for:

    • Text that did not increase in size by 200%. (WCAG 1.4.4)
    • Text that did not take on high-contrast colors. (WCAG 1.4.5)
    • Text that was cut off, overlapped, or otherwise became unreadable. (WCAG 1.4.4)
    • Information that was conveyed by color that is no longer distinguishable by any means. (WCAG 1.4.1)
    • You can have a separate window open for this to test effectively
    • To visually inspect elements in both high contrast and not high contrast, you can toggle high contrast mode as needed.

  6. Press left Alt + left Shift + PrtSc to turn off High Contrast.

  7. By this point, you can decrease the font size back to 100% and end the responsive mode simulation in your browser’s developer tools.

  8. Use a color contrast testing extension or manual checker to measure the contrast of any color combinations except in logos, decorative images, duplicative images, or disabled elements, such as the WebAIM color contrast checker. Check for and document:

    • Regular-sized text with a contrast-ratio less than 4.5:1. Regular-sized text is defined as less than 18pts non-bold and less than 14pts bold. (WCAG 1.4.3)
    • Large text with a contrast-ratio less than 3:1. Large text is defined as 18pts or larger text non-bold and 14pts or larger text bold. (WCAG 1.4.3)
    • User interface components (e.g., links, buttons, etc.) or graphics (e.g., icons, charts, etc.) with a contrast ratio less than 3:1 (WCAG 1.4.11)

  9. If any of the issues listed above are found, report a failure. In the report, clearly identify the element involved, which check it failed, and any steps required to reproduce the failure.

  10. For color contrast failures, clearly identify the element(s) and include the hexadecimal color codes of the foreground and background colors, the computed color contrast ratio, the required contrast ratio (4.5:1 or 3:1), and, if possible, a color that would meet the requirement, e.g., "Links are light blue (#6699DD) on white (#FFFFFF) with a contrast ratio of 2.9:1. The text should be darkened to meet the minimum of 4.5:1 (e.g. #4477BB)."

Keyboard Tests

Keyboard testing is performed using standard keyboard commands only – a mouse must not be used. Keyboard testing should be performed by doing the following on each page/screen:

  1. Browse to the screen to be tested.

  2. Explore the screen with the mouse to identify and determine the function of all interactive elements.

  3. Click in the browser address bar and press enter to reload the page; then set the mouse aside.

  4. If necessary, press the Tab key several times to move focus past any browser toolbars and into the page.

  5. Once focus is in the page, use the following keyboard commands to move to and operate all interactive elements:

    • Tab - Move to the next interactive element.
    • Shift + Tab - Move backwards to the previous interactive element (when needed).
    • Up or Down Arrow - Move vertically through items in a dropdown, list box, or radio button group. This will only work if the element is focusable and focused.
    • Spacebar or Enter - Check a checkbox, open a drop-down menu, or click a button. This will only work if the element is focused.
    • Enter -Click a link.
    • Other - For any other controls, look up the Keyboard Interactions in the ARIA Authoring Practices Guide (APG)  (https://www.w3.org/WAI/ARIA/apg/patterns )

  6. At each step, check for and document any:

    • Interactive elements that do not receive keyboard focus. (WCAG 2.1.1)
    • Elements that do not show a visual indicator (e.g., outline) when focused. (WCAG 2.4.7)
    • Elements that do not receive Sfocus in a logical order (e.g., left to right, top to bottom). (WCAG 2.4.3)
    • Elements that cause unexpected changes (e.g., reload the page) when they receive focus. (WCAG 3.2.1)
    • Elements that cannot be operated using standard keyboard commands. (WCAG 2.1.1)
    • Elements that cause unexpected changes when values are changed. (WCAG 3.2.2)
    • Elements that trap focus (i.e., prevent focus from moving to the next element). (WCAG 2.1.2)
    • There is an important exception here: If the element that the user’s focus is within is a modal, keyboard focus should not leave it until the modal is dismissed with the Esc key, or an action is taken to explicitly close the modal, such as a save or close button

  7. If any of the issues listed above are found, report a failure. In the report, clearly identify the element involved, which check failed, and any steps required to reproduce the failure.

Non-visual Tests:

Testing Non-visual Quick Start

  1. Turn on your screen reader of choice (NVDA or Narrator)

  2. Open Edge, Firefox and Chrome, and open the page that you want to test in each browser.

  3. Press the graphics quick navigation key (G) to determine which images are discoverable using the screen reader.

    • Note any images that don’t have alt text, causing the screen reader to read off the file name of the image, or just read “image”

  4. If there is an image that is meant to be purely decorative and it gets announced by the screen reader, apply an empty alt attribute to it.

  5. Ensure any charts on the page have a clear description of the data presented.

  6. Tab through the page with the Tab key or Shift+Tab to go through the interactive elements on the page.

    • Note any interactive elements that are supposed to be in the tab order, but are not.

  7. Note any interactive elements with no or unclear titles or labels

  8. Make sure the “Skip to Content” or “Skip to Main Content” link is the first focusable element on the page

  9. Use the form elements quick navigation key (F) to traverse the form elements on the page.

    • Note any element that is a form element like buttons, text fields, radio buttons, checkboxes, etc that were announced when going through by interactive element, but not when going through by form element.
    • This likely indicates that a role or other aria attribute was not properly applied.
    • It could also indicate that the element is inside another element that is hidden from screen readers using the aria-hidden attribute.

  10. Ensure that any interactive elements can be operated solely using the keyboard. This includes the space or enter keys for activating links, buttons, and checkboxes, the arrow keys to change the selected radio button in a radio group or dropdown, etc. For more, please refer to the ARIA Authoring Practices.

  11. Go through the page by heading to make sure that headings aren’t being used for style instead of for structure.

    • Note instances where headings aren’t used solely for structure.

  12. Make sure that proper landmark elements or proper landmark roles are used, such as main, header, nav, section, footer, etc.

  13. The link in the navigation, footer, etc., for the current page should have the aria-current=”page” attribute applied to indicate to the user the current page in a group of related links.

  14. The container for the image or other element indicating the current step in a multi-step flow should have the aria-current=”step” attribute applied to indicate to the user which step is the current one.

  15. Ensure that any video content has a transcript or audio description