Saying a product is “accessible” doesn’t mean much these days. Mostly because building a fully accessible product that caters for all known impairments (be it physical, cognitive, or otherwise) would be an ongoing and monumental task. It would require extensive user testing, consultation with accessibility professionals, and lots of iteration.
The blanket term “accessible” doesn’t adequately outline the considerations, choices, and concessions a developer had to make in building that product.
So, then, how do we measure accessibility?
A bit of background: WCAG
Thankfully the web industry has a set of guidelines called Web Content Accessibility Guidelines or WCAG. WCAG has been considered the industry standard, and the recommendation of the World Wide Web Consortium (W3C), since the release of WCAG 1.0 in May 1999. Its successor, WCAG 2.0 (released December 2008), proved that this is a living, relevant standard updated to reflect the evolving technology and needs of all web users.
By having a set of guidelines with levels of conformance, it’s easier to quantify the number of considerations that had been made. With WCAG, there are three levels of conformance: A, AA, and AAA. Saying that a product is compliant with Level A means it meets the minimum accessibility requirements outlined by WCAG.
In June 2018, WCAG 2.1 introduced 17 new success criteria for determining accessibility. They focus on users with cognitive or learning disabilities, accommodate low vision cases, and improve accessibility for mobile devices.
The landscape of the web and the technology we use to traverse it changed drastically in the decade between WCAG 2.0 and 2.1. It’s fantastic to see that after all this time, the team behind WCAG are still active, and that the spec continues to improve with the industry.
So what does this update mean for web development? Having recently attended Perth’s Web Accessibility Camp, I got the opportunity to listen to a fantastic talk by accessibility legends, Amanda Mace and Julie Grundy, on the new WCAG success criteria. What excited me most was how immediately practical they were. Here were my favourites:
Content on Hover Or Focus (Criterion 1.4.13) – Level AA
Displaying content on hover is a commonly used pattern in websites, used in elements like tooltips, or dropdown menus. The problem with this pattern is that it can be disruptive, and is device specific — meaning not every device is capable of a hover event (i.e. mobile and tablet devices).
To remedy this, WCAG’s “Content on focus” criteria specifies that content available on hover, should also be triggerable by other means, such as keyboard focus. It should be persistent, so content can be perceived without disruption, like when you accidentally move your mouse and end up hiding the content. Content available on hover should also be dismissable. This could mean providing a “close” button within the content area, or offering keyboard controls such as pressing the escape key to close the content.
This is ideal because: It means information can be accessible, no matter what device you’re using. Remember, there’s no such thing as a ‘click’ on a touchscreen.
Pointer Gestures (Criterion 2.5.1) – Level A
Pointer gestures are actions users must perform to do a certain task, eg. dragging a file into a trash can. More complex pointer gestures, such as path-based gestures (eg. sliders) or ones with multiple points (pinching two fingers to zoom), require a certain level of fine motor skills. Users who deal with certain physical disabilities like multiple sclerosis or Parkinson’s disease, may find these gestures difficult or outright impossible, preventing them from completing what they set out to do.
So, the “Pointer Gestures” criteria outlines that content can be operated without the use of complex pointer gestures. Path-based or multi-point gestures must have a single-point activation alternative. For example, a slider that allows the user to change the slide by swiping left or right on their device should also have arrows that allow the user to adjust the slide with a single click.
This is convenient because: If you are navigating a website on a mobile device, you won’t always have to have two hands free to perform certain tasks or actions.
Pointer Cancellation (Criterion 2.5.2) – Level A
Have you ever clicked on a link, then decided actually you didn’t want to leave the page? The expected solution is often to hold down the mouse button, drag the cursor slightly off the link, then release. Sadly, this doesn’t always work. It’s important — and generally considerate — to allow users to change their mind when performing an action.
WCAG clearly agrees: the “Pointer Cancellation” criteria outlines that events should be triggered on an up-event such as mouse up or key up, instead of a down-event like mouse down or key down. This gives users time to change their minds, and helps prevent accidental clicks or triggers.
This is practical because: For people with limited motor control that makes it easier to misclick (or if, like me, you idly click and drag as you read a page), being able to avoid triggering an unnecessary page refresh saves load time and reduces the risk of someone rage-quitting your website 😉
Motion Actuation (Criterion 2.5.4) – Level A
Many devices now have sensors such as accelerometers and gyroscopes to detect motions like tilting or shaking. Sometimes these motions are mapped to actions — for example, shaking a device will trigger an “undo”.
These gestures can be difficult or impossible for people with limited motor skills, or for devices that are mounted. Certain motor impairments such as tremors may also accidentally activate motion sensors, which is why many devices allow users to disable motion sensing or opt in for a “reduced motion” mode.
WCAG addresses this with its “Motion Actuation” criteria, requiring motion-based actions to accommodate alternative methods of activation. For example, an interactive photo (like a panoramic or VR/360° image) that allows users to move or pan a device should also have interface controls to perform the same actions.
This is sensible because: Do you really want to physically turn your entire body in public to view that 360° panorama that your uncle posted on social media? Probably not.
Status Messages (Criterion 4.1.3) – Level AA
Status messages change the user’s context without taking focus. For example, after pressing a search button, a status message may appear saying “5 results found”.
Consider people who use a screen reader. You wouldn’t want to change their current focus — that would just be annoying — however status updates are relevant information they may need to know.
WCAG 2.1’s “Status Messages” criteria specifies that content added to a page shouldn’t navigate users away from their current point of regard. The criteria goes as far as outlining ways to ensure that status messages are read out by screen readers in an informative and non-disruptive manner. Status messages should always use the appropriate ARIA role or aria-live property to ensure they’re interpreted correctly by screen readers.
This is vital because: When done incorrectly, it’s basically the un-sighted equivalent of trying to read a paragraph of text or complete a form, and being disrupted by an unexpected pop-up modal window. It’s jarring and a bad user experience.
We’re all just temporarily abled
As a developer, accessibility standards — WCAG in particular — have always been an interest and a moral obligation of mine. It can be difficult to put yourself in someone else’s shoes, but in the end, as web accessibility advocate Cindy Li once put it, “We’re all just temporarily abled.”
Building a more accessible web is beneficial to all, not only those with impairments.
So many accessibility considerations go unnoticed by abled-bodied and neurotypical users. Until, of course, those users find themselves in situations where they could use the “extra help”.
Considerations like what, you ask? Like a good contrast ratio between font colour and background colour to ensure readability. Or placing important clickable elements within thumb’s reach when browsing on a mobile device. Or captions on videos so that you can watch in public spaces without having to wear headphones. These are all examples of considerations outlined by WCAG.
Even as a non-assistive technology user, I benefit daily from the accessibility considerations covered by WCAG and the new WCAG 2.1 criteria. A website’s accessibility issues may be a mild annoyance for me, but for others it could majorly impact the way they interact with the product, or even render a product unusable.
As a developer, a user and a human being who may one day experience a disability, I am grateful for the accessibility standards that are making the web a more perceivable, operable, understandable and robust place.