Skip to Main Content

Simple Accessibility Tests

Additional resources:

There are a number of quick tests that may be performed to obtain an estimate of a web page’s level of accessibility support. Here are a few suggestions for performing a quick and simple accessibility test. Try first disconnecting the mouse - that way you will not be tempted!

  • Can you use the tab-key to navigate to hyperlinks, form fields, and buttons?
  • Can you activate hyperlinks with the Return/Enter key?
  • Can you activate all buttons with the space bar or Enter/Return key?
  • Do the videos have captions?
  • If you click on a form field label, does focus become set in that form field? 

If you can answer Yes to these questions, then the web page has a basic level of accessibility. Testing with assistive technology or finding individuals who use assistive technology to provide feedback may give you additional insights as to how to improve the usability of the page design.

Manual Testing Procedures

MS Word (DOCX) Version

Manual testing evaluates a website/web-application using a combination of keyboard-only interactions, assistive computer technologies, and web browser plug-ins to determine the functional accessibility of the site. Automated accessibility testing cannot capture all potential accessibility issues, whereas manual testing can identify those accessibility issues missed by automated testing alone. Manual testing is appropriate for development environments, production sites, or sites requiring user authentication and may be appropriate for the following site content:

  • Website templates
  • Content pages
  • Interactive forms
  • Dynamic content pages and transactions
  • Dialog modals, Lightboxes, carousels, and alerts
  • Entry and exit pages (e.g., account login and recovery pages)
  • Help and assistance pages

Site analytics, such as Google Analytics, is another strategy for identifying pages to evaluate manually. Pages receiving a significant amount of traffic should be prioritized for both automated and manual evaluations. For higher education institutions, manual checks should be conducted for the following site content regardless of website analytics:

  • Course registration pages
  • Counseling
  • Disability services
  • Financial aid
  • Health services
  • Wi-fi sign-on/access pages (if applicable)
  • Library access and printing stations (if applicable)

Common Content Issues

Verify the following:

  1. Identify the presence of page titles. Page titles should be unique as appropriate to the page content and/or task.
  2. A “Skip Navigation” solution is present for pages with repeated navigational elements.
  3. Web pages are organized using appropriate HTML5 elements and/or WAI-ARIA landmarks (e.g., role=”main”, role=”navigation", etc.) – Desirable, not required.
  4. Identify the use of headings. Headings should be sequential, with at least one H1 element on the page.
  5. Information is marked using appropriate semantic structure (headings, lists, paragraphs, tables, etc.). Data tables contain appropriate row and column structural markup.
  6. Form input fields have an explicit label. Instructions and/or formatting instructions are programmatically associated with the respective input field.
  7. Alternate text is provided for all images. Alternate text describes the content and/or purpose of the image.
  8. Hyperlinks provide descriptive link text or are associated with descriptive text.
  9. Videos have captions.
  10. Text and images (except logos) meet color contrast requirements of 4.5:1.
  11. Page content is still perceivable when Windows High Contrast Mode is enabled.

Common Interaction Issues

Verify the following:

  1. The page can be zoomed to 200% with no loss of functionality. Content and interactive elements must not be obscured.
  2. All form elements, buttons, hyperlinks, and menus can be navigated in sequential order using the keyboard (i.e., tab-key).
  3. Modal dialog windows can be dismissed using the Esc key.
  4. Modal dialog windows receive focus to the first form input (if present) or a cancel/confirm button when opened.
  5. Modal dialog windows will trap keyboard navigation.
  6. Any video player controls (e.g., play/pause, volume, etc.) can be operable from the keyboard and are functional with screen-readers.
  7. Any time-out interactions allow at least 60 seconds for the user to modify or extend the interaction time period using a simple keypress.
  8. Dynamic elements and informational alerts communicate updates to screen-reader applications (e.g., via aria-live region).
  9. Browser focus is visible when navigating interactive elements. If browser focus is controlled by CSS, then the focus is visible and distinguishable (must also meet color contrast requirements).
  10. If a form contains input validation, the errors are identified, instructions are provided, and focus is directed back to the invalid input field.