feat(toggle-button): new component

[ArtBlue]

Fixes #1970

• This PR contains CSS changes
• This PR does not contain CSS changes

Description

This introduces the Toggle Button component which is a subset of a future component, Toggle Button Group (responsive layouts using a set of Toggle Buttons).

Notes

Screenshots

Checklist

• I verify the build is in a non-broken state
• I verify all changes are within scope of the linked issue

• I regenerated all CSS files under dist folder
• I tested the UI in all supported browsers
• I did a visual regression check of the components impacted by doing a Percy build and approved the build
• I tested the UI in dark mode and RTL mode
• I added/updated/removed Storybook coverage as appropriate

[ArtBlue]

I had doubts about the benefits of having the buttons in a <ul> (deviation from the current draft of MIND patterns). From a screen reader perspective, there was a single spoken "list" between the two versions:

WITH UL

eBay Skin  document   
heading    level 2  @ebay/skin/toggle-button-group   The Toggle Button Group is a group of single or multi-toggle buttons providing a visual emphasis on the available selectable choices.  Toggle button group of text items  grouping  list  toggle button  not pressed    Text Button 1      toggle button  pressed    Text Button 2      toggle button  not pressed    Text Button 3    

WITHOUT UL

eBay Skin  document   
heading    level 2  @ebay/skin/toggle-button-group   The Toggle Button Group is a group of single or multi-toggle buttons providing a visual emphasis on the available selectable choices.  Toggle button group of text items  grouping    toggle button  not pressed    Text Button 1      toggle button  pressed    Text Button 2      toggle button  not pressed    Text Button 3    

[saiponnada]

Regarding semantics of using UL LI or not, when there is a button group there needs to be some level of defining a group. It can be either

• Using ul li as shown in mind patterns (gives list) (or)

• Assuming you are using role=group and aria-labelledby attribute to achieve that

  <div role="group" aria-labelledby="toggle-button-group-label">
     <span id="toggle-button-group-label">Toggle Button Group</span>
     <button type="button" class="toggle-button" aria-pressed="true">Image Button Title 1</button>
     <button type="button" class="toggle-button">Image Button Title 2</button>
     <button type="button" class="toggle-button">Image Button Title 3</button>
  </div>
  

IMO, both of these approaches are fine. The choice between them depends on the desired level of semantic markup and flexibility in styling.

I had doubts about the benefits of having the buttons in a <ul> (deviation from the current draft of MIND patterns). From a screen reader perspective, there was a single spoken "list" between the two versions:

[ianmcburnie]

1st rule of ARIA is don't use ARIA ;-)

The first rule of ARIA is if a native HTML element or attribute has the semantics and behavior you require, use it instead of re-purposing an element and adding ARIA.

[agliga]

Lets leave this for 16.3. That way we can have this as the first change and then also get a component out in the same release.

[ArtBlue]

@saiponnada , @ianmcburnie , just to clarify, the a11y issues to resolve for this particular PR is only for guidance to teams using the toggle-button component since it won't currently come wrapped in toggle-button-group since the work has been split up. In a future PR, when toggle-button-group is released, we will utilize our own guidance.

Originally, I believe we discussed having role="group" as well as aria-label. I may have seen both of those and the <ul> implemented at some point (I don't now). Sure, we can definitely use the <ul> in lieu of role="group", but we will still need to retain the aria-label to describe the list of buttons.

For now, this is what it would look like:

<div class="toggle-button-group">
    <ul aria-label="List of Shipping Options">
        <li>
            <button type="button" aria-pressed="false">
                IMAGE
                UPS Ground
                PRICE
            </button>
        <li>
            <button type="button" aria-pressed="false">
                IMAGE
                USPS Priority
                PRICE
            </button>
        <li>
            <button type="button" aria-pressed="true">
                IMAGE
                Fedex Ground
                PRICE
            </button>
        </li>
    </ul>
</div>

Would that work? I added the label on the <ul> to add context to the list instead of the parent <div>. What do you think?

[saiponnada]

I guess that should work. By default UL LI tag is interpreted as List. So in the aria label, just Shopping options is enough. Sometimes if we use a heading e.g, Shopping options, then this would be unnecessary. It depends on the context around. So when we develop this in ebay UI label might be empty.

[ArtBlue]

I guess that should work. By default UL LI tag is interpreted as List. So in the aria label, just Shopping options is enough. Sometimes if we use a heading e.g, Shopping options, then this would be unnecessary. It depends on the context around. So when we develop this in ebay UI label might be empty.

Sounds good! Yea, I was a bit concerned over the redundancy.

I do think that the aria-label should be necessary though for context to let users know they can select/toggle the buttons inside. Actually, not just for context, but because these buttons can either be multi-select or single-select, and users won't know that when interacting with the buttons. I don't think aria has anything out of the box to relay that info in a different way.

Something like, "Single-selection group of shipping options" (single-select) and "Multi-selection group of size options" (multi-select).

[ianmcburnie]

but we will still need to retain the aria-label to describe the list of buttons

I was imagining the context for the button group would be provided by either:

a) a preceding onscreen heading element (e.g. "Shipping Options")
b) quickly deducible from button labels alone (e.g. from "Visa", "Mastercard" it can be deduced these are payment options)

Option a) would always be preffered for most clarity.

The trouble with aria-label on the list or container is that it creates a different experience for AT. Better if we can to have same experience for all users.

[ArtBlue]

I was imagining the context for the button group would be provided by either:

a) a preceding onscreen heading element (e.g. "Shipping Options") b) quickly deducible from button labels alone (e.g. from "Visa", "Mastercard" it can be deduced these are payment options)

Option a) would always be preffered for most clarity.

The trouble with aria-label on the list or container is that it creates a different experience for AT. Better if we can to have same experience for all users.

I see. In the scenario without the heading though, would the context really be clear from the buttons themselves? One of the minimal layout themes simply has numbers -shoe sizes. Would we just prescribe/require a heading in those cases? I'm fine either way; we just have to cover all the use-cases and be more prescriptive in some circumstances.

That said, I'm not sure if there will be anything applicable to this PR. Should we continue this discussion in the following PR where this structure is going to be implemented (toggle-button-group)? This PR is merely for the individual toggle-button.

[ianmcburnie]

Would we just prescribe/require a heading in those cases?

Preference for app teams would be this order:

1. Use onscreen heading
2. Use offscreen heading
3. Use aria-label. This needs to go on an element with a role that supports aria-label. Options are a) the list b) the container div with role=group. I would also just keep the label to "Shipping Options" rather than "List of Shipping Options".

We could document this on Skin, and rather than having all 3 examples shown on Skin we could just go with the minimal version (option 3, ARIA) for the purposes of keeping examples concise (we do this with radio button and checkbox modules).

[LuLaValva]

Looks great! Just a few comments and points for consideration.

[ianmcburnie]

I would add a paragraph of text after the heading here explaining very briefly what "list view" means and under what circumstances it is used. Same goes for "gallery". These terms have connotations with List and Gallery views on SRP, which are completely different, so I think there could be some confusion here.

To be consistent with rest of docs, I would also separate out the second multiline example. Same goes for the image and icon examples for gallery view.

[ianmcburnie]

It feels like the List View variations section repeats the example that was in the first toggle button section. Following on from my previous comment, I wonder if we could just merge these two sections and show all list view variations in sequence, one at a time, followed by all gallery view variations?

[ianmcburnie]

Let's try and add some flavorful text after each h3. One thing I like to do is highlight what the delta is from the previous example.

For example:

Toggle Button with Title and Subtitle: a subtitle can be added via the toggle-button__subtitle block.
Toggle Button with Title and Multiline Subtitle: use paragraphs to create a subtitle that spans multiple lines (note: I'd even be tempted to removed this as a heading and just have it fall under the preceding heading
Toggle Button with Icon, Title, and Subtitle: Any 16x16 svg icon can be dropped in, inside of a toggle-button_
icon block.

EDIT: I see we are lacking this in other places, like split-button and listbox-button. So we should plan on doing a sweep of those in a follow up PR to restore consistency to the docs.

[ArtBlue]

Let's try and add some flavorful text after each h3.

@ianmcburnie , done.

[LuLaValva]

Looks great! Just one small docs change and then I think this should be good to merge

[ianmcburnie]

Just a few docs change suggestions. If you like them, they can be committed directly here in the GitHub UI.