Basic Checklist for UIS Drupal Editors
Every time you publish a page, use this checklist to verify that your page is accessible.
- Check every image on the page for descriptive alternative text. More help with alternative text.
- Check your buttons and links – is the link text descriptive enough? More help with descriptive link text.
- Open the page in Chrome and click the Siteimprove Chrome Browser Extension button (you'll have to install the extension before you can use it). Use the Siteimprove Issues Guide to fix any A- and AA-level errors and warnings.
Not sure if you're on a UIS Drupal template?
Add "/saml_login" to your site URL (e.g. uis.georgetown.edu/saml_login). If you see the Georgetown University netID login screen, you're on a UIS Drupal template!
All of the below checklist items should pass on the latest version of the four major browsers: Chrome, Firefox, Safari, and Edge.
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
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.