I spent some time trying to use the site with both JAWS (in a recent version of IE) and on a Mac in Chrome. The results were not particularly good. Has there been any work on this since the messages last year?
We did implement keyboard focus styles at the request of a customer. That should have helped some.
(try repeatedly pressing tab with the focus on this window.)
We finally got its sort of working on a mac. It slowly works it’s way around the page and eventually makes it to the content after about a minute. If you hit tab at any point you can never tab back to the content (post).
We are trying again with windows and jaws now.
Same issue the content of posts are not accessible via tab at all.
Ok using voice over (Mac) I can navigate, read posts and make this reply. The post gets broken into multiple chunks. In you reply the text before and the
tab
show up on separate lines. I am going to have to spend a bunch of time with Jaws (windows) it looks like.
That said I still think that there is an issue that stops tab from getting to the post content.
I need to apologize for my gruff tone here. We are in the first couple weeks of transitioning off of two old campus mailing lists that as one student put it filled them with rage. There are as you might expect some holdouts and that tension has added to that from trying to form a functioning community that will scale to thousands of users. When at the last minute we got reports of screen reader issues it left me gruff. Unfortunately we were so distracted both by the lovely functionality of the app and the community developing that we never really looked at accessibility. My/our bad there.
After both some work on my end using a screen reader and some more work by the person how reported the issues we have come to a conclusion. That is discourse is in this case is not much worse than average for new generation webapps.
As a sidenote if you have a mac turn on Voice Over (in the accessibly pref) , do the short training and try using discourse with your eyes closed. At the very least you will discover that the tabbing does not really work and that the order of elements on the screen may not be what you think they are.
Anyways if you thought I sounded grumpy sorry I should not have let that through.
6 Likes
Nah, don’t sweat it. I’d be there too. Accessibility takes a back seat anymore and it is annoying. Yes all of the infinite scrolling, sliding replies, pushing responses is awesome, but if it isn’t accessible it is all but moot. However, I also understand the need to get a product to fruition and then come back to accessibility. Accessibility is likely a very limited market, so circling back does make a good business plan.
It is true that the keyboard support has been greatly improved over the past couple of months. There is still room for improvement, but when isn’t there? 
1 Like
If there are other simple things we can do to improve, definitely keep suggesting them!
2 Likes
Hello,
I’m very interested in this issue. I myself am blind, run a few mailing lists, and find the concept of lists as typically implemented to be incredibly frustrating for a discussion group of any volume. I’d like to deploy Discourse for a few communities of which I am a member, but the access issues make that a non-starter.
As noted, I think Discourse’ accessibility compared to many modern web apps isn’t significantly worse, but there are touches that might improve things. One example I recently gave was of links without text. When tabbing around, I often just hear “link” with no idea what the link is to. This can sometimes be mitigated with a title attribute on the <a/> tag, or with an alt attribute in the case of image links. Use of ARIA might also be a nice touch, since i gather there are a number of rich UI components and it’d be nice if my screen reader identified them as such.
I’m a member of a co-op of blind software developers. Some of our early stage efforts involve identifying substantial open source projects, providing detailed and free reports of their access issues, working with them to fix the problems and, ultimately, documenting those experiences as blog posts/case studies proving that accessibility doesn’t necessarily mean ugly or non-functional. We’re currently doing this with Piwik, and the next version should have substantially better access. We may be willing to do this with Discourse too, but would really like a commitment to work to resolve any issues we identify since it takes time on our end too. As this thread demonstrates, accessibility is important for Discourse adoption, and is crucial if it is to move into some governmental and non-profit spaces. If there’s interest in continuing, drop me a private note and we’ll start the process!
9 Likes
So here it something I learned last week screen reader tools already have keyboard commands that people with visual difficulties use. The difficulties not just blindness but things like very small areas that the can focus through. So the keyboard commands might not be readily apparent to a person using discourse. There are some, crappy, ways to detect screen readers and it might by useful to make an explanation of the keyboard commands more readily available. What that would look like I do not know.
I’m not even necessarily talking about the keyboard commands, but just being able to tab to most elements is now viable and using Enter to select a link is typically viable now too (those were big improvements). As prior to that ability, you couldn’t even login using just the keyboard.
Actually tab never makes it to the content of a post. It also takes 15 tab to make from the avatar on one post to the avatar on the next post. I am using avatars as a proxy to count since you can not make it to the post. Any the keyboard commands under shift? are more useful.
Yes, there are still issues with tab, but not too long ago, tab was entirely broken. shift ? is full of issues too. Most of the items listed don’t really work (or don’t work well). Some pages don’t have any way to navigate using the shift ? commands (and you can only use tab), for example, the categories page.
If ARIA landmarks were implemented, would that help? I took a stab at it last year but I was defeated by never having used GIT to submit pull requests before and finding it to be completely opaque.
I think the advice here: Using WAI-ARIA Landmarks and here: Using ARIA landmarks to identify regions of a page would constitute a quick win for visually disabled users with reasonably modern screen reader software.
I have been wondering if the liberal use of the section tag wasn’t a mistake as far as accessibility is concerned - section is to identify major content divisions in a work, but in Discourse it’s used more generally as a container tag for UI controls. I suspect that creates a misleading document outline for screen readers.
2 Likes
Thanks so much for this! I think what I am interested in most is the “low hanging fruit” of things that are relatively easy to change to improve accessibility.
1 Like
Tab as a means of navigation is much less interesting than is just
having a good semantic structure. I’m not going to navigate any
website by pressing tab a million times. Instead I’ll press h/H to
navigate to the next/prev heading, l/L for lists, etc. I can arrow to
post content just fine, not sure why reaching it by tab is thought to be
desirable.
1 Like
I was only stuck on the tab key as it was initially proposed as a solution and I did not feel that it was. I am interested in your comments. I work for a small college and we are replacing a set of mailing lists with discourse. While the number of students and staff may seem low I do not want to fail them. At the very least your comments have given me some ideas on helping the person that provides their support.
Thanks @ndarilek
I would really like to dig into the issue of links.
Take two examples:
First
<a href="/users/eriko" data-ember-action="449">eriko</a>
Would you prefer:
<a href="/users/eriko" data-ember-action="449" title="eriko">eriko</a>
And front page:
<a href="/t/accessibility-software-and-discourse/13711/last" class="title">Accessibility software and discourse</a>
Would you prefer:
<a href="/t/accessibility-software-and-discourse/13711/last" class="title" title='Accessibility software and discourse'>Accessibility software and discourse</a>
There is a degree of duplication of information in this case, is it required?
For external links we can do better by grabbing title from the website linked eg:
<a href="http://cnn.com/" class="onebox" target="_blank">http://cnn.com/</a>
Can become:
<a href="http://cnn.com/" class="onebox" target="_blank" title="CNN.com International - Breaking, World, Business, Sports, Entertainment and Video News">http://cnn.com/</a>
Automatically if we start reaching out to links sprawled through posts.
What about names on the links in the top bar - the ones they were saying were just “Link”?
Name those “Notifications”, “Search”, “Menu”, “Profile”.
Totally support fixing that, PR?