Accessibility software and discourse

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