WCAG posts
Meeting WCAG Level AAA
In this post, we cover updates we've made to our own site in order to better satisfy the requirements of the Web Content accessibility Guidelines (WCAG) 2.1 Level AAA.
Foundations: accessible names and descriptions
An element's name, or accessible name, is how it's identified. An accessible description provides additional information, about the element, that complements the accessible name.
In this post we explore assigning accessible names and descriptions using HTML and WAI-ARIA.
Foundations: pointer gestures
A pointer gesture is an action a person performs using their finger, mouse, or an assistive technology like a head pointer or eye gaze system to operate a functional control. Some pointer gestures can be difficult or even impossible for certain people to perform, so an accessible alternative may be required.
This post introduces the different forms of pointer gestures and covers how and when to provide alternatives for people who can't perform them.
Foundations: introduction to WAI-ARIA
The Web Accessibility Initiative Accessible Rich Internet Applications specification 1.2, or WAI-ARIA or ARIA for short, is a technical specification written by the World Wide Web Consortium (W3C).
In this post we explore what WAI-ARIA is, and how it can enhance the user experience for people using screen readers.
Foundations: visible focus styles
Visible focus styles help us to understand which part of a web page we're interacting with. You may have seen visible focus styles appear as an outline around a link or a button for example.
For people who only use a keyboard to navigate the web, visible focus styles may be one of the few ways to understand where they are in a page and what it is that they are interacting with.
Foundations: target sizes
A target size is the area that can be activated in order to interact with an element. For people who have dexterity issues, the smaller a target size is, the more difficult it may be to use the website.
This post explores how to create usable, consistent, and well-spaced target sizes.
Foundations: native versus custom components
Deciding whether to use native or custom components for a website or web application can have implications in terms of development effort, user experience, and accessibility. This post considers the pros and cons of each approach with a focus on accessibility, and provides guidance on how to choose one.
Foundations: HTML semantics
HTML semantics provide accessibility information about page structure and an element's role, name, and state, helping to convey the nature and purpose of content on web pages.
In this post we explore what HTML semantics are, and how they're experienced by people using assistive technologies like screen readers and speech recognition software.
Android accessibility: roles and TalkBack
TalkBack only announces role information for a relatively small number of user interface (UI) elements within native apps. When comparing this behaviour against web content, this can often give the (false) impression that these elements must have been coded incorrectly and therefore need to be "fixed".
This blog post looks at when it is acceptable for a role not to be announced, the roles that TalkBack does announce, and what this means for conformance to the Web Content Accessibility Guidelines (WCAG).
Triaging WCAG 2.1 Level AAA
If you've taken the time to understand WCAG 2.1 Level AAA and have spent time testing WCAG 2.1 Level AAA, what do you do with the results?
