week11y issue 144

Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:

accessible forms needs and how to fix common errors

This is a handy guide to forms, covering the basics you need to get right:

Required fields, fields with special formatting, or other unique parts of the form have clear instructions
Clear navigation order using just the Tab key to go through the form
The entire form can be completed using only a keyboard
One accessible label is associated with each input and is readable by screen readers
Usable and accessible form validation for form errors

Each of these is covered in more detail further on in the article. The most interesting section is the one on validation:

Don’t use ‘default’ validation (built into the browser) as these don’t give clear instructions, have poor focus indication and don’t work well with assistive technologies
Error messages should go both above the form and inline with the fields that need correcting
Helper text should be programmatically tied to the fields, e.g. with aria-describedby
You should set focus on the first error message, after submitting a form incorrectly

The article ends with some examples and videos demonstrating good forms.

The Web Needs a Native .visually-hidden

This fantastic article by Ben Myers dives into the user need for textual content that is only available to assistive technologies, e.g.

<span aria-hidden="true">
	★★★☆☆
</span>
<span class="visually-hidden">
	3 out of 5 stars
</span>

Ben describes how we’ve arrived at the current standard implementation of ‘visually-hidden’ class:

.visually-hidden:not(:focus):not(:active) {
	border: 0;
	clip: rect(0 0 0 0); 
	clip-path: inset(50%);
	height: 1px;
	margin: -1px;
	overflow: hidden;
	padding: 0;
	position: absolute;
	white-space: nowrap; 
	width: 1px;
}

But this approach is hacky, trying to visually hide text without removing them from the accessibility tree (which is what would happen if we simply wrote display: none or visibility: hidden). It’s also been tweaked over time, to capture more and more edge cases in browsers and devices. Therefore, it’s difficult to know which snippet of code to copy and paste for each project, and implementations in third party libraries are liable to stagnate.

Ben puts forward the case for a native solution: display: visually-hidden. It would be far cleaner than the ‘copypasta’ solution above. Ben opts for a CSS implementation rather than a HTML attribute such as hidden="visually", as this has some legacy display: none styling in libraries such as normalize.css. Even a new HTML attribute such as visuallyhidden would suffer from the HTML architecture insofar as “the failure mode for a browser that doesn’t recognize the new value yet would be to exclude the content from assistive technology output altogether”.

Ben also considers the merits of a new CSS property, such as element-visibility: visually-hidden, but wonders how this would work in combination with something like display: none.

So, here’s hoping for a display: visually-hidden value to be added! Ben recommends adding your thumbs up to the existing GitHub issue that proposes something like this.

Airbnb launches new accessibility features to help people with disabilities find suitable accommodation

Airbnb have launched a genuinely useful feature. Its new ‘Adapted’ category features homes that are specifically adapted for wheelchair access.

Every home in the category receives a detailed 3D scan that creates a 3D model of the home. This is then analysed to confirm its accessibility features, and to display key details such as doorway widths. Hosts of ‘experiences’ (such as a tour or cooking masterclass, bookable through Airbnb) can also choose to allow ‘access providers’ free of charge. These are “anyone over the age of 18 who regularly assists a person with a disability, mental illness, or long-term illness with daily activities”.

You hear so many stories about people booking ‘accessible’ rooms only to find that this was a total lie, so it’s great to see Airbnb’s verification process, which should prevent issues of that nature.

The article concludes with an accessibility research form, which you can fill in if you’re interested in participating in a session about accessibility at Airbnb.

What’s New in WCAG 2.2 Draft

WCAG 2.2 introduces nine new success criteria. To recap, these are:

These already existed in earlier drafts of WCAG 2.2. But between September 2022 and January 2023, they were modified as follows (all changes are open source):

2.5.8 Target Size (Minimum): Changed the exception bullets for Spacing and Inline. Added a note about inline targets and line-height.
3.2.6 Consistent Help: Changed the first note.
3.3.8 Accessible Authentication: Changed the first note.
3.3.9 Accessible Authentication (No Exception): Renamed to Accessible Authentication (Enhanced).

Note that, apart from the 9 new criteria, the 2.0 and 2.1 success criteria are exactly the same, with two big exceptions:

4.1.1 Parsing has been emoved. We covered this in detail in dai11y 30/12/2022
2.4.7 Focus Visible is changed from Level AA in WCAG 2.1 to Level A in WCAG 2.2

Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.