a11y: triggering element cannot contain interactive elements

[blackfalcon]

Please verify the version of auro-dropdown you have installed

@latest

Please describe the bug

See code

auro-dropdown/src/auro-dropdown.js

Lines 473 to 491 in 57c991b

	<div
	id="trigger"
	class="trigger"
	part="trigger"
	role="button"
	aria-labelledby="triggerLabel"
	aria-controls="popover"
	data-trigger-placement="${this.placement}"
	tabindex="${this.tabIndex}">
	<div class="triggerContentWrapper">
	<label class="label" id="triggerLabel">
	<slot name="label"></slot>
	</label>
	<div class="triggerContent" chevron=${this.chevron}>
	<slot
	name="trigger"
	@slotchange="${this.handleTriggerTabIndex()}"></slot>
	</div>
	</div>

In the current implementation of the dropdown UI, the div container has [role="button"] effectively redefining the div to be a <button> element. This is problematic because the content in the trigger slot can be any HTML, including interactive elements like input, button, or select. See the DOM output of the auro-combobox element.

In any scenario where there is an interactive element placed within the scope of any element *[role="button"] is similar to adding interactive content within a <button> element and would be considered non-compliant.

• Both <button> and <input> are interactive elements with distinct behaviors
• A <button> is not intended to contain focusable, interactive elements like <input>. Nesting breaks the semantic meaning of the <button>, confusing assistive technologies and users.
• Screen readers may announce the <button> as "button," but they won't know how to handle the nested <input>.

Reproducing the error

This issue is reproducible on the Auro docsite

Recommendation

The root cause of the issue lies in the fact that auro-dropdown, appropriately so, attempts to manage the accessibility state of the popup content. However, in a scenario where the triggering element of the UI is interactive, the responsibility for managing this state should be delegated to the child element. In this instance, auro-input.

An update to auro-dropdown would be to consider the following:

1. Update the element so that role="button" is optional allowing the consumer some control over the interactive state of the trigger element.
2. Move all accessibility attributes, including role="button" to the name="trigger" slot element (see example)

Moving the accessibility attributes like aria-expanded to the <slot name="trigger"> where the <input> resides, and making role="button" optional, would simplify the structure and improve semantic clarity. Removing role="button" is only applicable provided that the <input> (or the slotted content) becomes the actual trigger element.

Example

  <div class="triggerContentWrapper">
    <label class="label" id="triggerLabel">
      <slot name="label"></slot>
    </label>
    <div class="triggerContent" chevron=${this.chevron}>
      <!-- Accessibility attributes moved here -->
      <slot
        name="trigger"
        aria-labelledby="triggerLabel"
        aria-controls="popover"
        aria-expanded="${this.expanded ? 'true' : 'false'}"
        @slotchange="${this.handleTriggerTabIndex()}">
      </slot>
    </div>

What browsers are you seeing the problem on?

Firefox, Chrome, Safari, Microsoft Edge

Additional context

This issue is related to an accessibility finding: https://alaskaair.hub.essentia11y.com/projects/6759ec2bc0afd4c33f103b81/tasks/6765ecf582f50344673fac0a?linkedPropertyData=652813da6eec28e13de119c4%7C652813da6eec28ef1ee119bd

Exit criteria

This issue can be closed one the updated auro-dropdown ensures proper accessibility and semantic integrity by dynamically delegating responsibility for interactive behaviors and accessibility states to the appropriate element. It should:

1. Avoid conflicts or non-compliance by preventing interactive elements from being nested within elements with role="button".
2. Allow the trigger slot content to manage its own accessibility states when it is an inherently interactive element (e.g., <input> or <button>).
3. Maintain full keyboard and screen reader compatibility, ensuring all interactions are intuitive and accessible across various scenarios.
4. Provide a flexible implementation that adapts to different use cases while offering clear guidance for consumers.
5. Be validated through thorough testing and updated documentation to confirm compliance and usability.

[blackfalcon]

Please include @blackfalcon in the code review process to evaluate the accessibility fix.

[blackfalcon]

The severity of the issue was updated to CRITICAL due to an active complaint from the DOT regarding accessibility in UIs supported by this element.

See ADO story for additional details https://itsals.visualstudio.com/E_Sell_Shop/_workitems/edit/1144649