Adrian Roselli

Your Browser Can Already Speak a Page

Adrian Roselli — Thu, 05 Mar 2026 14:13:59 +0000

Users can customize the features built into the browser, something not often available from third-party approaches.

Is an “AI” company offering to provide spoken versions of your pages for users? Is an overlay company promising to make your content more accessible by its overlay speaking it? Is some other vendor pitching you on some kind of thing that reads your web pages aloud to users?

You don’t need it.

Or, rather, your users may not need it. Their browser already offers it. At no cost to you. Nor them.

No Really, Try It

These features may not appear for pages that are not well-formed (lack a main region, are nothing but div-soup, etc.). If they don’t appear for your content, that’s a signal that you may have work to do on the underlying HTML. Any fixes you make would likely result in a better experience for everyone.

Instructions for common browsers:

In Firefox on desktop, you can enter reader view (F9) and then activate the headphone / “Read aloud” button (N).
Chrome:
- in Chrome desktop, right-click, choose “Open in reading mode”, and then hit the play button (K).
- in Chrome mobile, activate the “More” kebab, then choose “Listen to this page.”
Edge:
- Edge on desktop offers the Read Aloud feature (Ctrl + Shift + U).
- Edge on mobile uses the immersive reader, where you can choose “Read aloud” from the toolbar.
Safari:
- on iDevice Safari, activate the “Page menu” button (the double-underlined rectangle on the left of the address bar) and choose “Listen to Page.”
- on macOS Safari, choose “Edit” from the menu bar, then “Speech,” then “Start Speaking.”

In most cases, users can choose the reading speed and voice, pause or restart it, and even jump back and forth through paragraphs. This is more control than third-party products offer.

But Also

If an “AI” company offered on-demand or pre-recorded audio, they’re leveling up our overall destruction of the environment.

If an overlay vendor offered it through its overlay, you’re adding legal risk, trusting them to not be liars, letting them track your users, and assuming it will work. Because, as I’ve documented extensively, overlays don’t work (sometimes at all but usually as advertised).

Any other vendor is probably a mix of data harvester, crypto miner, scam platform, or government panopticon node.

Users who most benefit from a page being spoken to them know about browsers’ built-in features. Those users may rely on extensions for even more control. They are unlikely to benefit from (or care about) these third-party offerings.

However

If you have good research, not provided by the vendor, that your specific users are asking for this specific feature then sure. Go for it. But also track its use and understand you’re taking on the vendor’s risks as your own — for those users whose blockers don’t block it.

Honoring Mobile OS Text Size

Adrian Roselli — Fri, 06 Feb 2026 20:35:57 +0000

If your users scale the text size in Android or iDeviceOS, that doesn’t always affect the size of text on a web page. It’s a function of browser and authored code, as opposed to a standardized approach. That may be changing.

Support

The current state of affairs in the three rendering engines…

Firefox

Firefox on Android supports scaling a web page’s text if you adjust the system font size. It doesn’t seem to care if you use px units. You don’t need to do anything special; it just works.

Safari

Safari will not scale a web page’s text with the OS settings unless the author adds some CSS. This code points to the system font properties (such as size):

body {
  font: -apple-system-body;
  /* other styles, including font-family */
}

This feature query checks for support while trying to limit it to touch devices only, then sets the font size:

@supports (font: -apple-system-body) and (not (-webkit-touch-callout: default)) {
  :root {
    font-size: 100%;
  }
}

The rest of your styles have to use relative units or this breaks down.

Chrome

Google has opted not to follow Firefox’s lead and support OS text sizes by default. Google has also opted not to mimic Safari and make platform-specific features. Instead, Google has decided to use its weight in the CSSWG to mint a new value for the element:

For this to work, however, the author will need to “opt-in” by not setting a base font size in your CSS:

body {
  /* font-size: yeah, no */
}

You actually can set one, but it should be a percentage. You then need to avoid fixed units (such as px) throughout your site. If this seems familiar, it’s the core thesis of my aptly-named post The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet.

Read Josh Tumath’s post Try text scaling support in Chrome Canary for more details.

Frankenstyle’s Monster

Let’s combine those into one set of code that will work in Safari and now Chrome. Firefox was always on point, so no effort needed there.

Add this HTML to the of your page (it’s the CSSWG code):

Add this to the CSS of your page (it’s Apple’s code):

body {
  font: -apple-system-body;
  /* other styles, including font-family */
}
@supports (font: -apple-system-body) and (not (-webkit-touch-callout: default)) {
  :root {
    font-size: 100%;
  }
}

Done.

Frankenstyle’s Demo

I made a demo. It has images and a table. Visit the debug version in your mobile browser.

See the Pen Untitled by Adrian Roselli (@aardrian) on CodePen.

How to Test Frankenstyle’s Demo

Seriously, visit the debug version in your mobile browser. I’m not dealing with desktop here.

With your Android device, install Chrome Canary from the Google Play store. If you are using an Android device with another app store, I leave it to you to sort that out. Then, using chrome://flags, enable Experimental Web Platform Features in Chrome Canary.

Android

In Android, go to Settings → Accessibility → Display size & text; in the Size options section, go to Font size and make it as large as possible.

The smallest Android text size setting and then the largest setting.

iDevices

In iDevices, go to Settings → Accessibility → Display & Text Size → Larger Text, toggle Larger Accessibility Sizes, then drag that slider all the way to the to max.

The smallest iPadOS text size setting and then the largest setting.

My Results from Frankenstyle’s Demo

These are before (small text) and after (largest text) images of Frankenstyle’s Demo. Your experience may differ. If you’re reading this from the future, it may differ a lot.

None of these required a browser reload. It may take a moment, so be patient.

Firefox

Frankenstyle’s Demo in Firefox on Android, behaving just as it would without the Frankenstyles.

Safari

Frankenstyle’s Demo in Safari on iPadOS. I scrolled the second one a bit to show the inline images.

Chrome Canary

Chrome Canary showing Frankenstyle’s Demo.

You Know What? Just Don’t Split Words into Letters

Adrian Roselli — Thu, 05 Feb 2026 17:45:05 +0000

This is an unplanned part two for Barriers from Links with ARIA. The title reflects my exasperation because this isn’t new, I’ve simply failed to be explicit about it over the last decade or so.

In 2012 I vented about TypeButter using for each letter. In 2020 I noted the AWWWards site wrapped every letter in a

for animation, which screen readers presented letter by letter. In 2022, it was BeeLine Reader using s to achieve gradients across a word.

In 2026 I am finally writing about it because GSAP has its SplitText plug-in asserting screen reader support that doesn’t stand up to use. I appreciate the embedded video explains how it should work, and even includes an unnamed screen reader demo, but GSAP assumes authors will use SplitText in a very specific way and fails to note potential problems. That’s a bummer because now I have to be the buzzkill.

GSAP’s Demo

This is the animation demo on the SplitText page (or go to the debug view if you want to test it):

See the Pen SplitText Demo by GSAP (@GreenSock) on CodePen.

I also made a fork, just in case GSAP changes the code later (which would mess with future testing).

The simplest way to test this is to fire up a screen reader and try navigating the page with whatever method you prefer. You may get different results than I did, but that’s the fun of testing! Though I did get confirmation from one, then another, then a third screen reader user.

If you press the “Characters” button, this is the HTML output of the first line of text (which is in its own

Five words.

The ARIA Non-Solution

The demo uses a

, which in the HTML AAM maps to the generic role. The problem here is that the generic role does not allow itself to be named by the author — which means aria-label is prohibited on it.

The example code GSAP offers, however, shows headings instead (which allow aria-label). It makes no mention of the restrictions on which roles allow aria-label. An author might think nothing of using aria-label on a

. Kind of like the embedded GSAP demo.

When aria-label is used on an element that allows it, the GSAP page makes no mention of other risks. I’ve repeatedly said aria-label may not auto-translate for users. It also doesn’t talk about WCAG SC 2.5.3 Label in Name risks when aria-label is applied to any control.

Hiding Content

Kind of a nitpick, but the GSAP page links to a CSS-Tricks post that itself simply links to Scott’s Inclusively Hidden post. Scott’s post got an update in 2023. CSS-Tricks’ post did not. I consider that a disservice to both Scott and readers.