Editor's note: Michael Taylor sorts the screen reader barriers he runs into by how badly they hurt him, from unlabeled checkout fields that end a purchase outright to keyboard traps he can escape, and each one is a failure you can check for on your own site. New to the topic? Start with what a screen reader is and how it works.
Not every accessibility issue hits me the same way. Some are minor annoyances that slow me down, and others are complete showstoppers that shut me out of a task. Every time I face a new digital experience, I am asking myself which kind I am about to run into. In this post I will walk through the issues that stop me cold, the ones I can get around, and the workarounds I have leaned on over the years.
In my experience, a few types of accessibility issues can be total showstoppers and completely shut me out of a digital experience. The first is text labeling, and it's surprisingly huge. When buttons, links, and text input fields are not labeled correctly for screen reader recognition, it is often impossible for me to complete a task.
I recently used an e-commerce website where none of the text fields in the checkout form were labeled. I had no idea what information the fields were requesting, so I could not complete my purchase.
On another website, I tried to buy a pair of shorts. The color options were not labeled and were spoken simply as "Icon, Graphic." That meant I could not buy those shorts unless I was content with getting a random, unknown color.
A second type of issue that is typically a total blocker is a web element that goes completely undetected. I recently ate at a restaurant that used online bill payment. There was a checkbox for payment terms that had to be selected before I could submit payment, but my mobile screen reader could not detect it at all, regardless of the navigation method. That meant I could not independently pay the bill online.
A third major blocker is when a screen reader announcement contradicts the interface's visual state. I recently bought an item online that came in three different water capacity sizes. According to the spoken state of the variant chooser on the product details page, the largest capacity was selected. When the item arrived, it was the wrong size.
I returned to the page with a sighted user, who told me that even though the screen reader was saying large was selected, the interface visually showed medium as the chosen variant. It was not necessarily a blocker in the moment. But receiving the wrong item because of an accessibility flaw completely defeats the purpose of shopping online in the first place.
Other accessibility issues I encounter are still problems, but I can usually work around them. Most of these are clunky and slow me down, but they do not completely break the core functionality of the experience.
The first example is readability issues, which I mention frequently in my other blogs. Sometimes the way a screen reader announces information is confusing and illogical. For example, when I browse a list of account transactions on a banking website, the screen reader sometimes reads each detail of a transaction separately, such as the date, type, and amount.
Moving through each transaction component manually like this takes longer to find the transaction I am looking for, and it's much harder to keep the details straight. That being said, I can usually manage and complete my original task.
A second example is alternative text image descriptions. While these are incredibly helpful and enrich the experience, I can generally use a site as intended if the images are not described. The exception is when an unlabeled image contains necessary information or serves as an action button or other interactive element key to the experience.
Keyboard traps are another flaw I can usually overcome. They can be very annoying, but I can normally find a way to get focus out of the trap and keep going down the page.
For example, my cellphone provider's website has a known keyboard trap about halfway down the bill summary screen. If I jump focus directly to the bottom of the page, I can work my way back to the trap. Is this annoying? Yes, but it's doable.
The theme is that when these issues are in play, I can still complete my task, but the experience is not what it should be by a long shot.
As a screen reader user for almost twenty years, I have developed some workarounds to accessibility issues out of necessity. They don't work in every case and seem to lead to more failures than successes, but they have saved me on several occasions.
The first workaround I use from time to time is text analysis of a screen capture. Let's say I am trying to complete a web form that has several unlabeled action buttons at the bottom. I can take a screen capture of the page and run it through an OCR processor to try to extract the visible text labels on the buttons. It does not always work, but it has gotten me out of a few jams.
A second workaround that has helped a few times is using the camera and a text recognition app on another device. I hold that device up to the screen of the device I am having trouble with. If the problem is that something isn't being read aloud as it should, this sometimes unsticks me because the second device reads the visible text or web elements on the problem site.
As I described above, I can sometimes play games with the focus position to get past a trap or around a part of a website where focus behavior is erratic or otherwise incorrect.
This isn't technically a workaround, but experience has taught me to rely on context clues when I run into accessibility issues. For example, if I am on a product details page and find two unlabeled buttons directly below the product price and quantity picker, there is a good chance they are "Add To Cart" and "Buy Now." If the stakes aren't too high, I usually use trial and error to test my theory.
To wrap up, not all accessibility issues affect me in the same way. What I want to keep in focus, though, is that all accessibility problems hurt the experience and need to be fixed in the end.
And while workarounds are born of necessity and can help screen reader users get out of a jam, they are not a replacement for, or an excuse for, accessibility compliance and good design.
On the site I described, I could not finish the purchase. I could tell there were text fields, but nothing told me what each one wanted, so I had no way to fill them in. That is one problem I cannot work around.
It happened to me. The variant chooser announced the large size as selected, but the page visually showed medium, and I got the wrong item. I only found out after it arrived and a sighted person looked at the page with me.
Sometimes. On my cellphone provider's site, I jump focus to the bottom of the page and work backward to get around the trap. It works, but it is annoying every time.
Usually not for me. It matters when an image carries information I need or acts as a button. If one of those is not described, I can get stuck.
They get me out of a jam sometimes, but they fail more often than they help. They are something I fall back on, not a fix.
From the UsableNet team: Michael's blockers come down to the screen reader saying nothing useful or saying the wrong thing. On your own site, check whether every checkout field, button, and product option (like a color swatch) announces a real label, whether required controls such as a terms check box can be reached at all, and whether the announced selected state matches what is on screen. Michael's earlier post on what he wants developers and QA teams to understand about screen readers is a good companion to this one.
Sorting barriers by severity can help decide what to fix first, but the ones Michael can work around still need fixing. Barriers that stop a screen reader user from finishing a purchase or a payment are the same ones that show up in accessibility complaints, and finding one is a reason to look at the rest of the journey rather than a single fix. If your team does not have the developer bandwidth to work through them, UsableNet Assistive is a managed service: our developers remediate and maintain accessibility issues on your live site through a JavaScript layer, with legal indemnity included under the terms of the agreement.
Schedule a consultation to talk through what your checkout, forms, and payment flows sound like to a screen reader user.