Re: web sites detecting a screen reader
toggle quoted messageShow quoted text
I am not currently aware if any windows browser exposes the API you referenced in your email below. A lot of companies would like to get their hands on these metrics. The accessibility community is quite against this practise. For the simple bases, you are not developing web technology to support all users or in other words you are not using Human Centred design. The biggest fear comes from the old days of only text-only web pages built for screen readers. Technology today has the ability of supporting everyone, if best practises are used.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Joseph Lee
Sent: Sunday, 11 October 2020 12:51 PM
Subject: Re: [nvda] web sites detecting a screen reader
Ultimately, it is up to operating systems (such as Windows) to reveal this information to web browsers. On Windows, screen readers can inform Windows that they are active through a Windows API function named SystemParametersInfo (part of user32.dll), which is meant to be used by apps to adjust their workings, and I bet web browsers can expose this information to web authoring engines. Because this is a website-specific thing, I think it would be best to ask web authors to adjust their interfaces on the fly or add a box to suppress this (that last bit will be cleared if you delete web cookies).
To expand upon the API discussion: a few weeks ago some NVDA users working on PowerShell said an alert about PSReadline was issued at startup. A conversation with PowerShell team at Microsoft revealed that this is due to screen reader flag detection, which ironically uses the same Windows API function mentioned above (the difference is which flags are passed into modify system parameters globally). Apparently this was in response to reports that PSReadline module (used for cursor movement, editing and such) wasn’t working well with older NVDA releases, and I advised Microsoft to test PSReadline with newer NVDA releases.
As for web accessibility and screen reader detection on the web, an ongoing discussion between web standards stakeholders (web authors, browser vendors, assistive technology vendors, standards bodies, academics, and such) deals with how should software interpret seemingly conflicting ARIA (Accessible Rich Internet Applications) specifications. For example, should screen readers enter application/focus mode automatically when encountering what is essentially a web dialog, or how should screen readers announce form field descriptions and such. Making matters complicated is the speed of web development as you will find yourself meeting new browser releases every six weeks, and that “web standards implementations” on PC’s have pretty much became a battle between Mozilla on one side and Google and friends across the court. At first glance, NVDA may appear to provide the same experience, but trust me: there are internal differences between what Firefox says versus what Chromium family tells you (which, by the way, extends to how NVDA supports accessibility API’s, which merits a separate discussion; I’ll take a stab at giving you a tour of such topics if requested).
OK I am a strong believer in using Google to find answers before I ask one here. Giving me the term SR flag did not help much in resolving this issue. I tried all kinds of searches using SR flag and got nothing. Maybe you can be a little more helpful in hiding the screen reader from web pages.
On 10/10/2020 6:59 PM, Joseph Lee wrote: