I recently responded to a call for accessibility guidance on Mastodon. The author, a logician, frequently includes the abbreviation iff — short for “if and only if” — in his writing. He’d recently tested his content with a screenreader and found that iff sounded exactly like “if,” and he wanted some help making sure iff sounded distinct.
In logic, if versus iff is a very meaningful distinction. To borrow an example from Wikipedia, if Madison will eat a fruit if it’s an apple, then she’ll definitely eat any apples she comes across, but bananas or oranges are still fair game. On the other hand, if Madison will eat a fruit iff (if and only if) it’s an apple, then she’ll still eat any apple she comes across, but bananas and oranges are off the menu. Mistaking an if for an iff here, or vice versa, can mean entirely misinterpreting what a formal logic statement is saying.
While developers might reach for approaches such as ARIA attributes or the ol’ “visible-but-aria-hidden node plus the visually-hidden, screenreader-friendlier alternative node” one–two punch to try to force a particular pronunciation, the conventional accessibility wisdom here is instead to not override screenreader pronunciations at all, for a number of reasons. These override attempts often make braille display output much harder to read, and they can make it much harder to use other assistive technologies such as voice control as well. Crucially, overrides usually come from a place of assuming (and generally vastly underestimating) screenreader users’ familiarity with their screenreader’s pronunciation quirks and their comfort with their screenreader’s verbosity settings and navigation modes.
Is iff a special case? Does the possible confusion with if necessitate markup hacks to try and force a different pronunciation? I don’t know, and I’m genuinely not here to say. I think only user testing can give that judgment call. Instead, I’d like to propose a few steps one could take before using markup hacks to override screenreader pronunciations. If you’re dealing with your own case where you think a pronunciation override might be best, consider whether one of these options could work for you instead.
Let It Be
For logicians who use screenreaders, your iff is probably not the first iff they’ve come across, and it certainly won’t be the last. The same goes for other mathematicians, programmers, and other professions that rely on special symbols to communicate meaning.
In many cases, screenreader users with expertise in these fields have approaches for making sense of these symbols already. This might be inferring meaning from context, retreading the confusing text letter-by-letter, ratcheting up their screenreader’s verbosity settings when they know they’re in a symbol-heavy context, or leaning on custom pronunciation rules they’ve added to their screenreader for such a situation.
It’s also worth evaluating how serious the pronunciation quirk really is. When I worked at USAA, it was an occasional topic of conversation that the JAWS screenreader would pronounce USAA as “oosa.” As much as USAA would have liked to be pronounced correctly for brand reasons (and maybe that can be a reality someday with CSS Speech), internal accessibility subject matter experts, including some who are blind, generally advised against markup hacks, in part because anyone who was hearing “oosa” would figure out what that meant pretty quickly anyways. It was no more harmful than a GPS mispronouncing a street name — you chuckle for a bit, and then you move on with your day.
All this to say, your readers who use screenreaders may very likely already have techniques for dealing with unusual symbols, abbreviations, or pronunciation quirks, or those quirks might not be as critical as you might think at first, and so there might not be anything you have to do at all.
Still Let It Be, But Provide Some Guidance
The above might work just fine for someone who already has enough familiarity with a field to know how best to make sense of its text, but what about situations where someone might be coming in fresh such as a college course?
One option might be recommending your readers set up custom pronunciation rules in their own screenreaders. Here’s a few articles and tutorials you could point them to:
- Tutorial for using the JAWS Dictionary Manager
- Adding rules to NVDA's speech dictionaries
- Customizing VoiceOver on macOS
- Customizing VoiceOver pronunciations on your iPhone or iPad
It might be worth setting up a page where you provide guidance on adding custom pronunciation rules to one’s screenreader, along with a list of recommended rules for common confusing phrases you intend to use. From there, you’d just need to make sure that page is somehow discoverable, perhaps linked to from an accessibility statement. This has the advantage of fully empowering the reader to decide if and how to use the rules. Maybe they won’t add any rules at all — or maybe, they’ll decide that iff should be pronounced as “if F,” or “I F F,” or “if and only if.” Instead of you going through the work to hack the markup and slot users into whichever pronunciation you feel is right, you instead give readers the tools they can use to build whichever reading experience is best for them.
For what it’s worth, USAA has one such list of suggested custom pronunciation rules, which includes USAA, as well as abbreviations that are common in banking and insurance.
Rephrase and Unabbreviate
In some cases, you might be able to reword the text to avoid a contentious, confusing phrase altogether. In the case of iff, you might not be able to avoid it entirely in formal logic statements, but what about the surrounding prose? In many cases, it could be clearer to write out “if and only if” in full. In addition to being more explicit and not relying on pronunciation rules, verbosity settings, or markup hacks to get the point across, it’s also visually more distinct. If someone is scanning a page or reading quickly, iff is pretty easy to mistake for if, and that’s before adding low vision or dyslexia into the mix. In this case, the instinct to reach for a screenreader-specific hack could be a sign that this content is confusing or hard to read for lots of people in general.
Even if you can’t avoid all instances of the confusing text, you can still get some lift from rephrasing that minimizes the need for markup hacks elsewhere. Occasionally including the long form of an abbreviation alongside its short form, for instance, a la “intravenous (IV)” or the other way around, “iff (if and only if),” can be a subtle yet handy reminder to readers that possibly confusing abbreviations are in play, so they should be extra careful when reading the page. This is also a handy tactic for meeting the Web Content Accessibility Guidelines’ Success Criterion 3.1.4 Abbreviations (Level AAA).
Conclusion
Markup hacks meant to force a particular pronunciation in screenreaders often arise from incomplete understandings of how screenreader users navigate the web and unvalidated assumptions about how they would prefer to receive information, and they can shape a user experience at the expense of braille display users, voice control users, and more. Before reaching for a pronunciation hack, consider if it’s really necessary or worth the complexity you’re adding to your site, or if there are ways to rework the content or design to add clarity and avoid needing the hack in the first place.
Additionally, validate assumptions! If you can, get feedback from screenreader users. It may well be that they find leaving those phrases as they are really is confusing and untenable! I personally don’t believe we can avoid screenreader-specific hacks 100% of the time. If (and only if 😜) your user testing shows such hacks are necessary for comprehension, then by all means go ahead!