Skip Navigation
Blind Main @rblind.com soloActivist @links.hackliberty.org

Do screen readers read mouseover text when the alt attribute is empty (alt="")?

A public library’s website has iconified buttons instead of textual buttons; I assume to make it easy for those who don’t speak the local language.

The code snip looks like this:


           <div>Wifi</div>
     
 
           <div><p></p>
</div>

Will that cause problems for blind people considering alt=""?

I don’t have a screen reader or whatever tools blind people use, so I’m somewhat blind in being able to know if the website is reasonably accessible. Lynx shows the button descriptions just fine, so I think if a blind user ran #Lynx with a screen reader the UX would work. But what if a GUI browser is used in order to run JavaScript? I loaded the site in a GUI browser with image loading disabled and the text description (“WiFi” in this case) does not appear unless I hover the mouse over the substitute icon for the missing icon. So the question is: do a screen readers handle that okay?

EDIT: Shit, my HTML code was gutted by #Lemmy even though it was a code block thus making the above code useless (calling that a #LemmyBug). Perhaps it’s not important for answering my question. (bug reported)

4
4 comments

  • Yes, you do have a screen reader: Narrator on Windows, VoiceOver on macOS, Orca on most Linux distros. This may be a wild assumption, but you haven’t said “by the way I use Arch,” so it should be safe.

    Either way, that’s testable with Axe DevTools or even most browsers built-in auditing tots.

    An empty alt attribute will hide the element from screen readers though. It’s possible there’s another element in there that’s the actual alternative, but I’d have to read the code.

    • Orca is not installed by default on Debian. But I would be interested in seeing what the built-in tools do. In Firefox I hit F12 » Elements and saw an “accessibility” tab. From there I expanded a quite long tree of nested elements and got down to the hyperlinked image. Then I looked at the console frame with the link highlighted. There were over 30 messages with 6 errors. It’s very noisy. None of the errors or warnings indicate that the object would not be readable by a screen reader. It’s stuff like net::ERR_BLOCKED_BY_CLIENT and JSON parsing syntax errors.

      EDIT: this error looks interesting:

      city:60 GET https://cdn.equalweb.com/core/4.5.6/accessibility.js net::ERR_BLOCKED_BY_CLIENT

      If I understand correctly, Firefox is trying to run accessibility.js but because cdn.equalweb.com is a #Cloudflare site, I am blocked (Cloudflare is Tor-hostile). There’s a bit of irony here that a domain name “equalweb” leads to a discriminatory web server. I’m guessing this blocks Tor-using Firefox users from checking the accessibility of a webpage using FF’s built-in features.

      EDIT 2: it turns out accessibility.js is loaded by the site, not FF. So I’m not sure how to use the built-in functionality to answer the question.

      • I wouldn’t expect a JS file dedicated to accessibility to be necessary, but it could indicate a bad retrofit. Or not, who knows.

        If you want to get deeper into testing with Firefox, you can check out this guide. Either way, I’m kinda curious about looking at the website myself, if you wouldn’t mind sharing a link.