|
|
|
|
|
by bryanrasmussen
1995 days ago
|
|
well, the fact is the use of a screen reader (or at least most) can be detected relatively easily by having an element in the screen reader flow that is hidden from sighted users, and if you wanted for extra surety having an element that will be interacted with by anyone accessing the page - but that is hidden from screen readers but available to sighted users. detecting interaction with visually hidden element, but no interaction with visually shown element, can be registered as screen reader. Obviously this can also happen with bots, but probably you would prefer to register the bot as screen reader rather than to try to filter them out and inadvertently filter out a screen reader (which can often happen with bot filtering strategies anyway) |
|
This isn't true, at least not enough to be useful. The majority of screen readers present web pages in a kind of virtual buffer, which users can browse with the arrow keys and other shortcuts (e.g. H to jump by heading). In this mode, the majority of screen readers don't fire focus events to let you know, "hey, your screen-reader-only element has been hit". You would be limited to:
1. users operating a screen reader which does fire focus events;
2. trying to highjack scroll events for this purpose; and
3. less technically-inclined users (read: beginners) who move through the page with Tab/Shift+Tab before they've learned the other keystrokes their screen reader offers.