Blog Archive

Recently we ran a presentation on WCAG2.1 and WCAG2.2 additions to WCAG2. Since then we have been publishing these additions – one success criterion a day. Here is a list of the WCAG2.1 success criteria blog posts. Level A Success Criterion 2.1.4: Character Key Shortcuts Success Criterion 2.5.1: Pointer Gestures Success Criterion 2.5.2: Pointer Cancellation Success

Status messages should be programmatically determinable through appropriate roles or properties, allowing assistive technologies to present the information to users without altering their current focus.

When additional content becomes visible upon receiving pointer hover or keyboard focus (and subsequently becomes hidden when these triggers are removed) it should be dismissible in a manner that allows users to close the content without needing to move the pointer or re-focus. This applies unless the additional content communicates an input error (that has then been addressed) or does not obscure or replace other content.

The primary goal of this success criterion is to allow users to adjust text spacing to improve readability. This approach aims to improve accessibility for users with cognitive disabilities. It does not require all content to meet these exact spacing specifications; rather, it requires that the website remains responsive when users customize their preferred text settings.

The purpose of this standard is to ensure that content remains readable and accessible on mobile devices. In simpler terms, it is about making sure your website is responsive.

The purpose of each input field is to clearly define its intended function. Collecting user information can be automated when the input field’s label correctly identifies it, allowing the computer to input previously agreed content. For example, if a field is coded as a First name, then a system should be able to automatically fill in the user’s first name.

Mobile content should be usable in any orientation. In some cases, the mobile device can be affixed, set to a specific orientation and cannot be rotated by the user.

The goal here is to remove the need for users to manually move their mobile devices. Features such as shake-to-undo are problematic because they can be accidentally triggered by users who may not be able to hold their devices steady. Alternatively, requirements for device movement will be impossible for people who have their devices affixed to other objects, such as their wheelchair.

Ensure that the control’s text label and accessible name are the same where possible. This practice supports both visual users and those interacting through voice commands or assistive technologies.