Hacker News Reader

Comment by at_a_remove | Hacker News Reader

Many years ago, I spent a lot of time in the doghouse during a major redesign overhall. I had no say over the design, but the HTML and CSS were up to me. I took as much care as I could to work on accessibility, despite all of the "hurry hurry hurry." The guidelines then were not especially helpful, but what made things particularly difficult was that I could get zero access to any of the popular screen-readers.

I like to think I did alright, and I was eventually told by the various disability groups that I did ... but I really, really think not having various screen-readers to test against was something of a handicap of its own.

View on HN

Currently the situation with screen readers is a bit better:

* linux: orca, free and open source

* windows: nvda (free and open source), narrator (builtin, free)

* mac: voice over (builtin, free)

The point of having accessibility standards is that if you follow them, you won't need a screen reader to test them out.

That this approach doesn't work is a sign that various vendors (including those who write screen readers) don't value those standards.

I once worked for a nonprofit group that advocated for blind people - they were involved with the standards. This was a frequent complaint: Google/Mozilla were sometimes the problem as they felt some of the pretty good proposals would hamper the evolution of the web, etc.

It's hard to know whether you've followed the standard correctly if you can't verify the output.

> It's hard to know whether you've followed the standard correctly if you can't verify the output.

Being able to verify certainly makes it easier, but a standard like "Ensure all images have alt-text" does not require a screen reader to verify.

And the thing with standards is that often no existing product (screen readers in this case) will fully comply with the standard - so if a given screen reader fails on your site, it may well not be your site's problem. This was (and perhaps still is) the case with Web standards in general. In the old days, there was usually not a single web browser that was fully compliant.

Your reasoning for why one shouldn't want to test with screen readers seems more like reasoning one should want to. The more divergence from standards the more you want to validate it works as desired not the other way around.

You still need some sort of verification, even for something as simple as ensuring that images have alt-text. Maybe you missed some images that are dynamically generated in a way you forgot about, or have a typo in the tag.

If screen readers aren't compliant to the standard, then you need to test against as many screen readers as possible to ensure that your site is accessible. Users want a site that works, not a site that complies to an unimplemented standard.

I don't know how many additions are needed to standards but I'd like to see better support of the standards we have. It's way too common for browsers to implement standards wrong when building the accessibility tree. Also, there's so much of existing standards that are not supported by assistive technologies. I don't mean newer ARIA attributes, I'm talking about HTML4 (or older). Examples:

1. There's hardly any support by screen readers of the `headers` attribute on table cells, to associate the correct row and column headers.

2. Dragon NaturallySpeaking has provided voice control of computers, including web browsing, for quite a while but it still can't identify an implicit form input label (that is, <label>Name <input name="name"></label> rather than explicit <label for="name">Name</label> <input name="name" id="name">).

This is now a little better. One of the major screen readers is open source (NVDA, it's written in python and on GitHub), and there's a super basic one Google built for chrome you can easily try out.

If you have a Mac, you should be able to use Voiceover: https://support.apple.com/guide/voiceover/welcome/mac

If the website is usable in lynx/links/w3m etc. then it is probably adequate as far as accessibility is concerned. Or so I've been told.

That's not really accurate, as screen readers read the page that's present in the modern browser (IE, Chrome, Firefox), including whatever has been done with JS (mostly), so even if the initial page is fine, your progressive enhancements may yet make things inaccessible.

A very common problem is assuming mouse-only input for buttons or menus, making them not work from the keyboard use.

That was part of one of my best techniques. The boss thought I was crazy when she caught me trying it, but I would put on very dark sunglasses, fire up the site in Lynx, and then use a pencil in my teeth to get around. If that was too hard, I knew I had to rethink something.

Thank you for being a conscientious practitioner of your craft.

Reply on news.ycombinator.com