Accessibility review: Mode switcher onChange handler

[aduth]

In the course of #389, our accessibility lint rules hinted to a guideline relating to select change handlers:

• https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/no-onchange.md
• http://cita.disability.uiuc.edu/html-best-practices/auto/onchange.php
• http://www.themaninblue.com/writing/perspective/2004/10/19/

The gist of the recommendation is that keyboard navigating select inputs may cause an onChange to fire more frequently than expected in some browsers.

In our case, we decided to disable the rule with reasoning reflected in an inline comment:

Disable reason: Toggling between modes should take effect immediately, arguably even with keyboard navigation. onBlur only would require another action to remove focus from the select (tabbing or clicking outside the field), which is unexpected when submit button is omitted.

We should decide whether this is an acceptable disabling of the rule, whether refactoring should be made to accommodate the rule, or whether we should remove the rule altogether.

[afercia]

If the mode switcher is going to be implemented with a native HTML select element, then the onChange event is problematic since browsers behave differently. Also operating systems come into play. On Windows, focusing a select element with the keyboard and using the arrow keys doesn't open the select.

So on Windows, the only way to explore the options in a select is using the arrow keys and if that triggers the mode switching, it would be completely unexpected.

About browsers inconsistencies, historically Firefox has been for years the only browser to correctly implement the specification that states the change event should fire when a select option has been selected AND focus is moved away from the select. Instead, Chrome and IE trigger the event as soon as an option has been selected. That's wrong, according to the spec.

However, browsers have bug 😬 see https://bugzilla.mozilla.org/show_bug.cgi?id=1350700

[jasmussen]

What if it was a toggle button?

[Visual ▼]

click

[Text ▼]

click

[Visual ▼]

?

[aduth]

What about a button group or tabs similar to what exists currently?

To me, these seem clearest for managing a toggle between two states (select for many options, toggle button very opaque). But the equal weight between modes assumes that switching to Text is a common workflow.

[jasmussen]

What about a button group or tabs similar to what exists currently?

I like that a lot.

Edit: though I want to clarify that the reason I designed it as a dropdown initially, was in a vague hope that one day a plugin might register itself as another editing option there. Imagine picking "Markdown" in the dropdown, then toggling the splitscreen preview, and you essentially have Ulysses.

[afercia]

A button group would be perfectly OK for a11y, using an aria-pressed attribute set to true for the active mode and false for the inactive one. This would make them being announced as selected Toggle button and Toggle button, indicating that only one can be active at a time.

in a vague hope that one day a plugin might register itself as another editing option

wouldn't be possible to allow plugins to add buttons for their custom mode?

[jasmussen]

wouldn't be possible to allow plugins to add buttons for their custom mode?

Yes, but it's not a very scalable UI, it takes up a lot of space. And visually the more we can reduce, the lower the cognitive weight. It would also more easily translate to mobile.

[afercia]

Yeah.. than maybe a custom dropdown would help normalizing the various browsers inconsistencies, but it should be veeery carefully implemented.

[jasmussen]

Here's a mockup of the tabgroup version using icons:

[joyously]

I really can't tell what those icons mean. PLEASE don't get rid of the text labels!

[afercia]

@joyously I'd agree text labels are necessary. Same for the other controls in the toolbar that are being discussed on #467 and (partly) on #503. I'd greatly appreciate some feedback there from you and other designers :)

[melchoyce]

Icons sans labels tend to be "mystery meat" navigation — I agree that here especially, we'll want to include labels or consider an alternate design that's text-first.

[jasmussen]

👍 I agree in this case. But it's always, always a balance. Bold, for example, doesn't need a label ;)

[melchoyce]

Agreed — I think the majority of the editor icons don't need labels because they're so ubiquitous. But a couple of them still stump me, even with context.

[afercia]

Re: onChange, see also https://core.trac.wordpress.org/ticket/31634 and https://core.trac.wordpress.org/ticket/40925 where I've posted a video to illustrate what onchange does on select elements on Windows:
https://cloudup.com/iuFxQ7CkA7k

[aduth]

It's unclear whether there's an actionable direction here for the tab group design. Labeling as such.

[afercia]

The mode switcher is not a select any longer. It is now behind the "More" button, and technically it's a button. I think this specific issue can be closed, although the new drop down menu would benefit from some accessibility improvements, e.g. arrow navigation, constraining tabbing, proper labeling. These points should be addressed in a separate issue, as there has been some progress with specific components for drop down menus.