Manual Testing Checklists for Non-UIS-Themed Websites

These checklists are for non-UIS-themed websites. If you’re using a UIS theme, you don’t need to worry about this checklist (because Web Services takes care of these things!), but there are other accessibility checklists available.

To be AA-compliant, all of the below checklist items should pass on the latest version of the four major browsers: Chrome, Firefox, Safari, and Edge.

Keyboard Navigability

As soon as you load a page, start tabbing through the elements on the page and test for the following things:

  • Tab order
    You can tab through items from left to right, top to bottom.
  • Tab ability
    You should be able to tab through the entire page, without getting stuck.
  • Focus outline
    All focused items are outlined and the outline is obviously visible (i.e. the outline should contrast well with the background).
  • Focused element
    The focused item should be visible.
  • Skip links
    Skip links exist and are visible when they have focus. Usually, skip links will be the first tabbable element on the page.
  • Off-canvas navigation
    If there is an off-canvas navigation panel, you should be able to open the navigation, tab through the links inside of it, and close the navigation all with the keyboard.
  • Hover navigation (mega menu)
    If there are navigation menus that a mouse user would see on hover, then you should be able to see the navigation by pressing the down arrow, tab through the links inside of that panel, and exit the navigation by pressing the up arrow.
  • Keyboard Accessibility resources from WebAIM

Screen reader readability

Turn on your screen reader of choice. Have the reader read through the page sequentially and test for the following things:

  • All content is read
    The screen reader should not get stuck at any point.
  • Hidden content is not read
    For example, the off-canvas navigation or a hidden search form should only be read by the screen reader when that element is actually visible on the page.
  • The content that is read makes sense
    The biggest issues here are things like phone numbers, dates, abbreviations in general.


Pull up the list of landmarks in the screen reader and test for the following things:

  • Landmarks exist
    All content on the page must be inside of a landmark container. Therefore, unless there is nothing on the page, at least one landmark must exist.
  • Existing landmarks have roles that make sense for their content
    For example, a sidebar should have a complementary role, the main content of the page should have a main role, any navigation list should have a navigation role, etc. If this is not the case, a more appropriate landmark role should be used.
  • Redundant landmarks have labels
    It is OK for a unique landmark to not have a label. However, if there is more than one of any given landmark role on the page, all of those landmarks must have labels.
  • Landmark labels are unique and make sense
    It doesn’t help anyone to have two landmarks with the same label, especially if they are of the same role. Also, landmark labels should effectively describe the content inside of their landmark.

Look at the page’s source code and test for the following things:

  • All content on the page is inside a landmark role
    All means all – header logo, skip links, off-canvas navigation… everything.
  • Is there any content that should be put into a new landmark?
    There could be some complementary content inside the main content or a header inside a section.
  • Landmarks are using the HTML5 semantic tags, not the role attribute
    While the role attribute works, it is better form to use the HTML5 semantic tags for landmarks because it involves less code.
Landmark roles and HTML5
HTML5 tag Role
<header> banner
<nav> navigation
<main> main
<aside> complementary
<section> region
<article> article
<footer> contentinfo
<form> form