Develop example of switch design pattern

[mcking65]

This issue is dependent on issue #162.

Preview link for work in progress

Switch example in switch branch

[ZoeBijl]

Work on this is done in the “switch” branch. You can follow progress on the live example.

[ZoeBijl]

Got approval to use Carri Craver’s design.

[Owlbertz]

Because I recently stumbled upon accessibility of a switch, I found this one. I just noticed that the switch can only be operated using space and not enter. What's the reason for this behavior?

[ZoeBijl]

@Owlbertz because that’s the way native switches and checkboxes behave.

Tested with native switches on Windows 10 and native checkboxes on macOS 10.13.

[Owlbertz]

@ZoeBijl Ok, so you compare the switch to checkboxes. I guess I was thinking about a button with the aria-pressed flag set.
But I think comparing native controls is the right way to go, so I think you're right.

[annabbott]

No issues noted.

[jnurthen]

Needs to have a greater contrast in the off state to meet WCAG 2.1

[stes-acc]

Examples are insufficient.
What if Switch itself has a label inside that dynamically changes based on switch state? (e.g. On/Off)

[jnurthen]

@stes-acc Can you submit a separate issue for this. It would be helpful if you could provide a link to an example which demonstrates the feature so there is clarity as to what is being requested.

[stes-acc]

Well, an example can be found here: https://openui5.hana.ondemand.com/#/sample/sap.m.sample.Switch/preview

By the way, these are also toggled using ENTER key, which is quite common.

[jnurthen]

@stes-acc New issue please.

[mcking65]

@stes-acc, if using a switch, toggle, or checkbox, please never, never change both the label and state. At best, it creates very confusing redundancy. In some cases, it creates semantics that conflict with the label and make it impossible for the user to discern what to do. All the examples you cited are problematic and violate this guidance for toggles.

We have the following text in the button pattern. We should include something similar in switch:

Toggle button: A two-state button that can be either off (not pressed) or on (pressed). To tell assistive technologies that a button is a toggle button, specify a value for the attribute aria-pressed. For example, a button labeled mute in an audio player could indicate that sound is muted by setting the pressed state true.
Important: it is critical the label on a toggle does not change when its state changes. In this example, when the pressed state is true, the label remains "Mute" so a screen reader would say something like "Mute toggle button pressed". Alternatively, if the design were to call for the button label to change from "Mute" to "Unmute," the aria-pressed attribute would not be needed.

For instance, consider on/off switch. You hear "on switch button on" or "off switch button off". These are confusing. If an off button is off, is the element being controled on because the off button is not on?

My favorite is the "no" button. It says it is off. So, if the "no" button is off, is it a Yes?

For switches, the label needs to represent the thing being switched. Think of a light switch. If the button turns lights on or off, then you label the switch "Light". Then, you hear "light switch button on" or "light switch button off".

Using accept/reject as an example, for labeling, your options are:

1. Label a button withthe verb "accept" or "reject". Pressing will execute that action. In this case, you do not use a state on the button. Take this approach if the action is more important than communicating the current state.
2. Give a checkbox or toggle button a static label that represents a specific state and use an aria-checked or aria-pressed state to represent the user's action, e.g., a checkbox labeled "I accept the terms". The label never changes, only the checked state.

Hope that helps.

BTW, another issue with that example page is that role application is on the body.

[stes-acc]

@mcking65 It's all about that you need to change a value string on a switch and not only a boolean true/false value. If your answer is "don't do this at all with ARIA switches" then you ignore a common use case for switches and this discussion should turn into "what are invalid use cases for the switch role" which is extremely important to clarify in an APG and what are possible future ARIA attribute extensions of the switch role to reflect this properly. I agree that using label for this is a workaround here, but what is a good and allowed technique for exactly doing this using the switch role and not other roles in a redesign? This was the original question we had.

All the examples you cited are problematic and violate this guidance for toggles.

We have never seen such a guidance written and recommended as official statement from the ARIA group in the original specification. Can you please point us to the written reference source of this information besides of the APG? Also, it is NOT present as a general chapter in the APG since it affects many roles. And is this also valid for aria-label, aria-labelledby and aria-describedby? May those also never change as result of a control operation? I think resolutions on this have never been persisted centrally.

Nevertheless we will elaborate on your proposals, many thanks.

BTW, another issue with that example page is that role application is on the body

We don't want role=application on body at all but we need it to correct inappropriate and insufficient Jaws ARIA role recognition and Forms mode treatment for ARIA mainly in IE but also other browsers which is a commonly known Jaws issue in web-based business pages where the entire page IS an application. We know that it confuses potentially users but that is the situation. Not we but Jaws has to improve here making those workarounds obsolete.

[jongund]

We have some examples of toggle buttons in the toolbar example we are working: https://rawgit.com/jongund/aria-practices/toolbar/examples/toolbar/toolbar.html There is also one toggle button example in current practices for the button pattern: https://www.w3.org/TR/wai-aria-practices-1.1/examples/button/button.html Jon From: Stefan <notifications@github.com> Reply-To: w3c/aria-practices <reply@reply.github.com> Date: Friday, November 30, 2018 at 4:38 AM To: w3c/aria-practices <aria-practices@noreply.github.com> Cc: Jon Gunderson <jongund@illinois.edu>, Assign <assign@noreply.github.com> Subject: Re: [w3c/aria-practices] Develop example of switch design pattern (#243) All the examples you cited are problematic and violate this guidance for toggles. We have never seen such a guidance written and recommended as official statement from the ARIA group. Can you please point us to the written source of this information? Nevertheless we will elaborate on your proposals, many thanks. We don't want or need role=application on body but we need it to correct inappropriate and insufficient Jaws ARIA role recognition and Forms mode treatment for ARIA mainly in IE but also other browsers which is a commonly known Jaws issue. We know that it confuses potentially users but that is the situation. Not we but Jaws has to improve here making those workarounds obsolete. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#243 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABcE7DGWufBSV_UxlVZdjXStuAlaSAHoks5u0QqRgaJpZM4LnkNI>.

[carmacleod]

@mcking65
aria-checked is a required attribute for switch, checkbox, etc. We currently have it as an author error, with a fallback value of false, if the attribute is not provided. Please see the Required Properties with Default Values table that we created for w3c/aria#787.

Maybe we should discuss changing aria-checked to a supported attribute instead?
@jnurthen a topic for the call?

[ZoeBijl]

@jnurthen wrote:
Needs to have a greater contrast in the off state to meet WCAG 2.1

Have changed the design. The on state now passes with 3:1. But the off state still fails with 1.6:1. I’ll have another look at the design.

---

@Owlbertz wrote:

@MichielBijl Ok, so you compare the switch to checkboxes. I guess I was thinking about a button with the aria-pressed flag set.
But I think comparing native controls is the right way to go, so I think you're right.

Since your comment I’ve added support for the return key. This might change still—but it’s there for now. I can’t really think of a negative consequence; can you @mcking65?

---

I have completely rewritten the JS for this one. It now uses a class and is much more structured/readable.

Any feedback welcome.

[jnurthen]

@jnurthen wrote:
Needs to have a greater contrast in the off state to meet WCAG 2.1

Have changed the design. The on state now passes with 3:1. But the off state still fails with 1.6:1. I’ll have another look at the design.

background: #949494
would fix it - the question is, is it too dark that someone might mistake it for being "on". My gut feeling is that it is ok but I have no research to back this up :)
If simply darkening the grey is not acceptable then potentially simply having a slightly darker circle or border for the switch and retain the grey interior colour could work as that would still have a 3:1 contrast with the white.

[ZoeBijl]

That could work 👍

I was looking at something like this design on Dribbble which shows the state in text too—similar to how Apple does this in iOS.

[stes-acc]

Nevertheless there is the need to develop a switch pattern that changes and signals its internal value if it is NOT a boolean value.

There are different approaches to accomplish that:

1. Not using the switch role at all but the slider role instead with 2 values and use aria-valuetext attribute for the non-boolean value

2. Using the switch role pointing to an additional live region that dynamically changes with respect to the switch state, for example:

<span id="sl1">Please confirm:</span>
<span id="s1" role="switch" aria-labelledby="sl1" aria-describedby="lr" aria-checked="false" onclick="toggle(event)" onkeyup="checkKey(event)" class="switch red" tabindex="0">
<span id="lr" class="stext" aria-live="polite">Reject</span>
</span>

Please comment what to do in such cases.

[ZoeBijl]

@stes-acc do you have a working code example we could look at? I’ll have to read the rest of the thread but I’m not quite sure what you mean and whether it’s a switch pattern.

If this is about the Open UI switch example you posted earlier; all I see there is that the state is clarified by the text inside the switch. This is similar to how iOS adds an I and O indication within its accessibility features.

[stes-acc]

If this is about the Open UI switch example you posted earlier; all I see there is that the state is clarified by the text inside the switch. This is similar to how iOS adds an I and O indication within its accessibility features.

As a matter of fact, I and O are NOT separate non-boolean value text but an additional visualization of boolean values for people not knowing which switch position means on and which off.

Regarding the example:

Here is a rough sketch.

It does NOT contain a switch-like layout or any sliding animation. It should only demonstrate the principle of dynamically changing the text on a switch when activated. Please don't tell me to use a toggle button for that because it looks alike. Mandatory are switch visuals as in the Open UI switch example.

[mcking65]

Complete in #1892 with commit 594fe37.

@stes-acc I think we have addressed your concern about people not being able to understand which graphical position means "on" and which means "off". Please have a look at the first Switch Example. BTW, 2 more examples, one made with HTML checkbox and one ith HTML button are in the works and will land soon.