Mastodon: Accessible CW Dropdown

Created on 14 Apr 2017  ·  4Comments  ·  Source: tootsuite/mastodon

The CW dropdown seems to only be accessible to sighted mouse users. Suggesting, somehow, we add:

  • [ ] keyboard support
  • [ ] ARIA for accessibility tree and screen reader support


Screenshot
Screenshot showing the CW dropdown when expanded along with the HTML markup, which consists of inaccessible divs with no ARIA


I'm not sure precisely the best pattern to use for this. Perhaps along the lines of aria-controls, aria-expanded, usage of role, and then adding all the keyboard / arrow keys support one would expect in a <select>, because that is basically what we are mimicking?


  • [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
accessibility ui

Most helpful comment

Maybe this should be in a different ticket, but I also noticed it's quite difficult to tell if the CW button is actually on or not. I made a mockup of what the button could look like when it's on.

clear:
image

unclear:
screen shot 2017-04-14 at 23 13 41

Happy to break this out into its own ticket to potentially get this done faster.

All 4 comments

Maybe this should be in a different ticket, but I also noticed it's quite difficult to tell if the CW button is actually on or not. I made a mockup of what the button could look like when it's on.

clear:
image

unclear:
screen shot 2017-04-14 at 23 13 41

Happy to break this out into its own ticket to potentially get this done faster.

The "CW" button seems to work with the keyboard. It's based on a <button> element, so the browser provides the expected keyboard interaction based on the click handler.

It does have problems though:

  • There is nothing to indicate to screen reader users that activating the button will cause content to appear;
  • The content that appears is inserted into the DOM *before the button, making it difficult for screen reader users to locate it;
  • The aria-label attribute provides a completely different label for the button, making it difficult for screen reader users to recognise the "CW" button when it's referenced by other people/help files etc.

Suggest using a basic disclosure pattern, inserting the revealed content into the DOM immediately after the button, and changing the label.

<button aria-label="Content Warning (CW)" aria-expanded="true" aria-controls="this">CW</button>
...
<div id="this">
// Where the revealed content goes
</div>

The aria-label is now a more accurate reflection of the visible label. Because the acronym "CW" is included in both the visible and non-visible labels, it means speech recognition users can accurately target the button using voice commands too.

The aria-expanded attribute indicates that content is either collapsed or expanded. It should be set to false initially, then set to true when the button is activated and the content revealed, and then set back to false when the content is collapsed again.

The aria-controls attribute establishes a relationship between the controller (the button), and the content being controlled (the form that appears). It's only supported by one screen reader (Jaws), but it enables screen reader users to move directly from the button to the revealed content using a shortcut provided by the screen reader.

Until such time as more screen readers support aria-controls though, it's necessary to insert the revealed content immediately after the button in the DOM. This ensures that as screen reader users tab away from the "CW" button, they immediately encounter the new content.

I made a PR (#2303) to move the content warning input field below the toot box following issue #2209. Following this issue I made further changes:

  1. Added aria-controls to the CW trigger button referencing an id I added onto the input field
  2. Added aria-expanded to the CW trigger button as well when it's in an "active" state

I didn't want to go ahead and change the title without further discussion. Right now the title/label has "Hide text behind warning." Since these changes should make it clear to screen-readers what the button is controlling, I'm not sure it's important to change the label at this time.

This does not resolve @wavebeem's comment that it's hard to see when the CW button is active. I agree that would be a worthy UI change to make.

This PR does not resolve OP's issue. @jpdevries's issue was actually with keyboard accessibility for the _privacy_ dropdown, not the CW input. The buttons are tab accessible, but hitting enter does not activate the tab-selected button. These should also be arrow accessible. I believe that would require manually adding key listeners for up, down, and enter. Tab or arrow selecting a privacy dropdown option would also ideally give it the "active" class. I agree that would be an excellent change.

Fixed in #7318, I think

Was this page helpful?
0 / 5 - 0 ratings