[Accessibility] Adds support for an accessible "clear" button

[inkblotty]

Summary

New features

If an element with <input-id>-clear is detected in the autocomplete, clicking that button will:

• clear the associated input
• focus back on the input (a11y)
• announce that the input has been cleared (a11y)

Demo

Screen.Recording.2021-11-12.at.9.56.57.AM.mov

^ The above recording shows the user focusing on the input, typing "bo", selecting the "X" clear button, and their focus being moved back to the input. The screenreader announcement is visible and reads "Input cleared. Suggestions hidden."

cc @github/accessibility

[manuelpuyol]

we can be more strict and use HTMLButtonElement

[inkblotty]

Technically, someone can add the ID to another element like an anchor or a span. 🤔 I would like to keep it this way just in case, but I'm open to other ideas.

[keithamus]

Could we please provide some detail as to what the current limitations are for <input type=search> (which has a clear button, and is arguably more semantically relevant for this type of input) to warrant adding custom clear button behaviour. In addition, can we please make sure <input type=search> also works with the screen reader feedback, which I believe should be a case of adding an eventlistener for search or input and announcing when the contents are empty.

[inkblotty]

Could we please provide some detail as to what the current limitations are for <input type=search> (which has a clear button, and is arguably more semantically relevant for this type of input) to warrant adding custom clear button behaviour. In addition, can we please make sure <input type=search> also works with the screen reader feedback, which I believe should be a case of adding an eventlistener for search or input and announcing when the contents are empty.

While <input type="search" /> does provide an x interaction that refocuses on the input when clicked, this button is not accessible because:

• in most browsers, it's only visible on mouse hover
• there is no way to access this button using the keyboard

In Chrome, for example, this x isn't a button but a div with a pseudo="-webkit-search-cancel-button". It doesn't have a tab index or a way to navigate to it without a mouse.

@keithamus Do you think restricting this input not to use <input type="search" /> could be useful here? I could at least document why it shouldn't be used in the README. WDYT?

[keithamus]

this button is not accessible because...

Thank you for expanding on this.

I could at least document why it shouldn't be used in the README

Yes please.

[inkblotty]

I had a great conversation with @manuelpuyol today about the button-replacement idea and will be updating the implementation to do a more traditional error / prevent rendering instead. Updates coming as soon as I have time :)

[keithamus]

We do not want to be presenting errors to (potentially) the user. I don't think this should be here.

Instead of reporting accessibility violations within the main code here, we might want to add an additional file which can provide custom rules to Axe. Something like axe.ts with the following:

export default [
  {
    id: 'auto-complete-element-clear-button-is-button',
    impact: 'critical',
    selector: 'auto-complete-element [id$="clear"]:not(button)',
    excludeHidden: false,
    metadata: {
      description: "Auto-Complete clear elements must be a "button" element",
      helpUrl: "https://github.com/github/auto-complete-element"
    }
  }
]

We can then load this into the existing devtools we have for GitHub (which includes axe-core) and it can report on these types of violations during development without impacting the user.

[inkblotty]

Let's set up a sync to chat about options for this. I don't want end-users to see errors either, but this package doesn't include Axe, so I'd like to avoid relying on it. It is open source and could be used anywhere. I'll DM you.

[inkblotty]

@manuelpuyol @keithamus This PR will remove the controversial error handling methods, and those will be tackled in a future PR. Preview approach will be:

• provide aXe rules (for if the developer has aXe set up)
• provide ES Lint rules (for if the developer has linting set up)
• provide a custom Validation function (for if the developer has nothing set up)

[keithamus]

LGTM