Comment by duskwuff
6 years ago
Blind users do not, as a rule, use Lynx. This is a common misconception. The Lynx interface is, in fact, very poorly suited for visually impaired users, as it relies heavily on visual layout, color, and cursor positioning to convey information.
The majority of blind users use standard desktop web browsers with screen reader addons like JAWS or VoiceOver.
The blind user in TFA might be surprised at your assertion.
Blind users typically rely on screen-readers, including tools such as emacsspeak (which relies on either Emac's built-in eww browser, w3m (of which I believe eww is based), lynx, etc.
The ability to rely on console-based tools with text-to-speech capability, and receiving typed input, is fairly widespread.
The requirement that interactive content be rendered directly to speech is key.
I am blind. I know or have known at least 20 other blind people sufficiently to know what their browsers are. None of them used Links. One of them used Edbrowse. The rest (including myself) are Firefox, Chrome, or Safari. I have at least one personal project (not public) which uses React heavily. Saying that Links is necessary is an outdated view, so much so that we have things like the accessibility object model [0] in progress to possibly go so far as even supporting use cases like remote desktop connections in the browser by making fake screen reader only nodes in the accessibility tree.
In general, the terminal itself is even not so great. There are efforts like Emacspeak which mandate learning what is essentially a second desktop environment, but outside that it turns out that offering semantics (which only non-text browsers and apps can do) is useful: for example knowing whether or not the cursor is in a text editor, so that deletions are significant, or whether text is a table.
The idea that JS is bad for screen readers--or indeed that we use text-based browsers--is a consistent misconception that is no longer true. It was true 10 or 15 years ago, if not longer, but everything AT has come a very long way since then.
For a source that's not just anecdotal, this has info on primary browser: https://webaim.org/projects/screenreadersurvey8/
0: http://wicg.github.io/aom/explainer.html
> The idea that JS is bad for screen readers--or indeed that we use text-based browsers--is a consistent misconception that is no longer true.
To be perfectly blunt, I feel this misconception is pushed mainly by people with an "anti-javascript" agenda.
If one can no longer argue that "supporting non-javascript clients is the only way to support accessibility", one is only left with "if you break support for non-javascript clients, you will only be excluding people who deliberately disable javascript". And at that point, the amount of effort to support non-javascript vs. the return on investment shifts heavily in favor of not caring about users who intentionally disable javascript. This is an argument I've had in every shop I've worked at and at the end of the day in every instance we decided it was simply not worth the hassle to support people who intentionally disable javascript.
In fact, I'm pretty sure any competitive search engine these has to have a very complex crawler that is more than able to deal with javascript rendered pages. If they didn't, they'd be leaving a ton of content out of their indexes--not a good look for a search engine. So not even the "you have to support text-only browsers to please google" argument has most likely fallen out of favor.
10 replies →
I suppose that you are unaware of the spelling difference. You literally can't see it. I'll separate the letters for you:
They were discussing this: L Y N X
You switched to this: L I N K S
Both of those are text-based browsers. I agree that the one you were writing about would be terrible for blind users. The other one is better.
Wikipedia links for those browsers:
L Y N X is at https://en.wikipedia.org/wiki/Lynx_(web_browser)
L I N K S is at https://en.wikipedia.org/wiki/Links_(web_browser)
1 reply →
Experiences vary, I'll grant that.
There's also a difference between those who acquire perceptive limitations (sight, hearing, also motor control, etc.) later in life, whether through accident, injury, illness, or degeneration, and those who have limitations from birth or a young age. Having to learn some (admittedly arcane) interface such as emacs late in life, with fewer capabilities and often declining cognitive capabilities, is difficult.
And yes, mainstream commercial software and OS offerings are improving. Slighty. (Most are still abysmally poor.)
I'm hard-pressed, though, to see how an increased dependence on dynamic and programmatic web design elements improves accessibility. Especially when wielded by technologists, managers, and clients with little awareness or concern for such access.
Again: Google should be much better positioned to grasp this than most. They clearly don't.
3 replies →
You are falling for a pretty common misunderstanding. While many blind people use text-to-speech in combination with a classical "screen reader", that is not the end of the story. There is another major technology called Braille. And in countries where there is a good social system, blind people actually own so-called Braille displays. That applies to me, for instance. I am pretty much a pure braille user. Sometimes, when I use a Windows machine, speech will rumble along, but I really primarily rely on what I can feel beneath my fingers. And for braille display users, Lynx is really a nice option.
I own a braille display and use the 93-volume trigonometry textbook from high school and the logic around it with respect to making sure the right chapter was in the classroom with me as an analogy when explaining CPU caches to people. In the long run I discovered that incredibly fast speech rates scale better than braille for most tasks outside educational settings, but if it works for you, by all means use it. And before someone inevitably makes the "but braille is important for literacy and brain development" point: it is, and I advocate learning it.
However, putting the burden on site developers to support text-based browsers for this use case is O(sites) but putting it on the screen reader developers is O(1). In other words only the latter scales. Braille isn't a very good argument for site authors supporting text-based browsers from any practical perspective, and in all honesty I think most of them would find this off-putting. It's already hard enough to get people to do accessibility; if we make the bar as high as that and go around claiming that it's necessary for accessibility, no one will ever bother.
It belatedly occurred to me that blind people who primarily use braille may have a different perspective. I and most of the blind people I know are American, so we're accustomed to primarily using TTS. (I'm partially sighted, but I often use a screen reader for non-programming tasks.)
Still, it seems to me that accessing a GUI through a structured accessibility API would have advantages over accessing screen-oriented terminal programs, even for braille-only users. For example, there are all the quick navigation commands that JAWS introduced and most other GUI screen readers have copied. The screen reader is also free to reformat text in a way that's optimal for a braille display. Wouldn't it be nice to be able to read text in smoothly flowing paragraphs, uninterrupted by screen line breaks? I suppose that's not an issue if you exclusively use computer braille and the width of your console is a multiple of the length of your braille display.
Sadly the screen readers do actually do a not-so-good job of this, but I think that may in practice be more a function of poor UI for switching indicators on and off. You get 80 cells at most, and even the most conservatively unambiguous abbreviations for controls are going to use 2-3 letters of that. Hit a line with a few links and half your display is gone. I'm not enough of a braille user to know how to go about fixing this for sure, but there is definitely an inefficiency. Ending up in a "but my favorite text-based browser is more efficient" position because it turns a bunch of this off, or because it's configurable in a way your favorite screen reader isn't, or etc is something I can see happening, but nonetheless the real issue there is that screen readers need to be fixed, not that we should go ask all the sighted people to support Lynx.
NVDA's flow for deciding which formatting you care about is to tab through a list of 30 checkboxes. They have hotkeys when the dialog is open but it's still less than ideal if, as I suspect, braille users need to change them more often. And there is also a potential education problem around teaching braille users that the way they get more efficiency is to change them around all the time.
My solution in the world of infinite resources would be to make the cells 5 or 6 dots high so that you can put the formatting in line with the characters it's for. That's something I thought would be useful for a long time. But sadly we live in the world where good braille displays will forever be expensive and thus doubling the price isn't doable.
I used to be legally blind and heavily vision impaired. Even then, the most accessible web browser is Lynx since it runs in a Terminal which has a fixed and rigid UI.
I'm frustrated for you.
Are you saying the OP is lying about being blind or is a fake?
Perhaps I spoke a little too broadly. What I meant is that the bulk of blind users don't use lynx. This particular one appears to -- sometimes? -- but this usage is not typical.
...in your circle
4 replies →