Also see: http://www.discourse.org/faq/#browser
Also see: http://www.discourse.org/faq/#browser
OK, makes sense. Thanks. FWIW, Lynx might still be around in 10 years, just because it’s so useful for the visually impaired. But who knows?
I hope this vision does not include “getting rid of” all visually impaired people ;).
The answer to making sites more accessible is not to make them work in Lynx and other text based browsers. It’s to embrace standards like ARIA which has the backing of all major browsers.
Right now, Discourse should work out of the box with a screen reader due to already using these standards. I’m sure we could be better, but improving that is going to require feedback from users who use the screen reading software and provide feedback. If something is preventing them from doing it I’d love to hear it
To be clear, I did not mean to say that making a site accessible requires it to be accessible with text based browsers, strong ARIA support is (als you already said). However, accessibility is more than being nice to screen readers, it is being nice to any (sensible) form
I disagree. Being “nice to lynx” is not about accessibility, it’s about supporting obscure browsers. I would not lump “Netscape 4 support on Windows 95” under accessibility either.
Let’s focus on the users with disabilities (be they minor or major) and how we can help them use Discourse with the software they use every day like screen readers, large fonts, etc.
[Whoops, premature “Send”, this is the real thing.]
To be clear, I did not mean to say that making a site accessible requires it to be accessible with text based browsers, strong ARIA support is (as you already said). However, accessibility is more than being nice to screen readers, it is being nice to any (sensible) form of accessing the site, including non-/limited-JS agents (be it a browser, braille device, bot, et al.).
While making Discourse editable by non-JS agents is certainly not in scope for the project (and rightly so, at least for the time being), making it readable and navigatible for those agents is relatively straightforward and IMHO important for this software (though still not easy).
Sidenote: There are more reasons for JS not being available for an agent than missing/limited support or the user having disabled the feature, e.g. when there is a Network error or Internet access is poor (as in many many places even in the Western hemisphere! e.g. I’m currently browsing ultra-slow on my phone since I went past my monthly budget) or a proxy/ISP strips or manipulates the code (as it happens in many corporate environments and has happened with mobile providers!). Sometimes the user is just not in control of the network/his environment, and this will still be true in 10 years. At least reading & navigating should be possible in those situations.
I’ve been getting feedback from screen reader users on TuDiabetes and we’ve made improvements based on their findings. They use JAWS and NVDA. It would be great to have more contributions, so let us know what we’re missing.
As I’ve written in my full post (had a little issue with half-frozen fingers and bad phone UI, sorry about that), any reasonable way of accessing the website should be considered. Netscape 4 is obviously not relevant, Lynx is debatable, though not necessarily a sufficient reason to improve some aspects of Discourse.
Indeed that should be the focus.
If there is any chance to have Discourse render directly accessed pages on the server instead of pushing everything to the client, would help in a lot of cases (not only – or mostly – regarding accessibility, depending on how you understand “accessibility”).
We received advice from @stevefaulkner an expert in the field and acted on it.
We will continue to improve Discourse based on feedback.
As it stands the biggest pain point, which is a devil to solve is Email parsing. At the moment our parser requires the response is “at the top” if it is inlined or anything non-traditional stuff gets rejected. That tripped @MarcoZehe last time when he tried to respond. I would like to improve on it and we are logging all email failures so we can extrapolate better logic.
I received a message on our forum from a blind user who has recently signed up. He has expressed some disappointment with the accessibility of Discourse when used with a screen reader and I’m wondering if there is anything we can do to help.
Here is the message:
I am a blind person. I live in the village and would very much like to be an active participant on and contributor to this site. I have however had to ask someone to help me sort out sending this message.
I appreciate this forum is run by volunteers but I have to say it is one of the most impenetrable and inaccessible websites I have visited in a long time. To start with, all the buttons for taking actions of various types appear to be unlabelled graphics and my screen reading software simply announces them as lists of letters, numbers and symbols. In addition, navigating around the site is incredibly difficult given the layout and format that has been chosen.
I am far from being an IT expert. To me, IT is definitely a means to an end. I wonder though whether there is anyone involved with putting this site together, maintaining it or administering it who could do something about making it more accessible? I do hope so as I think it could be a really useful, local forum but as things stand, I am finding it so hard to use that it really isn’t worth the effort for me personally. I do hope something can be done to make it easier to use for everyone.
I have read through the linked topics here and appreciate that the team has desires to improve accessibility but I am wondering if it is one of your regular usability test cases? Is there a roadmap item to work on accessibility or is it deemed accessible enough (having had no experience with screen readers, I genuinely don’t know!)?
I don’t know the specific issues but I am reluctant to put the burden on our blind users to provide specific feedback. This user in particular is non-technical, hadn’t heard of Discourse, and simply wants to take part in the forum.
Is there anything more that we can do to improve accessibility for blind users proactively rather than reactively?
Has anyone in the meta community got any experience with this? Is there any feedback I can provide? Would a guide on keyboard shortcuts help? Does anyone know if the keyboard shortcuts work well with screen readers?
Step 1: find out what his screen reader software is. It seems that it might be reading him item ids, for example ‘ember1126’ for the ‘latest’ button… not sure of that, though.
I am very confused about this particular piece of feedback, our buttons all have
aria-label set, the “like” is labeled “like this post”, and so on. We need to know which buttons the user is talking about and which software they are using.
We very much want to fix and improve accessibility, we do need specific feedback and details on what needs fixing.
In the past we have worked with @MarcoZehe on a bunch of issues, as a result of direct feedback by him we added a large amount of
aria-label tags. Additionally, we have improved our email processing a lot to allow users to interact better with our site via email. Recently, we also added a proper
Reject log so we can better analyze all inbound email rejections.
My first recommendation for you @danwad is to ensure you have “incoming email” enabled. This is a must. After we need to know what software the user is using, maybe get it and try using it yourself, then report some specific issues to us?
I have since found out the user is using JAWS 15 but is in the process of upgrading to 17 which hopefully brings some improvements.
I have advised about the “email me for every new message” setting and I am in the process of getting a replies@ inbox for the incoming email.
I have also informed the user of the keyboard shortcuts for navigating around the forum. I noticed that when using j and k to select topics and posts a selected class is added to the selected item. As we are not using the browsers focus state, I would guess that a screen reader would not pick that up. If there is a reason we can’t use focus, maybe aria-selected is appropriate here, although focus is probably ideal?
Relevant: ARIA - Managing Focus
I will install a JAWS 17 trial and try to provide some concrete feedback.
JAWS 17 should not make any changes regarding the buttons-- it’s supported aria-label since at least 2010/JAWS12.
In any case, this may be more an example of someone like that person we all know who has a lot of trouble using something like Gmail. Gmail is “technically accesisble” but it’s built for nerds and power users. I have trouble with it (guess I’m not nerd enough), because it takes the basics everyone wants (an email client should let me read mail, write mail, delete mail, forward mail, and add attachments) and overcomplicates it by adding in a buttload of feature-creeped options on top that at least I am always accidentally triggering some way or other and it just fights me all the way. However, technically, it does not discriminate against users because they have a disability.
Discourse is the same thing. It’s a glorified forum software that loads so much more fluff and stuff on top that it’s restricted to certain kinds of users. It does not progressively enhance, it assumes all its users are nerds with the latest and greatest of hardware, software, and network. It assumes their icons always load and that all people magically know what they mean (ug). This is a deliberate decision on Discourse’ part, so things like usability and accessibility considerations must be taken in that light. Also keep in mind that both Marco and Nolan are nerds too. They are developers who also happen to use screen readers, plus Marco specifically works in the accessibility space. Neither are representative of Joe User who also happens to use a screen reader. They’ll catch actual bugs, and can offer some judgement calls, but that doesn’t mean if all those issues were fixed that anyone using JAWS will effortlessly be able to figure out how to use Discourse software.
Yeah, I personally am of the “Tim Berners-Lee definition of accessible” which means progressive enhancement, working reasonably regardless of hardware/software/someone’s income level/education/disability/whatever. But the official definition is something like “does not unduly hinder or lock out users simply because they have a physical disability.” That is the definition Discourse wants to use, meaning many people looking for forum software should look elsewhere.
My unsolicited advice to the Discourse devs is to continue to have users of AT (and keyboard, and touch, and speech, and and and…) continue to test Discourse and give feedback to devs, and not close issues like TechnoBear’s without fixing them, since anything that is continuously developed can continuously add new bugs you didn’t have back when, for example, Marco did some testing. It’s part of your regular QA, right? And developers are testing for accessibility as they build any new thing, for example by using an automated tester like Tenon.io right?
This will help Discourse improve and maintain its technical accessibility. And obviously any random AT user can find a bug and should report it, that’s good. But I don’t see Discourse working for stuff like Lynx any time soon, and I can’t say that counts here as accessibility issues. If there are JAWS bugs, then yes those are bugs. The email thing sounds promising, though.
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.
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.
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:
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.
End. Wow :clap:
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