Gutenberg: Post Settings toggle controls not keyboard focusable or triggerable

[abrightclearweb]

Tested on: Gutenberg 0.3, 0.4.

Setup: Mac OS X Sierra, MAMP, Safari 10.1.1.
Gutenberg is the only plugin active.

When tabbing through the Post Settings the Tab key can be used to open the panels and go through the controls one by one.

However, tabbing through does not focus on toggle controls such as the Pending review or Stick to front page toggles within the Status and Visibility section.

Therefore these controls can't be activated by keyboard alone.

[afercia]

It seems to me they're focusable and can be activated with a keyboard, but they miss a focus style. See #1562

[abrightclearweb]

Got you. Activated with space bar. Agree re: focus style.

[afercia]

Hm now that you made me think better at this, I see the potential issue. I knew these toggles are implemented with styled checkboxes so it was natural to me to use the spacebar. However, there's no reason why keyboard users should have a clue they're checkboxes. Only screen reader users will get them right because their screen reader will announce "checkbox".
However, these toggles don't look like checkboxes, so sighted keyboard users will probably try to activate them pressing Enter. This is potentially confusing. Should the toggle work also when pressing Enter? /cc @jasmussen

[svinkle]

@afercia Any thoughts around implementing the toggles as <button>s with role="switch" and aria-checked attributes? Reading over this Toggle Buttons article; it might be doable, though slightly inconsistent support.

[afercia]

@svinkle interesting. Yep, role="switch" is part of ARIA 1.1, still a Candidate Recommendation, and even Heydon warns about inconsistent support. So, as first thing we should have some data about support across the main assistive technologies. Also, I'm not sure I agree 100% on the proposed example on the article:
<button role="switch" ... >
because it goes against the second ARIA rule: don't change native semantics.

[joe-watkins]

@afercia @abrightclearweb It looks like the styles are based on the parent <span> vs. the <input> so :focus styles aren't going to go back upstream. The look and feel of that toggle would need to be coded from the <input> so when the element gained focus a visual indication of this focus would be visible.

A dirty temp hack would be to listen for focus w/JS and apply a class to the parent <span> to indicate focus... but who could sleep well after that?

[jasmussen]

The purpose of introducing a "new" toggle element (as opposed to just using a checkbox), is to _imply that once you toggle the switch, the action is already saved_. A checkbox usually requires an explicit "Save" button later on in the page, or the check won't be saved.

I think the toggle is great for this. But we know we want it to be accessible. I would be reluctant to use JS hacks to make it accessible, especially if they aren't super simple. I'd rather look at alternate designs, including alternate markup. Remember, if we get the switch component right _once_, we get it right _forever_.

I know @afercia has mentioned that it's possible to make switch designs accessible, so I'm curious what we are doing wrong, CSS-wise, and how we might be able to do it differently.

[afercia]

@jasmussen well it's not just an accessibility issue, it's also usability.
A bit ironically, blind screen reader users are in the best position here: this control is reported as a checkbox (because it is a checkbox) and can be activated with the spacebar as native checkboxes do.

However, sighted keyboard users see something that doesn't look like a checkbox. Once the control is focused, they will likely try to activate it pressing Enter, and that won't do anything.

[afercia]

P.S. as mentioned in other issues, to be fully accessible these switch toggles must always have a visible hint text on/off.

[afercia]

I would be reluctant to use JS hacks to make it accessible, especially if they aren't super simple

I'd try this:

• attach a ~click~ keydown event on the checkbox
• when the checkbox is ~clicked~ activated with ENTER, trigger a click on its label
• this is guaranteed to work if we keep the jsx-a11y label-has-for rule
• of course, pending testing to check any potential negative impact

Will try a PR.

[jasmussen]

P.S. as mentioned in other issues, to be fully accessible these switch toggles must always have a visible hint text on/off.

I have no problem making the visual label required instead of optional as it is now. Worst case we can switch the label place to be before or after the switch depending on the switch alignment (so the text length difference between on/off doesn't make it jump). And in cases of translations of on/off growing long, if testing suggests it necessary, perhaps we can make the font size smaller?

[afercia]

OK I have a working solution but it uses DOM methods... 😬
The fact is, FormToggle is used in different ways: standalone or wrapped in a BaseControl component, so I couldn't think of a React-way to get its label. Any suggestions would be appreciated! /cc @aduth

[jasmussen]

Screen options, for now, is punted, and the issue with the close button appears to be fixed:

For that reason, I'm closing this ticket as fixed. If this was in error, we can reopen.