Versions tested: various; latest: 2.20.0
Google Accessibility Developer Tools — henceforth abbreviated GADT — is an extension for Google Chrome/Chromium, which plugs into the built-in developer tools, which in turn are normally triggered through the inspect element context menu. It is not a standalone sub-feature of the developer tools, but instead integrates well with the existing tools, namely the Audits tab. By default, as of Chromium version 39, the other available audits are Network Utilization and Web Page Performance.
This extension does not download resources on its own, thus saving bandwidth for the tested servers. It is unfortunately severely limited in scope.
This tool is capable of performing the following 17 tests:
As such, it appears to be a student project, or a beginning of one, even though it is branded by Google, the largest Internet company in the world. Furthermore, since ARIA is not used on the net, and most of its guidelines are obsoleted by HTML5, the usefulness of this tool is severely limited. Since this tool is so limited, it does not make sense to point out what it doesn't support, given the list above. It can only be evaluated per said list, but nonetheless, it does have its quirks even then, and oddities which will be described in detail in subsequent sections.
The primary mode of operation for GADT is through the Audits tab in the developer tools sidebar (also positionable at the bottom of the page). Counterintuitively, the position of the sidebar actually matters, as it influences what is being reported; more on which later. Once the page is loaded, the 'Audits' button must be activated in the panel, which presents the HTML auto-generated audits selector webui. There are two options:
The latter, intended for audits of dynamic changes, never completes. The first one works fine. However, once the audit runs and the results are analyzed, one must return to the webui selector by clicking the 'audits' button again. Errors and warnings are presented in the form of a collapsible unordered list, which in addition to failures also mentions non-applicable and passed tests — out of the 17 covered. Each failure is accompanied by a link to the reference on Github (where the definitions are stored), and a list of offending code snippets. Unfortunately, these snippets are not clickable, nor do they open the integrated source analyzer (Elements tab). The only way to refer the snippet to the document is to hover each snippet, and observe indicator pop-ups on the page itself. Most of the time, the relevant element or block will not be visible on the page, necessitating multiple runs of hover, inspect, scroll. Very cumbersome.
The reports clobber the sidebar of the panel, with one button per tested page, but this build-up is cleared once the domain is switched.
Like the Wave extension for Chrome/Chromium, GADT also offers a built-in color contrast checker, based on one codebase. Since Section 1.4.3 of the WCAG specification mandates that depending on the text size, sufficiently high contrast ratio of the text and background must be provided in order to make text readable. Quite sensibly, the specification is less stringent in the case of very large text, in which case the letter shapes are much more discernible regardless of color. The highest contrast is that of black text on white background, or vice versa, while the lowest contrast is that of white text on white background — or more generally, when the foreground and background colors are identical. WCAG specifies two thresholds, depending on the text size. In our case, the minimum value is 4.5 to 1.
The GADT contrast checker incorrectly reports very low contrast in certain cases:
a {
color: hsl(232,10%,95%);
background: linear-gradient(hsl(232,40%,22%),hsl(232,40%,38%));
}
This pair of foreground and background colors satisfy the WCAG minimum contrast requirement, with plenty of room to spare. In fact, GADT would report a failure even when the highest contrast possible was used:
a {
color: white;
background: linear-gradient(black,black);
}
or
a {
color: white;
background: black linear-gradient(black,black);
}
From the GADT checklist:
"[Warning] Text elements should have a reasonable contrast ratio (14)"
See for AX_COLOR_01 more information.
White on black is reported as wrong not because the constituent
colors are wrong, but because GADT does not have support for the
linear-gradient or radial-gradient properties.
This failure is not due to an incorrect heuristic as such — the colors
are processed correctly, but the incomplete implementation of the
CSS specification results in the entire declaration being
dropped, which in turn implies that GADT is left with an incorrect pair
of colors during contrast evaluation.
Another contrast-related failure of GADT concerns disabled form
controls, such as input or option
elements. Traditionally, these are visually presented as washed-out text
of low contrast, with the exact values hard-coded in the browser. GADT is
being overzealous in that it should recognize this, but it applies
contrast color checking to computed styles.
<option value="apples" disabled>
<input type="password" disabled>
The same information and reference as in the previous text are issued.
The reason why GADT seems to be an immature project is that it reports errors which are due to its own interface implementation, of all things. Namely, documents long enough to exceed the viewport and which contain links not all of which are visible within the viewport for any scroll position will trigger the following warning:
[Warning] These elements are focusable but either invisible or obscured by another element
See AX_FOCUS_01 for more information.
This warning is issued for anchors which at the time of report execution were hidden by the developer tool's sidebar (or bottom panel) overlay. If the document is scrolled so that the allegedly offending anchors are fully visible outside of the overlay. Anchors which were previously visible but were now scrolled out of the viewport will be reported as hidden upon re-execution of the audit, assuming the overlay position is not switched in the meantime (from sidebar to panel, or vice versa). This bug indicates that the tool was barely tested, despite its age.
If in a chronicle-type document anchors contain dates as linked text, GADT will flag all such anchors as having unsuitable anchor content.
[Warning] The purpose of each link should be clear from the link text
While this is classed as a warning and not an error, it looks as if the algorithm employed is too simplistic.
Stylesheet documents are interpreted as HTML documents, due to the way Chrome/Chromium implements document view internally. Plaintext documents are wrapped in a minimal HTML document by the parser, and then displayed. GADT has no understanding of CSS as such. The same issue affects all plaintext files, regardless of content.
GADT flags image backgrounds as potentially meaningful, issuing warnings that such background should not be used (for example: pictures of text). However, since it is not a Captcha image processor, it cannot tell the difference between regular images and incorrectly used images, treating all in the same way. This implies false positives for background images such as rounded corners for blocks.
[Warning] Meaningful images should not be used in element backgrounds
See AX_COLOR_01 for more information.
Another instance of GADT being overzealous in its checks is the
iframe element. Issues found in the nested document will be
reported as failures for the top document, even though this should never
be the case. Authors may not have control over anything related to the
embedded document. An example is Google's own mapping application —
Google Maps. This false positive will have a huge impact on
today's web. If such failures are reported, they should be
presented separately. Whether or not the author is legally
responsible for embedded content remains unknown, and dependent on
legislation in a given jurisdiction.
Major issues with GADT:
The only benefit to using GADT is the color contrast checker, but since it is available in a more featured Webaim Wave, there is no reason to use GADT. That said, if it ever develops into a sophisticated tool, integration with Google Developer Tools will be appreciated. For now, this is just a toy.