The Test Page The Code Testing Results Keyboard Screen Readers Voice Control, Forced Colors, Speed Media Queries: 20 December 2023 Audio Description: 20 December 2023 Wrap-up Browsers each provide built-in video players for the <video> element. Nearly four years ago Scott Vinkle wrote How accessible is the HTML video player?,…
I made a tutorial for styling links and buttons, something which many developers have struggled with (resulting in links used as buttons and buttons used as links). I have embedded it on this page, but if you are coming in with your RSS reader you can visit the tutorial directly…
I use the CSS :has() pseudo-class to provide an interactive alt text decision tree (from the W3C WAI Tutorial) that uses no script. It is progressively enhanced, so browsers without support for :has() still get all the content. See my post Under-Engineered Dependency Questions if you want my argument why…
Does what it says on the tin. Uses <details> and <summary> with a bit of ARIA to create an accordion that works without JavaScript while working better with JavaScript. Mostly. See the Pen Progressively Enhanced HTML Accordion by Adrian Roselli (@aardrian) on CodePen. Visit the standalone version for testing or…
TL;DR: This post does not assert the correct way to code blockquotes, it will only demonstrate how screen readers announce some existing patterns. Test Details The first four examples are lifted from WHATWG HTML’s <blockquote> entry. The next three are from W3C HTML’s 2019 <blockquote> guidance (the W3C HTML spec…
When I wrote Under-Engineered Text Boxen in 2019 I mentioned <datalist> (WHATWG, MDN) but did not dwell on it. Partly because support was poor at the time. Once Can I Use’s <datalist> entry listed Firefox on Android supporting it in version 110, I got excited and started testing to write…
This is not a comparison between popovers and dialogs, nor is it a discussion of support. This is me trying to get ahead of a potential issue for users when developers mix and match the patterns. I will let this 32 second video explain: Sorry, your browser doesn’t support embedded…
TL;DR: Be careful when using the word menu. Be certain you have chosen the term that accurately describes the control you want. If this post looks familiar to you, that is because it is essentially a redress of my 2020 post Stop Using ‘Drop-down’. It is not as divergent as…
The slides for my talk are available as a
This post is about exposing field errors programmatically. I have already shared some opinions (such as a caution about displaying messages below fields or avoiding default browser field validation), but this post dives into using ARIA to convey them to screen reader users. With fields that produce error messages on…
Using ARIA instead of HTML is generally fine for content, layout, structure, and other static bits of a page. A <div role=”heading” aria-level=”1″> is the same as <h1> as far users and accessibility APIs are concerned. It is unlikely a user will ever notice the difference unless you use both…
Spanned table headers are not well supported across screen readers. While you can visually style these all sorts of ways to make the spanning clear, I am focusing on the programmatic outcomes. Which essentially means how they are exposed to screen reader users. This post uses only HTML <table>s. It…