doesn’t work in lynx

Manuel Strehl says:

The “doesn’t work in Lynx” card is so convenient, because it’s a simple way of what the average developer understands as accessibility. Firing up Lynx in the terminal is easy as pie.

It points to a fundamental problem though: the lack of easy-to-use and out-of-the-box tools to detect accessibility flaws. (I’m mostly not speaking of generating WCAG checklists but of ways to simulate the experience, so the dev can decide, what is an error, what actually a feature or irrelevant for the purpose of the page.) Only when there are widespread tools that are as easy to handle as typing lynx https://example.com in the console, those arguments will die out finally.

Tim Harshbarger says:

I entirely agree that using Lynx as a basis to determine accessibility is not valid. But what is the basis for deciding that or deciding what is accessibility supported? For example, we might agree that Lynx isn’t and that Windows 8.1/Firefox 27/NVDA 2013.3 is…but where in the middle do we draw the line and what factors are part of making that decision? I realize this post is about a blatent misuse of Lynx to try to establish that minimal accessibility line, but I expect figuring out where exactly that line might be is probably one of the more chalenging questions that face accessibility practitioners.

Jared Smith says:

For whatever it’s worth, in our most recent screen reader user survey, only .7% of respondents were using Lynx. Full survey data will be published in a couple days at https://webaim.org/projects/screenreadersurvey5/

Alastair Campbell says:

This is very closely related to the “If it doesn’t work without JavaScript is it accessible?” question, which Matt May answered rather profoundly:
https://lists.w3.org/Archives/Public/w3c-wai-ig/2012OctDec/0223.html

The fact that Lynx doesn’t support (new) HTML elements as well takes it a step further into obscurity. So long as there are cheap/free user-agents on the main platforms that do support the technology, Lynx is not relevant to accessibility.

Also, I’m not really convinced about the experience aspect Manuel mentioned, as depending on the site Lynx may not give you anything near the experience a screen reader user gets. For example, is there’s JavaScript & WAI-ARIA widgets on the page, the screen reader would get a very different experience from Lynx.

I agree that developers knowing about the experience helps, but there isn’t a short-cut to actually trying your interface with keyboard-only, zoom, screenreader, etc.

Denis Boudreau says:

https://twitter.com/dboudreau/status/439033710961520640

Steve Faulkner says:

Well the word accessibility alone doesn’t mean anything.

To clarify: Accessibility, in terms of providing access to web content for users with disabilities.

By building a website that doesn’t work in Lynx, you deny access to those who choose or have to use Lynx.

If someone chooses to use lynx, nobody is under any obligations to support it. Why would anyone have to use lynx? There are a wide range of free and freely available browsers that support modern web standards.

Stomme poes says:

Lynx (and W3M) have been invaluable to me in several occasions (when silly folk insist on sending me ginormous HTML emails so they can encumber their short spammy messages with nested tables to show the company logo they paid some designer too much money for; or when I decide to run the Operating System of My Choice on a laptop built only for the One True OS and therefore get about a half-hour of battery and I’m at a conference; or when I’m on a laptop *not* built by Molvanîans that simply has low battery and I want to get tweets to see where we’re meeting up after this talk…),
…however…
I don’t generally expect websites to work in Lynx, nor hold them accountable. In fact I can’t check Twitter in Lynx; I use EasyChirp instead. Mobile versions of sites generally work. Wikipedia generally works.

While I do see it as lazy for developers to use some user’s paid-for bandwidth to send a metric shit-ton of Javascript to load static plain text as HTML because it’s some latest hipster web-dev method, there are also times where developers have good reasons to load static junk with metric shit-tons of JS, and if I don’t know those reasons (load-balancing? Enabling more accessibility to a higher number of users by lots of feature detection and adjustment? Is only half content and half what someone called “designer-centric app-ification of the web” and needs to Do Stuff?) I can’t hold them to the so-called Lynx-standard.

Lynx and the like are just handy enough that it’s awful nice if sites I expect to be rather static, like say a Wikipedia page, actually work, but even as a general access matter, it cannot be a benchmark. It’s down there with “the site’s only accessible to people with computers and internets and speak the language,” almost.

Manuel Strehl is totally on to something– while developers like me are more than willing to spend hours reading up on accessibility things, and running a bazillion virtual boxes testing stuff, all for employers and clients who couldn’t give a rat’s butt, the *majority* of developers are not willing to do this, don’t have the time, and yet would indeed like to be able to check that something fits at least their version of “doesn’t cause global thermonuclear war”, much in the way many do now with Firefox 3.6 and Internet Explorer 6 and 7.

Imagine if Spotify devs had the ability to unplug their mice long enough to discover the subscribe button wasn’t clickable… oh wait. Okay, but still, I do totally see the use of a sort of quick-dirty check tool thing. It wouldn’t replace stuff like Wave– this would be for people who would and never will use Wave, because wherever they are and work, accessibility isn’t A Thing and never will be.