It's still early in 2023, but one of UsableNet's most popular webinars this year featured a blind presenter sharing his screen and experience while shopping on two e-commerce websites. Both websites were for large, well-known brands.
The featured presenter was Joseph DiNero, Assistant Program Director of Assistive Technology Services at Helen Keller Services for the Blind. In his work at Helen Keller Services, Joe teaches people who are blind or visually impaired how to use assistive technology to aid them in becoming more independent. Like me, Joe is blind and relies on Assistive technology to navigate the digital world. Because of his work and experience, Joe would be considered a "super-user" of assistive technology. In addition to working with Helen Keller Services, Joe is the head of the user testing team here at UsableNet.
If you joined this webinar, you had the chance to watch Joe share two website accessibility examples and the differences for a screen reader user when browsing a website with a strong foundation in digital accessibility and browsing a website with more work to do around web accessibility. If you couldn't join this live webinar, you can now watch the recording, "Web Accessibility for eCommerce: A Blind Customer's Perspective."
During the webinar, many attendees asked about screen reader accessibility and digital accessibility. I had the opportunity to review the questions, and in this post, I will answer a handful of the webinar questions to clarify some essential points about digital accessibility.
Before we begin, I want to remind readers that I write from my experience as a blind person who relies on my screen reader. That said, here we go!
Accessibility statements are significant, but not the end all be all in digital accessibility.
Accessibility statements show that the website owner knows accessibility requirements and how important it is to comply with relevant guidelines. The presence of a statement shows us that the company is actively working to improve the user experience for assistive technology dependents. This being said, I had encountered many websites that have excellent accessibility statements but are poorly optimized for screen reader use. While accessibility statements are a good sign and a definite step in the right direction, they do not guarantee that the site lacks accessibility problems.
When a screen reader speaks vague terms such as these, it usually suggests a labeling issue in the website's code. All buttons and links on a website must have corresponding text labels in the code to be correctly detected and read aloud by a screen reader. For example, suppose an image of a cart depicts the shopping cart button on a website. In that case, the term "Shopping Cart" must be attached to the button in the code so that the screen reader knows what the graphic means. If the text label is absent, the screen reader will announce meaningless terms like "Button" or "Image." If the software continuously speaks the word " blank," it can suggest either blank spaces in the text of a website or improperly labeled buttons, links, or other navigation elements.
The short answer to this question is no. In most cases, cure-all accessibility solutions such as accessibility widgets only allow the user to change settings on the site, like text size and page background color. While this functionality may be helpful for low-vision users, it offers little value to those who rely on screen readers. In most cases, the screen reader button in the accessibility widget enables a separate screen reader built into the website.
Not only are these auxiliary screen readers incredibly primitive, but they interfere with the primary screen reader, leading to a clunky and virtually unusable experience. Unfortunately, cure-all web accessibility widgets are not the answer to the problem of web accessibility.
While automated scans can help with the testing process, the best and most accurate way to evaluate a website for screen reader accessibility is through manual and user testing. Through manual tests, experienced real-world screen reader users can detect accessibility defects on a website that automated testing can miss.
Emails are susceptible to all of the same accessibility problems as websites. Unfortunately, I've found that emails are often neglected during a company's accessibility initiative because they are not part of the main website. I suspect this is because marketing usually writes and sends email communications, and some companies may not include the marketing department in digital accessibility training. Unfortunately, this lack of training and awareness frequently creates accessibility issues for me as a blind customer.
Read more about my experiences with email accessibility here.
Call-to-action buttons such as "Add to Cart" or "Proceed to Checkout" are super important. Often, these buttons are not labeled correctly and cannot be detected or activated by screen reader users. In other cases, the buttons have the wrong label and erroneously direct the user to a random site part. The call-to-action buttons sometimes have tiny touch targets on mobile devices, making locating the button by touch challenging.
The biggest price-related issue I face on shopping sites is the data presented using heavily stylized numerals that screen readers usually do not detect. Using plain text numbers to display the price generally solves this problem. However, my screen reader will sometimes miss the decimal period and announce the price incorrectly.
There is no exact science to this. A good rule of thumb is that all visual details in the image should also be available to assistive technology users. The text should be as detailed but concise. Therefore, it is essential to avoid lengthy multi-sentence paragraphs when possible because these will often bog down and delay screen reader users.
Yes, as long as you include any information presented in the image in the product description. An image caption is necessary if visual data in the item image is not in the text description. In this case, directing the user past the picture using the skip navigation link is inappropriate.
These cookie pop-ups could be more annoying and frustrating for screen reader users. For example, the small "X" button that represents the "Close Window" button is often not screen reader detectable. Even if my screen reader can find the button, it is rarely appropriately labeled. These pop-ups are often missed during accessibility audits because they are not necessarily a persistent site attribute present during manual testing.
For example, suppose a site has one of these cookie pop-ups. In that case, it is essential that the window can effectively be navigated and dismissed by assistive technology users because it is usually impossible to proceed on the site without closing the pop-up.
When in doubt about the experience of a blind customer on your website or app- ask a blind customer! I'm happy to answer questions like these, and I hope that if you have read this far, you found my answers helpful.
Your site may pass an automated accessibility scan, but that doesn't necessarily make a positive, accessible experience. That is why it's critical to include people with disabilities in your accessibility testing program, a practice that UsableNet promotes and follows in its services.
For more on how to build your accessibility testing program - check out this ultimate guide to accessibility testing.
If you couldn't join this live webinar, you can now watch the recording, "Web Accessibility for eCommerce: A Blind Customer's Perspective."
Editors note: This is a post written by our marketing intern, Michael Taylor. This post reflects his opinions and experiences. Read more about Michael and some other posts on his experience online here.