Introduction
Fortunately, there are plenty of accessibility tools that make it easy to understand potential accessibility issues. But, sometimes, the only way to tell if accessibility has been properly implemented is to conduct an inspection of the HTML that comprises a web page. While performing a code inspection may sound like a daunting project for a tester, the process can be quick and easy. Like a good anaesthetic, this guide hopefully minimizes any discomfort associated with this operation.
Accessing the Developer Tools
In general, the developer tools in Google Chrome and Microsoft Edge seem to work the best. We’ve already described how to access the developer tools in Microsoft Edge. The screenshot below shows how to do it in Google Chrome. First, you access the menu at the upper-right corner of the screen (it’s the icon with the three dots). Next, you select “More Tools” in the menu. Finally, you select “Developer Tools” in the submenu.
This opens the Developer Tools panel which is shown in the next screenshot. By default, this panel is located on the right side of the content on the screen. The most important tool here is the “selector”, which is located in the upper-left portion of the Developer Tools panel. It looks like a tiny screen with a arrow on it.
We’ve talked about this selector before. In a nutshell, you can hover over and click on portions of the screen– and the corresponding element in the HTML is immediately highlighted in the Developer Tools panel on the right. Just by hovering over elements, you can also get useful information– just as we used exactly this strategy when assessing color contrast from the Developer Tools.
One other handy feature of the Developer Tools is the search tool. By hitting control-F (command-F on MacOS), Chrome pops up a search input field in the Developer Tools panel. In the screenshot below, we are using this search tool to look for unordered list items (coded as “<ul>”) and the up and down arrows let us rapidly move through the 13 reported instances of unordered list items. Then, clicking on the line of code in the Developer Tools panel will highlight that element in the page content on the left.
When to Perform a Code Inspection
Fortunately, there are only a few times that a code inspection is needed. We’ll now quickly run through a few scenarios.
Verify Pages Don’t Use Preformatted Text or White Space for Formatting
Core Concept 1.3.2.2 (Do Not Use Whitespace Inappropriately) prohibits developers and designers from using whitespace inappropriately. Two ways that developers can do this can be quickly spotted by using the search tool in the Developer Tools panel. Just search for the following in the HTML code:
- <PRE>
-
Normally, two or more space characters in HTML are ignored and treated like a single space character. The <pre> element changes this behavior and extra spaces here get shown as spaces on the screen. This lets developers create formatted structures like tables for visual users that are inaccessible to screen reader users. Similarly, the non-breaking white space character ( ) can do the same thing if repeated. So if you see multiple characters in a row, there’s a good chance that the developer is using whitespace inappropriately.
Verifying Pointer Cancellation
One of trickier new requirements in WCAG 2.1 is Success Criteria 2.5.2 (Pointer Cancellation). When a user clicks their mouse on a standard HTML control (such as a button), they can cancel that event by moving off the button and releasing the mouse. Most common event handlers (e.g. onclick()) follow this behavior. There are, however, three event handlers that behave differently. Specifically,
- onKeyDown()
- onKeyPress()
- onMouseDown()
all react to the pressing a key or pointer down.
For purposes of Core Concept 2.5.2.1 (Pointer Cancellation), our focus is on the pointer device only. Therefore, if you encounter onMouseDown() in your source HTML, there is a good chance that pointer cancellation may be a problem. Therefore, a useful test process to verify that you have met Core Concept 2.5.2.1 (Pointer Cancellation) is to follow this procedure.
- Open Developer Tools panel.
- Search for “mousedown”.
- If you find any elements in the Developer Panel that uses this event handler, click on the element in the Developer Panel to highlight the content on the page.
- Click on the content or trigger it with a mouse press– then, while still holding down the mouse, verify that the content can be reversed or canceled (e.g. by moving away from the control when raising the mouse).
- If it is not essential that pressing down must trigger the event and the functionality cannot be reversed or canceled, content fails.
Verifying Character Key Shortcuts
As noted immediately above, the “keydown” and “keypress” react to pressing down on a key on the keyboard. Core Concept 2.1.4.1 (Character Key Shortcuts) is closely related to Core Concept 2.5.2.1 (Pointer Cancellation) but, instead of being concerned with the type of event (down versus up), Core Concept 2.1.4.1 focuses on whether a printable letter key is pressed at all. So, another event (“keyup”) will also be triggered if a single letter key is pressed. Therefore, if you encounter keydown, keypress, or keyup in your source HTML, there is a good chance that character key shortcuts may be a problem. Therefore, a useful test process to verify that you have met Core Concept 2.1.4.1 (Character Key Shortcuts) is to follow this procedure.
- Open Developer Tools panel.
- Search for “keydown”, “keypress”, and “keyup”.
- If you find any elements in the Developer Panel that uses one of these event handlers, click on the element in the Developer Panel to highlight the content on the page.
- Press the specific character that triggers the event and the event cannot be either disabled or remapped, page fails.