New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switches should always show On/Off label #2146

Closed
jasmussen opened this Issue Aug 2, 2017 · 42 comments

Comments

Projects
None yet
@jasmussen
Contributor

jasmussen commented Aug 2, 2017

From Helen:

https://twitter.com/helenhousandi/status/892392998264344577
https://twitter.com/helenhousandi/status/892393559734853633

I could swear there was an existing ticket for this. The closest I could find was this one:
#470 (comment)@afercia let me know if there's another.

We should always show an explicit On or Off label on or next to the switch. In our current mockups, this is the word "On" or "Off":

screen shot 2017-08-02 at 10 45 18

Perhaps in a PR there was concern about the switch moving places if the switch is right aligned and the text changes in length. We can just do this:

screen shot 2017-08-02 at 10 45 35

Helen has a great screenshot from iOS, where the labels are instead on the Switch, would that be an option?

Current size switches:

screen shot 2017-08-02 at 10 48 57

Slightly larger:

screen shot 2017-08-02 at 10 51 27

If the latter two can work, we'll probably want to find a different "unfocused" style than the current, which makes the switch knob into a ring. Perhaps a fatter focus rectangle outside the switch as a whole?

@jasmussen jasmussen added this to the Beta, Nice To Have milestone Aug 2, 2017

@afercia

This comment has been minimized.

Contributor

afercia commented Aug 2, 2017

let me know if there's another.

No, I think it was mentioned here and there but no specific issue about it. See for example #906.
Re: concerns about the hints moving: #1410

As a first step, this should be as easy as removing all the showHint={ false } props, right? I'd give that a try and then maybe iterate with the two ideas above: hint on the left (hmm.. not sure) and hint within (not sure either).

To avoid misunderstandings, I'd suggest to always refer to this visible On/Off text as "hint" or "visual feedback" or whatever we want to call it 🙂 , because the real "label" is the <label> element associated with the toggle.

For completeness, I think I've already mentioned Material Design switch control, where they've deprecated the “on” and “off” text in favor of making the state clear from the corresponding inline label. But I disagree with that, as the label text should never, ever change.

@hedgefield

This comment has been minimized.

hedgefield commented Aug 2, 2017

We've been exploring these switches too in some of our upcoming redesigns, and having a clear label next to the control always seems to be the best option.

  • The problem with the I - 0 is that it still is an icon, not a legible text, and not per se one that I would understand either.
  • The problem with text in the switch is of course the varying length with translations.
  • The problem with integrating the state in the description is indeed that it could confuse the meaning of what the switch does (the classic 'does the switch indicate the desired state or the current state' problem)

So I think your mockups look good! I'd be for the label on the left. Screenreaders don't register the label, they announce the state off of the switch itself, so then we're mainly left with the varying length concern - which makes left seem like the most practical choice?

@helen

This comment has been minimized.

Contributor

helen commented Aug 2, 2017

The on-switch icons are indeed icons that may require an initial understanding or occasionally be forgotten but IMO they have enough parallels in other places (appliance switches, other software) to be fairly universal.

@afercia

This comment has been minimized.

Contributor

afercia commented Aug 2, 2017

If the latter two (n.b. on-switch icons) can work, we'll probably want to find a different "unfocused" style than the current, which makes the switch knob into a ring.

To recap: right now, the "knob" gets filled increasing its border width. That's because on #1562, thanks to the Simply Accessible people, we've learned High Contrast Mode on Windows removes any box-shadow or background, thus making the standard focus style not perceivable... This also means most of the current focus styles in WordPress based on box-shadow don't work, unless they also use a change in the border or outline 😱

Perhaps a fatter focus rectangle outside the switch as a whole?

Windows 10 does that, but... hm doesn't look so nice?

edge switch toggle focus copy

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Aug 3, 2017

Would one of these work?

screen shot 2017-08-03 at 10 23 16

@afercia

This comment has been minimized.

Contributor

afercia commented Aug 3, 2017

@jasmussen it needs to be done with a border or outline, but the border is already used for the black border, and the outline is a rectangle...

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Aug 4, 2017

it needs to be done with a border or outline, but the border is already used for the black border, and the outline is a rectangle...

Ah, I see. Could it be done with a box shadow? Perhaps a stacked box shadow the innermost being white?

@afercia

This comment has been minimized.

Contributor

afercia commented Aug 4, 2017

Box-shadows get completely removed in High Contrast Mode :(

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Aug 4, 2017

Aaargh, why do they make it so difficult :D

@afercia

This comment has been minimized.

Contributor

afercia commented Sep 4, 2017

What about something like what was discussed in the latest a11y bug scrub, see https://wordpress.slack.com/archives/C02RP4X03/p1504543766000048

@karmatosed karmatosed modified the milestones: Beta, Nice To Have, Beta, Needs to happen Sep 24, 2017

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Sep 25, 2017

Coming back from paternity leave, apologies for the belated reply:

What about something like what was discussed in the latest a11y bug scrub, see https://wordpress.slack.com/archives/C02RP4X03/p1504543766000048

I think that could work! (that is, providing a descriptive label below)

I really like the idea of having the switch include the label in itself, though, as initially proposed. The primary concern here is still whether there's room for writing "On" and "Off" in a plethora of languages, right? Is there some way we could explore the worst case scenario for localizing those words and then consider whether it's feasible to make the switch bigger to encompass the necessary text?

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Oct 19, 2017

See also #3039

@jeffpaul

This comment has been minimized.

jeffpaul commented Feb 22, 2018

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

@jasmussen jasmussen self-assigned this Mar 7, 2018

@afercia

This comment has been minimized.

Contributor

afercia commented Mar 8, 2018

To visually represents a couple of the options proposed here, see the screenshots below:

screen shot 2018-03-08 at 19 22 41

screen shot 2018-03-08 at 19 20 06

The key point is there should always be a textual indication of the toggle state.

@afercia

This comment has been minimized.

Contributor

afercia commented Apr 11, 2018

Sorry but there's no consensus on the "solution" implemented in #5500 for the many reasons explained in that PR (not going to repeat them here). The accessibility issue stands, so I'm going to reopen this issue.

From an accessibility perspective, the important thing to understand is that the state of these switches needs to be reflected in some textual form too.

I think everyone can agree that during the development of these switches the accessibility feedback hasn't blocked experimentation and has been available to try different options, trying to get a good balance between visuals and a11y. However, at this point, I don't see a great value added by these switches compared to native checkboxes. These controls are problematic, they can't be used easily by everyone and, I'm sorry to say it, they're not the best example of inclusive design.

@afercia afercia reopened this Apr 11, 2018

@jasmussen jasmussen removed their assignment Apr 12, 2018

@karmatosed karmatosed modified the milestones: Merge Proposal, Merge Proposal: Accessibility Apr 12, 2018

@pento

This comment has been minimized.

Member

pento commented Apr 12, 2018

@afercia: To avoid miscommunication, could I get you clarify which accessibility issues you're referring to?

After reading your comments on the PR, my understanding is that we need a visible, textual representation of the on/off state of the control. That text doesn't need to be literally "on" and "off", it simply needs to clearly state what the control is currently set to. Is that correct?

If that's correct, I have a couple of questions:

  • From a HTML structure perspective, does that text need to be inside the <label> for the control, or can it simply be in an adjacent <p>?
  • The behaviour shown in #5500 (comment) seems to match the second suggestion you showed earlier in the this issue: #2146 (comment). Is this behaviour still something you'd recommend?

If this is the case, I don't mind leaving this issue open while we added help strings in the style of the one add in the Gallery settings in #5500, to the other nine instances of ToggleControl.

Were there any other accessibility issues that I missed while reading through?

@pento

This comment has been minimized.

Member

pento commented Apr 12, 2018

Oh, and there are four instances of <FormToggle> being used, which seems like it should be merged into <ToggleControl> and deprecated.

@afercia

This comment has been minimized.

Contributor

afercia commented Apr 12, 2018

@pento thanks for your questions. Yes, that's correct.

There are different levels of accessibility, as in accessibility = universal access. Serious disabilities, cognitive impairments, different cultures, unexperienced users, and so on and on. Everyone has his own needs.

In this specific case, a bit ironically, blind users will find these switch toggles perfectly accessible because, under the hood, they're native checkboxes and they will be announced as such by assistive technologies. E.g.:
Allow comments - checkbox - not checked / checked

Simple, and perfectly clear.

My concern is more about visuals. I'd say that's also an usability issue, not just an accessibility one. There are no "universal symbols" that can be understood by everyone. We can't rely on colors, we can't rely on symbols or icons alone. So yes, there's the need to use some textual representation as also recommended by the material design. Quoting:
https://material.io/guidelines/components/selection-controls.html#selection-controls-switch

while they've deprecated the previous version with the text “on” and “off” they also state:

The option that the switch controls, --> as well as the state it’s in <--, should be made clear from the corresponding inline label.

However, I'd recommend to not use the main label to represent the option state. That could be potentially very confusing, for example:

Comments disallowed - unchecked
Comments allowed      - checked

Instead, keeping the label unchanged and using additional text would be a better option. At Yoast we use a similar switch toggle with an "On / Off" visual "hint", and we've gone a step further: we hide the hint to assistive technologies using aria-hidden="true" because it doesn't really need to be communicated to screen reader users. It's just a visual confirmation of the current state.

From a HTML structure perspective, does that text need to be inside the for the control, or can it simply be in an adjacent

?

It depends on the solution: in both cases the text should be separated from the label so yes I'd use an adjacent <p>. I'd use aria-hidden="true" for On/Off. Instead, for a longer and hopefully meaningful "help text" I'd try to use an aria-describedby="some-id" on the checkbox and target the help text with <p id="some-id" .... That would be announced, for example, this way:
Crop Images - checkbox - not checked - Thumbnails are not cropped

The behaviour shown in #5500 (comment) seems to match ...

Yes, I like that behavior (also visually) and I'd recommend it. I didn't notice it was implemented for the gallery settings. For reference:

screen shot 2018-04-12 at 18 52 02

screen shot 2018-04-12 at 18 53 56

If all the switch toggles were standardized with some required help text, then I'd say the symbols I and o could be removed maybe?

@afercia

This comment has been minimized.

Contributor

afercia commented May 9, 2018

Some important considerations have been made on a related PR, see starting from this comment #6578 (comment) I'd say they complement the discussion here and they're useful to fully understand the ongoing conversation.

@mrwweb

This comment has been minimized.

mrwweb commented May 10, 2018

Can anyone explain why these switches were designed instead of using checkboxes? Do they add something important for usability or design that a checkbox lacks? It seems the initial rationale for inclusion is missing from this conversation and makes everything else hard to evaluate.

@designsimply

This comment has been minimized.

Contributor

designsimply commented Jun 14, 2018

Can anyone explain why these switches were designed instead of using checkboxes?

I was not present for the original design decision, however, I know that in design: switches toggle the state of a single setting on or off while checkboxes allow the selection of one or more items from a set. While it is also possible to use a single checkbox to turn an option on or off, switches may be preferred in this context due to design consistency and the fact they are already established in other areas (such as iOS, Android).

Do they add something important for usability or design that a checkbox lacks?

A switch turns the state of a single setting on or off and generally implies an immediate change.

@designsimply

This comment has been minimized.

Contributor

designsimply commented Jun 14, 2018

I removed the Good First Issue label from this issue because it lacks a clear direction at this point in time. We can add it back later if that changes!

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 18, 2018

switches may be preferred in this context due to design consistency and the fact they are already established in other areas

I'd say this is not the case in an application like Gutenberg that aims to be usable by everyone, regardless of their different ability levels. That's the whole point of the discussion going on here and previously on #6578 (comment) etc.

About "design consistency" I'd argue there are no switches in WordPress, so the ones introduced in Gutenberg actually introduce some inconsistency.

As already pointed out multiple times, the state of the switches may not be clear to everyone:

  • the toggle position alone is not sufficient to indicate the state
  • the color is not sufficient to indicate the state
  • the I/0 signs, although they're an industrial standard, don't have an universal meaning across all cultures and languages; they're also very small, and could be problematic for people with low vision or cognitive impairments etc.

There are a lot of potential issues with these switch toggles; the real question we should ask ourselves is if these switches actually add some value compared to native controls like checkboxes, which are universal as they're native.

@karmatosed

This comment has been minimized.

Member

karmatosed commented Jun 19, 2018

It's important to note the action of a checkbox isn't a boolean interaction alone. It can be for multiple choices and even to make a choice after. This means that in the case of a literal 'on/off' a switch is a better choice for interaction. It literally toggles something to one or other state. Imagine a light switch, a common interaction pattern. Performance wise there is no page reload or save changes, it just happens as naturally as that light switch.

This issue has gone around a little and it's time to settle on making the most accessible switches we can and move into implementation.

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 20, 2018

@karmatosed yeah however we should really distinguish the visual appearance of the switch from its functionality. Regardless it's a boolean choice or not, I'd just note that under the hood the switch is implemented using a checkbox 🙂it has the semantic of a checkbox and perceived by software (including assistive technologies) as a checkbox:

screen shot 2018-06-20 at 09 04 31

This means that in the case of a literal 'on/off' a switch is a better choice for interaction.

Any data, research, or user testing to support this statement?

Performance wise there is no page reload or save changes, it just happens as naturally as that light switch.

This doesn't relate to the actual control used. As said, the switch actually uses a checkbox. The saving can be made asynchronous using any form field.

I'd also recommend to consider that at the moment WordPress doesn't use switch toggles, so Gutenberg is going to introduce in core something that should be evaluated in the WordPress context.

Worth reminding all the accessibility feedback is asking here is to just make clear the current state of the switch, using some meaningful text.

@karmatosed

This comment has been minimized.

Member

karmatosed commented Jun 20, 2018

Any data, research, or user testing to support this statement?

I am not sure what you want data on as it's a literal on/off switch interaction here. It's widely accepted (which I know is a sweeping statement) that something with only 2 is binary in interaction. Do you have data, research or user testing that seems to counter this? Apologies but a little confused what you want me to provide.

Whether it actually uses a UI element of a checkbox or not we are talking about the visual rendering - we need to be careful not to confuse the two. In the case where the UI literally indicates and on/off state then having switches makes a ton of sense. Let me add some articles for that to hopefully respond.

http://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

In this article a point raised that adds context to what we are using them for:

Switches always indicate whether a setting is on or off. When users turn a switch to “on”, they expect an instantaneous action as soon as the label appears. This is what “on” implies, not just for UI switches but real-world switches too.

It simple comes down to:

  • Switches Are for Instantaneous Actions
  • Checkboxes Require a Button Press

The visual cue of a checkbox is different than a switch. While “on” implies instance, a checkmark only implies selection. This means users expect a more immediate change with switches than checkboxes.

Another good link is: https://uxplanet.org/checkbox-and-toggle-in-forms-f0de6086ac41

A valid point is that just because today WordPress doesn't use something shouldn't mean we don't explore new patterns.

Worth reminding all the accessibility feedback is asking here is to just make clear the current state of the switch, using some meaningful text.

Awesome lets move on then and get the state shown, there's some progress there we can move on with.

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 20, 2018

@karmatosed my question was related to the part where you state that "it's better":

a switch is a better choice for interaction

Without data or user testing, this is a personal opinion 🙂 Instead, what I've learned in years is that there's no such a thing that is "better" for everyone. Only native controls get close to be universally usable because they're native, expected, and supported by any software.

@samikeijonen

This comment has been minimized.

Contributor

samikeijonen commented Jun 21, 2018

There have been several discussion in different PRs and here is my conclusion.

  • Although I agree with @afercia, this is minor issue. Let the current switch stay, and make it better if needed.
  • Switch does look better than checkbox.
  • Switch does have a small learning curve: is the switch on or off even if there are visual hints.
  • Not all switch are born equal. Some definitely needed extra text, and some didn't. For example #6578.

I'll review is there some places we need the extra text or not.

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 21, 2018

During yesterday's accessibility meeting on Slack it was agreed with @karmatosed to use labels to make the switches state clear. So there's now consensus to indicate the state the switch is in also with some text.

What is left, is making a decision about which text should be used: the inline label itself or the descriptive text below the label? From an accessibility perspective I'd rather see the label text to not change. However, at this point of the discussion, any decision would be fine as long as there's a textual indication of the switch toggle.

Material.io was mentioned a few times through all the discussions about switches. So I'd like to recap some of the recommendations material.io does:

Switches are designed especially for mobile and tablet.
References:
https://material.io/design/components/selection-controls.html#usage

When to use switches
Use switches to: Toggle a single option on or off, on mobile and tablet

https://material.io/design/components/selection-controls.html#switches

Switches toggle the state of a single setting on or off. They are the preferred way to adjust settings on mobile.

I'm not opposed to use them on desktop too if designers think that's beneficial, however everyone should consider carefully they've been designed with touch interaction and mobile UIs in mind.

The state should be made clear in the text
Reference:
https://material.io/design/components/selection-controls.html#switches

Text label
The option that the switch controls, as well as the state it’s in, should be made clear from the corresponding inline label.

What material.io recommends is basically what you can see in the screenshot below, where the inline label changes to indicate the current state:

screen shot 2018-06-21 at 08 51 46

Instead, what we've tried so far in Gutenberg is to indicate the state in the description below the label. See in the screenshot below the Gallery "Crop" option that has been implemented this way since the beginning:

screen shot 2018-06-21 at 09 06 33

Either ways are fine (though the second one would be preferred for a11y). Once there's a final design feedback about the two options above, addressing this issue should be pretty straightforward. /Cc @karmatosed

@samikeijonen

This comment has been minimized.

Contributor

samikeijonen commented Jun 21, 2018

PR #6578 is good example that the copy text itself is more than hard sometimes. I personally don't know what it should be in that case.

And if it was unclear, I'm OK leaving extra text out for case like that. It's too minor issue comparing to bigger issues.

@karmatosed

This comment has been minimized.

Member

karmatosed commented Jun 22, 2018

To be super clear I meant label beside the toggle if we have to such as saying 'on' / 'off' not having sentences below. I still standby I don't think that is a benefit here. I also still feel to be clear because that's important that having the same text all the time doesn't work.

What Material do I think we could over having what we have currently suggested, which I don't think is the best route saying everything underneath as in #6578. I am going to early next week work on some ideas there. I want to dig into how Material do this as we totally can learn from them here. Thanks for looping back and I feel we are super close to a solution combining that balances design and usability here.

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 26, 2018

Let's try and focus on the issue at hand, the crux of which is: if there is a text label that indicates switch state, this is more clear for the user than if the label only describes the switch and the switch alone indicates state. Is that a correct assessment?

If yes, then let's lazer focus on that. We already have one solution for particularly gnarly switches like the Drop Cap, when contextual help text can both help clarify the effect of the switch as well as the state.

The recent suggestion to change the label itself correctly acknowledges the challenges with duplicate and overly verbose text, as well as the challenge that localization poses. In other words, if phrased right, it can presumably accomplish goals, as well as wrap. That's good.

The question here is — how can we make sure a contextual label doesn't actually add complexity, as opposed to take it away? Given that the primary purpose of a label is to describe the control, does it confuse if it doubles as a state indicator? Usually UI that is changing is bad for spatial memory. That's not an issue with the help text given it's a separate element.

At this point it is worth clarifying that "Line item off" is purely an example by Google, and not part of the guidelines. If you look at the top of the page, the switch is shown with example-text in context of radio and checkbox controls that show the same example-text:

screen shot 2018-06-26 at 08 40 47

It's clear from that context that Material guidelines treat the switch as a plain control exactly the same as a radio control or a checkbox control, and that the switch needs no more contextual information than a checkbox does. The pertinent part is this:

The option that the switch controls, as well as the state it’s in, should be made clear from the corresponding inline label.

Avoid creating a switch that includes the text “on” and “off” within the graphic itself. The switch alone should be sufficient.

Be that as it may, those are Google guidelines, and if we truly believe we have a better idea than Google here, that's totally fine. To find out, I think we should mock up & brainstorm a few examples and look at them through the eyes of accessibility, usability, readibility, before we proceed. @michelleweber can you take a look as well? Suggested controls to look at could be:

  • Stick to the Front Page
  • Pending Review
  • Allow Comments
  • Allow Pingbacks & Trackbacks

Screenshots, for good measure:

screen shot 2018-06-26 at 08 25 52

screen shot 2018-06-26 at 08 25 58

Here are some quick ideas:

Stick to Front Page    [ ]

Sticks to Front Page   [X]

Pending Review       [ ]

Is Pending Review   [X]

Allow Comments   []

Allowing Comments   [X]

Allow Pingbacks & Trackbacks [ ]

Allowing Pingbacks & Trackbacks [X]

Simply as an exercise of putting those labels together was hard, and I'm unconvinced that this adds clarity instead of confusion. But curious to see your thoughts and ideas here.

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 26, 2018

At this point it is worth clarifying that "Line item off" is purely an example by Google, and not part of the guidelines.

@jasmussen this is not correct. As mentioned several times, the material.io guidelines explicitly say the text label should indicate the switch state. You can read that under Switches > Usage:

Text label
The option that the switch controls, as well as the state it’s in, should be made clear from the corresponding inline label.

Again, for completeness, in their first version the material.io switches had a "On/Off" text. That version was later deprecated in favor of state indicated in the inline label text.

@jasmussen

This comment has been minimized.

Contributor

jasmussen commented Jun 26, 2018

I quoted that very same guideline in my comment above, except I quoted both paragraphs:

The option that the switch controls, as well as the state it’s in, should be made clear from the corresponding inline label.

Avoid creating a switch that includes the text “on” and “off” within the graphic itself. The switch alone should be sufficient.

We are interpreting semantics here, and it seems clear that you are interpreting it differently than I am. In my interpretation, "Allow Comments [X]" is a perfect example of an inline label that makes the state and the option the switch controls clear, without being contextual.

It doesn't seem productive to continue to try and interpret Google guidelines if we both disagree, but agree that we can rise above them if we have a better solution.

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 26, 2018

I'm sorry but what they say is “on” and “off” within the graphic itself where "on the graphic" means they've deprecated the previous "On/off" text used close to the switch (Edit: or inside the switch "track").

but agree that we can rise above them if we have a better solution.

the better solution is to indicate the state to the switch in plain text, as requested so many times. Overall, I have my doubts about the introduction of the switches themselves in WordPress. I still don't see a clear added value compared to standard checkboxes. Let's try, at least, to make these switches understandable by everyone.

@johnmaeda

This comment has been minimized.

Contributor

johnmaeda commented Jul 17, 2018

If we consider how mobile usage has overtaken desktop usage, and given that Gutenberg looks to the future, it's useful to note that the vernacular for user experience will be subsumed by the habits we learn on mobile. Over time, the approaches we held strongly to in the past will seem antiquated if we're not careful — and also desktop screens will be touch-sensitive like our smartphone screens within a few years (and on some desktop platforms it's becoming the norm). So when in doubt, I recommend that we keep learning from mobile patterns as they're the leading behavior of the future.

@afercia

This comment has been minimized.

Contributor

afercia commented Jul 17, 2018

Mobile patterns still have a long way to go when it comes to accessibility. They're designed for one specific device type, because the UI is embedded in a specific device. Instead, on the Web we should strictly follow a device-agnostic design.

It is certainly true that once in a while new technologies will come to life and influence the way many user interfaces are designed. It is also possible, for example, that in the next 20 years mobile devices as we know them today will be dead because we'll all be using, say, holographic interfaces 🙂That's just one more reason why web interfaces should abstract from the device types and user abilities, to be truly universal and inclusive.

@tofumatt

This comment has been minimized.

Member

tofumatt commented Oct 3, 2018

This issue has become quite muddled and it's a bit hard to follow. I'm going to start with a summary of what seems to be the issue here, and address attempts to fix it.

Issue

The argument is that switches alone are not an accessible UI because their state is not accurately reflected by their simple on/off button state graphical representation. The argument for this is based in switches not being universal UI. There has been a counterpoint that they are extremely common mobile UI and thus quite well-known. That point is somewhat debatable as even the countries with the highest smartphone penetration show 20% of users without smartphones.

Discoverability

That said, it's a switch, and a switch is a common UI paradigm in life. If presented with accessibility audits/studies/user testing that showed me a significant percent (let's say, over 10%) were not aware which switch state was which after a few minutes of usage, I'd be convinced that it was not a learnable UI. UIs throughout the web and mobile use switches with labels that do not have a third, semi-redundant state explanation. The drop cap explanation actually reduces usability by adding extra, changing text to a switch which already looks straightforward to any mobile user:

screenshot 2018-10-03 16 51 08

It was pointed out that sometimes these descriptions add even less context and are just repeats of the label. They can be difficult to write and create a crowded interface.


I don't think these switches require an additional label on the basis that a switch is not an understood UI. If the issue is that non-sighted users are not aware of the state, that is a separate, discrete issue which I would appreciate filed and would certainly consider a part of the 5.0 merge milestone for accessibility.

As it stands, I am actually for removing the state sub-labels for these switches because I think they are an impediment to more users than they help. They create a crowded UI with redundant information (because they are instant-effect their effects should be seen elsewhere, see: drop-cap):

2018-10-03 18 53 00


On iOS switches are given the accessibility option to have the I/O markers when on or off. Ours already do that by default (iOS does not), and I think that is sufficient unless we hear user feedback in a higher volume that these switches are not usable.

Conclusion

Our switches have I/O markers thanks to #5500, which closes this issue (I agree with @jasmussen on this one).

If there are issues with the usability of these switches for screen-readers, please file that as a separate issue that indeed needs addressing. For the on/off labelling of switches in Gutenberg, the decision is that our current I/O marker will suffice until we hear from users that it is unintuitive.

@tofumatt tofumatt closed this Oct 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment