Be wary when adding additional context only for #screenReader users. An example:
Say you're working on an e-commerce site, and some products have two prices to show how great a sale discount is. The before and after is made visually apparent via some aspect of text formatting, and you want to make it explicit for screen reader users too.
The first step is to ask if this is necessary. If a user encounters two consecutive prices and one is lower than the other, they may intuitively understand what's going on without any explicit signposting, and can verify how much they're gonna pay during the checkout process. Only your users can provide this verdict.
If it's determined that some additional context is helpful, you could format it as something like: "Was $14.99, now $8.99" (optionally swapping the prices). It's short and punchy in braille and speech, perfectly descriptive of the situation at hand, and mirrors how it may be spoken out loud on an ad.
Resist the temptation to go further than this. You do not need to say "original price: $14.99, current sale price: $8.99". This is much longer and more verbose, while adding nothing. It also implies that you think screen reader users need to be told what a price is and explained the concept of a sale, even though you're not doing so for other audiences.
You also don't need to spell out the word "dollars", format the price in words, repeat the product name, and so on. If you find yourself with screen-reader-only text like: "The current price of 500 Grams of Premium Oolong Tea was fourteen dollars and ninety-nine cents, and is now on sale for eight dollars and ninety-nine cents", it has gone way too far.
In short: Set out to identify the problems that actually need solving, and only solve those problems.
@jscholes Enter departure station name - Mandatory field - The autocomplete information will be displayed after entering the first character. Use the UP and DOWN arrows to move between the subsequent results. Use the ENTER button to confirm the station selection. menu pop up edit text
@miki I encountered some dropdowns on a survey recently that essentially followed this script. Only they also slipped in the unhelpful sentence, "touch devices are also supported", at the end. As it happens I was using a touch device and it took me about five minutes to work out how to select a value.
@jscholes Yeah, that hint used to also be present on mobile, though I don't think it's the case any more.
@jscholes People over-explaining stuff to screen reader users is one of my pet peeves. “Should we write out this phone number as individual number words so that the screen reader does not announce it as a large number?”
@yatil @jscholes Actually, just write it like the locality in question writes their telephone numbers, there's bound to be a dash in there somewhere. Synthesizers, and some screen readers, can cope with this. For example, I live in the US and use a synthesizer that speaks in an American accent. I can write the number 888-555-1234, or the sometimes used (888) 555-1234, and my screen reader clearly says eight eight eight, five five five, one two three four. It even has a specific type of intonation pause for reading phone numbers like that. Now granted this means it won't do well with something like UK numbers because the scheme is different. What I might recommend is separating the country code from the number with a space. Else the country code bleeds into the number and if it does activate number words, plus eighteen billion etc, that would be confusing.
@jscholes i agree mostly with what you say although your middle oint isn't too far
@jscholes What screen readers besides NVDA indicate strikethrough, especially by default? I know NVDA says deleted, which is slightly confusing at first, but having it read out the basic visual indicator of this is a price which has a line through it and this is the new price right next to it is reasonable and works for everyone, as long as there's enough of a semantic space or the screen reader puts one between the font changes to avoid the actual numbers blending. Unsure how this is indicated in Braille, though. Do the tables have an indicator for strikethrough?
@x0 Not really sure on any of this; I must admit to having those formatting indications disabled because I find them quite irritating. I also think that FS received complaints after exposing them by default in JAWS and ended up rolling back the change, but don't quote me on that.
@x0 @jscholes
Here's an article about that, data last updated in September 2023.
Screen Readers support for text level HTML semantics.
The <del> element is announced by JAWS, NVDA, and iOS VoiceOver; when style reporting is enabled, macOS VoiceOver and Windows Narrator announce its default strikethrough styling.
https://www.tpgi.com/screen-readers-support-for-text-level-html-semantics/
@cwilcox808 @jscholes Thanks for the resource!
@jscholes Not sure what you did, but I got 8 copies of this toot. lol!
@mcourcel I edited it slightly, which causes Mastodon to send out a notification to everybody who reposted and/or favoured it.
@jscholes
I'm still dreaming of a world where the alt text, after the description, also contains something like: "special for the readers of this description: you can get an additional 10% off with the code 'descriptiondiscount'."
@jscholes this is a great post! Whenever people ask me how they should format webpages for accessibility I tell them to think about how it would sound if they plugged the text raw into their computer's TTS (name-dropping "Microsoft SAM" if elaboration is necessary) since that's how most screen readers get used.
Another good way to have them visualize it is to tell them to move the page to a folder that doesn't load their CSS, JS, and images when served, and ask them "can you still understand what the page is saying?"