Editor’s note: This is the second article in our series “WCAG 2.1 – Improving Digital Accessibility”. Missed the first installment? Read it in the March Newsletter: Improving Navigation Menus and Focus Indicators. Subscribe to be sure you get each installment in this series! (The link is at the bottom of this page.)

This month, we talked with John Watne, the accessibility coordinator for Minnesota IT Services partnering with the Minnesota Department of Revenue. We asked John about beginning the work to meet WCAG 2.1. This article shares specifically about his experiences with the success criterion for:

• 1.4.13 Content on Hover or Focus (AA):
  • “Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true…” 
  • The success criterion goes on to describe the specifics of being dismissible, hoverable, and persistent. 
  • It also describes an exception.
• 4.1.3 Status Messages (AA):
  • “In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.”  

The following are some questions we asked John about his work to improve the digital accessibility for Department of Revenue websites. 

Content on Hover or Focus (AA)

What kinds of content appeared in your application on hover?

Several of our web applications use a Bootstrap Select Picker to implement a drop-down selector for certain items. Each item in the list of choices has both a value and a matching label. The value displays in the list. The matching title contains the same text as what appears in a pop-up for the item on hover. This happens when hovering on the field with the selected value(s) displayed.

The hover text is dismissible by pressing the <Esc> key, or by moving the mouse off the choice. 

Did your team use specific methods to find existing content to update? How are you testing to ensure you meet 1.4.13?

When updating a web page, we:

• Run it through multiple automated accessibility checkers, 
• Review any errors or warnings, and 
• Correct confirmed violations of WCAG 2.1 at level AA compliance.

• Checking in our changes to our version control system.
• Requesting a code review. 
• Pulling those changes into the main code branch.

As part of the code review, we check that any changes are consistent with how we have written similar bits of code in the past. We also verify that code items such as labels are meaningful, correct, and clear for the intended audience.

We use the following three Google Chrome plug-ins to check the accessibility of the pages we work on. Each has their own strengths and may capture errors that one or more of the others do not:

• WebAIM.org’s WAVE web accessibility evaluation tool browser plugin.
• Microsoft’s Accessibility Insights for Web browser plugin. 
• Deque’s Axe Accessibility Testing Chrome extension. 

Status Messages (AA)

What considerations did the team have when considering status messages?

There are status messages in most, if not all, of our web applications. Many of them, such as Audit Room, allow filtering or searching for specific values in a table with potentially thousands of rows of data. The number of results displays near the updated filtered table.

Several other actions produce dismissible alerts. These indicate either success or failure of the action. Some example alerts include:

• The Member List export file will be emailed to you. 
• New room member John Smith was successfully invited.
• Room DEV-jwatne-autowired-discussion was successfully updated.
• This room member already exists. [example of an error message]

Did you add specific steps to plan and meet the success criteria? How did you test to validate the status messages met 2.1?

We used the same testing and correction process as for 1.4.13. Several people work together to decide the text of the alerts:

• The developers draft the alert text.
• The business owner requests changes or enhancements to the application, based on feedback from the users.
• The Department of Revenue’s Communications department is largely responsible for ensuring Revenue’s clear language requirements.