Why you should almost never use screen reader only text

“Why can’t we just use screen reader only text?” is a familiar question to accessibility engineers everywhere. It often arises when an accessibility bug requires an overhaul of the underlying HTML to make it more semantic and readable to assistive technology. Whoever said that HTML is the “easy” web programming language has never seen the ashen faces of a development team when you suggest that something that looks like a button should semantically be a element, and find out that would require abandoning a very entrenched third party plugin.

Screen reader-only text is often thrown out as a quick, easy, and accessible solution to an accessibility bug that would otherwise require a major HTML overhaul, and then it’s our job as accessibility engineers to make the case that even if it would make this particular bug go away, it’s almost always a bad idea. Here is that case.

Reason 1: Silos are for grain, not people

“Is there any way we could just detect if someone is using a screen reader, and then redirect them to a special site?” is another common question accessibility engineers get, and that too is almost always a bad idea for the same reason: siloing disabled users almost always marginalizes them in the end. When you have one page experience intended for you able-bodied users and a completely different one intended for your disabled users, almost always the disabled UX is inferior. Images that would have contributed color and insight to an article are dropped, because adding alt text is too onerous. Maybe the “Ask for help!” chat widget that’s available for able-bodied users is replaced with a phone number disabled users can call, because making the widget accessible is too difficult, even though one is far more convenient than the other.

Screen reader only text functionally silos disabled users into one experience of the page that is different from the able-bodied users of the page. It’s also almost always a measure taken where the goal is “accessibility compliant,” not a user-friendly experience. Disabled users deserve to access the internet in ways that are close to the way able-bodied users do, and they deserve to have their user experiences made pleasurable, not just compliant.

Siloed experiences also make it very difficult for disabled users to relate to able-bodied users when accessing the same page. Suppose Amy, a screen reader, calls over her friend Brian, a sighted user, to ask his advice on how to fill out this form field:

Thank you so much for filling out our address field! It means so much to us that blah blah blah blah

The address field should be for your home address if you meet X criteria and should be for your business address if you meet Y criteria

Address

Thank you so much for filling out our address field! It means so much to us that blah blah blah blah>

The address field should be for your home address if you meet X criteria and should be for your business address if you meet Y criteria

The following conversation takes place when Amy, a screen reader user, calls over Brian, a sighted user, for help:

AMY: It’s asking for my address, but there’s all of this text thanking me for filling out the form. Does it eventually tell me whether to use my home or business address?
BRIAN: I can’t even see that part of the page, and I’m sitting next to you. Could you scroll up?
AMY: I can, but when I start typing the page is going to jump down again.
BRIAN: Hang on, I just need to read the information above the field.
AMY: What information above the field? Do you mean the information below it?
BRIAN: I can’t see anything below the field, what are you talking about?

Amy and Brian are functionally looking at two completely different page layouts, even if they have the same information. Amy’s screen reader only text is below the field, Brian’s is above. Amy’s form field is lower on the page, Brian’s is higher. It makes it very difficult for Amy to get help from anyone who isn’t a screen reader user.

“I hear you,” you might say, “but MY siloed experience is going to be a DREAM! Screen reader users will be pampered and accommodated, and I’ll be sure to keep the screen reader only information RIGHT NEXT TO the visual information, so the UX will be the same.” That may be, but you will probably run into reason number 2.

Reason 2: Code rots, turnover happens, and priorities change

Congratulations, you’ve passed your accessibility audit! Somewhere on the page, you have some code that looks like this:

My Donation Amount

This is technically accessible – the right information is read aloud as a user comes across this form field. It would have been far better to change the

element into a element that’s programmatically attached to the , but that would’ve required a serious HTML overhaul of a darling 3rd party plugin, which was a non-starter for the deadline you had to meet.

Then, a month after the audit is complete and the accessibility engineers leave, the word comes down from corporate. They want everything on the page to be translatable into Spanish. Your code now looks like this.

It seems the engineer forgot that screen reader users are sometimes Spanish speakers too. Or maybe translationPlugin doesn’t accommodate aria-label attributes, only inner HTML content. In any event, we already have a worse user experience for screen reader users.

Then, a year later, the marketing team reaches out. “My Donation Amount” is confusing users who are donating on behalf of an organization; it should just say “Donation Amount.” Now your code looks like this:

You see, in the year that’s passed since the accessibility audit, several members of the development team left and were replaced by new members who weren’t as familiar with accessibility conventions, and they forgot to make sure the visual label matched the aria-label. What’s more, corporate needs a VPAT every 5 years, so they’re not going to be strict about making accessibility a priority for another 4 years. In the meantime, disabled users might be getting hit with the same confusion able-bodied users had when they saw “My Donation Amount,” but they’re not being accommodated.

Maybe in another year, the team will decide this form field will actually collect someone’s first name and forget to change the aria-label. In another scenario, maybe the information was put in a

element with screen reader only CSS applied, and the input field was ultimately erased while the developers forgot to erase the matching screen reader only text. There are a hundred different ways code can rot, engineers can have a forgetful moment or a third party plugins can fall short of accessibility requirements. Disabled users are almost always the first ones forgotten when site changes happen, which is why it’s so important to make sure they’re not siloed.

Reason 3: It’s a bandaid that side-steps real learning

Let’s give another example – the client has a widget that visually resembles a button element, but the code looks like this:

Boot camps and CS programs everywhere may only spend 20 minutes teaching good HTML (which is a subject for another blog post), but they almost always cover elements, and how they can be used to make a button on a page. If someone is doing something like this to their buttons, there are bigger problems with their HTML knowledge and understanding. What’s more, it’s likely they’re not aware just how much happens behind the scenes with a button attribute that would have to be hacked onto it in order to get an equivalent. Does it read as a button to a screen reader both when tabbing through it and when the b hotkey is pressed to cycle through the buttons on the page? Can it be activated with a click, an enter key press and a space bar press? Does it support the disabled attribute?

In this case, the developer might have passed over the element with a screen reader, heard JAWS read out the title attribute, and then congratulated themselves on a hack well hacked for getting an accessible name onto this element. The developer isn’t going to learn about the particulars of the element, or how inconsistently the title attribute is read across browsers and screen readers, or generally how to write good code in HTML, and they won’t carry that new knowledge with them when they develop other parts of the site.

Reason 4: We can’t guarantee screen reader-only CSS will stay that way.

Let’s do a little time travel, back to the year 2007. Smartphones and tablets were still a twinkle in Steve Jobs’s eye, all the cool kids had a Razor cell phone, and accessibility blogs told developers everywhere that if they wanted to add some screen reader only text, this was the way to do it:

/* DO NOT USE THIS CSS, I will tell you why in the following paragraphs */> .screen-reader-only { position:absolute; left:-10000px; }

This way, text would semantically happen in the right order you wanted a screen reader user to see it, but visually it rendered so far off-screen that it was invisible.

Then, touchscreens took the world by storm. And while this CSS still worked for most of them, some touch screens prioritized scrolling ease and availability to all content. And when these touch screen devices sensed there was anything off-screen, they simply made sure a user could scroll over to it.

Today the recommended CSS for screen reader only content involves clipping the content down to 1px in size. Right now, with our current technology, it works. Will something new come along that breaks it? Maybe. We can’t be sure, which is why it’s best to use semantic HTML and a non-siloed experience so that even if a new technological development breaks that convention, developers will immediately recognize that it is broken and fix it.

Of course, there are still going to be some times where screen reader only text is the right call. When and where is a subject for another blog post. But all things considered, it is almost always a better idea not to use screen reader only text if it can possibly be helped. Thank you for reading, and remember, semantic HTML is free!