
The difference between keyboard and screen reader navigation - UkiahSmith
https://tink.uk/the-difference-between-keyboard-and-screen-reader-navigation/
======
fyfy18
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.

~~~
JimDabell
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.

------
nine_k
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.

~~~
zzo38computer
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.

------
wrnr
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...](https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb?hl=en)

~~~
detuur
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.

------
komali2
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?

~~~
mwcampbell
If you have a Windows machine handy, I suggest you grab the NVDA screen reader
([https://www.nvaccess.org/](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](https://github.com/tspivey/tdsr)

------
ggm
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.

