[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lynx is a form of accessibility (was Re: Lynx is not Accessibility)



I use many different operating systems, as a person who is blind. I don't usually use textual web browsers, because they usually don't have the amazing amount of commands that a screen reader, like NVDA on Windows, or Orca on Linux, provides. In visual browsers like Firefox, using screen readers, I can jump directly to an HTML item type, like headings at various levels, forms, links, lists, editable text fields, radio buttons and checkboxes, landmarks, and so on. I can do a bit of that in Emacs' browser with Emacspeak, but really the only time I use that is when I'm reading something that I'm going to be using while inside Emacs, like documentation or something, since it doesn't have _javascript_ support.

While text *is* usually accessible, it's not always the easiest to use. Take email for example. Having quoted material at the top of the message means that I (using the Gmail web app), must arrow through possibly many levels of quoted material to get to the reply, and since I may have just heard the material that is now quoted just moments before, it's not all that useful right now as I reread it. However, I'm not going to ask that this way of producing email be changed; although if bottom-posting is the rule of this list, do let me know so I can leave it.

Really, the point of all this is that structure is good for accessibility, but screen readers and browsers must know about it, and be able to use it to allow blind users to move past possibly irrelevant material, or move to relevant stuff.


On Mon, Mar 7, 2022 at 5:31 PM Thorsten Glaser <tg@debian.org> wrote:
Sam Hartman dixit:

>    Thorsten> Alternative solutions may • have accessibility problems
>    Thorsten> (not work with lynx, for example
>
>Working with Lynx is not a requirement for accessibility.

No, but not working with lynx is an accessibility problem.

>Obviously accessibility depends on what your requirements are.

Exactly.

>The needs of someone who is blind are different than than for someone
>who has mobility issues for example.

Right.

I occasionally help out a couple of blind users on the lynx mailing
list. Some of them are on DOS systems and shell out to Unix systems
to access lynx, even.

But that’s not the only use case. Slow connections, text only,
or even font sizes (lynx runs in a terminal where *I* choose
that), are other use cases.

Also, _javascript_ thingies tend to be over-designed. There was
this firewall solution I encountered at work where you had to
drag-and-drop things to create and order firewall rules.

The current solution is to just enter a couple of numbers,
sign and send, which is just perfect for many use cases.

Can we at least agree that there are multiple use cases and there
is not a single solution covering all of them out of the box?

IIRC you mention something about writing a frontend to help craft
the mails that are sent to the voting system. I agree that having
the need for that, in such a technology-oriented community that
Debian is, while surprising to me, shows that eMail only has its
problems.

But I want to assert that removing the current, working, method
cannot be a/the solution for that problem either.

>I stopped using Lynx many many years ago.  Originally it was because
>some sites just weren't usable in Lynx and I wanted to use them.

Yeah. I use lynx daily and do encounter this problem. I have an
ever-changing mix of browsers to fall back to, but the developers
of Firefox seem to want to make my life just so much harder (ever
since the update from 78 to 91 it’s so slow it’s barely usable on
a Core2Duo laptop), and I really hate the bad mouse-oriented
usability of it. Also, lynx at least has black background in my
terminal…

>These days though,  modern browsers actually have better
>technology for navigating a web page accessibly than Lynx does.

Again, depends on your use case. In my case, the font and colour
selection being user-controlled, the blazing-fast rendering (also
on page down, search, etc.), links and form fields are numbered,
textfields need activation, and the space and b keys for scrolling
is massively superiour to any graphical browser (even though links2
comes somewhat close… I like it as manga viewer, but it has issues
elsewhere).

>is not directly an accessibility issue.  In some cases it is because

I’d argue having to rely on proprietary _javascript_ drawing things
is both an accessibility and a worse issue (GNU LibreJS seems to
not have gone anywhere, plus, with it enabled you’d have just the
same site breakage as in lynx).

Webbrowsing at the German ministry for IT security also is (or at
least was $smallnum years ago) enforcing JS disabled for GUI browsers.

>misleading to simply say doesn't work with Lynx == accessibility
>problem.

I will continue to assert that it is, even if not for the obvious
reasons it used to be, with the reasons I listed above.

>regular basis please don't spread the myth that Lynx == accessibility.

I’m not. I *do* spread that !Lynx == !accessibility though, which
I have enough reasons to consider justified.

(There’s also the ROCA principle, in which some webpage should
work fine without CSS and JS, and every “layer” (CSS, then JS)
added just makes it “nicer”. I attended a tech talk by someone
proposing this and figured that it’s also a great case for both
lynx and some amount of a11y out of the box. I think the other
attendees were a bit… surprised by the presenter and me nerding
about it like that… but it’s a point.)

Sorry for rambling, it’s late and I need sleep. I hope I was
at least able to make my points.

Goodnight,
//mirabilos
--
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
                                         -- Henry Nelson, March 1999


Reply to: