Tips for accessibility testing
If your company is just starting to embrace accessibility, this may be helpful to get them on-board with the changes that need to be made and understand how to make the changes. This is not an in-depth analysis, but these are notes that were helpful to me when I was learning accessibility, and I hope that they will be helpful for UXers and others just getting into accessibility testing. Remember that the best way to test whether your application is accessible is to completely turn off your monitor, and you should always test with someone with the actual disability you are solving for when at all possible.
After performing keyboard and JAWS screen reader testing on several applications, I shared the results with each team by taking them through each page, explaning what a keyboard user couldn’t get to, then I did the same with a screen reader user, explaining what this user’s experience was in navigating the screens, understanding the gist of each page, and performing tasks. The team really appreciated the in-depth explanations, as it helped them articulate why something needed to be done, making it part of their story (that’s a link to my blog post about storytelling, sketching, and digging for information in unexpected places to make a great user experience). I also prepared screenshots of each of the pages, with red callouts detailing the most important issues, and orange detailing the moderate issues. This gave the team a visual to share with the members of the team who were not in the accessibility review meeting.
Many issues can be fixed by proper coding and usage of CSS properties and ARIA, as will be detailed.
Screen reader users have no indication which tab or sidetab is currently selected. Both the main nav and the sidebar are read as lists. “List has 5 items: Home link, Blah link, Blah link….list end”. To solve this, add ARIA attribute aria-selected=true to indicate which item is currently selected, in combination with a role, such as: role=menuitem aria-selected=true;
Subnavigation (menu drop-downs)
There is no indication to either keyboard or screen reader users that there are any items under each of the main tabs. Keyboard users should be able to use the down arrow to show the menu items, while screen reader users need hidden text added to these menus using the CSS Clip technique:
position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
A fairly modern technique of using CSS to hide or clip content that does not fit into a 1 pixel visible area will essentially hide the content visibly, but still allow it to be read by modern screen readers is detailed at http://webaim.org/techniques/css/invisiblecontent/. More information on describing hidden menus using ARIA: http://www.w3.org/TR/wai-aria-practices/#menubutton.
Screen reader users need a clearly coded header. Starting the main content area with a list of toolbar buttons doesn’t help them at all! Add page titles above toolbar buttons to provide contextual information to screen reader users on the content being read.
Headers need to be defined on main pages and dialogs using H1-H2 coding, so that screen reader users can use the H command to understand the gist of the page, as it just reads “This page has no headers”. For a long page with many headers and tables, this is impossible for screen reader users to get the gist of the page.
All icons must receive focus and be part of the tab index, as well as having alt-text so that the meaning of the icon is clear to those who cannot see it.
Feedback must be provided in a way other than just a visual indication. For example, if a new object is created, modified, or deleted, just showing the new/modified item or the lack of the item in the table does not help screen reader users, as this is not announced by the screen reader, thus they cannot “see” these changes. To resolve this:
- Add ARIA attributes to indicate when a button has been pressed:
2. Give an ARIA alert role to a message of successful or unsuccessful change:
Any alert dialogs or error messages must be read to a screen reader so that the user can react and fix the problem. If errors only display visually, they are not read to the screen reader user, who thus has no idea an error has occurred. If multiple errors have occurred, provide all errors at once and provide jump links to problem fields so that screen reader users do not have to try to keep all of that information in their heads, which is difficult for anyone! Errors must also indicate the field name, which makes it particularly difficult for screen reader users. For someone who can only hear the error and cannot see any visual indicators, “An error has occurred.” isn’t helpful at all.
- Add jump links for long forms
- Display all fields causing errors
- Make sure to include field names in the error
- If a field has an invalid value, explain how the user can fix it. Invalid value could mean anything, but letting the user know that no spaces are allowed in an ID field allows them to quickly fix the problem.
- Set aria-live=”assertive”. Be sure to check any browser discrepancies
There is some browser discrepancy in dealing with the assertive setting, as detailed in https://www.paciellogroup.com/blog/2012/06/html5-accessibility-chops-aria-rolealert-browser-support/
Tables must be properly coded so that header and data rows are all seen as part of one table by the screen reader.
Pagination and refresh icons
Pagination controls and refresh button must have alt text and be focusable so that keyboard and screen reader users can access them. Text-based pagination < 1 2 3 4 … 10 > works much better than images for pagination arrows, which is no longer the industry standard.
Dialogs must be coded such that they are announced, the dialog header and text within them is read, and all buttons and links, including the close button are announced and focusable. Nothing is worse that a dialog that a keyboard or screen reader user cannot close because the close button is not focusable! If there are fields in the dialog, ensure that the screen reader user can tab to get to each of them. Ensure that the dialog title uses H1-H2 coding, so that screen reader users can use the H command to understand the gist of the page.
- Code the dialog title and headers as H1-H2.
- Make the rest of the dialog focusable, as well as any buttons, links, and fields.
- Create a focusable element inside the dialog and set its role=document. This will allow the screen reader to perceive the content of a dialog as a normal web page. Move the focus back to the the last focus point (generally the button that launched the dialog) in the application when it is closed. (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_dialog_role)
If an asterisk is used to indicate a required field, as is the current norm, a screen reader user hears “First name edit star, Last name edit star, Email edit star”, for example. Because the form is read quickly, it is easy to miss these required indicators. To fix this, add ‘required’ to the input control to let the screen reader know the field must be filled out: Username: <input type=”text” name=”username” required> (http://www.w3schools.com/tags/att_input_required.asp)
Moving the required indicator to the right of the field label itself is ideal, as “First name star edit” creates a closer relationship in the user’s mind that the field is required.
Calendar controls and date field format
Calendar controls should be to the right of date fields, and you should ensure that the display of the calendar does not obscure other fields on the form. Here, you must check for browser discrepancies, as in IE and Firefox, a calendar can obscure the field below, while in Chrome, the calendar can obscure the field above. To fix this, use a jQuery calendar control, as it is accessible, and allows navigation within the calendar control using the following keyboard keys and key combinations. While the datepicker is open, the screen reader or keyboard user should be able to use these controls (http://api.jqueryui.com/datepicker/ (see Keyboard Interaction):
- PAGE UP: Move to the previous month.
- PAGE DOWN: Move to the next month.
- CTRL + PAGE UP: Move to the previous year.
- CTRL + PAGE DOWN: Move to the next year.
- CTRL + HOME: Open the datepicker if closed.
- CTRL/COMMAND + HOME: Move to the current month.
- CTRL/COMMAND + LEFT: Move to the previous day.
- CTRL/COMMAND + RIGHT: Move to the next day.
- CTRL/COMMAND + UP: Move to the previous week.
- CTRL/COMMAND + DOWN: Move the next week.
- ENTER: Select the focused date.
- CTRL/COMMAND + END: Close the datepicker and erase the date.
- ESCAPE: Close the datepicker without selection.
In addition to the calendar behavior, try to have forgiving date format, and change to the the expected standard if you know the user’s time zone (US is mm-dd-yyyy, while dd.mm.yyyy is the EU standard).
Results per page drop-down
Make sure that there is a label on the Results per page drop-down to provide context to screen reader users as to what the drop-down is.
Does not use CSS to space elements, so screen reader users hear “blank”s between a table and the buttons, or between a form and the buttons.
Displaying x to y of z items
For non-lazy loading displays, displaying the indicator of how many items are in the table and how many total items exist above the table would provide this contextual information in the beginning so that the screen reader user doesn’t have to read through the entire table first.