Skip to Main Content

Automated & Manual Accessibility Testing

Accessibility testing should involve a combination of automated tests and manual evaluations in order to assess the technical and functional accessibility of a website. For example, while automated tests can identify if there is an accessibility violation at a technical level (e.g., missing alternate text for images), such automated tests cannot accurately assess the quality of the alternate text when such information is included. Evaluating a website for accessibility requires attention to both automated and manual accessibility tests in order to ensure all individuals have the opportunity to engage with the information.

 

Automated Testing

Automated tests may include the use of site-wide accessibility tools or web browser testing tools to evaluate the technical accessibility issues of a website or web-application. Automated testing should be performed during the development process and outstanding issues should be resolved prior to manual testing.

Accessibility Monitoring

Automated accessibility monitoring provides large-scale assessments by scanning and reporting on potential accessibility issues of a website. Although scanning tools are limited in the types of accessibility issues they can evaluate, such tools can identify problematic areas of a website that may warrant further attention. The CCC Technology Center has acquired a license for the Tenon accessibility evaluation solution and is available to colleges to monitor public-facing websites for accessibility issues.

 

Manual Testing

Manual testing evaluates a website/web-application using a combination of keyboard-only interactions, assistive computer technologies, and web browser plug-ins to ascertain the functional accessibility of the site. While it is not feasible to manually test every single page of large website, focusing where manual tests are applied can streamline the evaluation process. For example, manual accessibility testing could be performed on the following main types of pages:

  • Site templates
  • Representational content pages
  • Interactive forms
  • Dynamic content pages
  • Dialog modals and alerts
  • Key entry and exit pages (including account login and recovery pages)
  • Help and assistance pages

Another idea is to use website analytics to identify the pages that receive the most visits and traffic and prioritize that content for manual accessibility testing. This can aid in remediating the pages that site visitors use most often.

Common Content Issues

The following items should be checked manually to ensure the content is accessible to all visitors:

  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 and WAI-ARIA elements (e.g., role=”main”, role=”contentinfo”, etc.). Not required, but a best practice.
  4. Identify the use of headings. Headings should be sequential, starting with h1.
  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 input details are programmatically associated with the respective form field.
  7. Alternate text is provided for all images. Alternate text describes the content and/or purpose of the image.
  8. Hyperlinks offer descriptive link text or are associated with descriptive link text.
  9. Videos have captions.
  10. Text and images (except logos) meet color contrast requirements of 4.5:1 (foreground/background).
  11. Page content is still perceivable when Windows High Contrast Mode is enabled.

Common Interaction Issues

The following items should be checked manually to ensure interactive aspects of the site are accessible to all visitors:

  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 (e.g., tab-key).
  3. Browser focus is visible when navigating interactive elements. If browser focus is controlled by CSS, then focus is visible and distinguishable (still must meet color contrast requirements).
  4. Modal dialog windows can be dismissed using the Esc key.
  5. Modal dialog windows receive focus to the first form input (if present) or a cancel/confirm button when opened.
  6. Modal dialog windows will trap keyboard navigation.
  7. Any video player controls (e.g., play/pause, volume, etc.) can be operable from the keyboard and are functional with screen-readers.
  8. Any time-out interactions allow at least 60 seconds for the user to modify or extend the interaction time period using a simple keypress.
  9. Dynamic elements and informational alerts communicate updates to screen-reader applications (e.g., via aria-live region).
  10. If a form contains input validation, the errors are identified and focus is directed back to the invalid input field.