Accessibility / Assistive technology support?

(Leo Breebaart) #1

I was wondering if the discourse team have any specific ideas or plans for making the discourse software friendly towards assistive technologies such as screen readers, and possibly conforming to some level of web accessibility guidelines/standards.

I can completely understand this not being a top priority right now, but I also know from experience that it is much better to take this sort of stuff into account at the very beginning, rather than trying to attach it onto an existing architecture afterwards. So I thought I’d ask if there have been any thoughts on this subject.

Web Accessibility testing
Keyboard shortcuts?
Accessibility audit and shepherd for making improvements
(Michael Brown) #2

We certainly want Discourse to be 100% accessible to all users. It’s just not that way first thing out of the gate.

One of the ways that we hope to enable full accessibility is that everything in the Discourse web client uses an API. Alternative web clients (or CLI clients, or…) can use this API in the same manner, hopefully allowing everyone to participate.

We’re actually inviting people with varying needs to take a look at it right now and give their feedback and suggestions.

(Nick Caldwell) #3

When I was starting out in web design one of the golden rules was that retrofitting accessibility is making a rod for your own back. Better to have it plumbed in right from the start.

Obviously too late now, but still.

In any case, it will be good to see your findings. Javascript web apps are clearly not going away anytime soon and it would be good to have some data on how accessible they can be made. ARIA roles (oh god tell me you’ve heard of them) are very helpful.

(Jeff Atwood) #4

Well, try browsing this site with JavaScript disabled – it’s pretty good because it has to be, otherwise Google can’t index us…

(Nick Caldwell) #5

Hi Jeff,

That’s helpful to make the content accessible to older screen readers, but for users with modern screen readers who want to interact with the site, aria roles will help orient them around the major content areas. For example, adding an aria role of “main” to the main content area might let a user’s screen reader skip straight to content. Marking up headers with role=“banner” establishes their function, and so on. HTML5 elements aren’t yet terribly well supported so it’s good to double-load meaning with aria roles.

You can also use aria roles to establish interactive functionality, such as announcing when a hidden element is made visible again, describing custom javascript widgets by their function, etc etc. I’m still feeling my way around this stuff myself, but there are a few helpful things that could be added to the template quite quickly with very little impact.

(Sam Saffron) #6

We are open to a pull request that improves Discourse for the visually impaired if you are feeling brave.

(Nick Caldwell) #7

That would require learning some git, I suspect. OK, I will give it a go but I fear the ice caps will have melted by the time I figure everything out.

(Nick Caldwell) #8

I’ve read the contributors’ notes, started a branch, and begun by adding ARIA “landmark” roles to Discourse. Right now I’m attempting the minimal job of adding “banner” and “main” roles where applicable. I’ve also marked up the body with role=“application”, and hopefully will get some feedback on that, as there’s some ambiguity about when a web app that features content rather than purely controls etc should be defined as such.

(Nick Caldwell) #9

As I suspected, Git is proving to be well named. I’ve followed as far as I can (which was the section just after “Ensure that if you supply a multitude of commits, they are squashed into a single commit:”) and now I just get permissions denied and so forth. I’m not a developer, but as a web designer who writes front-end HTML & CSS I do work with version control (well, OK, SVN) but this is just baroque.

(Sam Saffron) #10

If you are having too much trouble don’t worry about squashing commits, we can take care of that on our end.

What exact error are you getting?

(Nick Caldwell) #11

OK, well, from git rebase -i

git rebase -i
You asked me to rebase without telling me which branch you
want to rebase against, and ‘branch.discourse_aria_roles.merge’ in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git rebase ').
See git-rebase(1) for details.

If you often rebase against the same branch, you may want to
use something like the following in your configuration file:
[branch “discourse_aria_roles”]
remote =
merge =
rebase = true

[remote "<nickname>"]
url = <url>
fetch = <refspec>

so I tried “git rebase” instead, then a little later, after I’d created a public repo:

git push origin discourse_aria_roles -f
ERROR: Permission to discourse/discourse.git denied to Rocketpilot.
fatal: The remote end hung up unexpectedly

(Rocketpilot is my other main handle, which I use on github)

(making dinner right now so this is all a little confused, sorry)

(Nick Caldwell) #12

I think part of the problem is I’m kind of typing some of these commands in blind – not really understanding what each step actually does – so there’s every chance I missed a step, which would have caused problems. I initially skipped the entire section after “they are squashed into a single commit:” because it seemed from context like the entire code block quoted was actually about squashing a commit, and my commit only had one line of comments anyway.

(Sam Saffron) #13

were you ever able to push to github, is your origin set to your fork?

(Nick Caldwell) #14

Don’t think so. OK, so here’s the sorry history of my attempts to push my changes. Don’t laugh! :smile:
(don’t think there’s anything self incriminating in this history log either)

518  git checkout -b discourse_aria_roles
519  git commit -am 'Initial tentative support for aria landmark roles in the application template files'
520  git checkout master
521  git pull --rebase
522  mate .git
523  git remote add mine
524  git push mine discourse_aria_roles
525  git remote add mine
526  git push mine discourse_aria_roles
527  git push mine Rocketpilot/discourse_aria_roles
528  git remote -v
529  git push origin discourse_aria_roles -f
530  git remote add upstream
531  git fetch upstream
532  git checkout discourse_aria_roles
533  git rebase upstream/master
534  git rebase -i
535  git rebase -i discourse_aria_roles
536  git push origin discourse_aria_roles
537  git push origin discourse_aria_roles -f
ERROR: Permission to discourse/discourse.git denied to Rocketpilot.
fatal: The remote end hung up unexpectedly
538  git rebase
539  git rebase discourse_aria_roles
540  git push origin discourse_aria_roles -f
ERROR: Permission to discourse/discourse.git denied to Rocketpilot.
fatal: The remote end hung up unexpectedly

(sunnydeveloper) #15

wondering where Discourse stands with Accessibility one year after this post?

(Sam Saffron) #16

we still strive to have great accessibility, are there any particular issues you are having?

(sunnydeveloper) #17

No specific issues, but we are reviewing forum software and accessibility is a requirement. (Screen Reader friendly for example). It would be helpful to have information on this, would love to use Discourse - but it’s a ‘no go’ otherwise.

(Jeff Atwood) #18

It kind of depends on the Screen Reader. Which ones are you looking at?

Also, if you need basic accessibility for reading, our JavaScript off mode is HTML 3.2 compliant and would work with anything. But that doesn’t cover posting, just reading.


We have tested Discourse fairly extensively for accessibility and unfortunately there are some gaping holes. For more details, check out Technobear’s posts. I’m sure she’d be happy to answer your specific questions via PM.

(Sam Saffron) #20

@HAWK what in particular is left? We did a lot of work to improve the keyboard story in the past month or so.