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?
https://github.com/discourse/discourse/commit/4191d97d48e2451ff583ed808dee081544a34d14
https://github.com/discourse/discourse/commit/4f53b85ee2bf293af6ff3e9f67f83f02700cccbe
6 Likes
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! 
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! 
Marco
6 Likes
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.
3 Likes
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.
2 Likes
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. 
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.
[/quote]
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
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:
- 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.
- 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).
- This could then contain a p element that gets replaced each time something interesting happens. Interesting things could be:
- A new post has been added to the current topic. Message could say: āNew posts availableā.
- 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.
- Any of the post list pages have been loaded. āTopic list loadedā. āLatest topics loadedā etc.
- 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.
- 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.
Marco
2 Likes
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.
3 Likes
Thank you so much! Now Travis just has to be made happy.
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?
Marco
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. 
7 Likes