I am no longer able to use Google with Lynx
blind.guru
blind.guru
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...
[2] https://developers.whatismybrowser.com/useragents/explore/so...
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!
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.
Eh, if the issue really was (as figured out below) that lynx doesn't support divs inside anchor tags, that seems like the best possible solution if you aren't going to drop lynx support altogether. Even IE6 allows that.
It just isn't worth trying to do progressive enhancement by tying everything into knots trying to keep the page strict html 4.
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.)
If you can make something without JS you should. cryptomarketplot.com has an accessible mode FOR CRYPTO!! If crypto sites can, everybody can.
I think you may be blind to the harshest criticisms, though. It was a common view that the web was built for static content (or server-side dynamic content) and code execution by the client is mostly a nuisance at best. And there is some validity to that. When JS was developed, roughly contemporaneous with worse ideas like java applets and ActiveX on the web, it was thought by proponents that untrusted code execution is OK to good. 20 years later, it was still assumed that if JS is sandboxed, memory safe, has a different page table from the rest of user mode, untrusted code execution is safe. Then spectre and meltdown happened.
And tangentially, I was pointing out more recently that the grumpy position from older times actually would have prevented some real world problems. (Spectre and meltdown go from being local privilege escalation bugs to "holy shit you can own my machine if I visit a web page")
OTOH I don't worry too much, accessibility-enforcing laws will provide plenty of job opportunities for future developers... So yeah, good move, 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.
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.
I disagree strongly with this. The web has moved a lot in the direction of developer experience (ES6, modules) and new capabilities (WebSockets, WebRTC, WebAudio, SVG, canvas...). Yes, most of this happened because it's a side-effect of big surveillance capitalism companies wanting make that sweet sweet digital pollen to be even sweeter, but that doesn't make it any less sweet just because it was made in bad faith.
I can tell, because I order pizza quite frequently from a variety of sites.
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.
People value privacy when made aware of the issue, but very few people are aware of how websites track (and manipulate) them.
All of the studies I'm aware of that ask people to choose between different price points based on privacy end up showing minimal valuing of privacy.
Most people, however, are not enthusiasts or activists who are wholly invested in these topics. Even being aware of the issue, most act based on their immediate needs. Immediacy is an extremely important factor in decision-making.
If we were to give this a utilitarian assessment formula:
[severity of problem] * [immediacy of problem] <||> [importance of need] * [immediacy of need]
Many people using social media to communicate with their family may evaluate that as:
[100] * [1] < [100] * [100]
Why is it that people working in the field tend to be paranoid about privacy, and people outside are not? It can't be that we are just on average more paranoid. It's more likely that we know exactly how this data can be aggregated, stored forever, analysed in the future with capabilities that don't exist yet, etc. I think most people don't understand privacy in those terms.
You have to factor in the fact that people know they are tracked whether they are paying or not. Given that fact I'd prefer not paying as well.
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.
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.
Better forms inputs could very well be useful, I agree.
The recent MSFT + GOOG snogfest announcing major improvements to HTML by ... improving form and input fields in their (GUI-only) browsers strikes me, in light of rather ominous icebergs looming on the HTML horizon, of rather gratuitious deckchair-rearanging. No matter how fine those arrangements might be.
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.
Sometimes it feels like the web of yore was so simple to use and free of unnecessary bloat simply because that was as far as the technology had progressed at that point. React didn't exist and the browser was limited from a technical perspective so the best people could manage was some clever CSS hacks to cobble together something mildly attractive. It might have taken a while to render even those simple pages on computers of the time, so back then those pages might have hit a performance ceiling of some kind.
Maybe as more and more features get added to a piece of technology, there's some kind of default instinct that some people have to always fully exercise all of it even if it's not at all necessary. Simply because you can do more with it that you couldn't do years ago, there's some assumption that it's just better for some vague reason. It's easier to overcomplicate when everyone else is doing it also, so as to not get left behind.
Then everyone who doesn't have knowledge about web technologies in the like get used to it, and people's expectations change so this "new Web" becomes the new standard for them and start enjoying it in some Stockholm syndrome manner - or not, and the product managers mistakenly come to this conclusion from useless KPIs like "time spent on our website" which will obviously increase dramatically if it takes orders of magnitude more CPU cycles just to render the first few words of an article's headline.
I'm only speculating though.
Personally, as someone with a headless server running Docker, it pains me to no end I can't browse Docker Hub with elinks.
I suspect this is very true. It seems true in my experience. I think the reason may be just that our field is so young and dynamic, that everyone learns everything on the job. If you want to stay up to date, you have to gain experience with the new tools, and the best way to do it is to find a way to make using them a part of your job. It saves you time after work, and you even get paid for it.
It takes good judgement to experiment with new technologies on the job without compromising the product one's working on. I feel that for most developers, the concerns of end-users rarely enter the picture when making these calls.
However, the way the poster you're replying to sees this issue is not as a candy salesman; but, as a public engineer. There's a problem, like "what should web be", "how should web work", which is akin to "how to build a railway over this valley", "how to minimally disturb the ecosystem", etc. That's not a realm of likes and dislikes, but of practicality.
One of the realities of today is that the average user is extremely distanced from the technicalities of Web, whether that's desirable or not. That puts a lot of burden on the informed and on the developers, which are often the same people. The few are obligated to make decisions for the many.
Do you deliver a box-shadow, but increase technical debt? Do you migrate to a more energy efficient platform, but alienate some users? Do you broaden the scope of your system, in turn increasing system complexity, or do you delegate to a dedicated third-party system, having the user possibly learn to use that third-party system?
It's a question of which compromise best serves the user. It shouldn't be a question of likes and dislikes. This is a complex situation rife with miscommunication, ignorance, conflict of interests, and inertia. Any simple solution, such as disregarding the opinions of developers, should be regarded with great suspicion.
Though it wasn't patently insulting, you have gone ad hominem - "to the man" - rather than the idea. Whether one is a developer or not, doesn't have any bearing on whether economy and efficiency are worthwhile values in a computer application. Although it so happens that developers tend to also be users. If they ARE users, then they represent users. Also in the sense of acting as an advocate of sorts for the user, developers represent users.
"Average" users having never been offered the thing being proposed here (faster and ad-free versions of the same apps, with the same network effects etc.), I don't see how you can state with any confidence that they wouldn't have chosen them, were they available.
By far.
Is there any evidence that web apps of today are faster in achieving what equivalent non appy web pages of the past managed? Despite the fact that those older "apps" were running on computers which were orders of magnitude slower than our cell phones today.
I've worked with 2 companies now where their users (and both these companies have users who pay 4 digit annual fees per user) have refused to migrate to the new Web 2.0 apps these companies have tried to foist on them.
The difference in these cases is that the users, by virtue of paying, actually have a say and so have required the companies to provide parity with the older and newer applications, and usage continues to not just be higher, but grow faster on the older versions (despite having a larger base).
Regular users have no such option. Google changes GMail, but its users still insist on using the older versions of the app, which is why they provide HTML mode, etc. However, it's users do not pay Google, and are forced to go with whatever Google wants to do, which is constantly hiding the older version and making it progressively worse to use.
It's not evident to me at all that regular users "want" to use these new web 2.0 apps, as much as they don't have a choice.
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.
(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.
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.
What are you seeing that leads you to think this? The ads and engagement drivers (autoplaying videos of other content on the site) on sites that need eyeballs to keep the lights on, or the articles showing how to download the minimum usable assets so you don't waste the user's bandwidth, battery, and disk space[1]? The latter is what I tend to see when I'm looking at pages describing "best practice".
1: https://alistapart.com/article/request-with-intent-caching-s...
Some "best practices" articles discourage all this, but in my experience, that's ignored. The trend is in ever decreasing density.
It all makes sense if you consider apps following the practices I mention as sales drivers and ad delivery vectors. Putting aside the ethical issues of building such things, my issue is that people take practices developed for marketing material, and reapply them to tools they build, without giving it any second thought.
The world is bigger and more interesting than screens and screens of uninterrupted plaintext.
Fortunately, good dynamic HTML also exists.
And I wouldn't write off rounded rectangles as superfluous fluff. They're fairly ubiquitous in user interface design because round cornered structures are fairly common in nature. They make a UI look more "real". And decreasing the artificiality of a user interface isn't superfluous; it lets more users interoperate with the interface without feeling like they've strapped an alien abstraction onto themselves. A lot of people in the computer engineering space have no trouble working with alien abstractions for hours at a time, but it's an extremely self-selecting group. We are often at risk of believing that what is normal for us should feel normal for everybody.
https://bgr.com/2016/05/17/iphone-design-rounded-squares-exp...
Are you sure this is the case? Because I think it may be a shiny object trap, where on first view a visually fancy site is great and appealing but in the long run a simple, fast-loading site is preferable.
You're aware that pure HTML and CSS alone can produce visually fancy content with pictures and colors, right? It honestly seems like a lot of web developers are starting to forget this, but it's true, I swear. My personal web site (https://coyotetracks.org/) is minimalist by design, but it has accent colors, custom fonts, Retina-ready images, and that silly little fade in and out when you hover over links, all without any JavaScript whatsoever. Also: turns out it works pretty well on Lynx!
I think JS gets a bit of a bad rap these days and am willing to leap to its defense even though I don't like it much as a language, but a huge chunk of the reason it has a bad rap is because people do bad things with it, by which I mean either malicious things or just unnecessary things. An awful lot of modern web sites could run just fine with far, far fewer scripts than they're deploying.
(And, yes, I can even do web analytics without JavaScript, because there are these things called "server logs" I can analyze with utilities like GoAccess.)
Sophisticated web pages are not necessary to disseminate text-only context. 90's HTML is perfectly capable of doing that.
I have no problem with loading 30MB of JS libraries into the browser for an application that actually does something. I have a problem with loading 30MB of shit to read 10kB worth of news.
And still average people aren't taking advantage of this and creating their own websites because despite it being massively easier, the way the web is now has pushed it still beyond the average person's reach. If these 'sophisticated' stacks and technologies weren't the norm and instead the web was more focused on being s place where.the average person can easily put up their own fancy looking simple webpage maybe we wouldn't be so dominated by these massive companies that have become the gatekeepers by providing limited platforms for people to do what did used to be a relatively easy thing even back in the day.
There's a reason these companies fund and push these technology stacks, it gives them huge control over the internet and in the end, they don't really do anything fundamentally different than what good old fashioned HTML and CSS can do. Hell especially the HTML of today.
Well if talking progress, we can also compare, say, energy efficiency of information transmission, or the number of well maintained Web clients. That doesn't look so good, does it? The question is what problem are we solving, or, in your words, what is "sophistication"? According to some measures we did achieve impressive things. But a lot of us experience heartache, because we think we didn't do all that well.
Html did. It was hyper text, and rendering was done for document flow.
Then we could script a bit, and soon after we wanted "webapplications". Now, we lost probably 15 years trying to fit in an application-ui and lifecycle model in a document-flow model.
Html, or rather xml, or rather trees, are a good way to represent a user interface. Unfortunately back then, the only languages available were C++ and Java for any proper work oh yeah, and visual basic!).
Javascript, php, and perl were a godsend in terms of productivity. Just like the 80s home computers and basic. It just worked. Type and run. This is also why bad badsoftware gets popular btw..
Coming back to the post.. Lynx renders HTML how it was intended: as a document.
Most application UIs are not complicated. Most applications are just interactive documents. There is nothing special about 90% of the apps I use on my native computer that means they couldn't be rendered as HTML. The document model is fine for applications. Preferable, even.
Heck, a reasonable portion of the native applications on my computer have optional pure-terminal interfaces. If your application can work in a terminal, it can work with HTML -- and embracing a document model for your application UI would be a better user experience than whatever the heck pixel-perfect framework that everyone is chasing nowadays. That's true on the web, and it's true on native.
The problem with the web is not that HTML is incapable of being used as an application platform; it's not that we're trying to fit a square peg into a round hole. It's that both web and native developers overestimate the interface requirements of their applications, and bring in unnecessary cruft to achieve pixel-perfect layouts that are worse for end-users.
We have a square peg, and a square hole, but we like to go to conferences and pretend that our peg is actually some convoluted, recursive star shape.
That is really the fault of "modern web", that web pages are more "sophisticated" than they really need to be to present the information they contain in a visually pleasing and usable manner. There are so many round-about approaches to the problem that people don't concern themselves with the most straight forward one. I can't say that it's somehow massively easier to create a simple list of links with some excerpt in a way that it doesn't work on a 15 year old browser than it is to create one that doesn't. You really have to go out of your way to break something as simple and fundamental as linking.
There is no way that the percentage of developers doing that isn't vanishingly small. Like 0.1% or less. I always chuckle when 1 person chimes in on a show hn post to complain that the site doesn't work well in lynx... Ya, I'll get right on that, top priority!
> 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.
I'm generally against unnecessary web complexity, but I don't understand how anyone can paint Lynx a hero for randomly ignoring anchor tags.
I embrace progressive enhancement where possible, all of my blogs/sites will load and function without Javascript. I'm not going to serve alternative HTML in a scenario like this. There has to be a give and take towards Lynx supporting objectively valid pure HTML content.
It wouldn't violate any of Lynx's pure-text principles to parse modern HTML correctly.
Does headless Firefox (what brow.sh is at it's core) even launch if there's no X11 available? Is it that headless?
They would be correct replies!
In addition there is this concept called "graceful degradation", where if the browser has more advanced features, you support them, otherwise you work anyway. It's not like supporting Lynx means you can't have a map in the search results when using Chrome. Certainly not for a company with the resources of Google.
Also they should probably send something like a Lynx-version of Google down to people with a poor internet connection.
Yeah, web standards such as images and video and audio. Not keeping up with those standards is kind of the point.
As I recall it, we weren't mad about IE "holding back the Internet", we were mad about IE encouraging web designers to stick a bunch of dynamic clutter such as ActiveX controls into their webpages. Largely because they created this lock-in where sites only worked well on one browser.
It turns out that JavaScript has been co-opted into being the new ActiveX, and Chrome is the new IE. But since JavaScript is nominally an open standard, and Chrome runs on the big 3 OSes, nobody seems to get mad that alternative browser projects are dying because they can't keep up with all the stuff that needs to be implemented in order to work well with sites that were only tested on Chrome and WebKit.
Anyone who has heard of the phrase "embrace, extend, extinguish" should be at least a little bit uncomfortable with this situation. For example, it implies that any potential alternative OS needs to be able to compile Chromium (or, as what can only be seen as a second-class substitute nowadays, Gecko) before it can really be viable. If you're the kind of person who likes a free, open and competitive software landscape, that's a looming threat.
- 1. you need a beefy device to render in a reasonable timeframe
and
- 2. you need The One Blessed Renderer to even see anything
I do recall the situation 20 years ago, when I could use about 2/3 of the relevant Net, with the rest going "meh, chronic complainer, just use IE. What? Yeah, that's your own fault for not choosing Windows." The second part is far more worrying, as it is not resolvable locally, either by optimization, or by horsepower.
Not sure that's the case, if so, I'd expect a comment that shows a little deeper understanding of the issues involved.
"HTML from 1999" isn't the issue. Lynx did fine on that... and HTML from 5 years ago, just like a whole host of non-visual or semi-visual user agents.
brow.sh is... OK, I guess, nice to have around in a pinch, but like most other schemes that rely on a headless full-fledged browser in order to work with applications that have become dependent on JS to merely render content it introduces a glorified screen-scraping layer to something that can easily be much simpler, assuming web application developers can be bothered to think about it.
We don't need to freeze the web at 1999, and some applications fit poorly in a non-visual context. But a little bit of reflection on how the merits of progressive enhancement and moving forward without losing the benefits we had at that stage would be nice. The stage where people cared about such things was pretty amazing in terms of the breadth of devices web applications would in fact work on pretty well.
Also, if you're not thinking about pretty plain HTML version of your app, chances are half decent you're missing an opportunity to engineer your application better whether or not you care about UA interop.
But, you know, if you're pretty sure the browser should be "thought" about as nothing more than The VM That Lived™, by all means, carry on.
AFAIK most of us don't complain when a dynamic website doesn't work. We just use a modern browser.
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
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.
It looked like this: https://www.searchenginejournal.com/google-is-testing-search...
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).
Edit: I can see it on all my searches on https://www.google.co.uk/ it is cache/similar
The one that got me was when a search result pointed me to a site that was something like:
example.com/?ipaddr=10.3.4.3
example.com > ...
This is the point. If you've ever viewed an AMP site using Mobile Safari, you'll still see "google.com" in the Location Bar, instead of the site's own domain name. Google's fix for this is to try to kill the URL.
I'm looking forward to this change. It will incentivise websites to make their URL paths more human readable because now their
example.com > cgi > html > static > actually_human_readble_part.html
noise is seen by everyone not just weirdos that look at the URL bar like me.
Needless to say, this was the straw that made me switch to DuckDuckGo instantly, and I've been happy with it, especially with the ability to use the Google bang (!g) in the infrequent case it's required.
This has taught me a valuable thing about A/B testing though—don't make an experiment any longer than it needs to be, and a refresh should bring them back to the old behaviour, just in case it's bad enough to make them switch completely.
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:
It was pitiful that I had to do this but there you have it.
The majority of blind users use standard desktop web browsers with screen reader addons like JAWS or VoiceOver.
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.
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/
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.
I have gripes about Aria. It's definitely possible to abuse this stuff and end up with an inaccessible mess, but overall we have been trending toward a more accessible internet and things like the aforementioned do exist.
I've been blind since birth. I started on a device called the Braille 'N Speak 2000, which functioned very much like Emacs. I don't use Emacs because Emacspeak requires Linux desktop and adds a ton of extra complexity on top for very little gain. Linux dropped the ball big time on accessibility and audio in general, and never really recovered. Obviously this is opinionated, but I feel like you're implying that I lost my vision later in life and am forming my opinion around that perspective. You might additionally want to look into Jaws and NVDA. Learning those is about as bad as learning Emacs or etc; knowledge from when you were sighted doesn't transfer in the slightest and the interface is much more arcane than you probably imagine it to be.
This is off topic, and I don't want to distract from the current conversation, but speaking of sheets -- as a web developer, I often build SVG charts with d3, and I've been racking my brain lately trying to figure out how to make them more accessible to blind users beyond just linking to tables of data.
If you're using Sheets, are you also regularly consuming charts as well? Is there a common auditory shorthand for representing something like a pie chart?
For Sheets, the underlying stuff that runs it is quite complicated. They ended up doing something akin to an offscreen model with HTML to make it work because afaik they use a canvas of some sort to draw everything. In fact, unless you turn on braille mode, both products actually have a built-in screen reader that talks via aria live regions. That's terrible practice, but to their credit they got ahead of what the internet was providing for accessibility and didn't have a choice in that regard.
For something you can practically implement without a huge project, I suggest text descriptions of the data. If you want to do a bit better, make it an HTML table--that'll give some convenient navigability for free.
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.
What are the good, modern alternatives to Lynx?
NVDA offers scriptability for the web and otherwise in Python as well, so anything it can't do can probably be added. For instance there's an add-on for using your local screen reader to control a remote machine, provided that both run it (not the most applicable to accessibility, but a good example of how far you can take NVDA's scripting). Jaws also does much of this but is much more proprietary including an only half documented scripting language.
The quickest way to get some idea is to probably look at the NVDA user guide: https://www.nvaccess.org/files/nvda/documentation/userGuide....
iOS is also good. unfortunately Apple very much dropped the ball on OS X and hasn't picked it up again, but my brother (also blind, it's genetic) did an entire business degree on an iPhone because he didn't want to be bothered learning a laptop. That's a loss in efficiency, but even the lesser options are now sufficient enough that a non-programmer can pick them up and go get a college degree.
There is an idea that goes something like "Obviously screen readers have to struggle to present information, therefore dedicated text-based browsers are better". That was true in 1995 when we didn't even have MSAA. I know people from that era and they had to hook APIs in other processes at runtime. But in actuality, once you expose the accessibility tree and hand it over to the people who want to use it, good things happen.
I was interested in hearing about browsers that do what Lynx does, but are better. Unfortunately, the browsers you mention are graphical, and so are not Lynx replacements.
I'm not the right person if you're looking for someone who shares enthusiasm for text-based browsers, in other words. In general I would like it if people would stop using blindness as a point in their arguments that they're necessary because it shows a massive misunderstanding of what the world of accessibility is like.
Save the region-specific engines which likely lag behind, Google [0] and Bing [1] both support crawling javascript, and Bing is generally the search engine index of choice for all other search engines like Yahoo, DDG (at least for now, I occasionally get crawls from duckduckgobot), etc.
0: https://developers.google.com/search/docs/guides/javascript-...
1: https://blogs.bing.com/webmaster/october-2018/bingbot-Series...
I'm frustrated for you.
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.
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.
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.
Chrome seems to let me create non-default search engines, set the full DDG as the default, but not set lite as the default.
Search term(s) are the URL parameter:
?q=<query>
In the search form, it uses POST instead of GET to perform the searches.
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.
PS C:\> 'accessibility' -replace '(?<=^.)(.+)(?=.$)', {$_.Length}
a11y
This is a cool one-liner though!
({.,(":@(_2+$)),{:) 'accessibility'
--> a11y (⊃,(⍕2-⍨≢),⊃∘⌽)'accessibility'Here's a much more convoluted way, because everything is difficult in this language:
,/((⊂∘⍕∘⍴∘⊃@2)⊢⊂⍨((1@2)1,⍨¯1↓1⌷(↑(1,⊂))))'accessibility'
a11y
'accessibility'
1100000000001 ⍝ for penclose
(Is there a way to drop from the middle of an array? "delete index 4 5 6"? Or to insert into the middle of an array? "Insert between elements 2 and 3"?)
To insert items from B into A at point N, you could (in pseudocode, I don't have time to play with APL right now!):
(Take N of A) , B , (Drop N of A)
To remove items from the middle of an array between N and M, I can think of two ways (I might have off-by-one errors here):
- (Take N of A) , (Drop M of A)
- Bools / A
where "Bools" is an array of 1/0 values, and the 1's indicate the elements to keep. As a dyadic verb, "/" means "compress", that is, to keep only the indicated elements from the right-hand object.
I'm sure there are other ways! These are the few ways that my limited brain could come up with. :)
Vector[2 8 5]←100
Or like you can do ~ for set subtraction "without some values" like (⍳9)~5 7 but treating the right argument as indices to remove from the array, rather than values to remove from the array. I feel like there's two patterns which work in the same way as the thing I imagine and a space where the thing I imagine could exist but doesn't. Which I've now tried to code up:
4 9 8 7 10 11 {(~(⍳⍴⍵)∊⍺)/⍵}'accessibility'
accssty
I just enjoy the mental challenge sometimes.
There's no accounting for taste ;)
---
Abandon all hope, ye who read further.
I try not to worry too much about making things tacit. But there's a neat trick you can play in J to find a tacit definition for a non-tacit expression (if one can be found). I don't know if there is a counterpart in any common APL distributions.
First you define an expression in terms of values named 'x' and 'y'. Your goal is to find a tacit verb -- let's say 'T' -- that you can call as 'x T y'. (X is always on the left and y is always on the right, by convention -- compare with ⍺ and ⍵, sort of.) There is a J operation, cryptically named '13 :', which will try to make such an expresssion tacit.
Here's a quick attempt at writing 'N M drop Y', which will return Y but with the N:M section deleted. Again there might be off-by ones here (you could use Increment/Decrement to fix that):
Define some 'x' and 'y' values for experimenting:
x =: 5 10 NB. these will be our N:M indexes
y =: 'abcdefghijklmnopqrstuv'
5 {. y
abcde
10 }. y
klmnopqrstuv
{. x
5
}. x
10
(({. x) {. y ) , (}. x) }. y
abcdeklmnopqrstuv
13 : '(({. x) {. y ) , (}. x) }. y'
(] {.~ [: {. [) , ] }.~ [: }. [
And that's our tacit version. We can try it out, give it a name, and try it out again:
x ( (] {.~ [: {. [) , ] }.~ [: }. [ ) y
abcdeklmnopqrstuv
drop =: (] {.~ [: {. [) , ] }.~ [: }. [
x drop y
abcdeklmnopqrstuv
5 10 drop 'abcdefghijklmnopqrstuv'
abcdeklmnopqrstuv
But I'm going to have to read more to work out what/how the tacit version works because I have no intuition for telling where the x and y or ⍺ ⍵ enter into them.
Dyalog have this document for tips for translating d-fns into tacit form: https://dfns.dyalog.com/n_tacit.htm but how that compares to what '13 :' does internally..
This sort of feels like we are two tourists, trying to help each other translate between two languages that neither of us speaks very well. :)
These two pages might help you to build an intuition about how J does verb trains. The diagrams help to explain where the x and y values are used throughout (and where they are not).
https://code.jsoftware.com/wiki/Vocabulary/hook
https://code.jsoftware.com/wiki/Vocabulary/fork
I'm starting to be able to write long-ish forks in J without mechanical help, although I usually get them wrong the first dozen times. Practice makes perfect, I guess!
I'm planning to do this year's Advent of Code puzzles (https://adventofcode.com/) in J this year... at least until I reach a problem that explodes my brain. I'm hoping that this will give me something concrete to sharpen my skills on.
Vector[(iota rho Vector) set-minus indices to remove]
The idea that your precious text browser == blind people is wildly presumptuous. Don’t use people with disabilities as your human shield.
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 (#1 result), but 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.
> Or consider how "elm dict" in Google takes me to https://package.elm-lang.org/packages/elm/core/latest/Dict (#1 result), but 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
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.
So instead of trying to beat google on full web searches, the trick might actually be to index all 100 best ranking websites according to some metric (alexa rank for instance) and do it better than google. Then, maybe you can grab over 50% of the search traffic. For broader queries (in the search knowledge graph sense), in this scenario, people would fallback to google.
I wish there was some compromise, because Google regularly seems to read another mind than my own, automatically "correcting" search terms to terms with similar spelling that are totally irrelevant to my search or including what is superficially synonymous but for my purposes irrelevant in the results. I frequently feel like I have to convince Google to stop second-guessing me and actually consider what I wrote rather than what it assumes I meant.
A few more knobs and switches to adjust that behavior would be helpful at least for power users.
I'll agree with this too. Thing is, 99.XX% of the time DDG works fine. 1% of the time if I can't find a thing, I try with google and probably 50% of the time I can then find what I wanted. E.g. DDG has a 99.5% success rate, Google has a 99.75% success rate. Not too bad by DDG, as I know that last .25% is REALLY hard.
Either way, google is seeing only a tiny % of my search queries, so I'm happy.
Of note, I switched to DDG earlier this year. I've tried to do it in the past and found that the DDG/Google ratios were like 80%/99+% in the past, which is WAY too much of a tradeoff to make. DDG has MASSIVELY improved, I'm using google search <1/day now.
Jumping from "this isn't working on my incredibly niche browser" to "Google don't care about blind people" is completely ridiculous.
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 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.
(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).
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.
While I get what you mean, the use of the term "standards" just conflates an orthogonal issue.
You can be 100% standards compliant and not readable on Lynx, or 100% standards compliant and readable on Lynx.
Relying on JS is not some niche obscure corner or some bypass of the standards as per the English/Greek analogy. It's basically the norm for most SPAs today.
The problem is that the standards are not compliant with Lynx (or rather that Lynx is not compliant with the standards).
What you want is not Google to use the standards, but to use the part of the standard that is about simple, not JS dependent, HTML.
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.
What does that even mean? What standards it complies with? Is there a compliance test suite or report somewhere? Because there definitely are bunch of standards it does not comply with.
(FWIW I work at Google, but not on the search team. I might go looking at internal discussions to see if this is being looked at at all)
[0]: Couldn't find a quick source on this
[1]: https://theintercept.com/2019/03/04/google-ongoing-project-d...
They don't do it because they are more preoccupied with extracting data about their users than they are about accessibility, and yes, this includes blind people. There is not way around it.
It is perfectly legal to be selfish, but let's not bullshit ourselves about what is really going on...
(Extreme apologies for any implied equivalence between myself and the blind.)
It has solutions, like Google voicing out the contents, instead of doing a webpage that is so scrappable that screenreaders can parse it.
The real solution is to find a business model, or a way to organize society, that does not depend on us building nonsensical prisons or restrictions for each other. It's almost as if surveillance capitalism is not the final answer...
They seem to have captchas down to an art in every other context...
Accessibility is "just" a side effect in their EEE war on users.
It should also be noted that it seems that this is a bug with Lynx, not Google.
There's this is you care to read it: https://www.google.com/accessibility/
But that's not the point.
Google seems to be heavy users of https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... which offers a lot more power and flexibility towards accessibility compared to plain text by enabling accessibility to full featured web interfaces instead of basic versions.
See other methods https://www.chromium.org/developers/design-documents/accessi...
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. :(
Should they be expected to make their own ‘re-Googler’ to fix the page so they can use it again?
When there's a browser bug, someone needs to debug it and fix the browser. Otherwise the browser bug will remain forever.
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.
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://www.bloomberg.com/news/articles/2019-07-15/to-break-...
The behavior based searching is crap which has been usurped by people seeking profits. Optimizing the dopamine feed of users and ad impressions of publishers isn't a good thing or something to aspire to.
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?
Yup - curling with Lynx user agent gets a targets of href="/url?q=<whatever>" rather than href="<whatever>" ping="tracking"
Same author, no tracking, works over Tor.
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.
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.
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.)
Perhaps, but the Web is now effectively requires Chrome, or things which look enough like it.
This issue was opened recently for it.
If Mario is able to use Lynx, the expectation is that Mario can probably also use googler.
Hopefully we'll have a PR merged soon.
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.
Is it that you can't think of a good reason to use text-based browsers at all or is lynx itself the issue? command line web tools like lynx and curl are pretty handy to have available.
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.
Starting to feel like Luke Skywalker and Princess Leia in the trash compacter, the walls are closing in.
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.
Any reason people prefer lynx over w3m or eww?
Moreover, fuck Google and non standard practices in general.
A screen reader is a tool like JAWS or VoiceOver which interacts with desktop software (including web browsers like Chrome or Safari) to provide information about what the user is interacting with.
FFS, you had console screen readers in Linux since forever.
And even OpenbSD, with yasr. It works fine with speech-dispatcher.
Less accesible? Maybe in your limited world, but this is "Hacker" "News".
Well, I guess the new IT generations are even less aware of TTS systems since 1998 or so.
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'...
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...
lynx -tagsoup https://www.google.com/search?q=whatever
Yes, because your use of deprecated software is no longer supported is TOTALLY the same thing as being relocated into the Ghetto in Warsaw.
With with lynx not.
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.