Improve accessibility for screen readers

[Neurrone]

Showdown is pretty popular among screen reader users. However, some parts of the UI are problematic, which motivated someone to create a guide on how to work around some of them. I plan to try fixing the issues identified in that guide.

• [x] Use role="log" to enable automatic reding of incoming battle log text.
• [x] Do the same for chat room screens.
• [x] Add labels to unlabelled controls (e.g alt attribute or aria-label).
• [x] There are 2 edit boxes in the DOM when on the battle and chat room screens. One of them looks llike its not meant for use, so should be hidden.
• [x] Add WAI-ARIA landmarks to divide the UI into logical regions for faster navigation. E.g, to quickly check the health of the opponent.
• [x] Make custom slider controls used for volume adjustment keyboard operable.

Edit: more things to investigate, added by Zarel

• [ ] Section off and label panels
• [ ] Better support for dropdowns

[Zarel]

The weird part is that the buttons are labeled in that they have title attributes "Sound" and "Options". But I guess title attributes are not screen-reader compatible. I'll look into aria-label.

[Zarel]

The second edit box is designed for edit box scaling, and is hidden. How should it be hidden from screen-readers?

[Zarel]

I haven't been able to find a slider library that actually works for PS's use-case and is accessible, unfortunately. Best I can do is a text box, which I should probably be doing anyway...

[Zarel]

Okay, I discovered aria-hidden. Do you use a screen-reader? Can you help with this?

[Neurrone]

@Zarel yup aria-hidden does the trick. Originally thought about fixing the entire issue in a single PR, but I think the improvements I've made to the battle interface improves the experience so much that it should be done first. Lets continue discussion in a PR.

Yup, I use a screen reader.

[Zarel]

It looks like PS's menus are weird for screen-readers – the article you linked to mentions "opens a menu at the bottom". How do I make that menu easier to access?

[Neurrone]

Which menus do you mean? The main menu (with home etc), or the menus that appear (e.g to choose a format)?

[Neurrone]

@Zarel is there an easy way for me to be signed in in 2 places simultaneously so I can leave the battle window open without havinig to actually conduct a battle?

[Zarel]

The menus that appear, like the format/team choosing menu, and the pokemon/item/move/ability choosing menu in the teambuilder.

[Zarel]

For the format/team menu, I could focus the selected element when it appears.

[Zarel]

The pokemon/item/move/ability menu is more complicated, because that one updates on typing, and I don't want to steal focus while someone's typing.

[Neurrone]

Moving focus would be a perfect solution for the battle format menus. When the menu is dismissed (e.g with escape key), focus should also be restored to where it was before the menu was expanded.

I'll look into what can be done for the second case.

[Neurrone]

For sliders, why not the html5 input element?

[Zarel]

The HTML5 input element has pretty poor support overall, unfortunately. I stopped using it because of that, I think.

[Neurrone]

Is the compatibility table here on MDN on <input> support accurate?

If so, then input looks to be well-supported bar things like date pickers.

[Zarel]

The compatibility table says "(Yes)" without specifying version and without saying how it's supported, which generally worries me.

Especially with a slider, support can be rather complicated. Styling is basically completely unsupported, which was I think a serious problem. Other problems include poor support on older browsers (especially phones).

I don't consider this a problem; like I said, I plan to provide a text box as an alternative.

[Neurrone]

@Zarel noted. Thanks for all the help on this issue, appreciated :)

[Zarel]

On second thought, I think I'm going with input type="range". The text box code is too complicated and I care about accessibility more than older browsers and styling.

[Zarel]

Now the main things left to do that I can think of are to make dropdowns easier to use, and to section off rooms somehow.

[Zarel]

Is there a way to detect a screenreader and force single-room mode? PS normally shows two rooms at a time, which is useful for sighted users but probably unnecessarily confusing for screenreaders.

[Neurrone]

There've been debates around whether allowing screen reader detection is a good idea, and this article explains why I oppose it.

I suggest adding role="complementary" and an appropriate aria-label="..." around the div that surrounds all elements in each battle and chat room window. That makes it very clear what's on the screen, and since the close button is near the top of the chat pane, its easy to close too.

[KamilaBorowska]

@Zarel

The compatibility table says "(Yes)" without specifying version and without saying how it's supported, which generally worries me.

It says (Yes) only for Opera Mobile and Edge Mobile. I would be surprised if Edge Mobile was anyhow different than desktop version of Edge (other than lack of extensions for some reason), considering Windows 10 supports touch screens quite well, and UWP style is about the same on both mobile and desktop (so no need to implement some mobile-only slider).

As for Opera Mobile. Presto Opera Mobile wasn't all that different from desktop version when the feature didn't involve anything outside of viewbox (there is no reason for slider to do anything on chrome level). I can see it being a fair case for Opera based on WebKit however that it wasn't always supported, but I'm willing to bet it was considering Opera 14 was mobile-only release, and generally Opera authors are more concerned about mobile (considering they get most profits from mobile).

I wonder about trying to detect slider support, and simply using HTML5 slider if it's implemented.

[Zarel]

Like I said in 27ebc01, we use HTML5 ranges for volume now. Falling back to textboxes on mobile is better than the previous (jslider doesn't support mobile anyway).

We're still using jslider for EVs because we need to implement the 510 EV limit. I'd definitely strongly prefer a more modern slider library that also permits that (and supports mobile), but for now, the EV text box does provide an accessible alternative.

[Zarel]

I should probably have a checkbox for single-tab mode. Hm, or a selector on the Join Rooms screen.

[Zarel]

@xfix are you looking at the same chart I am? The one I'm reading says Chrome for Android and Safari Mobile both support it, and those are the main ones I'd care about.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range

[KamilaBorowska]

I don't see what's the issue with type=range and EV limit, seems like quite straightforward thing to implement - https://jsfiddle.net/j94Lty8t/1/