New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make braille_previousLine and braille_nextLine functional outside of text content #4097
Comments
Comment 1 by jteh on 2014-04-28 08:51 The issue is that outside of text controls, the concept of "line" is far less clear.
|
Comment 2 by msuch (in reply to comment 1) on 2014-04-28 09:53
|
Comment 3 by jteh on 2014-04-30 07:05 |
Comment 4 by msuch (in reply to comment 3) on 2014-05-01 11:23
|
@dkager, @LeonarddeR, @bramd, this is technically a "feature", but users tend to think of this as a deficiency rather than a nice-to-have. Thoughts on priority? Does every other screen reader do this? Any ideas on how to address the issues described above? |
@jcsteh Well, now I think of it, I think every screenreader does at least something when pressing braille up/down. I haven't used JAWS extensively for years, but if I remember correctly, scrolling up/down would bring you out the structured mode and into line mode. The line mode in JAWS displays what is kind of the equivalent of a line in NVDA's screen review mode. And yes, on the desktop that means that you would miss the rest of the columns on your focus line. JAWS has a toggle to link braille scrolling to the control of the cursor, so you simulate arrow keys when scrolling up/down. And yes, as sometimes also happens in NVDA's screen review, you don't see things or don't see anything at all. Back in the days the line mode and JAWS cursor worked best with old style window controls and would fail with more modern applications that needed UIA/MSAA to interact. JAWS now has something called the touch cursor to improve that situation, but I'm unsure how that works together with a braille display. Supernova also allows scrolling up/down with a braille display and will show lines on the screen ,I'm unsure how a focus on a line with multiple columns, such as on a desktop, is handled. I think @dkager can fill us in there. I'm unsure how/if we should handle this, but here are some considerations:
|
Marking as feature. |
Yes, we discussed (1) in the last call. I'm still a big fan of this, but there are some issues that we also discussed. I'm interested in a combination of (1) and (3), assuming that flat review is reliable enough. I guess it makes a stronger cse if both touch and braille rely on it. Scrolling through screen lines works and is even quite efficient, but only when you are used to it and when the underlying app supports it. This is where JAWS/SuperNova are struggling a lot nowadays. |
I agree with 1 and 3, with the exception that I"m not sure whether the flattened object hierarchy should be used. When moving up and down on the desktop, for example, I think it would be enough just to move through all the icons on the desktop (i.e. next/previous object), but only on that level in the object hierarchy. Flattened object review is a bit broad, and you get things you don't expect (i.e. when you are on the first desktop icon, flattened object nav brings you back to the parent list). |
Yes, flat review is most intuitive for left/right, not up/down. But then what do you do with up/down? Simulate arrows? That isn't always appropriate. |
Wondering if this could still go somewhere. Like this being more broadly defined as "next" and "previous" appropriate unit. In edit controls, this is lines, since that is the most obvious. In other contexts, this could mean next and previous object, so like flicking right and left on a touch screen. Routing buttons could then be used to focus/execute on that new object. I realize this would move away from the strict line concept. But as screens are so dynamic on Windows anyway, and hardly ever one line of icons on one computer matches the same set of icons on a second, unless all parameters like screen resolution etc., are exactly the same, the only place where lines actually are conceptually exactly that, are edit controls anyway, I think it would make sense to broaden the scope of next and previous. What do you all think? |
Reported by msuch on 2014-04-28 07:49
On Seika, Braille_previousLine is bound to b3and braille_nextLine is bound to b4.
They don't work as I would expect:
They work fine when in a text editor, pressing b3 gets to previous line, pressing b4 gets to next line.
The problem occurs when in a list, for example on the desktop or in a menu like NVDA menu.
Pressing b3 or b4 does nothing, I would expect then to bring me to the previous or next item.
The text was updated successfully, but these errors were encountered: