Accessibility software and discourse

Yes I already brought this to @techapj’s attention, so hopefully that will be resolved soon.

I added aria-labels to both sharing links and composer, it should be deployed here in the next 10 minutes.

@MarcoZehe can you confirm it looks good?


Niiiiice! The labels for the composer buttons also contain the keyboard shortcuts! This is marvelous!

Just one nit: The Close button in the Sharing panel is the only one I found that is still missing the label. But all the other sharing options now speak properly, too! Great stuff! :+1:

With these enhancements in the past few days, the major functionality of Discourse became much more accessible! I will probably run into other little things as I continue to use various instances of Discourse, and will report them ASAP. But if all these are so easy to fix, we should be in good shape! :slight_smile:



Out of interest: When will these changes be deployed elsewhere? E. g. when will self-hosted Discourse instances get these enhancements? I assume you are in control over the ones you run/sell, but am wondering about others, too.

I added an aria-label here too. The timing of these fixes is perfect because I was just about to fix these for someone who uses a screen reader.

Self-hosted instances that follow the tests-passed branch will get these fixes when they upgrade.


Here’s another enhancement that would immensely increase navigability for screen reader users. Screen readers render pages in what we call a virtual document. Basically multi-column layouts are reformatted into a logical order, mostly following the DOM order of elements. Other semantic information is exposed such as lists, tables, headings etc. We also have navigation keys available that are not browser shortcuts, but shortcuts specific to screen readers. One of them allows us to move quickly from heading to heading.

In Discourse, there is a H1 at the start of the topic, but no subsequent headings for each post. There are other headings strewn about, like for “suggested topics”, which are H3, and some links like to Github commits, which are H4. It would be very very very helpful if at the start of each post within a thread, there was a heading 2 to jump to so each post start can be found very easily. The author name is a possible candidate to be enclosed in such a h2 tag. It’s already there as a link, and that link would just have to be wrapped. Alternatively, text could be added that would contain text such as “post #5”. Not sure how that fits in the current design, but semantically, headings for each post within a thread make a lot of sense I think.


Oh, a friend found another unlabeled button. The one that shows or hides the topic details. To make this really cool, a contextual aria-label would be fantastic. One that says “Show topic details” when they’re hidden, and “Hide topic details” when they’re showing. :smile:
Alternatively, if there can only be one label, which I don’t suppose since the showing/hiding needs to be done anyway, aria-expanded=“true” if the details are showing, and aria-expanded=“false” when they’re hidden, placed on the button, would also be a way to indicate the state. But the contextual label is definitely preferred.

1 Like

Hm, I just tried to do this, and it seems that bind-attr doesn’t recognize aria-label, or something of the sort. Any ideas @eviltrout?

bind-attr is old news, if you want to fix this fix it in the htmlbars branch.

1 Like

Aria labels on buttons, are these usable with Dragon?

ie, how would a Dragon user know the name of the button to call out? (though you can say “button” and if it’s a button and not a link it could find it I believe)

A few people have suggested that if things (like posts) are being ajaxed into pages and there’s no refresh or similar events, that the new stuff should get aria live regions, so AT users get a notification that there’s something new.

alert roles don’t sound right for new posts, so more like aria-live=“polite” on the container of the new post.

Copied from Sitepoint (post was by @Stomme_poes at SP)

[quote]A new issue found:

Someone liked a post of someone else. I wanted to see who. It’s a link wrapped around an image. The image has no alt attribute. Instead it has a title.

Images without alts usually cause an SR to read out the image’s src attribute, as an attempt to read out something useful (even when there’s a title). That URL ending with “661.png” is pretty damn useless though. Title is as usual not available to keyboarders, touch screen users and users of stupid browsers. It’s somewhat more likely people might hear titles if there’s an empty alt="", but the best thing is alt=“user name”. A title could still be there in addition for mouse users if you want.

If we could switch these, it would be nice.


1 Like

I’m not sure why it wouldn’t work, but like Sam said you don’t need bind-attr in the ember branch, which will be merged in shortly. {{bind-attr aria-label=wat}} should work for now. aria-label={{wat}} will work shortly :smile:

1 Like

[quote=“Stomme_poes, post:43, topic:13711”]
A few people have suggested that if things (like posts) are being ajaxed into pages and there’s no refresh or similar events, that the new stuff should get aria live regions, so AT users get a notification that there’s something new.[/quote]

Actually, I don’t think this is a good idea to actually put a live region on the new posts. A short notification in some hidden text would be better. It should say “New posts available” when there are new posts added to the current topic, and “New topic loaded” when a whole new topic has been loaded. In both cases, because the content is being swapped out via JS, but this is not a full page reload, screen readers don’t get notified of the availability of the contents once it has finished loading. So I suggest the following:

  1. Create a div element that gets a CSS class of hidden-accessible-notification or something evenly clear and explicit, so everyone can see what this is for.
  2. The further attributes on this element are: aria-live=“polite” (to not be too intrusive), and aria-atomic=“true” (so all the text within this div is spoken upon update).
  3. This could then contain a p element that gets replaced each time something interesting happens. Interesting things could be:
    1. A new post has been added to the current topic. Message could say: “New posts available”.
    2. When a new topic has finished loading: “New topic loaded” or “topic loaded”. The user usually still remembers what link they clicked on, so no need to repeat the full topic title here.
    3. Any of the post list pages have been loaded. “Topic list loaded”. “Latest topics loaded” etc.
    4. other interesting pages that are only done via JS, not full page loads. If done right, this can be made very extensible and can easily be enhanced.
  4. The CSS class should look something like described here.

There is no way to solve this kind of announcement with an aria-label. In this instance, a persistent element with hidden text must be used.



Submitted all 3 of these, but based on the ember branch, so it’ll only get deployed to Meta until the ember upgrade is complete.


Thank you so much! Now Travis just has to be made happy. :smile:

As I have always manually refreshed pages to see if there’s new stuff, I actually have no idea what Discourse currently does to show that there’s new stuff. But the Twitter model does exactly what you’re proposing: adds a small notification saying there are new tweets or whatever. Certainly would cut down on the verbosity. Me likes.

1 Like

I thought aria-atomic=true was the default, is this needed explicitly for support reasons?

edit: nevermind, that’s only on alerts. default is false otherwise.

Even if it was the case, as you found out yourself it isn’t, if I want specific behavior like in this case, I am all for explicit declaration and not relying on implicit values. What if one day, the ARIA TF decides that the default value of something should change, browser implementors adjust their behavior, and suddenly things break because one relied on an implicit value?


We really appreciate all your feedback on this @MarcoZehe and others. We always wanted to do this, so getting specific guidance on what to change to have the most impact is extremely helpful. :ok_hand: