Re: NVDA's handling of checkboxes especially in Google Chrome


On Wed, Nov 17, 2021 at 04:43 PM, Gene wrote:
I’m curious why it was hard to understand.  Is it that being used to there being no cursor on web pages, the idea somehow didn’t make sense? 

This is a good question, and since the virtual cursor concept exists for JAWS and NVDA, I am going to quote a two sentences from the Microsoft Support page entitled, Use Microsoft Teams with the JAWS virtual cursor: "As the JAWS virtual cursor moves around on a web page or similar environment, no visible indicator is shown as to its location. This way you can move the virtual cursor outside the range of the content currently being displayed on your screen."

For someone who can see, as soon as the virtual cursor moves into territory not actually displayed on the screen I end up "in the weeds" very quickly.  This is all the more true because how screen readers decide to load a webpage into the buffer which the virtual cursor traverses often is at a big disconnect from the visual layout on the screen that structures things for the sighted.

When I first started working with JAWS the function (and I can't recall what they call it at the moment) that equates to focus highlight in NVDA did not exist.  I often would have no idea what my student was going to "land on" next because how the buffer was loaded was just so much differently than I, or anyone I know who's sighted, would have perused the copy on that webpage with our eyes.

Focus highlight, which keeps the display in sync with where the virtual cursor is located, and actually puts a visible indicator around the word, control, etc. on which the virtual cursor has focus was a godsend to me.  It was also one way I came to understand why I became so lost, because I could see how the pages were being traversed in real time, and how different the order of traversal often is compared to how I would ever have read those pages using my vision.  And I imagine that much of that ordering is driven by HTML structure, which is very different than the visual structure that HTML produces on the screen, or at least that's my theory.

I often wonder why something like focus highlight didn't make it into screen readers in general much earlier.  It's not that the target demographic for a screen reader actually need it, but one of the purposes of a screen reader (among many) is for workplace use.  I don't know of a single sighted person who doesn't get hopelessly lost when a screen reader is merrily reading all and is currently reading material that is multiple full screen scrolls down from what is currently displaying on the screen that a sighted coworker is looking at.  We "follow" with our eyes, primarily, and when the screen does not scroll along with what's being read we just don't know where in the document, webpage, whatever we are.

The best analogy I can give is if you're a Braille reader, it would be as if the screen reader kept going and going and going while your scanning finger was stopped at the bottom of the current page you're reading and was not able to continue scanning the text to determine where what's being spoken is actually located.  Unless you have the entire text memorized already, you have no idea what page the screen reader may be on.

Brian - Windows 10, 64-Bit, Version 21H1, Build 19043  

The ignorance of one voter in a democracy impairs the security of all.

         ~ John F. Kennedy


Join { to automatically receive all group messages.