Allow list-item action slots to have an independent disabled state form the list-item

[ethanbdev]

Description

The use case is that a list item (GP tool) is disabled, but we want to show an information icon that the user can interact with either on hover / click to give help to the user on why this item (GP tool) is disabled. This would occur when the licensing is not sufficient to use the tool and we need to direct them to information on getting the license / seeing more information about the licensing level.

Right now, the actions inherit the disabled state from the list-item, so there is no way to provide user interaction on those actions.

Blocked issues: #8373

Acceptance Criteria

The scope of the issue would be the list-item respecting the disabled attribute on itself and any slotted actions independently.

Relevant Info

Which Component

calcite-list-item

Example Use Case

https://codepen.io/eborgen/pen/WNyvagJ

Esri team

ArcGIS Map Viewer

[driskull]

@jcfranco @benelan @eriklharper What are your thoughts about how disabling could work here?

• Would we introduce another property to disable only the content of a list item?
  • content-disabled?
  • Would we introduce a mode? `disableMode="content"; // probably not its ugly.
• Would we update disabled to not affect slotted actions? If so, a user would have to disable them separately.
  • If we do this, we would need to update the interaction helper to not set pointer-events for the whole component.

Other ideas?

[benelan]

@geospatialem any a11y concerns with a disabled component having non-disabled child(ren)?

[geospatialem]

@geospatialem any a11y concerns with a disabled component having non-disabled child(ren)?

@benelan This sounds like a very solid use case. From the a11y perspective, its not a known or expected pattern, so would need to consult with a few other a11y professionals to determine the best path forward on the enhancement. Can report back here in a few weeks once a few of us can convene together.

[driskull]

Yeah if we disable the component it will get aria-disabled on the host. I'm not sure if that will affect slotted children or not.

[nattarnoff]

Disabled is not a valid attribute on the <li>. What needs to happen here is the disabled attribute needs to be applied to the button. It is also preferred to use this attribute over the aria-disabled attribute.
<li>
<button disabled><span>ICON</span> TITLE</button>
<button class="tooltip" aria-label="NAME">icon</button><button class="tooltip" aria-label="NAME">icon</button>
</li>

This will allow you to disabled the control but allow the tooltips and other icon buttons to still be accessible.

[karl9006]

@driskull @geospatialem Please refer to Nat's response above.

[driskull]

@nattarnoff I'm not following your comment. I don't see a disabled attribute added to any li within the calcite-list-item. There is no <li> used internally on that component.

[driskull]

Since the "content" button is internal to the component and not slotted, we would need to be able to disable via a prop or something like that if we want to support this without breaking changes.

[nattarnoff]

@driskull as the calcite-list-item has role="listitem" on it, it IS a lias far as the browser and assistive technology are concerned. Therefore, you cannot put disabled or aria-disabled on it. Those should be located on the items inside the listitem.

[driskull]

@nattarnoff

Therefore, you cannot put disabled or aria-disabled on it. Those should be located on the items inside the listitem.

Its also a custom element, so we can put disabled on it because we define that attribute as a custom attribute. disabled is not a global reserved attribute so we can use that name for the custom component calcite-list-item.

As for the aria-disabled. We do this for all of our components we we add our disabled attribute on them. cc @jcfranco
If we need to change that part, we can. From what I understand, we can add aria-disabled to any custom element regardless of the role. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled

Another reason to need use the aria-disabled attribute over the HTML disabled attribute is if you have created custom controls which need to be marked as disabled, but are not using an element that allows for the disabled attribute.

[nattarnoff]

@driskull I went through the Codepen at the top of the description. The problem with how it is written now is that the second icon in the first calcite-list-item isn't tabbable despite being a button and having aria-disabled="false". If you navigate by arrows, you find that it announces as a button, but is unavailable.

From the first description paragraph of the linked MDN article (emphasis mine):

The aria-disabled attribute, when set to true, indicates that the element upon which it is set and all of its focusable descendants are meant to be in the disabled state. This declaration will inform people using assistive technologies, such as screen readers, that such elements are not meant to be editable or otherwise operable.

Aria-disabled cascades. Once set, the children cannot be unset. Putting these attributes on the container and not the controls causes problems. I've put together a sample using a basic UL to demonstrate: https://codepen.io/nattarnoff/pen/dyeVgdV?editors=1111

You still need to move the attributes from the parent (rendered LI) to the rendered controls (button). This is what the AT is concerned about regardless if the control is built using a JS framework like Calcite or native HTML.

[driskull]

I went through the Codepen at the top of the description. The problem with how it is written now is that the second icon in the first calcite-list-item isn't tabbable despite being a button and having aria-disabled="false". If you navigate by arrows, you find that it announces as a button, but is unavailable.

Yes, it's working as designed right now. If a component is disabled, all things inside it are disabled as well. I think we would need to engineer a way to disable only specific parts of the component. If we need to rethink how this is engineered, we can do that.

You still need to move the attributes from the parent (rendered LI) to the rendered controls (button). This is what the AT is concerned about regardless if the control is built using a JS framework like Calcite or native HTML.

I think it's up to the user to disable anything they slot into the component. Since they can slot custom components like calcite-action, we don't know all the things that may need to be disabled. In this case, the user would need to set disabled on the calcite-action as well. We could try to query for known slotted components and disable them but I'd prefer to not modify the light DOM in these cases.

[nwhittaker]

The Field Maps web app is looking to use the list component for listing and selecting layers. In some cases a layer is not selectable, but we still want to be able to perform actions on it (e.g. "Delete"), or show accessible error iconography w/ tooltips.

[jcfranco]

@ethanbdev, @nwhittaker Could you provide info on priority/impact for this?

[nwhittaker]

Could you provide info on priority/impact for this?

This issue is one of several that are blocking an effort in Field Maps Designer to refactor the list of layers and group-layers as a <calcite-list>:

• List: Allow collapsing of item groups #6537
• List: allow clicking on group names to expand/collapse  #6546
• Child list-items do not appear in filter results #6574
• [List / List items] Support custom filtering supporting a filter function with a prop #6544

Our current implementation is a combination of custom components and <calcite-tree> elements. We'd like to migrate to the <calcite-list> element because it provides built-in filtering, more action/content slots, and grouping/nesting. The impact of moving to this element is that it would hopefully streamline the code and improve the consistency, maintainability, and testability of our layers list UI.

For prioritization, our refactoring issue is beginning to block other issues (that would like to make use of the list-item slots) that are slated for the Summer release (6/27). I imagine we have some flexibility, though, if that date's not feasible.

[ethanbdev]

For web analysis, its blocking a design to communicate licensing information to users.

I would put p3 - want for upcoming milestone if @nwhittaker agrees or wants to put it higher

[geospatialem]

Thanks all for the great discussions and insights to use cases.

Calcite is proceeding with the above request on list-item via a new boolean property, unavailable, anticipated implementation of Q4 2024 (25.R1).

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified with Chromatic build with list-item's new unavailable attr/prop: