Blind users do not, as a rule, use Lynx. This is a common misconception. The Lynx interface is, in fact, very poorly suited for visually impaired users, as it relies heavily on visual layout, color, and cursor positioning to convey information.

The majority of blind users use standard desktop web browsers with screen reader addons like JAWS or VoiceOver.

The blind user in TFA might be surprised at your assertion.

Blind users typically rely on screen-readers, including tools such as emacsspeak (which relies on either Emac's built-in eww browser, w3m (of which I believe eww is based), lynx, etc.

The ability to rely on console-based tools with text-to-speech capability, and receiving typed input, is fairly widespread.

The requirement that interactive content be rendered directly to speech is key.

I am blind. I know or have known at least 20 other blind people sufficiently to know what their browsers are. None of them used Links. One of them used Edbrowse. The rest (including myself) are Firefox, Chrome, or Safari. I have at least one personal project (not public) which uses React heavily. Saying that Links is necessary is an outdated view, so much so that we have things like the accessibility object model [0] in progress to possibly go so far as even supporting use cases like remote desktop connections in the browser by making fake screen reader only nodes in the accessibility tree.

In general, the terminal itself is even not so great. There are efforts like Emacspeak which mandate learning what is essentially a second desktop environment, but outside that it turns out that offering semantics (which only non-text browsers and apps can do) is useful: for example knowing whether or not the cursor is in a text editor, so that deletions are significant, or whether text is a table.

The idea that JS is bad for screen readers--or indeed that we use text-based browsers--is a consistent misconception that is no longer true. It was true 10 or 15 years ago, if not longer, but everything AT has come a very long way since then.

For a source that's not just anecdotal, this has info on primary browser: https://webaim.org/projects/screenreadersurvey8/

0: http://wicg.github.io/aom/explainer.html

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

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.

I see this like supporting DOS in 2019 or somesuch. There might be an esoteric reason to do so but when 99% of the userbase has left and the old thing can't support new technologies, saying that we need to support the old thing forever because a tiny subset of users still use it stops meaningful progress. If there weren't plenty of good, modern options I would be all for Links but there are, so I'm not. At some point it's on the user for choosing not to leave their little island of familiarity, especially when the user is technical enough to be using Links.

> If there weren't plenty of good, modern options I would be all for Links but there are, so I'm not.

What are the good, modern alternatives to Lynx?

Firefox and Chrome both have mature accessibility API implementations at this point. Edge is also at least okay. Internet Explorer has worked forever. You then couple those with a screen reader--most commonly Jaws or NVDA--and you get something that very much resembles Emacs or what have you: there's around 50 or 60 keystrokes I use on a regular basis. It's like a local client-server model (indeed documentation on this topic uses those terms). You couple something implementing the server with a client, i.e. a screen reader, a one-switch controller, speech recognition, what have you, and those consume exposed semantic information. Browsers then map web pages to the platform's accessibility model for consumption.

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.

Ah, I'm sorry, I misunderstood what you meant. You're talking about screen reader compatibility only.

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.

From my perspective there is very little difference. The interface I get out of Firefox is exposed as if it were a text-based browser for lack of a better analogy (it's not quite the same, but the differences are subtle and not obvious at first glance). But I also get the ability to do all the non-text-based-browser things with that interface instead of being limited to what a text-based browser supports, and those things can be made accessible to me. But the really big advantage is that my skills at driving Firefox also work with Chrome, IE, and Edge, and any web view on the platform. Plus there is a large common subset that is shared with all the desktop apps as well.

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.

In that sense, there's links2 (http://links.twibright.com/). (While it supports graphical output, it's a text-mode browser at heart.)

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

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 admit I have an anti-javascript agenda since most JavaScript on the web is used against me, to track me, show ads, autoplay videos, popups, exploits etc. I don't trust you, I don't want you to run code on my computer.

You're already visiting web pages that are directing your computer to access servers somewhat arbitrarily. You're running quite a bit of other people's code on your computer.

I don't consider displaying static documents to be running code.

I appreciate your assistance but I can check spelling; a simple "Did you know that it's Lynx" would have sufficed. Good to know there's two text-based browsers. I didn't, but I and everyone else I know will go on not using either.

Experiences vary, I'll grant that.

There's also a difference between those who acquire perceptive limitations (sight, hearing, also motor control, etc.) later in life, whether through accident, injury, illness, or degeneration, and those who have limitations from birth or a young age. Having to learn some (admittedly arcane) interface such as emacs late in life, with fewer capabilities and often declining cognitive capabilities, is difficult.

And yes, mainstream commercial software and OS offerings are improving. Slighty. (Most are still abysmally poor.)

I'm hard-pressed, though, to see how an increased dependence on dynamic and programmatic web design elements improves accessibility. Especially when wielded by technologists, managers, and clients with little awareness or concern for such access.

Again: Google should be much better positioned to grasp this than most. They clearly don't.

Google themselves are your example. Leaving aside some horrible accessibility keybindings in Docs, both Docs and Sheets are basically fully accessible. in fact Sheets is the best spreadsheet program I've used. It's not as powerful as Excel, but Excel is laggy for a variety of technical reasons that shouldn't exist, at least with NVDA. I can also read presentations in slides, and I might be able to make one. I've never tried; web or not, making slides just isn't something super feasible for a blind person if it's going to look any good.

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.

> Docs and Sheets are basically fully accessible. in fact Sheets is the best spreadsheet program I've used.

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?

Sadly no. Making charts accessible is an unsolved problem. There have been some efforts for accessible graphing calculators that work more or less, but it's not trivial to make a generic one-size-fits-all solution.

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.

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.

I own a braille display and use the 93-volume trigonometry textbook from high school and the logic around it with respect to making sure the right chapter was in the classroom with me as an analogy when explaining CPU caches to people. In the long run I discovered that incredibly fast speech rates scale better than braille for most tasks outside educational settings, but if it works for you, by all means use it. And before someone inevitably makes the "but braille is important for literacy and brain development" point: it is, and I advocate learning it.

However, putting the burden on site developers to support text-based browsers for this use case is O(sites) but putting it on the screen reader developers is O(1). In other words only the latter scales. Braille isn't a very good argument for site authors supporting text-based browsers from any practical perspective, and in all honesty I think most of them would find this off-putting. It's already hard enough to get people to do accessibility; if we make the bar as high as that and go around claiming that it's necessary for accessibility, no one will ever bother.

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.

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.

I used to be legally blind and heavily vision impaired. Even then, the most accessible web browser is Lynx since it runs in a Terminal which has a fixed and rigid UI.

I'm frustrated for you.

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.

...in your circle

You could say that about literally any anecdotal observation. I’m sure you notice trends around you and generalize. In fact, if you didn’t, you would find it hard to pretty much do anything in life. In short, your comment is myopic and unhelpful.

I don't draw broad software trends from just my own perspective though, espcially when my own perspective is directly contradicted by the op

No where does OP suggest that using lynx is common among blind users. He simply stated that he used lynx. Throughout this thread, multiple other blind users have noted that use of lynx is uncommon, even among blind users.

But Google has the access logs to their own website to know how frequent use of any particular browser is, regardless of circles.

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

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

a11y = accessibility; I had to look it up so I'll save everyone else the trouble.

And it reads "ally" ?

The 11 stands for 'eleven letters ommitted'. Cf. k8s (Kubernetes), i18n (internationalisation), l10n (localisation).

Okay, that explains that trend, but wow. We actually managed to come up with something arguably more obtuse than an acronym (and they're hardly the most friendly of things)

I'm pretty sure that "i18n" and "l10n" are about fifteen years old -- not exactly a trend any more (at least, not a new one).

They're a bit older than that – this credible report suggests 'i18n' was in use at DEC in 1985, with appearances in public online discussions by 1989, and in books by the early 1990s:

http://www.i18nguy.com/origini18n.html

Amazing. I wouldn't have guessed it was that far back.

Fancy web people are too cool for acronyms

What was the acronym for "accessibility" again?

    PS C:\> 'accessibility' -replace '(?<=^.)(.+)(?=.$)', {$_.Length}
    a11y

(PowerShell 7)

That's not an acronym, GP's point is that a single word acronym contains even less information than this (apparently called a 'numeronym').

I'm resisting the urge to rewrite it in APL. :) Nicely done.

No need to resist

  (⊃,(⍕2-⍨≢),⊃∘⌽)'accessibility'

I tried to write it a couple of different ways, but I keep coming back to approximately your code as the most direct way, if written slightly differently with (⍕¯2+⍴) in the middle; I'm puzzled by the behaviour of being able to drop and take negative numbers to index from the end of the array, but not being able to use negative indexes in other contexts. Why is (¯1⌷word) an error, instead of working like (¯1↑word) works?

Here's a much more convoluted way, because everything is difficult in this language:

    ,/((⊂∘⍕∘⍴∘⊃@2)⊢⊂⍨((1@2)1,⍨¯1↓1⌷(↑(1,⊂))))'accessibility'
    a11y

a frustratingly roundabout way to build up the boolean vector:

    'accessibility'
     1100000000001   ⍝ for penclose

without counting the length first.

(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"?)

"Everything is difficult in this language" made me smile. :) I mostly agree. There are things things that APL / J make amazingly easy, too, but a lot of simple things are just brutal to me. I'm not a hardcore APL programmer -- I've played with J more than APL, but I'm still a novice at both. I just enjoy the mental challenge sometimes.

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. :)

I'm also a novice at APL, despite thousands of lines of session scrollback building up basic lines that almost work then I change one character and INSCRUTABLE ERROR, over and over. Your take,B,drop design looks simple and sensible but the repetition of N is bugging me - I tend towards codegolf more than code clarity. The kind of drop I was hoping to find would be like you can index non-contiguous indices and update them:

    Vector[2 8 5]←100

but instead of them getting value 100, they get deleted.

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

It's not so ugly, but that took me down another rabbit hole of why I can't turn that into a train because there seems to be no way to force monadic iota when the trains design wants it to be dyadic. That is I want 3 4(⍳⍴)'accessibility' to come out the same as (⍳⍴)'accessibility' by somehow blocking the iota from having a left arg. Like 3 4(⍬∘⍳⍴)'accessibility' but Dyalog shoves the numbers in as a left arg then complains that the left arg is unavailable. Is this a problem with having to overload every glyph with a double meaning because of limitations on IBM 1960s printer technology, or is this my misunderstanding of tacit code and limited knowledge of operator behaviour, who knows. Maybe in another thousand errors I'll know a little more.

I just enjoy the mental challenge sometimes.

There's no accounting for taste ;)

Sorry about the pseudo code but I don’t have an APL font on my phone:

Vector[(iota rho Vector) set-minus indices to remove]

No accounting for taste -- truer words never spoken. :)

---

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'

Here are examples of Take and Drop (these are just to help you translate between APL and J):

       5 {. y
    abcde
       10 }. y
    klmnopqrstuv

Monadically the same verbs mean First and Last:

       {. x
    5
       }. x
    10

With M and N defined as the first ({.) and last (}.) values of X, take M from Y, and join (,) it up with the result of dropping N from Y:

       (({. x) {. y ) , (}. x) }. y
    abcdeklmnopqrstuv

Close enough! Now here's where we invoke the 'make tacit' verb, '13 :'. We have to wrap the original x/y expression in quotes, to make it a string, and then call it like this:

       13 : '(({. x) {. y ) , (}. x) }. y'
    (] {.~ [: {. [) , ] }.~ [: }. [

There's the magic. The tilde (~) is like ⍨ in APL, and the bare [ and ] represent 'take left value' and 'take right value'. The [: word is called a 'cap' and is used to limit the left side of a verb fork. (Sorry, I don't know the equivalent in APL.)

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
 

If you've truly abandoned all hope, the J vocabulary is listed here: https://code.jsoftware.com/wiki/NuVoc

Ooh that's interesting, and I can read enough J to see how the basic version works, and a bit of what the tacit version is doing; the left and right functions map to ⊣ and ⊢ in APL, I don't know that the cap [: needs an equivalent because Dyalog APL recognises two functions alone without that, and calls it an "atop" for (fg) is (f(g(x)) or "f atop g".

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

Cool! I didn't know that about APL, and thanks for the Dyalog 'n_tacit' link.

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.

APL is a strong drug, I need to regulate my dosage. :)

Why can I not resist these urges? Here it is in J, which is basically APL but in ASCII:

       ({.,(":@(_2+$)),{:) 'accessibility'
       -->  a11y

Did you reply to the wrong person?

This is a cool one-liner though!

TIL

Thanks. I should have spelled that one out.

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

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

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

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

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

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

They don't?

Search term(s) are the URL parameter:

   ?q=<query>

Which does show in my history AFAICT.

On the regular version, not the lite. Here's my URL after searching for "asdf":

https://duckduckgo.com/lite/

In the search form, it uses POST instead of GET to perform the searches.

Even if the search form uses POST, the server does read the parameter if it's specified in the querystring. That is, https://duckduckgo.com/lite/?q=asdf works, so adding it as a search engine with URL .../?q=%s should work as well.

That's nice I guess. Still a shame the text input can't be used without forgoing the history.

For desktop, I believe so. Not for Android.

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

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

How would I get into such accessibility circles?

A good starting point:

https://a11yproject.com/resources/