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. Devin Prater [email protected] On Mon, Mar 7, 2022 at 5:31 PM Thorsten Glaser <[email protected]> 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 > >
