Skip to content

Accessibility: tooling, better target sizes, etc.

  • The WebAIM Million survey found that home pages with ARIA present averaged 41% more detectable errors than those without ARIA. ARIA is an essential tool for creating complex web applications, but the specification is strict and can be tricky to debug by those who do not use assistive technology regularly. Tooling can help us ensure that we are using ARIA correctly and not introducing more errors to our applications.

    The Paciello Group has created a WAI-ARIA bookmarklet which scans your page to make sure all elements and their given roles and ARIA attributes are valid. Upon activating the bookmarklet, the page is scanned for any errors, and a new tab will be opened with the results. The results include the total number of valid roles, any detected ARIA errors, and code snippets of where any errors were found so that you can easily debug your page.

    One thing not explicitly tested in the above bookmarklet is the presence of duplicate ARIA roles. Certain landmark roles have names that sound like they might apply to several elements, but should only be used once per page, such as banner or contentinfo. Adrian Roselli has come up with a simple CSS-based bookmarklet to check if any of these ARIA roles have been duplicated. Activating the bookmarklet will add a red outline to any offending element.

  • WAVE by WebAIM has been an integral part of my tool kit. Available in extension form as well as a mass testing service and an API, I find this tool best for checking my work as I develop due to its simplicity and speed. Everything is loaded as a panel on the side of your page, and you can get a holistic view of errors by scrolling through the page. If an error is displayed in the side panel but you aren't sure where in the DOM it is, you can turn off styles to locate it within the markup. WAVE's heading and landmark feature is one of my favorite things about it as it ensures that my document semantics are correct as I build.

  • Not all browsers and screen reader combinations work well together, and not all accessibility features are equally supported across browsers. These tools can help you check if you are experiencing a bug on a specific combination of devices. HTML5 Accessibility is a list of newer HTML features and whether or not the default browser implementation is accessibly supported. In a similar vein, Accessibility Support provides a list of ARIA roles and their support in the most popular browser and screen reader combinations.

  • This bookmarklet by Level Access labels every focusable element on the page, so that you can check that the focus order matches the reading order. For the Firefox users out there, Firefox's Accessibility Inspector has added this feature since version 84.

  • If you're wondering whether there's a criterion for target size, the answer is yes. It's WCAG 2.5.5. Pulling straight from the guidelines. passing WCAG 2.5.5 with a AAA grade requires "the size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

    • Equivalent: The target is available through an equivalent link or control on the same page that is at least 44×44 CSS pixels;
    • Inline: The target is in a sentence or block of text;
    • User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
    • Essential: A particular presentation of the target is essential to the information being conveyed."
  • Small target sizes can cause accessibility hurdles for many people. Have you ever been traveling in a vehicle on a bumpy road and you’re trying to interact with an app on your mobile [but] can not press on an element? That is an accessibility hurdle. Those with motor skill or cognitive impairments will have a much harder time because it is much harder for them if the target size is too small and does not meet WCAG requirements.

  • [...] But with all this said, we do actually have a CSS media query that can detect a pointer device so we can target certain styles to either fine or coarse input interactions, and it's well-supported. Here's an example pulled right out of the spec:

    /* Make radio buttons and check boxes larger if we have an inaccurate primary pointing device */
    @media (pointer: coarse) {
    input[type='checkbox'],
    input[type='radio'] {
    min-width: 30px;
    min-height: 40px;
    background: transparent;
    }
    }

    But wait. While this is great and all, Patrick H. Lauke offers a word of caution about this interaction media query and it's potential for making incorrect assumptions.

  • [...] Let's take the example that the WCAG explainer provides, again, in it's description of inline target exceptions:

    If the target is the full sentence and the sentence is not in a block of text, then the target needs to be at least 44 by 44 CSS pixels.

    That's a good one. We ought to consider whether the target is its own block or part of a larger block of text. If the target is its own block, then it needs to abide by the rules, whether it's a button with a short label, or a complete sentence that's linked up. On the flip side, a complete sentence that's linked up inside another block of text doesn't have to meet the target size requirements.

  • If the target is completely un-styled — in the sense that you've added no CSS to it — and instead takes on the default styles provided by the browser, then there's no need to stress the 44×44 rule. That makes sense. The User Agent is like [a] system-level UI so changing it superficially with our own styles would be overriding an entire system which could lead to inconsistencies in that UI.

    So, yeah, if you're rockin' a default <button> or the like, and there are no other styles or sizing applied to it, then it's good to go. But lots of us use resets to normalize UI elements across browsers, so watch for that in your codebase because that's going to affect the User Agent styles of your target.

  • The BBC Mobile Accessibility Guidelines set out best practices for mobile web content, hybrid and native apps.

    This guidance brings together a set of recommendations for some of the ways HTML documents can meet those guidelines.