Comment by dredmorbius

6 years ago

There used to be a saying in a11y circles, "Google is a blind user".[1]

Now Google are manifestly anti-blind-user.

Shouldn't be anything a major ADA lawsuit couldn't fix.

Meantime, DDG is actually pretty damned good. For console users: https://duckduckgo.com/lite

________________________________

Notes:

1. https://www.w3.org/2006/Talks/06-08-steven-web40/

72 comments

dredmorbius

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

  • dredmorbius  6 years ago

    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.

    • CAMLORN  6 years ago

      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

      17 replies →

  • mlang23  6 years ago

    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.

    • CAMLORN  6 years ago

      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.

    • mwcampbell  6 years ago

      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.

      1 reply →

    • commandersaki  6 years ago

      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.

at_a_remove  6 years ago

Back when I did web design stuff and I couldn't get anyone to put any effort into accessibility, I would "sell" the concept as it being SEO: search engines see what we put in for text, not images. Accessibility for humans is accessibility for Google.

It was pitiful that I had to do this but there you have it.

anonygler  6 years ago

LOL. Do you know how goddamn strict Google is, internally, regarding a11y/i18n/l10n?

The idea that your precious text browser == blind people is wildly presumptuous. Don’t use people with disabilities as your human shield.

  • CAMLORN  6 years ago

    Strict or no, Google actually fails at accessibility a lot. The basically broken unergonomic keybindings in docs for starters and the entire fiasco that is Android come to mind immediately. For a really "fun" fail that's recent, Youtube recommendations are now a live region. This means that if you leave that tab focused, your screen reader just starts reading things while you're trying to play music and are across the room and can't stop it. That seems like a minor example except the whole point of Youtube is hearing things so that's kind of a big ball for someone to drop, thinking that live regions are a good plan. Things have improved some (I no longer hate the GCP console) but my point is that strict about accessibility doesn't mean good at accessibility by any means, and Google has a deservedly bad reputation in blindness circles that they earned over a very long time.

jld  6 years ago

Is there a way to make DDG Lite chrome's default search engine?

Chrome seems to let me create non-default search engines, set the full DDG as the default, but not set lite as the default.

  • jolmg  6 years ago

    The problem is that the search query does not go in the URL in the Lite version. That really sucks. It makes it useless in the browser history as well. In fact, because all the URLs are the same on each query, they're not even added as separate entries in the history.

  • dredmorbius  6 years ago

    For desktop, I believe so. Not for Android.

    I've fully ditched Chrome desktop for Firefox, however.

    Other than the landing page for search itself, the distinction doesn't much matter. If you set web search as a homepage or bookmark, you can definitely do it there, however.