There are people who seem to feel really strongly about this being a good thing for screen reader users, and I must admit to being bewildered about why. Websites changing aspects of screen reader output may be equitable, if we compare it with the way webpages can alter visual presentation through fonts and other aspects. But to me it feels entirely inappropriate to cross that boundary between the browser as the user agent and accessibility software in order to interfere with very personal settings.

Meanwhile on iOS, the related accessibility attributes are being used to achieve outcomes nobody wants or needs, like spaces between all the digits of a credit card number. @miki @prism

I can see the point for e.g. text-to-speech APIs built into the browser, maybe even read-aloud features. But the case for screen reader compatibility seems to be built on the foundational assertion that SR output is monotonous and can't be "livened up" by brands.

As assertions go, I think that is both true and exactly how it should be. I don't use a screen reader for entertainment. I can think of few things more obnoxious than a marketing person thinking that my screen reader should "shout this bit."

Many web authors can't even label stuff correctly. Why on earth would we expect them to treat this sort of feature with informed respect? @miki @prism

@prism I think without ARIA or an equivalent (like more things built into the web platform), the web would've continued galloping forward with all the same UI widgets and design patterns but with no way to make them even halfway accessible, and we'd be left even more behind than we are now.

By contrast, I don't think the inability for a website to change the pitch of NVDA is a legitimate blocker to anything worthwhile. @Piciok @miki

@miki I think it's a trap to suggest that such problems should currently be solved only through speech properties and auditory cues within individual apps. Expressive semantics on the web have only been explored at a surface level so far, and it's a complete stretch to go from "We don't have the ARIA properties to convey complex information," to "Let's have every application implement its own beeps and boops."

Imagine having to learn the sound scheme for Gmail, then Outlook, then Thunderbird. Then going over to Slack where they also have unread state albeit for chat messages rather than emails, but they use an entirely different approach again.

All the while, braille users are getting nothing, and people who struggle to process sounds alongside speech are becoming more and more frustrated. Even if we assume that this is being worked on in conjunction with improvements to ARIA and the like, how many teams have the bandwidth and willingness to implement more than one affordance?

We've already seen this in practice: ARIA has braille properties, but how many web apps use them? Practically none, because getting speech half right and giving braille users an even more subpar experience is easier. Your own example highlights how few apps currently let you control things like verbosity and ordering of information.

CSS Speech could turn out even worse. A product team might opt to implement it instead of semantics because the two blind people they spoke to said it would work for them, and never mind the other few million for whom it doesn't. They'll be the people complaining that there's no alternative to the accessibility feature a team spent a month on and thought was the bee's knees.

@silverleaf57 @prism @Piciok