Let's talk Accessibility and Discourse

Continuing the discussion from Welcome to The New SitePoint Forums:

It sounds like Discourse needs some Accessibility love, feel free to post suggestions/improvements here so we can see 1) what needs to be done and 2) where it needs to be done.

I’m more than willing to work on these (where possible). So if you can identify them, how to resolve them, I’ll be glad to attempt to get them implemented.


There’s random use of outline:none; on text links. As you tab through a page some links correctly show an outline when in focus but others don’t.

On this very page these links are problematic:

  • Notifications icon
  • Search icon
  • Category icon
  • Topic heading category link
  • Like, share, flag, bookmark & thread reply
  • Star, Share, Flag, Reply in topic footer

… and possibly more.

The solution should be straightforward, just remove all instances of outline: none; in all stylesheets :smile:

On Firefox 32 (Ubuntu Gnome) things like the search icon, notification icon etc. do show a dotted outline, as do the main options on the dropdown menus. Where I have real problems is with the category badges - either on the forum homepage or the hamburger menu; they don’t show focus clearly (there is a partially aligned, blinking cursor; same for the “Reply” button at the bottom of this box.

@bluedreamer - most of the things you’ve mentioned can actually be triggered via keyboard shortcuts, which saves tabbing through the links. (? will bring up the shortcut menu, and there’s also a slightly more detailed breakdown in the “Cheat Sheet”.)

What browser are you using? As I see outlines on all of those…

Granted, it is hard to see the outline on the Reply button, but it is there (same for the Category badges). The outline is definitely there…

I used Chrome to test this.

Just tested with FF, expecting to see the “floating cursor”, which is what used to indicate focus there, and I can confirm that there is no indication at all. I don’t know when this changed, as I gave up tabbing once the keyboard shortcuts were fixed (thank you ).

Feels like a Firefox bug. There isn’t a outline:none style set those buttons. It seems the use of <button> tag does not generate an outline when tabbed to in Firefox.

So I’m a bit lost on how to fix it…

Using Firefox (latest) on Win7. In the main stylesheet there are 14 instances of outline:0 - can’t really say exactly where they are being applied as the CSS is minified and I haven’t got time to deminify right now.

Thanks, that’s all very well but hard work when all I want to do is tab through links and see where I am! Shortcuts should be in addition to basic accessibility?

I can tell you they aren’t on the icons/buttons. They are related to select2 (used for the drop down functionality – category drop down, tag drop down, etc). Some are also on inputs (think search).

Firefox should be using moz-inner-focusring or inner-border or whatever weird mozzy thing with buttons, even if buttons were given outline: 0;

(another pro of Opera: it doesn’t give a rats that someone set outline: 0. If you’re keyboarding, you get nice ginormous blue fugly outlines. Yay)

Question, why is there only an outline when the reply button is focussed?

Why does it not have the funky transitiony thingie I get with :hover?

<a href="/category/community" data-drop-close="true" class="badge-category" title="Tell us about your weekends, hobbies, travel and pets. Discuss computer hardware and software issues, industry news, careers and education … pretty much anything goes—except politics or religion, of course!" style="background-color: #005687; color: #FFFFFF; ">Community</a>

This here’s a classic bit of code showing why, even when someone could get to hear titles via an AT or something, they really, really, really wouldn’t want to, and why more and more AT default to title not being announced. Holy crap.

That’s a description that really belongs only on the category list page under each category.

More context please. :smile:
Are we still talking Firefox? As in Chrome the outline exists in both states.

Chromium (rather than Chrome) gives ZERO indication of anything in the header. no outline, no colour change, zippo nada.

It gives ONLY outlines on the buttons. Firefox doesn’t even show those on the buttons. Firefox (but not Chromium) shows outlines of the elements in the header but as Bear said, you can hit enter to open the notification dropdown but you can’t get into it (up/down arrows are set to scroll my page).

This is your stylesheet, for the reply button:
nav.post-controls button.create:hover {
l33t-super-c00l hover styles !!!1;

There should be :focus styles at just about every line that has a :hover style.

That way, if the focus outline doesn’t appear in Chromium, at least the icons would light up white for us :confused:

Opera, perhaps because it hijacks browser keys and always highlights where you are, also is the only one showing l33t-haxx0r button transition-colours when focussing on for example the reply button.

*All* browsers could be enjoying that if someone had bothered to write some :focus styles. Me wants sumthin like this

%s/((.*\s*):hover)/$1, $2:focus/

@cpradio has done a lot of work on keyboard shortcuts. There is still a problem (which he’s intending to work on) with giving focus to the dropdown menus:

Overall, keyboard accessibility has improved tremendously over the past few months, thanks to cpradio and @system.

@orodio, is this something you and @HAWK can talk about?

Yes, but if you push it repeatedly the focus goes to the menu (I think 3 key presses) – except for the notifications. I want to build a better solution, but I haven’t figured out how to yet. :frowning:

Indeed it does. (I thought the post I quoted from meta.discourse explained that, but obviously not! )

I didn’t click it… :smile: so it could have. I do have an idea on how to fix it (a technique I just used for navigating post links).

1 Like

I moved 14 posts to a new topic: Discourse Search - How does it work?

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.