The days are getting shorter, the temperatures are getting cooler, and the spooks are in the air. Halloween is almost upon us, and I feel it is the perfect time to talk about frightfully bad accessibility.
I wrote a similar blog last year highlighting some common accessibility flaws that I deemed to cause a particularly horrifying web usage experience when in play. That post only pertained to desktop websites. If you're curious about desktop-specific accessibility issues that can haunt the user experience, check out last year's post here.
I will revisit this topic this spooky season. However, I will discuss issues related to touch-based screen readers on mobile devices. These defects are significant accessibility blockers that usually scare me away from using a specific website or mobile application.
Spooky Button Labeling Issues: Making Icons Accessible
Because mobile websites are visually optimized to run on devices with smaller displays, icons, graphics, and small images are often used to denote commonly used buttons and links to conserve screen real estate. Suppose these symbol-based buttons do not have proper text labels in the code. In that case, mobile screen readers will not process the button correctly. They will announce vague, meaningless terms like "Image," "Graphic," or "Symbol."
Suppose some or all of the buttons on a mobile website do not follow correct labeling conventions. I will have tremendous difficulty using the site as intended, mainly because mobile websites rely on small graphic buttons for internal site navigation and feature activation. Some areas where I find unlabeled icon buttons are the top navigation bars of mobile websites and the bottom tab bars in apps.
Sometimes, I even encounter incorrect button labels when there is a visual discrepancy between the button's symbol and function. For example, when a graphic of the print letter "X" is used to denote a "Close" button, a mobile screen reader will sometimes announce this button as "Add." I believe this is because the print letter "X" is visually similar to the "Plus" icon often used to symbolize an "Add" action.
Developers should follow best practices for button design to ensure better accessibility. My blog on button accessibility for screen readers provides more detail and guidance.
When I encounter a website with these issues, the ghosts and ghouls of inadequate button labeling are very successful at scaring me away from the site.
Navigational Nightmares: Ensuring Consistent Access
When navigating a mobile website, I typically use a combination of two different methods: manual swipes and direct touches. Manual swipes allow me to move through the page one web element at a time or by a specified category, such as buttons or links. Direct touches let me pinpoint a specific spot on the display and hear what falls directly below the exact place where my finger contacts the screen.
Both navigation methods have pros and cons and are helpful in different scenarios. One of the most frightening accessibility issues is when not all items on the site are accessible through all navigation methods.
For example, the "Add To Cart" button on a product details page on a shopping site may be spoken by the screen reader if the user touches the button. However, that same button is difficult to discover if the person is manually swiping through the items on the page in search of the button. This sort of thing happens far too often.
The worst part is that there is no way to tell if this issue is in play when visiting a new website. When I am having trouble completing my task, it is not always apparent if the problems are specific to that navigation style or are a fundamental limitation affecting the site's core accessibility.
The result is usually a slow, clunky, inefficient, and sometimes even unsuccessful web usage experience. Navigation inconsistencies like these are a fear-invoking part of using mobile websites as a screen reader dependent.
Watch this video to learn how a blind user navigates a website. It provides a powerful example of the challenges and frustrations involved.
Text Input Frights: Overcoming Form Accessibility Challenges
One of the most frightfully bad areas of mobile screen reader accessibility is text input. So many websites struggle to offer an accessible and usable experience for navigating text fields and entering data using the virtual keyboard.
When entering text on mobile websites or applications, I usually encounter an accessibility problem. One of the most significant issues is unlabeled text fields, which confuse me entirely about the information the digital system requests.
Another area of incredible frustration is when the site discloses that fields marked with an asterisk are required, and the screen reader doesn't announce which fields are required. This flaw usually leads to me filling in all fields as a precaution and potentially providing more personal information than I would like.
Perhaps the worst text entry shortcoming is when the virtual keyboard visually covers some text fields, and the screen reader focus refuses to move to the covered fields. I must repeatedly dismiss the keyboard whenever I want to move focus into a text field obscured by the floating keyboard.
This experience dramatically slows me down and drastically increases the time I take to complete the digital form. Text entry accessibility defects most definitely have the potential to spook me into using a website with better accessibility.
The Haunting Importance of Accessibility Standards
There are so many accessibility issues that can lead to poor experiences for mobile screen reader users. However, some are scarier than others. The scenarios I highlighted above are some of my personal worst nightmares.
As we strive for better accessibility, it's important to note that WCAG 2.2 is the new international standard for web accessibility. This updated guideline offers more comprehensive criteria to ensure your digital content is accessible to all users, including those relying on screen readers. For more information, check out this blog post on WCAG 2.2.
When mobile web developers can ensure that these and other similar flaws are not present on their websites, mobile screen reader accessibility will begin to trend in the right direction.
TL;DR: Scary Accessibility Issues in Mobile Web Design
This Halloween, we explore the frightfully bad accessibility issues that plague mobile websites, especially for screen reader users. Critical problems include poor button labeling, navigational inconsistencies, and text input troubles. These issues can create a hauntingly frustrating experience, scaring users away from websites that fail to prioritize accessibility.
Key Takeaways: Exorcising Accessibility Flaws
- Button Labeling is Key: Ensure all icons and buttons have proper text labels to prevent screen readers from announcing vague terms like "Image" or "Graphic."
- Consistency in Navigation Matters: Both swipe and direct touch methods should provide access to all site elements. Inconsistencies can lead to a confusing and inefficient experience.
- Text Input Accessibility Needs Attention: Unlabeled fields, missing required field announcements, and keyboard obstructions can create significant hurdles for users filling out forms.
- Focus on User Experience: Developers should prioritize fixing these accessibility flaws to create a smoother experience for mobile screen reader users.
- Beware the Accessibility Ghosts: Addressing these common issues can significantly improve mobile accessibility and help users feel welcome rather than scared away.
For now, I will take refuge in the pumpkin patch and continue using websites with fewer accessibility ghosts and skeletons.
Editor's Note: Special thanks to our Guest Contributor, Michael Taylor, for having a little fun with us in his 2nd annual Halloween post! Read more blogs about Michael's experience as a screen reader user here.
