mastodon - Link to source

“Don’t Override Screen Reader Pronunciation”
adrianroselli.com/2023/04/dont…

#a11y #accessibility


Don’t Override Screen Reader Pronunciation

When many devs, testers, and authors first start listening to content through a screen reader, they are surprised to hear dates, pricing, names, abbreviations, acronyms, etc. announced differently than they expect.
Adrian Roselli
#a11y #Accessibility
in reply to Noah Carver Has Moved

mastodon - Link to source

Noah Carver Has Moved

The capitalization of Roman numerals in Roman numeral analysis is critical information for theoretical score analysis as it shows a chord's quality, thus MS4 announces when a numeral is lowercase rather than uppercase. Choosing not to modify pronunciations leaves a user unaware of this information unless they check each numeral individually, requiring them to select the numeral and enter editing mode to read character by character.
in reply to Noah Carver Has Moved

mastodon - Link to source

Noah Carver Has Moved

I didn't realize this was a problem until I began using MuseScore after using another notation program, Sibelius, for a semester. During my time with Sibelius, I had to constantly check Roman numeral analysis the hard way to ensure all numerals were capitalized correctly. MuseScore's announcement of lowercase Roman numerals means I can review a score quickly and efficiently in a way that wouldn't be possible if designers hadn't elected to purposefully modify pronunciations.
in reply to Adrian Roselli

mastodon - Link to source

Jamie Teh

@noahcarver There's also a subtle but critical difference between modifying pronunciation and altering the text that is exposed. The latter should not be done to achieve the former, as it breaks braille and review by character. Unfortunately, current a11y APIs don't provide a way to distinguish these two things, though there's been more discussion about it lately in the W3C Pronunciation Task Force.
@Noah Carver Has Moved
⇧