by Michael Murdoch
I was recently helping a friend of mine troubleshoot an issue with a screen reader. I was unable to replicate it. The long and the short of it was he was using a completely different version of the software.
Upon investigation, I also found out that version of NVDA, which is terrific software, had a veritable laundry list of security vulnerabilities. All of these had since been resolved, but my friend was using an outdated version. There was no real way for me to know this without extensive probing on my part.
And the website he was on would have no way of knowing this either. Figuring a browser version today is relatively trivial with UA (User-agent) sniffing. Screenreaders do not send information though. This is because many screenreaders feel, and rightfully so, that they may be discriminated against if the software at the other end knows they are blind or visually impaired. The law in America hasn't been Plessy vs Ferguson's "Separate but Equal" since Brown vs Board of Ed in 1954. Unfortunately this is a very real problem after the Dominos lawsuit wherein Dominos argued they did not have to provide an accessible web experience to provide the same access to a blind man who wanted to order a pizza because he could call in an order, which really did harken back to the thinking of Plessy vs Ferguson's "Separate but Equal". So rather than do that, hopefully you engage with a better solution - universal accessibility on the other end of things using WCAG of course.
But the problem comes in on problem solving situations when you can't reliably troubleshoot user problems when there are additional complicating factors introduced by the screenreader using telemetry or related though.
Admittedly, while you can do something like this indirectly and detect ARIA usage, browser accessibility APIs, or forced colors it's normally inadvisable and really goes against the spirit of designing for universal accessibility. Directly detecting specific screen readers like NVDA from a web browser using JavaScript is generally not possible due to browser security and privacy restrictions. Browsers intentionally limit access to system-level information to prevent malicious scripts from identifying user assistive technologies.
This makes sense. If a user navigates to a malicious website, the screen reader will faithfully read the content of that site, including deceptive text designed for phishing or social engineering attacks. The screen reader itself doesn't filter or identify malicious intent. This is a general cybersecurity concern and safe browsing habits, avoiding suspicious links, and only visiting trusted websites. Obviously, keeping web browsers and antivirus software updated is also crucial. Still this is more acute in certain attacks if they were specifically designed to target screen reader users.
This presents an even more interesting problem in that upon trying to figure this, it's not nearly as difficult as I would have thought. Do these API calls need to be encrypted or further minified to ensure users do not need to fear being treated differently? What measures need to be taken?
While this may not seem like a revelation, it pays to ask if, while troubleshooting a problem related to the user experience of they are utilizing a screen reader or related accessibility software as this may not be immediately apparent, but yet may be a major factor. It's also not advisable to engage in circuitous means of determining if a user is using a screen reader, especially if you plan to deliver a stripped down or deficient version of the web experience.
Some well-meaning sites like Lenovo, who make the p330 tiny thinkstation I'm on right now actually do this. Not to deliver a deficient version of the site, of course as they are a reputable company who makes excellent products, but in an attempt to aid users w/accessibility issues. They also prompt, but unbeknownst to some users, this can actually break overlay accessibility with some software. So again, we have to circle back to that issue of whether or not this information should be transmitted. Should this usage of a11y APIs itself and the related I pointed out be treated as a form of PII? Here, even when done for a fine and noble purpose, it has resulted in problems. An errant click, and a problematic overlay result. Would it not have been better if Lenovo just simply asked?
Beyond that, going back to the versioning, the software can be set to auto-update or not, so it's really not that huge of a deal except in some workplace settings where administration and updating is more complex.
Another security concern is a screen reader vocalizes all content on the screen, including sensitive information. If a user uses a screen reader in a public place or within earshot of others, this sensitive data could be inadvertently overheard. Realistically, since this can be solved with headphones and most people in a secure installation will also have a Clearance, this isn't a very big issue unless the user works from home around uncleared individuals.
Oddly, this has never really been treated suitably, though there are several reasons why. First and foremost, for security reasons, the browser usually don't expose audio devices and hardware access is normally limited to the operating system. Second, while you could probably use some unholy combination of aria-hidden = "true" and navigator.mediaDevices.enumerateDevices() in most circumstances it will either not work, not read the text, or both. Plus, aria-hidden can have unpredictable effects since it will affect all children. Granted the secrets will stay secret, but the enduser probably won't be able to read them.
On a similar note, by default, and for security reasons, NVDA (and most other screen readers) are designed not to read passwords out loud character by character when they are typed into a standard HTML password field (). Instead, when you type into a password field, NVDA reads "bullet" or "asterisk" for each character typed. Or, it might simply say "password field" and then indicate the number of characters entered (e.g., "password field, 5 characters"). You can turn it off though as well, which is a security risk.
Hopefully, my stumbling about with this has aided you in thinking about this somewhat. Let me know in the comments if you have any input!
Top comments (0)