month11y issue 36

Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

We begin with a Smashing Magazine special! It’s a great publication – which I’ve written for a few times – and I’ve had some of their a11y articles sitting in my bookmarks for a while. These articles are long and full of useful info, so it’s sure to be a bumper week. Let’s dive in!

Making Sense Of WAI-ARIA: A Comprehensive Guide

An article by Kate Kalcevich, Head of Accessibility Innovation at Fable. She recaps how HTML is parsed into two structures: the DOM and the Accessibility Tree. Assistive technologies access the accessibility tree nodes to understand the element role, state and name. Native HTML elements such as <input> populate both structures automatically, but custom components made up of <div>s and <span>s need extra markup to fill the accessibility tree properly. This markup is called ARIA (Accessible Rich Internet Applications).

ARIA gives extra information about an element, but doesn’t give extra behaviour. For example, adding role="button" to a div won’t make it respond when you press the Enter key, but it does tell the accessibility tree what it’s claiming to be. The ARIA Authoring Practices Guide includes a list of what interactivity should be added to various components such as accordions, buttons, carousels, and the MDN web docs has a complete list of available roles.

Kate cherry-picks some key ARIA states and properties:

  • aria-checked ("true" or "false") to indicate whether checkboxes and radio buttons are currently checked
  • aria-current ("true" or "false") to indicate the current page within breadcrumbs or pagination
  • aria-describedby – used with the id of an element containing extra information for a form field beyond just its label, e.g. examples of the required format for a field
  • aria-expanded ("true" or "false") to indicate if pressing a button will show more content (e.g. accordion)
  • aria-hidden ("true" or "false") to hide something that is visible, but you don’t want assistive technology users to know about it, e.g. a card component with image and text linking to the same place, but structured as two links; use aria-hidden="true" on one of the links.
  • aria-required ("true" or "false") to indicate if a form element has to be filled out before the form can be submitted

And Kate rattles off some of the most common ARIA-related mistakes:

  • Using an aria-labelledby attribute with an ID that doesn’t exist
  • Adding roles unnecessary (<button role="button">)
  • Using child roles without parent roles (e.g. <li role="option"> without a direct parent with role="listbox")
  • Using role="menu" for navigation; it’s intended for things like custom menus on right click, not for general site navigation, which is more of a table of contents than a menu. For the latter, use <nav aria-label="Main menu">. Read Heydon Pickering’s Building Accessible Menu Systems for more.

Finally, there’s a section on focus management, how to validate ARIA, and resources for frameworks and component libraries.


Accessible Front-End Patterns For Responsive Tables (Part 1)

Adrian Bece writes two in-depth articles about implementing responsive tables.

He shares Adrian Roselli’s JavaScript snippet that applies the correct ARIA roles to table elements, which are to ensure that browsers continue to keep good table semantics even when certain CSS styles are applied. The snippet is from 2018, but an update in December 2022 suggests it is still needed for Safari. Note that the JS itself isn’t needed, but the resulting markup, which you could add to your HTML manually or in a preprocessor.

Tables should have a <caption> element as the first child, with a nested heading describing the contents of the table. If it can’t be the first child – e.g. because you’ve added a wrapper element to make the table scrollable – you’ll need to include the table in a <figure> element, use a <figcaption> for the title, and apply a aria-labelledby to the table’s wrapper.

Small / simple tables can be made neatly responsive with table { width: fit-content }, to remove any unnecessary space when viewing on larger screens. For tables with lots of columns, it becomes necessary to horizontally scroll, by applying an overflow: auto to the wrapper element, alongside a tabindex="0" to make it usable for keyboard users.

Some OS’s hide scrollbars by default (I’m looking at you, macOS!), so you may want to consider adding a shadow gradient to indicate the table is scrollable. With background-attachment: local, local, scroll, scroll;, you can subtly hide and show the shadow on either ‘edge’ of the table depending on the direction you scroll. Another visual cue to let the user know a table is scrollable is to force a crop of the last visible column. You may want to consider making the table headers sticky, to keep them in view as you scroll.

Adrian then discusses the stacking approach; useful for tables where the data isn’t supposed to be ‘compared’, e.g. a table of people and their contact information. In the demo, each ‘row’ gets pulled into its own ‘block’ on smaller screens. But this can make pages very tall on mobile. An alternative is the accordion pattern, where you may choose to only show the primary data column (e.g. user’s name) on smaller screens, with a button to expand and reveal the other columns as needed (see demo). Another space-saving option is to give users the ability to show/hide columns.

In Part 2, Adrian looks at patterns for much larger tables, including how to improve their rendering performance by either paginating the results, virtualising the rendering (i.e. keeping the table in memory but only rendering the number of DOM nodes you need in view), or exploring the CSS contain: strict property. Adrian also touches on JavaScript libraries for enhancing tables, and some other special use cases such as rendering calendars.


When CSS Isn’t Enough: JavaScript Requirements For Accessible Components

Stephanie Eckles shares those scenarios where you need a sprinkling of JavaScript to make components accessible. The TLDR is that these include “tooltips, modals, tabs, carousels, and dropdown menus”. Components marketed as “CSS-only”, that use methods like the “checkbox hack“, often do more harm than good.

As a quick sense check, ask yourself the following:

  • Does the feature include showing and hiding of content? If so, you need JS to at minimum “toggle aria and enable closing on Esc
  • Is the natural focus order the most ideal? “If the natural order loses the relationship between a trigger and the element it triggered, or a keyboard user can’t even access the content via natural tab order, then you need JS to assist in focus management”
  • Does the effect rely on hover and/or focus? You may need JS to make an alternative solution “for touch screen users and those using desktop zoom of 200%+ or magnification software”

Tooltips should be used as a last resort. Ask yourself why you’re adding this text to the UI, and where else it could go. But if you do use one, make sure it’s dismissable without moving hover or focus, that its contents can be hovered without it disappearing, and that it doesn’t disappear based on a timeout.

Modals, as we’ve covered in previous frequent11y issues, would ideally be implemented with a HTML native <dialog> element, but it isn’t currently accessible. Custom solutions need JS because it should be dismissable with the Esc key, and the keyboard focus should be trapped inside. As to what to focus on when opening the modal, Stephanie’s presented a decision tree.

Tabs need to toggle aria-selected to true for the current tab, create a roving tabindex to “distinguish tab selection from focus”, and move focus by responding to arrow key events, all of which require JavaScript. NB: a roving tabindex is a way of programmatically controlling the focus order of elements, e.g. by setting the selected tab to tabindex="0" and all the others to -1.

Dropdown menus need JS, even though we now have CSS’s :focus-within property, because we still need to toggle aria-expanded, be able to close the open menu button with Esc and implement arrow keys for navigating between menu items.

Carousels are notoriously considered a bad design pattern, but if you’re going to build one, you’ll need JS to provide paginated and prev/next controls, as well as auto play.


“I Used The Web For A Day…” series

I said earlier that I’d written some articles for Smashing Magazine in the past. As this issue is a Smashing Mag special, I thought I’d share those articles with you now! Mine was a short series on using the web for a day, but with a limitation: to highlight barriers to accessibility and provide tips on how to build a better web.

You can read the articles below:


Now, onto non-Smashing-Magazine things…


Twitter is getting rid of its free API tier. That’s a nightmare for accessibility activists.

Twitter has announced that, starting February 9, they will no longer support free access to the Twitter API (both v1.1 and v2). This move has not been popular, including with myself – basic things like the automatic tweeting of my dai11y article will probably just stop working. Only time will tell!

This Mashable article details some of the accessibility bots that may no longer be viable. There are bots that highlight a lack of alt text in newsroom and government tweets, which I covered in dai11y 21/10/2022. There’s also @A11yAwareness, a bot with over 17k followers, which shares tips and articles about accessibility. The owner of the bot will now have to sift through findings and manually schedule all of the account’s tweets to keep it running.

Then there are the various ‘utility’ bots that serve as accessibility tools for users with various disabilities. These include the Thread Reader app (or ‘unroll’), which makes it easier for users to read long Twitter threads. Or an Alt Text Reader app that visually surfaces any manually added alt text, which can otherwise be hard to find. Then there are third party clients like Tweetbot and Twitterific, which no longer work – some of these clients were aimed at providing better accessibility than native Twitter.

This comes on top of Twitter’s accessibility team being let go last November, resulting in no updates to Twitter’s accessibility page since October.


Chris’s look at ChatGPT

I’ve had a few ChatGPT related accessibility articles in my inbox of late – I’ve read them and summarised them so you don’t have to!

In “How ChatGPT can help your code be accessible“, Ashley Smith describes how you can use ChatGPT to give you some markup as a base to build upon. For example, you can ask it to write the code for a green “Read More” button, in React, that is “completely 508 compliant“, and it will give you a snippet of code.

I strongly caution against this. What ChatGPT generates might make rough sense to you, the reader, it has no proper understanding of what it’s talking about. In other words, it’s a bull**** generator. For example, in the code example ChatGPT returned for the above request, we have a completely unnecessary aria-label on our button. It is dangerous to just copy and paste ChatGPT’s output and assume everything is fine: a code snippet isn’t necessarily accessible just because you asked ChatGPT to make it so.

Scott O’Hara covers exactly this example in “Setting expectations for asking ChatGPT web accessibility questions“. He expands on why an aria-label on a button can actually be actively harmful, such as if you’re using a ‘translation widget’ to translate a page into another language. These widgets often neglect the values of aria-label attributes, concentrating only on visible text. There are other parts of the answer ChatGPT gave to Scott, which he picks apart (such as the unnecessary recommendation to give the button a tabindex and to use JavaScript to listen for ‘Enter’ or ‘Spacebar’ key presses).

Finally, in “Will ChatGPT threaten the future of the digital accessibility field?“, Denis Boudreau actually has a Q&A style interview with ChatGPT on where it sees itself (insofar as it can) in the realm of a11y. It’s actually given some very self-aware answers that I wouldn’t argue with! I’ve pulled out some snippets below:

As a large language model, my primary purpose is to assist users in generating human-like text based on the input provided to me. I do not have the ability to impact the future of the field of digital accessibility or any other field.

The future of the field of digital accessibility will be shaped by a variety of factors, including advances in technology, changes in laws and regulations, and shifts in societal attitudes towards accessibility. It is important for professionals in this field to stay current with developments in these areas and to continue to work towards creating more inclusive and accessible digital products and services. However, the success or failure of a particular natural language processing model is unlikely to be a major determining factor.

Digital accessibility is a multifaceted field that encompasses a wide range of technologies, design principles, and best practices. While natural language processing models can certainly play a role in making digital products more accessible to people with disabilities, they are just one part of the larger ecosystem of tools and strategies used to achieve this goal.

It is important to recognize that [ChatGPT is] not a substitute for expert knowledge and understanding in the field of accessibility. Natural language processing models are limited by the data they are trained on and the algorithms they use, and they may not always produce accurate or reliable information.

Natural language processing models are trained on large data sets, but the quality and relevance of that data can vary. Some models… may be trained on data sets that are more limited in scope or that contain biases or errors. As with any source of information, it is important for aspiring accessibility professionals to critically evaluate the quality and accuracy of the information they are using, regardless of whether it comes from a natural language processing model or any other source.

The article concludes with some suggestions for how ChatGPT can best be used as a tool in the field of accessibility. These suggestions, again, are provided by ChatGPT, but look very sensible!


Progressive enhancement poem in the style of Shakespeare

In more a11y ChatGPT news, my colleague Derren Wilson asked ChatGPT to “explain progressive enhancement in the style of shakespeare”, and I’m absolutely gobsmacked at the results. Enjoy.

Hark! What light through yonder window breaks?
It is the concept of Progressive Enhancement,
That doth illuminate the web with its grace.

Forsooth, Progressive Enhancement is a noble goal,
To build a website with layers that unfold,
To ensure that all may access its content whole,
Be they on a phone or a screen vast and bold.

At first, the website is built with simple means,
With plain HTML and CSS, so it seems,
But as the layers add on, like a rising sun,
The website grows in beauty and function.

With each layer, new features are revealed,
And yet, the website’s core remains unpeeled,
Accessible to all, no matter their device,
No user left behind, no matter the price.

Thus, Progressive Enhancement is a shining star,
A beacon of hope, in a web world that’s marred,
A way to build websites that all may share,
And make the web a place that’s just and fair.


Meet the first-ever accessibility engineer at The Washington Post

The Washington Post hired Holden Foreman in January. Holden is keen to stress that whilst he is the first person at the newspaper with the ‘Accessibility Engineer’ title, accessibility is not a new concept there and the lack of formal roles at smaller news organisations does not mean that those places don’t care about accessibility.

Holden started working at the Post in 2020. Interestingly, he was key in pushing for the creation of an Accessibility Engineer role:

I started an informal working group at the company with biweekly meetings for skill shares, news, internal updates, shoutouts and other discussions related to accessibility. With the help of Julie Bacon Arsenault, one of the Post’s engineering directors, I delivered a pitch last year for an accessibility engineer job title. Arturo Silva, an engineering manager who oversees the Washington Post Design System among other things, was willing to make a home for the role on his team.

He sees his role as exploring new opportunities in research and feature development, as well as educating others at the company and being a resource for support. He also hopes to create a stronger dialogue with users, to learn how people actually use the Post’s tools.

Holden adds that accessibility isn’t just about coding, or even about disability:

It’s essential to think about accessibility not just in the context of disability but also in the context of other inequities affecting news coverage and access to news. For instance, writing in plain language for users with cognitive disabilities can also benefit users with lower reading literacy.

[The Post published a plain language version of Foreman’s introductory blog post]

The interview more or less concludes with Holden’s thoughts on the role:

It’s definitely stressful to be the first in this new role. I feel deep down like I need to justify its creation with every step that I take. My managers and colleagues have been fully supportive, and it is thanks to them that the role exists, so I would say that the pressure feels self-enforced. Thankfully, there is a lot of collaboration in the accessibility world, and I have already been in contact with some folks from outside of The Post regarding how we can support each other.


Screen Readers support for text level HTML semantics

Steve Faulkner writes about accessibility support for HTML tags such as <strong> (and <b>), <em> (and <i>), and <del>, <ins> and <mark>. (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:

  1. Required fields, fields with special formatting, or other unique parts of the form have clear instructions
  2. Clear navigation order using just the Tab key to go through the form
  3. The entire form can be completed using only a keyboard
  4. One accessible label is associated with each input and is readable by screen readers
  5. 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:

  1. 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
  2. Error messages should go both above the form and inline with the fields that need correcting
  3. Helper text should be programmatically tied to the fields, e.g. with aria-describedby
  4. 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:


Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♄ by developer @ChrisBAshton.

Loading...