191–200 of 333 posts
There used to be a saying in a11y circles, "Google is a blind user".[1] Now Google are manifestly anti-blind-user. Shouldn't be anything a major ADA lawsuit couldn't fix. Meantime, DDG is actually pretty damned good. For console users: https://duckduckgo.com/lite ________________________________ Notes: 1. https://www.w3.org/2006/Talks/06-08-steven-web40/
a11y = accessibility; I had to look it up so I'll save everyone else the trouble.
Startpage.com, a Google proxy, still works fine in lynx.
Earlier quoted context omitted.
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…
A lot of todays websites are evil. Just today, I couldn't even mark and copy just simple plain-looking text.
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.
Earlier quoted context omitted.
Are you saying the OP is lying about being blind or is a fake?
Perhaps I spoke a little too broadly. What I meant is that the bulk of blind users don't use lynx. This particular one appears to -- sometimes? -- but this usage is not typical.
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/ is a console-based browser that claims to support modern sta…
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.
Earlier quoted context omitted.
The blind user in TFA might be surprised at your assertion. Blind users typically rely on screen-readers, including tools such as emacsspeak (which relies on either Emac's built-in eww browser, w3m (of which I believe eww is based), lynx, etc. The ability to rely on console-based tools with text-to-speech capability, and receiving typed input, is fairly widespread. The requirement that interactive content be rendered…
I am blind. I know or have known at least 20 other blind people sufficiently to know what their browsers are. None of them used Links. One of them used Edbrowse. The rest (including myself) are Firefox, Chrome, or Safari. I have at least one personal project (not public) which uses React heavily. Saying that Links is necessary is an outdated view, so much so that we have things like the accessibility object model [0]…
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.
Earlier quoted context omitted.
Perhaps I spoke a little too broadly. What I meant is that the bulk of blind users don't use lynx. This particular one appears to -- sometimes? -- but this usage is not typical.
...in your circle