
I am no longer able to use Google with Lynx - mlang23
https://blind.guru/endofgoogle.html
======
mbrukman
Hi Mario,

I am an engineer on Google Search frontend.

Thank you for posting this, and I'm really sorry and saddened to see this
broken; this is certainly not intended behavior.

I've reproduced the issue you described in the blog (Lynx does not allow
clicking on the search results page). Even though Google serves valid HTML to
Lynx, it's probably HTML that Lynx cannot parse, and since it used to work
before, this is a regression. I filed a bug for our team to look further into
it and address the root cause.

Interestingly enough, pressing <L> shows a list of links in the current
document, and it does show all the available result links, so Lynx does see
and parse them, it's just not rendering the links inline with the search
results, so that's something we have to investigate as well.

In the meantime, as a temporary workaround, if you're open to using Chrome
with a simple UI that would be amenable to a screenreader and keyboard
navigation, you can use a User Agent switcher extension by Google [1] to set
the user agent header to Lynx [2] and Google will serve the same HTML that it
would have served to Lynx. You can then use the <Tab> key to iterate over the
search results, and <Enter> to select a particular result.

I look forward to seeing this bug resolved, and will be personally following
up on the status of this bug.

Again, I'm really sorry to see this, and I hope we'll be able to restore your
ability to use Google with Lynx shortly!

[1] [https://chrome.google.com/webstore/detail/user-agent-
switche...](https://chrome.google.com/webstore/detail/user-agent-switcher-
for-c/djflhoibgkdhkhhcedjiklpkjnoahfmg)

[2]
[https://developers.whatismybrowser.com/useragents/explore/so...](https://developers.whatismybrowser.com/useragents/explore/software_name/lynx/)

~~~
mlang23
Thanks a lot for this positive reply! I am thrilled to read that this might be
counted a regression and actually fixed. I really hope that can happen.

Regarding 'L', Lynx sometimes "hides" links if the anchor is around a div.
Maybe it is just that simple. IIRC, <a href=...><div>...</div></a> will
trigger a similar behaviour.

Regarding your Chrome suggestion, that really doesnt help me much since I
spend 99% of my workday on a plain virtual console. The context switch of
moving to another computer that runs Windows for simple searches is really not
practical.

Again, thanks for spotting this and acting on it!

~~~
mbrukman
Hi Mario,

Your analysis is correct; the issue was due to <div> tags appearing inside <a>
tags. This should be fixed now; I've verified that I can follow result links
using Lynx.

Once again, my apologies for you running into this issue! Thank you for
reporting & debugging it and thank you for your patience as well.

I hope this is resolved for you now; please try it out and let me know whether
or not it works for you, or if you run into any other issues.

------
jrockway
I feel like many of the text-mode browsers have failed to keep up with
changing web standards. We were all mad when IE was holding back the Internet,
and I'm not sure we should give lynx and w3m a pass because they're geek
tools. (Accessibility is an important concern, but web browsers running under
a GUI system support screen readers.)

[https://www.brow.sh/](https://www.brow.sh/) is a console-based browser that
claims to support modern standards. Perhaps that is what we should be using.

(I am now prepared for 6 comments replying to me saying that anything that can
be implemented with HTML from 1999 should be, and a list of search results can
be. I guess. If all that stuff works for everyone, why did we invent new
stuff? Just because? Or perhaps it wasn't really as amazing as well all
remember.)

~~~
TeMPOraL
I'll be the first (EDIT: third) of six.

> _If all that stuff works for everyone, why did we invent new stuff? Just
> because? Or perhaps it wasn 't really as amazing as well all remember._

To better track people and push ads. It's really mostly just it. Modern web
has very little to do with providing value to the end-user; any utility that's
provided is mostly a side effect, and/or a vector to lure people into
situations where they can be monetized.

Text browsers aren't holding the web down, they're anchoring it in the port of
productivity, even as the winds of commerce desperately try to blow it onto
the open seas of exploitation.

~~~
blauditore
Come on, you can't be serious about this.

Creating sophisticated web pages is massively easier than 10 or 20 years ago.
Yes, HTML of plain simple text-only pages is still pretty much the same, but
most users actually prefer visually fancier content with pictures and colors.

Yes, companies presenting themselvses online profit of more capabilities. And
yes, presenting ads is probably easier too. But if you think those changes
were just made because of monetary greed, you could say the same about almost
any technological advancement, like color photography, or electric cars,
because all of these had a commercial side to them too.

~~~
TeMPOraL
I am serious. Yes, it's true it's easier than ever to create sophisticated
websites. But it's also true that almost all this sophistication delivers
negative value to users - it distracts them, slows them down, and forces them
to keep buying faster hardware. It doesn't have to be like this - but it
currently _is_. It's not even just a problem of explicit business incentives -
the technical side of the industry has been compromised. The "best practices"
in web development and user experience all _deoptimize_ end-user ergonomy and
productivity.

~~~
ppod
The mistake you are making is that you are trying to answer the question of
what the average user wants by looking at what you want. Developers are not
representative of users.

~~~
TeMPOraL
That's a cop-out. Being a developer and a long-time computer user biases me,
but also gives me a more informed perspective on what's productive and
ergonomic, and what's distracting and annoying. I can name the issues I see,
instead of writing off the frustration as "this computer must have viruses" or
"this is just how things have to be".

Bloat because of inefficient design isn't delivering any value to regular
people that a developer is oblivious to. It's just bad engineering. Similarly
for distractions, abandoning all UI features provided by default for the sake
of making a control have rounded corners, setting the proficiency ceiling so
low that no user can improve their skill in using a product over time, etc.

~~~
leesalminen
In my experience (years of talking IRL with thousands of users of my B2B SaaS
product), there exists a large cohort of users that don't want to improve
their computer skills. They want the software to make things as absolutely
"user friendly" as possible.

As an example, I tried standardizing on <input type="date" /> across our
product (hundreds of fields). Within 24 hours we logged >1,000 tickets with
users saying they disliked the change. They preferred the fancy datepicker
because it let them see a full calendar and that enabled a more fluid
conversation with the customer (like "next Wednesday").

Yes, Chrome does offer a calendar for this field type, but Safari for desktop
does not (just off the top of my head).

I'm a vim-writing, tmux-ing, bash-loving developer. If it were up to me, I'd
do everything in the terminal and never open a browser.

I recognize that the world doesn't revolve around me and my skills, interests
and tastes. If a large cohort of my customers tell me they don't want to
improve their computer skills and want a fancy UI, who am I to tell them
they're wrong? They're paying me. They get what they want.

~~~
TeMPOraL
You're conflating a couple of things here. It's true that users don't like
change - and for good reason; messing with UI invalidates their acquired
experience, and even if you know you've changed only one small thing, _they_
don't know that. It quite naturally stresses people out.

Two, I'll grant you that you sometimes have to use a custom control, because
web moves forward faster than browsers, and so you can't count on a browser-
level or OS-level calendar widget being available. But then the issue is, how
do you do it. Can the user type in the date directly into your custom field?
Is the calendar widget operable by keyboard? Such functionality doesn't
interfere with first-time use, but is important to enable users to develop
mastery.

A lot of my dissatisfaction with modern UI/UX trends comes from that last
point: very low ceiling for mastery. Power users aren't born, they're made.
And they aren't made in school, but through repeated use that makes them seek
out ways to alleviate their frustrations. A lot of software is being used
hours a day, day in, day out by people in offices. Users of such software will
be naturally driven towards improving efficiency of their work (if only to
have more time to burn watching cat photos). If an application doesn't provide
for such improvements, it wastes the time of everyone who's forced to interact
with it regularly.

------
dessant
The redesigned version of Google Search that is being A/B tested no longer
shows links. Despite being a developer, I'm anxious to click search results,
especially because when results are filtered to be from the last day or week,
they are full of phishing sites and pages with scraped content that
immediately redirect to malware.

This change can't possibly be beneficial to users. It makes people even more
ignorant about the technologies they depend on, and exposes them to further
risk of being exploited.

UPDATE: This is the new design I've seen, the domains are missing:
[https://i.imgur.com/5RTdXI1.png](https://i.imgur.com/5RTdXI1.png)

~~~
hombre_fatal
They took urls away and then added this:
[https://i.imgur.com/RI4xxgs.png](https://i.imgur.com/RI4xxgs.png)

For example, searched "hierarchy" and it'll show "en.wikipedia.org > wiki >
hierarchy" above the wikipedia search result.

> This change can't possibly be beneficial to users.

You're right if the url/domain isn't even shown at all. But I can think of a
few benefits of showing the domain as it currently does, like to avoid
phishing. It also basically parses the url and interprets it for less-
technical users which is something that more-technical users are already doing
when they read the url.

I don't think it's so bad as a default if there's a config option for
displaying the full url for more technical users, or the necessary data
available to at least write a browser extension.

~~~
dessant
Multiple versions are being tested. The one I've seen does not contain the
domain, not even in a tokenized form.

It looked like this: [https://www.searchenginejournal.com/google-is-testing-
search...](https://www.searchenginejournal.com/google-is-testing-search-
results-without-urls/329465/)

~~~
hombre_fatal
Yeah, the iteration I'm being served is definitely an upgrade over that. The
one shown in your link is what I had previously, so it seems that mine is a
refinement of it and a middle ground that I don't think is so bad.

~~~
boomlinde
I don't see the issue with showing _both_ an URL and a tokenized
representation, outside Google's seeming motive to "kill the URL". In both
versions, information that would be immediately available in the URL is
potentially left out, which can't possibly help prevent phishing unless Google
goes out of their way to actually verify that websites are what they say they
are.

It's also hard to trust Google engineering to get something like this right
after the Chrome "trivial subdomain" stripping
debacle([https://bugs.chromium.org/p/chromium/issues/detail?id=881694](https://bugs.chromium.org/p/chromium/issues/detail?id=881694)).

------
dredmorbius
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](https://duckduckgo.com/lite)

________________________________

Notes:

1\. [https://www.w3.org/2006/Talks/06-08-steven-
web40/](https://www.w3.org/2006/Talks/06-08-steven-web40/)

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

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

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

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

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

~~~
hombre_fatal
DDG results are so much worse for me, especially anything longer tail or in
Spanish, that I switch to Google when I'm actually getting work done. I find
myself adding "!g" to an important search just to check for any results that
DDG doesn't know about and it's almost always an upgrade to see Google's
results.

Search is hard.

I don't like to chime in to say something negative about an underdog like DDG,
but I see this "people probably just don't know how to use DDG" suggestion a
lot and it's quite the opposite: Google feels like it can practically read my
mind with minimal context, like knowing I also may be talking about a recent
event that shares the name with a generic search term. And I'm not talking
about personalized search.

Or consider how "elm dict" in Google takes me to [https://package.elm-
lang.org/packages/elm/core/latest/Dict](https://package.elm-
lang.org/packages/elm/core/latest/Dict) (#1 result), but
[https://duckduckgo.com/?q=elm+dict&t=h_&ia=web](https://duckduckgo.com/?q=elm+dict&t=h_&ia=web)
in DDG doesn't (nowhere on page 1).

Run into this enough and it becomes hard to willfully use DDG when you know
you're likely missing out on good results when trying to do real work.

~~~
eggie
I know you're probably annoyed that I'm telling you that you're using ddg
wrong. That's not exactly what I'm saying. It's more like: we're trained to
expect certain things from the search engine, and so it's hard to switch.

> Or consider how "elm dict" in Google takes me to [https://package.elm-
> lang.org/packages/elm/core/latest/Dict](https://package.elm-
> lang.org/packages/elm/core/latest/Dict) (#1 result), but
> [https://duckduckgo.com/?q=elm+dict&t=h_&ia=web](https://duckduckgo.com/?q=elm+dict&t=h_&ia=web)
> in DDG doesn't (nowhere on page 1).

ddg gives me the source code to elm Dict (8th hit, so it's in the first page):
[https://github.com/ivanov/Elm/blob/master/libraries/Dict.elm](https://github.com/ivanov/Elm/blob/master/libraries/Dict.elm)

I assume it's the same because ddg is claiming not to affect search results by
anything except time and user configuration.

Google's results (for me) are a full page of references to every different
version of elm's documentation for dict. Not exactly a wide net, and frankly
pretty redundant. To see anything else, I have to click at the bottom of the
page. It doesn't show me the source code. I went through the first ten pages
and didn't see any link to it.

For ddg, I just use the arrow key to scroll down, and I can press enter to
follow the link I want, changing the meaning of "first search page" for me
quite a bit.

> DDG results are so much worse for me, especially anything longer tail or in
> Spanish, that I switch to Google when I'm actually getting work done. I find
> myself adding "!g" to an important search just to check for any results that
> DDG doesn't know about and it's almost always an upgrade to see Google's
> results.

I have a completely different experience in italian. They're actually pretty
good, which is surprising given the small audience.

For work, usually I directly search for documentation in reference systems
(e.g. en.cppreference.com). Neither ddg or google will consistently direct me
to the "best" documentation. YMMV.

~~~
inciampati
A comment on my comment. It is really true that Google indexes the deep web of
generated content (like AliExpress, eBay, and others) better than ddg. That's
part of the long tail that's costly to cover.

------
jedimastert
> However, being a blind person, I guess I have to accept that Google doesn't
> care anymore.

Jumping from "this isn't working on my incredibly niche browser" to "Google
don't care about blind people" is completely ridiculous.

~~~
amerine
Lynx is niche now? Low user count, yeah, but it’s a standards complaint
browser.

~~~
jnty
The definition of niche is literally "appeals to a small, specialized section
of the population" so, er, yes.

~~~
normalnorm
Perhaps, but in this case Google would just have to comply with the standards,
which are not niche at all.

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

~~~
normalnorm
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 miserable life because Google attained a de facto monopoly,
but does not recognize some of the moral obligations that people like me feel
should come with such a position. "With great power comes great
responsibility", or maybe not.

~~~
joshuamorton
Is lynx up to spec on HTML5 ARIA attributes? My understanding is that that's
how accessibility is "supposed" to be done now, but if lynx hasn't been
updated in a while, it might not support those HTML5 features, and thus not be
standards compliant.

(edit: Someone below notes that lynx appears to incorrectly parse valid HTML5
on the google homepage, so it sounds like Lynx's lack of updates are hurting
here).

~~~
JimDabell
> Is lynx up to spec on HTML5 ARIA attributes? My understanding is that that's
> how accessibility is "supposed" to be done now

No, that's not true at all and is unfortunately a common anti-pattern.
Accessibility is supposed to be done by using standard HTML elements and
attributes. ARIA is there to extend / fill in the blanks and to fix things
when people deviate from the norm. For instance, if you have a button, you
should almost always use the standard HTML <button> and only use some other
element type with an ARIA role=button if it's unavoidable. And <button
role=button> is redundant. Best practice is still to use the semantics defined
by HTML, as it always was.

~~~
joshuamorton
I should have been clearer, but imo correctly using html5 node types is part
of correctly using html5 attributes.

------
exikyut
Curious, I installed lynx just to check this out.

I find that I physically cannot navigate to the links in the page except the
first few at the top.

But.

On the pages I get, the <a ... href="..." ...>...</a> structure is still 100%
intact. It's buried in a table and div soup, but it's there.

So, I argue Lynx parsing bug!

The author of this article would have done well to save and diff the
working/not-working HTML they received. :(

~~~
hvdijk
Not really a bug more than an outdated browser not being updated for HTML 5.

In HTML 4, <a href="..."><div>...</div></a> is an error and Lynx deals with
this by implicitly closing the <a>, turning it into a hidden link (which can
still be followed by pressing 'l').

In HTML 5, <a href="..."><div>...</div></a> is valid.

~~~
tbodt
Google actually detects the Lynx user agent and sends an HTML 4 page, but
apparently this new code wasn't written with that in mind.

------
mastazi
> Luckily, there is duckduckgo. However, I have to admit, the search results
> of duckduckgo are by far inferior to what Google used to give.

For cases where DuckDuckGo isn't quite enough, I usually rely on StartPage
[1]. It uses results from Google, but like DuckDuckGo it doesn't track its
users.

Startpage, like DuckDuckGo, also works well in Lynx (I've just tested in Lynx
2.8.9 on Ubuntu 16.04).

Additionally, you can get StartPage results right from within DuckDuckGo by
just appending the !sp shortcut to your search query [2]

Edit: you may want to keep in mind, however, that StartPage is now owned by an
advertising company. Some users took issue with that. Personally, I'm OK with
that as long as users are not being tracked. Relevant HN thread:
[https://news.ycombinator.com/item?id=21371577](https://news.ycombinator.com/item?id=21371577)

[1] [https://www.startpage.com/](https://www.startpage.com/)

[2]
[https://duckduckgo.com/bang?c=Online+Services&sc=Search](https://duckduckgo.com/bang?c=Online+Services&sc=Search)

~~~
colechristensen
DDG has been getting better. I've switched my browsers search to it and only
occasionally go back to Google for something specific.

~~~
rosybox
DDG's results are very bad still, and they will likely always be terrible.
It's not hard to find a query that is objectively much worse than what Google
has. DuckDuckGo will never be able to catch up to Google's search quality
results. It doesn't have Google's data, Google relies on the search behavior
of most of the people of the internet to guide its results along with its vast
human and hardware resources to create results that even Microsoft can't
match.

[https://www.bloomberg.com/news/articles/2019-07-15/to-
break-...](https://www.bloomberg.com/news/articles/2019-07-15/to-break-google-
s-monopoly-on-search-make-its-index-public)

~~~
rige
From my view, I think it must depend on your use case and common searches.
I've been using DDG for years now without any major qualms on search results.
For my purposes it finds what I need, and for the few cases where it doesn't
(perhaps 1 out of 50 searches?) it's easy enough to just add on a !g to my
query to use Google instead.

~~~
olyjohn
Every time I do the !g anymore, I never find Google has any better results.
Usually, I just get 32,000,000 more results listed that are just auto-
generated junk. Most of those don't even have the words in them that I
searched for, so I don't understand how they come up.

------
patmcguire
Did they also remove link wrapping with this? The HREF goes straight to the
destination for me now on Chrome, where previously it went to some Google
domain redirect. It's there on the first HTML load too, it's not a JS thing
after the fact. Is there a different response for Lynx or are they formatting
it in such a way that Lynx doesn't pick it up?

~~~
Avery3R
They're using the ping property of the <a> element now, the only good thing to
come out of this

~~~
e12e
On a more substantial note, that's documented here:

[https://www.w3.org/TR/2008/WD-
html5-20080122/#hyperlink0](https://www.w3.org/TR/2008/WD-
html5-20080122/#hyperlink0)

It's a little odd, to see that a browser "must parse", but also "may either
ignore the ping attribute altogether, or selectively ignore URIs".

It strikes me as a bit clumsy compared to the typical MUST/SHOULD/MAY wording.

Anyone (other than Google) using a-pings?

------
earenndil
Try googler
[https://github.com/jarun/googler](https://github.com/jarun/googler)

~~~
dredmorbius
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 _very brief_ bash functions for equivalent
capabilities, again, launching any arbitrary browser (though usually w3m by my
personal preference).

Now what's needed, and you're recommending, is a content-side wrapper as well.
This story ends poorly.

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

I think this ship, if it hasn't sailed already, is at least starting its
engines and getting ready to leave the harbour.

User agents and servers are increasingly trending towards an adversarial
relationship, where the user _doesn 't want_ to do much of what the server is
asking of it. This has been true from the first pop-up blockers, through to
modern adblocking and anti-tracking measures (the situation now being so bad
that tracking protection is a built-in default feature in some browsers).

Eventually, a "filter out the crap" strategy becomes too onerous, an "extract
what looks good" strategy starts to look better, and you end up with tools
like Reader Mode. Custom clients are a natural next step - when someone gets
desperate enough to write an article-dl to match youtube-dl, we'll be there.

~~~
dredmorbius
Oh, I agree that the ship is now barely visible over the horizon.

That doesn't diminish the fact that the _original_ intent was to have a
common, freely-available mechanism for accessing, viewing, and presenting
content.

(I'll probably be asked for citations. TBL has probably written on this, and
Tim O'Reilly had an essay on his early response to the WWW as opposed to
alternative, proprietary, systems, when O'Reilly & Associates were plotting
their early course.)

------
corodra
When it comes to searches for technical reasons, dev related, sci, even gov
searches, duckduckgo blows google out of the water. Junk random searches,
trivial things, yea... its weak. My experience I should say.

------
Spivak
Serious question, why search Google in your terminal with Lynx as opposed to
`googler`? The actual result pages can still open in Lynx but the experience
of navigating the results is very nice.

~~~
dljsjr
Author of the post is blind so I'd imagine the usage of Lynx is for screen
reading/accessibility reasons.

~~~
Thorrez
Spivak is asking why Mario isn't using
[https://github.com/jarun/googler](https://github.com/jarun/googler) .

If Mario is able to use Lynx, the expectation is that Mario can probably also
use googler.

------
mwcampbell
> However, being a blind person, I guess I have to accept that Google doesn't
> care anymore.

This is not a blindness issue. It would be more accurate to say that Google
doesn't care about geeks who cling to old ways of doing things long after
there's a good reason to do so. As others on the thread have pointed out,
blind people can use graphical web browsers with a screen reader, even under
GNU/Linux. I know you know this; I'm pointing it out for the benefit of
everyone watching the thread.

~~~
boomlinde
On the other hand I don't feel like I'm in a position to blame a blind user
for clinging to something they already know instead of learning how to use a
graphical browser. A lot of people in general have good reasons for sticking
to what they know. Especially if what they stuck to worked fine until
recently, and doesn't now only for some trivial reason that's easy to fix.

------
AdrienLemaire
> However, I have to admit, the search results of duckduckgo are by far
> inferior to what Google used to give.

I've switched to DuckDuckGo since I read its CEO's book "Super Thinking", and
I'm not feeling that it's inferior. Sure, it doesn't have rich cards and other
goodies, but I've come to realize that these are nice-to-have, but not
essential. On the other hand, reducing the confirmation bias by getting out of
the filter bubble is, I believe, essential.

------
nyxtom
It's been probably years since I've used Google search. It's entirely possible
that I'm not getting desired results, but as far as I've been able to tell.
It's entirely possible that because I don't end up on answers, I end up (most
of the time) going directly to read source code and documentation more often
than not. This seems to have helped created something of a better
understanding of whatever tech I'm using at the time.

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

~~~
ta0987
Unfortunately, they got bought:
[https://news.ycombinator.com/item?id=21371577](https://news.ycombinator.com/item?id=21371577)

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

------
hartator
Hey! We will be happy to give you an infinite access to our search API:
[https://serpapi.com](https://serpapi.com)

It will be slower than regular Google but at least you are not going to be
blocked.

Edit: Create an account without credit card details, send an email to julien
_at_ serpapi.com with it, and I’ll make sure you have an active account.

------
vvllmprz
w3m works fine for me.

Any reason people prefer lynx over w3m or eww?

~~~
jolmg
Also works with elinks.

~~~
erikbye
Indeed.

------
khronix
This is a trend I've noticed also, behemoths breaking standards without
permission nor apology, crushing the canary in the coal mine (w3m/lynx, though
emacs eww browser works). As a member of an IT Development team creating
various web applications, we have found different approaches are needed based
on client needs and workflow. We develop many complex data-based backed
query/display single page web apps usually with zero js. Where not needed it
is little more than a security hole begging for trouble. Where no 'live' user
experience is required this is equals resource waste (xtra payload, xtra
client cpu cycles if no js blocker) especially in many work environments.

As user/engineer I am annoyed when any site sends me their worthless js to
execute unnecessarily, thus wasting my devices cpu cycles, battery, plus my
lifejuice, and for what??? In most cases nothing I want/desire/need, therefore
just to make a bigger tool of me than before, and not for the better. That
being said, using web communications, live/simulated data visualizations
benefit greatly from js.

Separation of concerns is what is missing, js was created to benefit and
enhance user experience, the ne'er do wells have hacked it into a tool
mindlessly used and often enough does screw the user over without permission
nor apology...

Interestingly the creators of what became Google received their start with NSF
funding. Good way to finish off giving everyone the finger Google, continue to
'do only evil'...

------
linusnext
From JWZ.org

Greetings, Lynx users. There is a reason this page doesn't use ALT tags on the
images. The reason is that the bozos responsible for both MSIE and Netscape
Confusicator 4.0 decided that they would display the ALT tags of images every
time you move the mouse over them -- even if the images are loaded, and even
if they are not links. The ALT attribute to the IMG tag is supposed to be used
_instead of_ the image, not _in addition to_ the image.

This looks absolutely terrible, so I don't use ALT tags any more in self-
defense.

If they wanted to implemented tooltips, they should have used the TITLE
attribute to the A tag. That's in the HTML 1.2 spec and everything.

I had to decide between making this page look good for the vast majority of
viewers, or making it be readable by the miniscule minority of you stuck in
the 70s. Those of you in the retro contingent lost. Sorry.

from view-
source:[https://web.archive.org/web/20000304020552/http://www.jwz.or...](https://web.archive.org/web/20000304020552/http://www.jwz.org/)

~~~
jandrese
Someone got really worked up over text appearing when they moused over an
image, and broke accessibility because of it?

~~~
catalogia
jwz has a... strong personality.

~~~
dredmorbius
And several more in ready reserve!

------
skykooler
Google locked me out of Lynx nearly a year ago. I'm surprised it took this
long to affect other people.

------
sullivandanny
I'm Google's public liaison for search. Thank you for bringing this to our
attention, and our apologies for the inconvenience caused. This was indeed a
bug that our engineers have explored, and it should be fixed now.

------
arasx
I am willing to bet, attorneys who specialize in exerting money from ecommerce
sites based on fluke accessibility lawsuits will not take notice of this
problem that presents an actual hardship.

------
tantalor
Sounds like a bug in lynx.

------
3xblah
Solution: Use alternative HTML parser

    
    
       lynx -tagsoup https://www.google.com/search?q=whatever
    

The program will now display search result URLs as visible links.

------
glloydell
"Bye bye mainstream, hello ghetto."

Yes, because your use of deprecated software is no longer supported is TOTALLY
the same thing as being relocated into the Ghetto in Warsaw.

------
zoobab
Strange with elinks I can still click on the links.

With with lynx not.

------
kion
This appears to have been fixed since the posting. Links in the search results
work again in lynx.

------
Koshkin
I am able to Google using Links (another excellent text mode web browser).

------
Reason077
duck.com works well with lynx.

------
anonymousisme
Sounds like an ADA lawsuit is in the works...

------
addandsubtract
That's what happens when Google releases their own console killer.

~~~
freehunter
I think you may be confusing console (the terminal emulator, command line
interface) with console (video game console like Xbox or Playstation or
Stadia).

------
Apofis
Google search no longer working with text readers should be an ADA Violation.
[https://www.ada.gov/complaint/](https://www.ada.gov/complaint/)

~~~
duskwuff
Lynx is not a screen reader.

Screen readers are tools like JAWS or VoiceOver which interact with desktop
applications, including desktop web browsers such as Chrome or Safari. Google
works fine with these.

~~~
anthk
And YASR under Linux with lynx/edbrowse works 200000 times better than jaws,
starting with a logical layout for the blind.

