Live data from Hacker News

I am no longer able to use Google with Lynx

blind.guru

181–190 of 333 posts

Re: I am no longer able to use Google with Lynx

#181

Try googler https://github.com/jarun/googler

A fundamental principle of the Web is that site-specific clients or apps shouldn't be necessary. That they are only underscores Google's massive blunder here. Yes, there've been CLI wrappers around web queries before. Until the past few years, these simply addressed search format, URI arguments, and namespace. They launched in the user's choice of browser, text or graphical. Surfraw is the classic, I've written a few…

> A fundamental principle of the Web is that site-specific clients or apps shouldn't be necessary.

Perhaps, but the Web is now effectively requires Chrome, or things which look enough like it.

Re: I am no longer able to use Google with Lynx

#182
post #44

Earlier quoted context omitted.

The standards just describe what to do to make a standards compliant HTML page, what tags are allowed etc. There are no standards that say that e.g. your page can't be all dependent on JS. In other words, Google could be 100% standards compliant, and not work in Lynx.

The grammar of the English language does not forbid one to write in Greek, but if you choose to write in Greek only, you will compromise on a lot of people being able to understand you. The same with standards, and you are misunderstanding on purpose. If Google chooses to not support simple HTML, then they are choosing to not support countless accessibility tools, and they know it. Some blind people will have a more…

Google shouldn't be restricted to a subset of the available technology because a niche browser isn't updating to available technology. Yes, a side-effect of this is that the blind community using Lynx can't use Google. While unfortunate, it's also a tiny, tiny, TINY community.

If you want to be upset, be upset with Lynx for falling behind. Or don't be upset and switch to JAWS, BRLTTY, Orca, etc. But the idea that anyone is supposed to support every possible browser is just silly.

Re: I am no longer able to use Google with Lynx

#183

Earlier quoted context omitted.

It doesn't feel faster to me. And that's the case with Ajax in general - in principle , it can allow for snappier, faster experience. In practice, it rarely does.

I just measured it: switching between "drafts" and "inbox" on the new gmail takes ~15 ms, while on the simple HTML view, it takes 3-500ms per load. Its literally 20 times faster, and importantly, cuts across the human visual perception boundary, which is at ~200ms. So the old HTML version is human perceptible, while the new version renders in ~1 frame.

Fair enough. On a fast enough machine. This is off-topic, but while on my beefy dev desktop I get similar times to you, this was absolutely not the case on a much weaker laptop I used sometimes during travel - and the latter is more representative of how regular people experience things.

(Also, FWIW, loading delay of HTML pages on said beefy desktop, as tested right now, are consistently about 750-1500ms for me.)

More on-topic, these times apply only when the pages are hot in the browser cache. On my desktop, the first-time switch between "drafts", "sent" and "inbox" takes around 3 seconds each, and only then it is instantaneous. So regular users are likely to experience these long Ajax delays more often than not.

Re: I am no longer able to use Google with Lynx

#184

Earlier quoted context omitted.

The capabilities are there. The dev experience is there (somewhat; JS ecosystem is a mess, but I guess that's just a side effect of moving very fast). But the capabilities are not used for end-user benefit. Not much, anyway. Yes, I benefit from Netflix, I benefit from Google products (not as much as I would if they didn't keep on worsening the UX every few months) - and such functionality requires some of the new cap…

I think a pizza ordering site is a good SPA example, but progressive enhancement still applies. React probably makes its design simpler. Elm would, even more so. But it’d be nice to access it with Lynx.

And I think a pizza ordering site is a good case for server-side and mostly static HTML. There's very few things on such page that change more often than every few days, and as for the dynamic stuff, all you really need to manage is a client-side basket, which is trivial in isolation. I believe you could easily cut the time spent on such site by a third if you approached it this way. Even more for people accessing the site from older machines.

I can tell, because I order pizza quite frequently from a variety of sites.

Re: I am no longer able to use Google with Lynx

#185

Earlier quoted context omitted.

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…

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

Re: I am no longer able to use Google with Lynx

#186

Another person notes that ddg is inferior. Maybe people get used to a certain way of searching with Google that doesn't translate to ddg. Haven't noticed a drop in quality myself and I think I might have been retrained to use different patterns and techniques in structuring my queries.

I think Google's results have become dramatically worse, and I've become better at DDG. I now often find it difficult or impossible to find what I want on Google, and straightforward on DDG. I also use the bangs all the time now, they're great.

Re: I am no longer able to use Google with Lynx

#188

Earlier quoted context omitted.

Yes and no: Ajax allows interactive (snappier/faster) behavior in most cases, especially for complex interaction flows. Using the minimal html Gmail interface vs the modern one, the modern one is quicker for complex interactions because I end up loading fewer pages,even if the average load is more expensive.

It doesn't feel faster to me. And that's the case with Ajax in general - in principle , it can allow for snappier, faster experience. In practice, it rarely does.

It depends on the application though. Mapping apps (e.g google maps) without ajax are awful.

Even basic UIs like filtering can be bad if you want to change multiple filters, and you have to wait for a whole page load in between each change (page load times for pages with filters are often slow as they're performing complex queries).

It's a case of different things being appropriate for different use cases I think. There definitely are still times when plain HTML is best, but it's also not always faster.

I've built a React app that's under 300kb (cached with a service worker for subsequent page loads) that loads almost instantly and works offline. On the other hand, plenty of plain HTML sites include heavy CSS frameworks, or 5mb images, gifs, etc and load pretty slowly, especially on poor connections.

Re: I am no longer able to use Google with Lynx

#189
post #141
post #69

Startpage.com, a Google proxy, still works fine in lynx.

Unfortunately, they got bought: https://news.ycombinator.com/item?id=21371577

Wow, first Private Internet Access, now startpage? What's next, the next Waterfox version will be based on Chrome!?

Starting to feel like Luke Skywalker and Princess Leia in the trash compacter, the walls are closing in.

Re: I am no longer able to use Google with Lynx

#190

Earlier quoted context omitted.

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…

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]…

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.

Post reply on HN