fortnight11y issue 72

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

Screen Readers support for text level HTML semantics

Steve Faulkner writes about accessibility support for HTML tags such as  (and ),  (and ), and <del>, <ins> and . (He performed the same analysis 15 years ago – things have moved on a bit since then).

For strong/emphasised text, there is no audible distinction in any of the major screen readers. This is because the underlying Browser Accessibility Tree does not even expose this information to the screen readers, unless an explicit ARIA role=strong/role=emphasis is added. Even then, screen reader software chooses to do nothing with it. ‘Emphasis’ was briefly supported in NVDA but was removed because it is “very much over-used in the wild” and thus was extremely unpopular with users.

It’s worth noting that the less commonly used semantics such as <del> do seem to be supported by JAWS and NVDA, either through a voice change or an explicit “deleted” announcement. However, they don’t seem to be supported by VoiceOver or Narrator.

With the appropriate setting, all major screen readers expose text styles audibly (‘bold’, ‘italic’, ‘strikethrough’ etc), with the exception of VoiceOver on iOS, which gives no indication of text style.

Steve concludes with this:

WCAG SC 1.3.1:Info and Relationships is often cited as a reason why strong and em must be used and Technique H49:Using semantic markup to mark emphasized or special text provides examples of “Using the em and strong elements to emphasize text”. In practice their use does nothing for screen reader users at least, nothing that the i and b elements don’t provide (with their default styles).

Simply put the strong and em are not accessibility supported and therefore should not be a factor in accessing conformance with SC 1.3.1:Info and Relationships. Visually identifying emphasised and important text via CSS styles is an accessibility supported method and will be conveyed to SR users when they have the required settings enabled. This can be achieved by style declarations alone, it does not require the use of elements with particular semantics. By all means encourage the appropriate use of em and strong elements, but don’t require it.

Progressively-enhanced dark mode

Darin Senneff writes an incredibly in depth article about his progressively enhanced dark mode toggler.

Darin opts for a HTML form with three radio buttons: ‘auto’, ‘light’ and ‘dark’. The ‘auto’ option looks at the user’s operating system level preferences, i.e. serving light mode by default, but with a prefers-color-scheme media query that overrides to dark mode if that is the user’s theme preference.

If the user makes an active choice by submitting the form, he saves their preference in a session cookie, which persists as the user navigates around the site. He also keeps the selected theme pre-checked in the form, so it’s clear to the user which option they have selected. The explicit choice is used to apply a data-theme="dark" attribute on the root <html> element, and leads to some unavoidable CSS duplication as we now need to style based on the data attribute or user device theme.

Darin doesn’t stop there, and uses JavaScript to replace the form with a button. Triggering the button opens a dialog/modal, where the user can configure all of their preferences in one place, as well as have a live preview – and submission – of their chosen theme without having to refresh the page. Darin walks us through listening for all the necessary keyboard events for things like exiting the modal.

The user’s choice is now persisted in localStorage with JavaScript, which is more persistent than a session cookie, and thus able to store the user’s preference between visits.

You Can Make Your Giant iPhone Easier to Use With One Hand

A lifehacker article listing several things to try if you’re finding it uncomfortable trying to use a large iPhone display. I like these articles for discovering accessibility features I didn’t know existed.

There’s nothing particularly new to me on this list (except the AssistiveTouch feature, explained below), but it’s a useful roundup nonetheless:

Use Siri to action things like setting reminders and playing music
Use Dictation instead of typing messages
Rearrange the apps on your home screen, so that your commonly used apps are towards the bottom of the screen
Apple has a “Reachability” feature: “you can lower the top half of the screen with a swipe, giving you quick access to Control Center, Notification Center, and the apps and elements at the top of the screen”. You can enable it by going to Settings > Accessibility > Touch, and toggling on Reachability
Set up shortcuts to replace certain actions that would otherwise be difficult to do with the hardware buttons (such as taking a screenshot):
- “AssistiveTouch [is] a virtual Home button that lives on your screen, giving you access to a multitude of different actions like opening Control Center, activating Siri, taking a screenshot, among many others. You can enable AssistiveTouch by going to Settings > Accessibility > Touch > AssistiveTouch. On the same settings page, you can select Customize Top-Level Menu and tap the various icons to change the shortcuts accessible via the virtual Home button.”
- “Alternatively, you can use the iPhone’s Back Tap feature to set up similar shortcuts. Go to Settings > Accessibility > Touch > Back Tap and set up actions for both double and triple-taps. Now, you can tap the back of the iPhone twice or three times to execute the actions you’ve set up.”
Finally, consider using Display Zoom to make the icons larger and easier to reach.

Here, here, and here

Martin Underhill digs into the issues associated with a writing style we’ve all seen on the web. Someone might write “You can find some songs I like [here], [here] and [here]”, where each “here” is a link to a separate song.

If you work in the field of accessibility, you’re likely no stranger to the issue of a “here” link, and the main reason it is an issue is that screen reader users have different tools to navigate web pages. Whilst sighted users might visually scan the page to see what’s interesting or relevant, a screen reader user might bring up a list of headings, or a list of links, displayed in isolation and out of context. Link text of “here” provides no clue as to what’s at the other end of the link, and multiple links with text “here” is even worse because there’s no way of distinguishing between them.

The “no idea what’s at the other end of the link” problem applies to sighted users too, who at best might hover over the link (assuming they’re on a desktop) and see a built in browser tooltip that shows the URL of the link. This is a WCAG failure, specifically of WCAG 2.1 Success Criterion 2.4.9 Link Purpose (Link Only), which stipulates that the purpose of each link should be identifiable from link text alone.

Other less obvious issues include reliance on memory; if you click on a ‘here’ link and then go back, how will you know which one you’ve already clicked? Not all sites implement :visited styles now.

Finally, another phenomenon is the ‘series of words links’, like “here are some [songs] [I] [like]”, which, though nicely succinct and at least with unique text this time, have their own issues. For example, it can be hard to know that there is more than one link, as visually it might look like a single link with text “songs I like”.

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.