Accessibility: Keyboard accessibility in tutorial popups

accessibility

(Kevin Robinson) #1

This is split out from the master accessibility thread: Accessibility audit and shepherd for making improvements

The issue here is that in certain tutorial popups, users aren’t able to get out of it with using a keyboard alone. Note that the initial report is from March 2017.

Report:

In the Banner, and in the Reply field (the pop-up that comes up to remind you of discussion etiquette), you cannot dismiss the banner nor make the warning go away without the use of a mouse. This must change as it is what we call a keyboard trap. There should be a way to give the dismiss X keyboard focus and actionability. This can be worked around by setting an option to disable this feature on an instance, but ideally the default setup upstream would included keyboard accessibility as well.

This may have changed since the original audit was done. It’s visually different than what I remember myself too, FWIW. Here’s an example of what I see opening this topic now:

For me on Chrome Desktop this works as expected, and there’s no issue on that popup.

Looking back in code to confirm that this was fixed, I found what I think is the code adding the “ESC” but blaming makes it look like this hasn’t been changed in the last six months: discourse/app/assets/javascripts/discourse/controllers/composer.js.es6 at a0b2b3c8a76adf1ef52f0c31424017b44d232221 · discourse/discourse · GitHub

I’ve pinged folks on my end to help confirm that this is fully accessible, and so unless I hear back differently from there or other folks can chime in here I think we can consider this one resolved.


(Kevin Robinson) #2

@sam I’m a bit confused on this, both because our audit document shows that this was a problem in March, and I myself remember several conversations about this. I tried looking back at git blame on the composer.js Ember component to confirm that this has been changed in the last six months but couldn’t definitely find that. Perhaps that isn’t the right place for this component in the code though? It’s the “education message” ESC that was problematic.


(Jeff Atwood) #3

Escape has always worked here and still does.


(Kane York) #4

Just a guess here, but perhaps the ESC keystroke is being interpreted by the screen reader software as a cancel for something it’s doing, and not being passed to the page?


(Kevin Robinson) #5

Yeah, apologies for the noise. This came up back in March as an issue, and I remember verifying this myself manually, but I can’t reproduce now. It’s possible the actual issue was in the different part of the UI and we captured it inaccurately in the audit, or it’s possible we just made a mistake back then. :slight_smile:

So I think we can consider this resolved for now :+1:


(Joshua Rosenfeld) #6

Sounds good. This topic will close tomorrow. If anyone can still reproduce it, speak now or forever hold your peace!

Or just flag the topic and ask us to re-open it.


(Jeff Atwood) #7