Always fun to read #hackerNews and their rather ... let's call it ... qualitatively exceedingly disappointing mentality towards #accessibility (stroopwafel to the dutchies who see what i did there). But some points do make me think to what degree, say, #screenReaders could be innovating more.
One thing that stuck by me was a comment on an article regarding the use of "click here" that basically suggested some kind of heuristic for, say, reading the entire line of text when that's encountered, rather than the link text. Another one could be including the previous sibling's accessible name on unlabeled form fields which I ...think? JAWS might already be doing?
Like obviously these should be toggleable to not screw up audits but I think after 30 years we can safely say people often can't be forked to learn #HTML basics and it might make some things smoother?
One thing that stuck by me was a comment on an article regarding the use of "click here" that basically suggested some kind of heuristic for, say, reading the entire line of text when that's encountered, rather than the link text. Another one could be including the previous sibling's accessible name on unlabeled form fields which I ...think? JAWS might already be doing?
Like obviously these should be toggleable to not screw up audits but I think after 30 years we can safely say people often can't be forked to learn #HTML basics and it might make some things smoother?
Florian
in reply to Florian • • •Mikołaj Hołysz
in reply to Florian • • •It's really sad how we went from "there's no accessibility API so let's just hook some interrupt handlers" to "not our problem, please file an issue upstream"
Screen reader developers these days seem to be doing very little in therms of "forcing" 3rd party apps to be accessible, even if their developers don't care.
If we want accessibility, we should be doing as much of the legwork as possible, not depend on somebody else's generosity and charity.
Florian
in reply to Mikołaj Hołysz • • •Mikołaj Hołysz
in reply to Florian • • •I'm sure NVDA's GPL license (which makes it almost impossible to commercially develop scripts) doesn't help either.
Apple actually has the infrastructure for it, but it doesn't seem to be used beyond first-party apps.
Florian
in reply to Florian • • •Some ideas off the top of my head:
- Addons/scripts not for applications or websites, but for specific UI toolkits (QT/the 50 different .NET ones/WX etc.) so the screen reader can work out better labeling for unlabeled, or badly labeled controls. Yes, .NET developers should toString() their list items. No, they probably aren't going to do so, so please just concat the text of the child(ren) of the listItem and echo that instead.
- When "click here", "Learn more" etc. are encountered check for more text in the current line. If exists, read. If not, depending on a config settings with loads of "you might not want this" disclaimers, read the previous line instead.
- I'd be curious to what degree we can infer state/roles for "clickables" based on what comes back from the browser's accessibility tree... CSS classes? Common heuristic patterns? I doubt it, but I'd be curious.
- Form field with no associated label? Check the previous non-<i> sibling, it's ALMOST always the right label.
etc.
Mikołaj Hołysz
in reply to Florian • • •There are a few popular icon toolkits out there. Most icon buttons are either done via fonts or CSS classes. Recognizing and properly labeling e.g. the 10 most common trash buttons would go a long way in fixing the "unlabeled button" problem.
On the web, you could even have some kind of database mapping sha256 hashes of the most common SVGs to their lables.
Florian
in reply to Mikołaj Hołysz • • •Mikołaj Hołysz
in reply to Florian • • •Yeah, I think extensions are a really good idea, because they seem to have more access than a screen reader, e.g. the ability to run arbitrary JS.
I think screen readers should have their own companion extensions for things like this, but... a man can dream.
Mikołaj Hołysz
in reply to Mikołaj Hołysz • • •