bind-attr is old news, if you want to fix this fix it in the htmlbars branch.
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]
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
[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
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.
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.
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.