Size Change: +236 kB (+15%) ⚠️

Total Size: 1.86 MB

_{compressed-size-action}

It was such a blast 🍐 'ing with you on this @sarayourfriend :D.

Going through the PR now.

I think it was awesome that we got an initial implementation of nested + collapsible lists working in the story:

For now, I think we should remove it from the story (until we can refine + create a better working implementation)

Thoughts on design:

The original new Menu component was designed to work as a (sub) component of Dropdown. We want to carry that spirit within this new/updated implementation of ItemGroup (or List? name is TBD?)

That Menu component was intentionally designed (aesthetically) to look like the current Gutenberg dropdown:

In that case, we may need to make some style adjustments.

I did a quick test, and I was able to get these new ItemGroup components working with the Reakit/Menu component (https://reakit.io/docs/menu/), which is what powers the new Dropdown components.

It's too much effort to get it working 100% in the Story. I did enough to ensure the integration, features, and mechanics work 👍

I've pushed up some styling updates to prepare the component to replace Menu when rendering within the new Dropdown.

Note: The current Popover story implementation is very simple. The actual Dropdown component is much more involved.

I've also updated the "Non action" story to showcase some alternate UIs we can build using this component:

✋ Question about semantics + role

(cc'ing @diegohaz )

With this new component, we're able to render a collection of items that may or may not be actionable.

Non actionable scenarios may result in HTML that look like this:

<div role="list">
    <div role="listitem">...</div>
    <div role="listitem">...</div>
    <div role="listitem">...</div>
</div>

Actionable setups result in HTML that look like this:

<div role="list">
    <button role="listitem">...</button>
    <button role="listitem">...</button>
    <button role="listitem">...</button>
</div>

(Note: Like any of the components from the new system, you can always render as another component).

The question I had would be... what is the most appropriate markup in regards to semantics/a11y?

For example... What about ul/li?

We can totally render ul/li instead. However, we'll need to accompany this with a series of normalizing styles. This is because ul/li typically have globalized styles of some kind.

For actionable setups.. should the role change to something else?

Hey! Great work!

I don't think we should render role attributes here though. Instead, we can just default to ul and li elements.

Also, the following markups are not valid:

// button is not read as a button if it has role listitem
<div role="list">
  <button role="listitem" />
  <button role="listitem" />
</div>

// ul requires children to be li's
<ul>
  <button />
  <button />
</ul>

This makes the action prop a little bit confusing. This could be used to change the item element, but the list element would remain as ul unless it's aware of this action prop. I guess, in this case, it's better to put the action prop on the ItemGroup component instead:

<ItemGroup action>
  <Item />
  <Item />
</ItemGroup>

That would render this:

<div>
  <button />
  <button />
</div>

That's the best markup I can think of for a group of buttons. But I wonder if it wouldn't be better as a separate component. I would expect it to be ButtonGroup -> Button.

@diegohaz Thank you for your thoughts!!

(Humour me for a second, haha ❤️)

If you have the time, I'd love to know how you would approach the construction of these use cases - specifically from a semantic/a11y perspective and a React component API perspective.

To clarify, I'm mostly trying to understand the best rendered HTML markup.
For starters, I can provide my thoughts. Maybe you can expand on those :)

List of actions (or links)

(Link to demo)

HTML

<div>
  <nav>
    <ul>
      <li><a>Link</a></li>
      <li><a>Link</a></li>
    </ul>
  </nav>
  <hr />
  <ul>
    <li><button>Action</button></li>
    <li><button>Action</button></li>
  </ul>
</div>

React component:

<div>
  <nav>
    <List>
      <ListItem as={NavLink} to="/url">Link</ListItem>
      <ListItem as={NavLink} to="/url">Link</ListItem>
    </List>
  </nav>
  <Divider />
  <List>
    <ListItem action onClick={...}>Link</ListItem>
    <ListItem action onClick={...}>Link</ListItem>
  </List>
</div>

List of non-actionable items

(Link to demo)

HTML

<ul>
  <li>...</li>
  <li>...</li>
  <li>...</li>
</ul>

React component:

<List>
  <ListItem>...</ListItem>
  <ListItem>...</ListItem>
  <ListItem>...</ListItem>
</List>

Complex list of actionable items, with inner actions

(Link to demo)

HTML

<ul>
  <li>
    <input type="checkbox" />
    ...
    <button>...</button>
  </li>
  ...
</ul>

React component:

<List>
  <ListItem action onClick={...}>
    <Checkbox />
    ...
    <Button>...</Button>
  </ListItem>
  ...
</List>

Thank you!!

I tried giving this a test and the G2 components test page is so inaccessible. There are so many unlabeled buttons and links, it's hard enough finding the component to test. Once I finally found it, once again, the iframe with Mac's Voiceover doesn't play well. I wrote all this to say there's really no way to pass this accessibility wise until a more suitable testing environment is created. If your testing environment is inaccessible from the start, it's tough to tell what the new feature is.

When I clicked the dropdown it said something about a bunch of random letters web dialog opened. Again, not sure if this is just a side-effect with the iframe or something is going wrong with the dialog that opens.

Thanks.

@alexstine Haii! Thank you for trying to help!

it's tough to tell what the new feature is.

The new component is just a general (consistent) way to render a list of items.
You can think of it like a stylized unordered list (<ul>) element.

At this moment, we're not ready for a real accessibility run through, as we're still figuring out the correct structure (convos above with @diegohaz ).

We are planning on using it for a new Dropdown component. However, the one from Storybook was just an initial test to see if it would even work.

Perhaps we should switch the status of this PR to draft - since we're still actively working on it.

Your comment has raised an important point.
Once we're ready for folks to test and poke at the UI..
If the changes are within Storybook, we should provide a direct link to the (test optimized) Storybook iFrame URL.
This makes it easier for everyone 🙏 .

(cc'ing @sarayourfriend)

If you have the time, I'd love to know how you would approach the construction of these use cases - specifically from a semantic/a11y perspective and a React component API perspective.

To clarify, I'm mostly trying to understand the best rendered HTML markup.
For starters, I can provide my thoughts. Maybe you can expand on those :)

List of actions (or links)

If they're all navigation links, but it makes sense to have some distinction between the groups of links, we can have multiple nav elements:

<div>
  <nav aria-label="Primary folders">
    <ul>
      <li><a>Inbox</a></li>
      <li><a>Drafts</a></li>
    </ul>
  </nav>
  <nav aria-label="Secondary folders">
    <ul>
      <li><a>Trash</a></li>
      <li><a>Spam</a></li>
    </ul>
  </nav>
</div>

But, if Trash and Spam are buttons, just wrap them within a div:

<div>
  <nav>
    <ul>
      <li><a>Inbox</a></li>
      <li><a>Drafts</a></li>
    </ul>
  </nav>
  <div>
    <button>Move to Trash</button>
    <button>Move to Spam</button>
  </div>
</div>

Complex list of actionable items, with inner actions

This looks like a table.

<table aria-label="Items">
  <tbody>
    <tr>
      <td>
        <input type="checkbox" aria-labelledby="title-1" />
      </td>
      <td>
        <a href="#" id="title-1">Line item 1</a>
      </td>
      <td>
        <button>...</button>
      </td>
    </tr>
    <tr>
      <td>
        <input type="checkbox" aria-labelledby="title-2" />
      </td>
      <td>
        <a href="#" id="title-2">Line item 2</a>
      </td>
      <td>
        <button>...</button>
      </td>
    </tr>
  </tbody>
</table>

Or, in the case we want keyboard users to be able to navigate through the table with arrow keys, a role="grid" element.

@diegohaz Wow!! That's really helpful!!!

I never thought of that layout like a <table> before (very interesting!).
Would it be appropriate to use non table elements, but use role="grid"?

Would it be appropriate to use non table elements, but use role="grid"?

Yes! That would look like this:

<div role="grid">
  <div role="row">
    <div role="gridcell">
      <input type="checkbox" aria-labelledby="title-1" />
    </div>
    <div role="gridcell">
      <a href="#" id="title-1">Line item 1</a>
    </div>
    <div role="gridcell">
      <button>...</button>
    </div>
  </div>
</div>

If we use role="grid" for that though, we'll have to implement the correct interactions (like the Reakit Grid does).

@diegohaz Hmm! Maybe this particular UI I had in mind doesn't fit a role="grid".
Would you be able to checkout and poke at the rendered example to confirm?

https://material-ui.com/components/lists/#checkbox