Skip to content.
Adrian Roselli
Outsourced Trained Library CRT

All Posts Tagged: html

Splitting within Selects

The native HTML <select> is renowned for its styling limitations. Even with control over the closed state and trigger appearance, the options themselves are still defined primarily by the browser and the OS. While I think this is generally fine (preferred, even), the <selectlist> (nee <selectmenu>) hopes to change that.…

Posted:

Tags: accessibility, browser, Chrome, Firefox, html, Safari, standards, usability, whatwg

Browser Video Players Review

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?,…

Posted:

Tags: accessibility, browser, Chrome, Firefox, html, mobile, Safari, standards, W3C, whatwg

Styling Links and Buttons

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…

Posted:

Tags: css, html, usability

An alt Decision Tree Using Only :has()

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…

Posted:

Tags: accessibility, css, html, WAI

Progressively Enhanced HTML Accordion

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…

Posted:

Tags: accessibility, ARIA, css, html, JavaScript, pattern, print, usability, UX

Blockquotes in Screen Readers

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…

Posted:

Tags: accessibility, html, standards, usability, W3C, whatwg

Under-Engineered Comboboxen?

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…

Posted:

Tags: accessibility, css, html, pattern, usability, UX

Brief Note on Popovers with Dialogs

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…

Posted:

Tags: accessibility, html, usability, UX

Be Careful Using ‘Menu’

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…

Posted:

Tags: html, lingo, pattern, standards

Exposing Field Errors

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…

Posted:

Tags: accessibility, ARIA, browser, html, usability, UX

ARIA vs HTML

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…

Posted:

Tags: accessibility, ARIA, html, standards, usability, WHCM