Accessibility software and discourse

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 :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.

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. :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?

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. :ok_hand:

7 Likes