I’ve got a couple of accessibility related articles I thought I’d share this week. I’ve specifically picked them out as examples of well-done accessibility writing. For each, I’ve plucked out a bit I found particularly interesting. But you, you should read the whole thing.

• Demystifying WCAG 2.2 by Nathan Schmidt. WCAG 2.2 was released late 2023 (and so was this article), but I’m pretty sure 2.2 is the latest stable recommendation, with 3 still being experimental. WCAG is a “technical standard”, like other web specs, so it’s not written for regular website developers like me or you. Nathan’s article, however, is and it covers what’s new about 2.2. I learned that those options on forms like “Shipping address same as billing address? that prevent you from having to enter the same information twice are actually required.
• Super short note on CSS text by Steve Faulkner. A good reminder that not all screen readers behave the same. Like with <span>?</span> with span::before { content: "?"; } “JAWS announces “question mark, question mark” NVDA does not announce anything.”
• Screenreader only by Donnie D’Amato. Donnie doesn’t love utility classes in CSS. Even setups that don’t use them generally still typically have a .screenreader-only or .visually-hidden. But what if that was a component, what would the semantics of it be?
• Content hiding techniques and their accessibility implications by Sara Soueidan. Speaking of those screenreader-only still utilities, we specifically use those because other methods of hiding have side effects we don’t want. For example, a bit of text for screenreaders-only (and thus visually hidden) can’t use display: none; or it will be hidden from the accessibility tree as well, making it useless. We can’t use visibility: hidden; either for the same reason and it would still take up space in the flow. There are a lot more hiding techniques as well, and Sara compares, as the title says, their accessibility implications.
• Data Table Accessibility in 2024 by Zell Liew. Zell makes a table out of display: grid; and subgrid… and the results were that “Table semantics was not stripped out by screen readers in most browsers. They were able to announce table, rows, and columns accurately.” (with the very notable exception of Voiceover + Safari.
• contrast-color() is a good thing, but also solving the problem at the wrong layer by Eric Bailey. Eric wrote this in 2024 but it’s especially notable now as the CSS function just became widely available last month. Eric wonders, among other things “Why does all this have to be the website or webapp author’s responsibility?” Would the web be better if browsers enforced this automatically? (Probably.)