The difference between keyboard and screen reader navigation | Hacker News Reader

The difference between keyboard and screen reader navigation

tink.uk

71 pointsUkiahSmith13 comments

I was at a conference the other week, and one of the big takeaways for me is how many people actually have some sort of disability. In the US for people aged 18 - 65 it's 10%, but for those over 65 it jumps to 37%.

It's easy to dismiss these statistics as 'not applicable to our customers', especially when you are a healthy twenty-something, but the statistics say that as we get older, 1 in 3 of us will have some sort of disability.

The talk also mentioned temporary impairments which restrict the way users can interact, similar to disabilities. What happens if you have a climbing accident and your mouse hand is in a cast for three months? Or maybe you are just on a train, holding the rail with one hand while it's swaying backwards and forwards.

I'd say 10% is low--the rate for dyslexia alone it's 15-20%.

Temporary impairments are a massive thing to consider! One example I recall was that Facebook learned video engagement rose massively when subtitles were added because most people scrolling through Facebook on their phone don't have sound on due to the environment (work, commuting, etc.).

Another example that I'm always complaining to designers about is that low contrast text might look fine when you are designing something on your desktop machine indoors, but take it outside on a phone and a sunny day might make it all unreadable.

I had this exact thing happen to me: https://mobile.twitter.com/csswizardry/status/10812788212806...

Verdict: we need to do better.

To sum up: screen readers critically depend on a proper document structure for efficient navigation, So, build a correct logical structure, then style it. Do not make everything out of divs and rely on CSS to render it nicely.

Screen reader is not the only reason to do that, but it is one reason. There are also other reasons why you should define the proper document structure.

I am a big fan of the viumium extension, it add easy keyboard navigation to any webpage. I'm not touching this mouse this if I can avoid it.

https://chrome.google.com/webstore/detail/vimium/dbepggeogba...

Mouseless for Firefox is great, too.

I've gone the other way. I'm using mouse gestures so that I can control my browser with a minimum of mouse travel, making keyboard shortcuts obsolete. Rocker gestures (hold left then click right and vice-versa) control my history, scroll gestures (hold right then scroll) scroll through my tabs, and regular gestures (hold right then draw a small figure) do the rest.

It's a very convenient and quick way to browse one-handed, like when lied back in a desk chair.

But on my old laptop I used qutebrowser for a while, which is a lightweight browser which also is focussed on vim-like controls.

Something we've been trying to figure out is how to get screen readers to play nice with a terminal emulator. We're building one as a webapp and had a pretty good solution in an old version of jQuery terminal, but the new one splits each character into its own span... So we're trying out xterm which builds out a whole aria tree, but simple concepts escape me like... How can a screen reader "scroll back and forth" between terminal output, without just redoing a terminal command and listening to the whole output all over again?

If you have a Windows machine handy, I suggest you grab the NVDA screen reader (https://www.nvaccess.org/) and try it out with the Windows console to get a feel for what a good screen reader plus terminal experience is like. I understand that the Orca screen reader for GNOME also has good terminal support, and I think JAWS for Windows does as well, but I'm more familiar with how it works with NVDA.

Here's how you move around the terminal with NVDA. For all of these commands, you need a keyboard with a numeric keypad, and NumLock should be off. I believe there are alternatives for laptops without a keypad, but I'm only familiar with the desktop layout. To read the current line, press numpad 8. To move to the previous line, press numpad 7. Next line is numpad 9. The same pattern applies for words (numpad 4-6) and characters (numpad 1-3).

Incidentally, on Mac, VoiceOver's terminal support is crappy enough that my friend Tyler Spivey wrote his own screen reader for the terminal environment, called tdsr [1].

[1]: https://github.com/tspivey/tdsr

http://emacspeak.sourceforge.net

Google Chrome supports a set of rational kbd warrior controls across Gmail photos, and the like.

i sometimes wish they'd bullied website Devs the way they did with amp to enforce hjkl vi/Emacs motion support.

Reply on news.ycombinator.com