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.