Why test for accessibility?
Roughly 20% of the U.S. population live with a disability. Thus, accessibility is the removal of technological barriers to access for persons with disabilities. When it comes to testing content for accessibility, we are primarily concerned with disabilities related to the eyes, ears, hands and brain.
The benefits of producing accessible content include:
- Improved experiences for all users
- Improved public perception
- Greater impact and reach to a wider audience
- As accessibility is a civil right, it helps avoid legal action
This non-comprehensive article will provide accessibility considerations with respect to two distinct user groups: keyboard and screen reader reliant users.
Keyboard users are typically sighted, have a mobility impairment and interact with web pages without the use of a mouse. In this case, it is important to ensure that all content and interactive components are keyboard accessible/operable.
Screen readers allow blind and visually impaired individuals to access content independently by outputting the contents of the screen to speech. Popular screen readers include JAWS, NVDA and VoiceOver (Mac and iOS only). For most, NVDA remains the screen reader of choice for accessibility testing.
Important keyboard shortcuts for keyboard testing
TAB: Navigate to links and form controls (e.g., input field).
SHIFT + TAB: Navigate backwards.
ENTER: Activate links and buttons.
SPACEBAR: Activate checkboxes and buttons.
ARROW KEYS: Radio buttons, select/dropdown menus, sliders, tab panels, autocomplete, tree menus, etc.
Keyboard Testing Check Points
- Using only the keyboard, are you able to tab to all interactive content? This includes links and form controls. It is expected that non-interactive content (e.g., headings, text) should not be keyboard-focusable.
- Is anything mouse-only (e.g., tooltips on hover)?
- Is the order of content logical and intuitive?
- Can you reach all elements/regions/components on the webpage using only a keyboard?
- Is there sufficient focus to indicate the currently selected element?
- Is there sufficient color contrast between text and the background?
Screen Reader Testing
Important keyboard shortcuts for screen reader testing (using NVDA)
Note that all of the above keyboard shortcuts apply for screen reader users as well.
CONTROL: Stop speaking.
CAPS LOCK + Q: Quit NVDA.
CAPS LOCK + S: Cycle through speech modes (talk, beep and speech off but NVDA still running).
TAB: Navigate to next focusable item.
H/SHIFT+H: Navigate to next heading, previous heading.
F/SHIFT+F: Navigate to next form, previous form.
T/SHIFT+T: Navigate to next table, previous table.
B/SHIFT+B: Navigate to next button, previous button.
L/SHIFT+L: Navigate to next list, previous list.
Screen Reader Testing Checkpoints
- Is there a unique page title for every page? This is important because it is the first thing a screen reader user hears. If two pages share the same name, a screen reader reliant user must navigate the entire page to find out more about that page (hence the use of brief, unique and descriptive page titles).
- Conveying meaning
- Is color being used to convey meaning? (e.g., aClick on the red rectanglea).
- Is meaning conveyed in a visual manner only? As a rule of thumb, itas best to avoid referencing color, size, location, position and shape in instructions or help information. If you must, youall also want an alternative method of communicating that information to non-visual users.
- Are images provided with descriptive and meaningful alternative text?
- Are link destinations clear with good link text? (e.g., aClick herea is ambiguous and does not explain the destination or purpose of the link).
- Does the website have a heading structure? Headings are important because they provide an outline of the page and are structural landmarks for screen reader reliant users. Using NVDA, you can navigate by heading using the aHa key.
- For data tables, is there an association between table cells and the headers? Providing this explicit relationship between header cells and data cells ensures that the table structure and its information is properly conveyed to screen reader reliant users.
- Are form elements labeled and clear as to their purpose? (e.g., a aFirst Namea text field is labelled as such).
- Charts and graphics: do they have titles? Are there alternative methods of presenting this information if it is only presented visually?
- Dynamic content
- If regions of the page are changing, such as with dynamic content, are these being communicated to screen reader reliant users?
- If an error message or dialog box appears, is this being communicated to screen reader reliant users? In general, are changes in the state of dynamic content communicated to screen reader reliant users (e.g., A user would expect to activate a button element by pressing ENTER or SPACE, is this true).
The following are various resources to assist with accessibility testing:
- The aFocus Highlighta NVDA plugin allows sighted users to visually see the element that is currently being read/interacted with. For more information on this, and general screen reader testing visit the Web Aim article on testing with the NVDA screen reader.
- WebAIM has a more comprehensive quick start guide of shortcuts.
- The Ohio State Accessible Classroom Technologies Wiki (ACT Wiki) also has great information on accessibility assessments/evaluations. Youall also find a plethora of information accessibility including captioning, designing accessible content and much more.
- WebAIMas color contrast analyzer checks to see your color choices to ensure they are within web content accessibility guidelines.
- The WAVE automatic accessibility checking tool can provide a general report of accessibility problems. Please note that this tool does not provide a comprehensive accessibility assessment and should only be used a starting point.
Questions? Email ODEEaccessibility@osu.edu