Skip to content.
Adrian Roselli
Outsourced Distrbuted Ledger System SME

All Posts Tagged: browser

Brief Note on aria-readonly Support

TL;DR: Support for aria-readonly is nearly non-existent for the roles I tested. Should you need it, you cannot rely on it. You will be better off revising the pattern where you think you need it. For some background, the aria-readonly property: Indicates that the element is not editable, but is…

Posted:

Tags: accessibility, ARIA, browser, standards

Your Accessibility Claims Are Wrong, Unless…

Now that it is a market differentiator to talk about accessibility in projects, that’s all many do — talk about it. In a sea of pop-dev noise, “accessibility” can be claimed with little risk someone will challenge it. If someone does, the response is often a fine balance between silence…

Posted:

Tags: accessibility, browser, rant, standards, usability, WCAG

It’s Mid-2022 and Browsers (Mostly Safari) Still Break Accessibility via Display Properties

It was late 2020 when I last tested how browsers use CSS display properties to break the semantics of elements. I had been waiting for Safari to fix how it handles display: contents for four years now, and was excited when the announcement came in June. Then I started testing…

Posted:

Tags: accessibility, browser, Chrome, css, Firefox, html, Safari, tables

Internet Explorer Still Does Not Go Away Today

At the start of 2016 I wrote Internet Explorer Does Not Go Away Today because back then IE up to version 11 was being retired. But not Internet Explorer 11. I asked an AI (Neural Blender) to give me a picture of the Internet Explorer logo on fire. It’s almost…

Posted:

Tags: browser, internet, Internet Explorer, rant, standards

Keyboard-Only Scrolling Areas

I have spent a few years banging on about ensuring scrolling areas on a page are accessible to keyboard-only users. This is partly because the term “keyboard” maps to other input types that we distill to “keyboard” for ease of reference (speech input, sip-and-puff, on-screen keyboards, scanning software, etc.). When…

Posted:

Tags: accessibility, browser, Edge, Firefox, Safari, usability, UX

24×24 Pixel Cursor Bookmarklet

9 May 2023: The 2.5.8 language has changed. For the latest bookmarklet and language, skip ahead to the 9 May update. The proposed WCAG version 2.2 has gone through a bunch of revisions since I covered the first draft in 2020. One new success criterion that persisted is 2.5.8 Target…

Posted:

Tags: accessibility, browser, standards, WCAG

A “Best viewed with…” Gag

I made some pointless things again. The First One See the Pen Best viewed in… by Adrian Roselli (@aardrian) on CodePen. A spinning box for each word is not exactly a compelling interface element, I admit, but I based it off this old tweet that was sitting around in a…

Posted:

Tags: browser, css, html

Brief Note on Buttons, Enter, and Space

Keyboard interaction note for just one control from the entire panoply of HTML controls: A native <button> fires on key down when that key is Enter. If you hold down the Enter key, it continues to fire for as long you hold Enter (or something crashes). A native <button> fires…

Posted:

Tags: browser, html, pattern, UX

Accessible Description Exposure

If you have little experience with ARIA, screen readers, or testing in general, understanding accessible descriptions can be trickier than understanding accessible names (already confusing for many). I have written explanations so many times for clients and in fora that I opted to put this together so I maybe never…

Posted:

Tags: accessibility, ARIA, browser, standards

Column Headers and Browser Support

Data tables need column headers. Monolitten, a granite column of humans (each with a head) at Vigelandsanlegget, a sculpture park in Frognerparken in Oslo, Norway. What they probably do not need is a new set of column headers every few rows, particularly not when they change the meaning of the…

Posted:

Tags: accessibility, browser, html, tables

Reference: SRs and Extended Characters

This post serves no purpose other than to demonstrate the fidelity of screen readers when announcing non-emoji Unicode characters when using default settings. There is no judgment on which is correct. This is simply for reference. I grabbed the following tweet and recorded it across common screen readers (WordPress ate…

Posted:

Tags: accessibility, browser, Chrome, Edge, Firefox, Safari