Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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

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




Defaulting to simple HTML allows one to support all incredibly niche browser. That is the beauty of protocols and standards. This is particularly relevant when it comes to accessibility. Google search results are literally lists of web links, so this is absolutely doable.

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


Yep. Following standards has great side-effects all around. The same things that break sites for the blind also break it for UX-enhancement extensions like Tridactyl, which lets you click elements from the keyboard, so long as sites don't go out of the way to make clickable buttons undiscoverable.

(Extreme apologies for any implied equivalence between myself and the blind.)


I actually think this a great example of the Curb Cut effect, where accessibility features that are vitally important to one group of people (wrt curb cuts, wheelchair users) also provide broad benefits to many others (wrt curb cuts, one example would beparents with small children in strollers).


Blind enablement also allows easier webscraping, which is what I think Google is more worried about.

It has solutions, like Google voicing out the contents, instead of doing a webpage that is so scrappable that screenreaders can parse it.


Webscrapping isn't bad per se. It's being made to look bad by parties that want to eat their cake and have it too. If you show something to a person, that person should also be able to use custom automation to view it. If you show something publicly, the public should be able to use custom automation just as well. Don't want someone scraping off your site and using it for profit? Limit the audience and sue people making profit off your data for copyright infringement.


What about bot-throttling heuristics and captchas for suspected ones?

They seem to have captchas down to an art in every other context...


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


Google is mostly focused on trying to kill URLs at the moment, both in their pages and Chrome.

Accessibility is "just" a side effect in their EEE war on users.


I don't feel that's fair -- yes, Lynx is not really updated much anymore and at this point very niche. But it must work for their workflow, and I feel like something as critical as search should have fallback to work with very 'primitive' browsers and older W3 standards.

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


Recently I read announcements that Google was making it harder to view internal projects/discussions on other teams [0] (suspiciously, this came after the leak that they were still working on a search browser for China [1]). Have you, as a Google employee, found it hard to audit or observe previously visible projects?

[0]: Couldn't find a quick source on this

[1]: https://theintercept.com/2019/03/04/google-ongoing-project-d...


Perhaps you could contribute better by citing examples where Google does care about blind people instead of calling an actual blind person's argument ridiculous.


It doesn't matter if he's blind; I'm calling the connections ridiculous. Lynx isn't a browser for blind people, it's a browser for the terminal. The terminal isn't some accessibility tool either, and was never made to be one. Drawing a connection between Lynx and blindness accessibility is tenuous, saying that this change is Google is attacking Lynx is even more tenuous, and drawing some sort of transitive connection between all of them to say that the change made is somehow against accessibility because it doesn't work on lynx is doubling so, bordering on...

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.


Please, learn a bit about edbrowse, made by a blind developer, and think again.

https://edbrowse.org/


Perhaps we could contribute ourselves instead of asking if others can.

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


How about the built-in screen reader in ChromeOS?


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


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


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


The standards just describe what to do to make a standards compliant HTML page, what tags are allowed etc.

There are no standards that say that e.g. your page can't be all dependent on JS.

In other words, Google could be 100% standards compliant, and not work in Lynx.


The grammar of the English language does not forbid one to write in Greek, but if you choose to write in Greek only, you will compromise on a lot of people being able to understand you.

The same with standards, and you are misunderstanding on purpose.

If Google chooses to not support simple HTML, then they are choosing to not support countless accessibility tools, and they know it. Some blind people will have a more 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.


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

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


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

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


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


>The same with standards, and you are misunderstanding on purpose.

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.


SPA's are shit for the blind.


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

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


According to another comment thread, this isn't accurate: https://news.ycombinator.com/item?id=21629207


It seems that the problem is caused by the fact that Lynx isn't standards compliant anymore, and fails to interpret valid HTML5 structures correctly because they aren't valid under older standards.


Lynx is the definition of niche...


According to some other comments, the problem might indeed be that it is not a browser compliant with the current HTML standard: https://news.ycombinator.com/item?id=21629207


> it’s a standards complaint browser.

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.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: