Accessibility software and discourse

Tab as a means of navigation is much less interesting than is just
having a good semantic structure. I’m not going to navigate any
website by pressing tab a million times. Instead I’ll press h/H to
navigate to the next/prev heading, l/L for lists, etc. I can arrow to
post content just fine, not sure why reaching it by tab is thought to be
desirable.

1 Like

I was only stuck on the tab key as it was initially proposed as a solution and I did not feel that it was. I am interested in your comments. I work for a small college and we are replacing a set of mailing lists with discourse. While the number of students and staff may seem low I do not want to fail them. At the very least your comments have given me some ideas on helping the person that provides their support.
Thanks @ndarilek

I would really like to dig into the issue of links.

Take two examples:

First

<a href="/users/eriko" data-ember-action="449">eriko</a>

Would you prefer:

<a href="/users/eriko" data-ember-action="449" title="eriko">eriko</a>

And front page:

<a href="/t/accessibility-software-and-discourse/13711/last" class="title">Accessibility software and discourse</a>

Would you prefer:

<a href="/t/accessibility-software-and-discourse/13711/last" class="title" title='Accessibility software and discourse'>Accessibility software and discourse</a>

There is a degree of duplication of information in this case, is it required?

For external links we can do better by grabbing title from the website linked eg:

<a href="http://cnn.com/" class="onebox" target="_blank">http://cnn.com/</a>

Can become:

<a href="http://cnn.com/" class="onebox" target="_blank" title="CNN.com International - Breaking, World, Business, Sports, Entertainment and Video News">http://cnn.com/</a>

Automatically if we start reaching out to links sprawled through posts.

What about names on the links in the top bar - the ones they were saying were just “Link”?

Name those “Notifications”, “Search”, “Menu”, “Profile”.

Totally support fixing that, PR?

I’m not sure where to put the names, as it’s currently like this:

<li class="notifications">
            <a class="icon" href="#" data-ember-action="2" data-notifications="notifications-dropdown" id="user-notifications" title="notifications of @name mentions, replies to your posts and topics, private messages, etc"><i class="fa fa-comment"></i></a>
        </li>

That is odd to me, it has a title, it should work fine. @ndarilek and idea why it does not work?

note: adding title attributes to links is not helpful and may result in duplication of information for some users. See Using the HTML title attribute for details.

1 Like

Hi folks!

As @stevefaulkner said, using the title attribute is not desirable for many reasons for screen reader users. In the example of the notifications, putting a concise text bit in either an aria-label attribute on the href element or as a child of that in the form of a span with text that is positioned off-screen so only screen readers can read it, would be much much better.

The same goes, for example, for all the buttons except the Reply button to any post. So the Like, Bookmark, etc. buttons below each post don’t get their function spoken by screen readers automatically, either. Only the title attribute conveys some information, but you usually have to press an extra key to read that. As the article linked by Steve points out: The title attribute has been abused so badly over the years that screen readers and browsers simply don’t rely too much on it any more when calculating what we call the Accessible Name of any element. So alt, aria-label or using hidden text are the preferred ways to name elements.

To see how hidden text can be accomplished, see, for example, here.

I would really like to see this improved in Discourse, since this is one of the major pain points I have myself. However, I do know nothing about Ruby and thus would have a very steep learning curve when trying to fix this bug. However, if someone else volunteers to fix the bug, I will be happy to review the proposed change before a PR is merged. I can see from looking at code if it does the right things (most of the time), I only cannot implement this myself.

3 Likes

I really want to make some progress here, I just added aria-label to the buttons in the toolbar, does that improve things.

The “labels” feel a bit long to me, should we have different labels to the titles or perhaps just shorten both.

@codinghorror to be honest I don’t think “share a link to this post” is really any better than “share a link” , a lot of pointless words in the button titles.

@MarcoZehe ideally I would like to avoid the hidden text trick if possible, it may have some performance concerns as it introduces a bunch of workaround rules.

3 Likes

@sam, shortening some of the button labels would make sense. For example: “Begin composing a reply to this post” is quite long. “Reply to this post” would be totally sufficient. The important thing is to keep the “this post” part, since there is also an over-all general reply button at the bottom that adds a new reply, but doesn’t specifically link to any of the other replies.

In general, the labels, what’s put in aria-label, should be concise and to the point. Title can always be used to augment that, if the concise label leaves any doubt as to what the function of the control is.

Using aria-label is fine, the suggestion to use hidden text was merely an exit route in case you didn’t want to use aria attributes for some reason. All the browsers you cite in the requirements support this attribute, so do modern or semi-modern versions of common screen readers.

HTH!

Marco

2 Likes

Thanks heaps, if you can give me any more specific examples of spots you would like fixed (and aria-labels added) let me know.

I kind of oppose this, as that statement is meant to help people learn that they can compose while they read, e.g. the composer does not block reading, or even navigating to new topics with the editor open. “Reply to this post” implies that is all you can do, e.g. it is a modal reply form that whisks you away to a dialog or a different page.

Perhaps better is “Show the post editor”?

“Begin replying to this post” ?

“Show the post editor” is omitting the fact it is also attaching current post to the editor.

3 Likes

@sam, I agree with this. And I like this new label suggestion. And while we’re at it, I wasn’t aware that you could even switch to a different thread and still keep the current post in the editor open. So my suggestion was indeed not totally appropriate.

1 Like

Oh yes, I just discovered that all items in the editor like inserting links and stuff have the same problem. I’m still in the beginnings of learning Discourse, so there may be more over time I stumble upon, but this is one that I just found while looking around the actual text field.

1 Like

@sam, found another: Hit the Share This Post button below any post. The links following the text field which contains the link, they all only have the topic title as the title attribute set. And no other text or aria-label. A screen reader user does not know which link is for which social network or other sharing means.

2 Likes

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?

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! :+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:

Marco

6 Likes