Thanks for the in depth feedback. It’s a shame about the keyboard-shortcut incompatibilities.
Since some of these tools expect plain HTML, perhaps the best alternative in this case is a richer HTML interface.
It’s not so much that they expect plain HTML. It’s just the keystroke thing is a known thing.
Javascript on focusables don’t have this problem for example: listening for keystrokes on form controls, links and buttons should always work.
Also, certain roles on elements should also alert a screen reader to pass on keystrokes-- the question then is just one of support, spec robustness, etc. I recently ran across this with drag and drop: supposedly if your drags and drops occur in elements with list and tree roles, keystrokes should be passed on.
However sometimes developers need other HTML (non-lists, non-trees… these are kind of restrictive honestly), and in my case even doing everything right worked everywhere except JAWS in IE. For that, we added role=“application” which can force the SR to pass on keystrokes, but this is one of those powerful dangerous tools as you’re basically taking all navigation and tools away from the user and claiming you can meet all their needs with your own JS. And that’s often a pretty bold claim to make (so for this reason, role=application is meant to be used sparingly, and on the smallest part of a page or app as you can manage… and if there’s any plain text inside that container with role=application, you need to wrap that back in a role=“document” to give reading/nav keystrokes back to the user so they can read).
I think Discourse can work with screenreaders-- remember, the shortcuts like j/k etc are for keyboard-only power users who are not using AT. Users of AT already have similar keyboard shortcuts if your code is sufficiently structured, so that’s not necessarily a problem. You can have two kinds of people surfing the same site in two different, but fairly equivalent, ways.
But with an application this javascripty it takes some devs on the team who know more about this area, and it needs AT users to test and report bugs (also screen mag users, keyboarders without AT, Dragon users etc).
7 Likes
I tested with Lynx following interest from valued community members who are sometimes (or often) in areas with low bandwidth; who typically prefer Lynx in such situations.
Not a long test (only ten minutes or so), but enough to be pleased with the appearance, the orders of things and so on. An example screenshot:
Without detracting from the foci on accessibility:
- please, how much effort might be required to enable log in for users of Lynx?
Beyond that point: from what I saw of the NLI (not logged in) views, I assume that already there is support for most of the features that logged in users will treat as essential or desirable.
Side notes:
- should tags in meta include accessibility? (I found no more recent/relevant topic for Lynx)
- noted in Firefox, with thanks, the Discourse response to keying
End. Wow :clap:
4 Likes
Have you had a chance to evaluate Discourse for ease of use with a screen reader since your last post a year ago @Stomme_poes ?
Does anyone else know if any improvements have been made since the most recent big discussion on accessibility about year ago on the other similar thread Accessibility software and discourse
3 Likes