False Positives for `a11y-click-events-have-key-events` and `a11y-no-static-element-interactions` with Shoelace `<sl-button>` and Other Components

[gengns]

Describe the bug

Description

The Svelte compiler generates accessibility warnings (a11y-click-events-have-key-events and a11y-no-static-element-interactions) when using the <sl-button> component (and other Shoelace components) from the Shoelace library. These warnings are false positives because <sl-button> is a custom element that extends the native <button> functionality and already includes proper keyboard event handling and interactive semantics internally.

Warnings Observed

1. a11y-click-events-have-key-events:
   "Clicking elements with a click event handler should also have a keydown or keypress event handler."

2. a11y-no-static-element-interactions:
   "Static HTML elements with event handlers require a role."

Expected Behavior

The Svelte compiler should recognize that Shoelace <sl-button> (and other Shoelace components extending native HTML buttons) already handle keyboard events and have appropriate roles or semantics. These warnings should not be triggered.

Actual Behavior

Warnings are displayed for Shoelace <sl-button> components, even though they are accessible by default.

Proposed Solution

The vite-plugin-svelte or Svelte accessibility rules should:

1. Detect custom elements like <sl-button> that extend the native <button> element and suppress these warnings automatically.
2. Alternatively, provide a way to configure the accessibility rules to whitelist certain custom elements (e.g., Shoelace components).

Workaround

Currently, the only way to suppress these warnings is by using svelte-ignore directives:

<!-- Suppress both warnings -->
<!-- svelte-ignore a11y-click-events-have-key-events a11y-no-static-element-interactions -->
<sl-button on:click={handleClick}>Click Me</sl-button>

However, this adds unnecessary boilerplate and clutter to the code for components that are already accessible.

Additional Context

Shoelace components like <sl-button> are designed to follow accessibility best practices out of the box. According to the Shoelace documentation:

• <sl-button> extends the native <button> element.
• Keyboard interactions and appropriate roles are implemented internally.

References

• Shoelace Button Documentation: https://shoelace.style/components/button
• Svelte Accessibility Warning: https://svelte.dev/docs/svelte/compiler-warnings#a11y_click_events_have_key_events
• Svelte Accessibility Warning: https://svelte.dev/docs/svelte/compiler-warnings#a11y_no_static_element_interactions

Reproduction URL

https://github.com/gengns/svelte-shoelace-a11y-issue.git

Reproduction

Steps to Reproduce

1. Install Shoelace in a Svelte project with Vite using vite-plugin-svelte.
2. Add a Shoelace <sl-button> component to a Svelte file with a click event:

   <script>
     function handleClick() {
       console.log('Button clicked');
     }
   </script>
   
   <sl-button on:click={handleClick}>Click Me</sl-button>

3. Run the development server (e.g., vite dev or bun dev).
4. Observe the following warnings in the console or terminal:
   • a11y-click-events-have-key-events
   • a11y-no-static-element-interactions

Logs

❯ bun dev
$ vite --host
Forced re-optimization of dependencies
Port 5173 is in use, trying another one...

  VITE v6.0.11  ready in 503 ms

  ➜  Local:   http://localhost:5174/
  ➜  Network: http://192.168.1.73:5174/
  ➜  press h + enter to show help
1:48:57 pm [vite-plugin-svelte] src/App.svelte:3:0 Visible, non-interactive elements with a click event must be accompanied by a keyboard event handler. Consider whether an interactive element such as `<button type="button">` or `<a>` might be more appropriate
https://svelte.dev/e/a11y_click_events_have_key_events
1:48:57 pm [vite-plugin-svelte] src/App.svelte:3:0 `<sl-button>` with a click handler must have an ARIA role
https://svelte.dev/e/a11y_no_static_element_interactions

System Info

• vite-plugin-svelte version: 5.0.3
• Svelte version: 5.19.0
• Vite version: 6.0.11
• Shoelace version: 2.19.1
• Bun version: 1.1.36
• Operating System: Ubuntu 24.04.1

[dominikg]

you can use compileOptions.warningFilter or onwarn to filter warnings without having to use an ignore comment at every usage site.

It is not feasible for the svelte compiler to know which custom elements might be accessible already or not.

The only possible improvement i see here is to ensure that the tagname of the element with the warning is always part of the warning so that you can more efficiently filter them, but this would have to be filed as an enhancement request in the svelte repo.

[gengns]

That's correct! We can suppress accessibility warnings in vite.config.js using the following configuration:

svelte({
  onwarn(warning, defaultHandler) {
    if (warning.code.startsWith('a11y_')) return; // Suppress all accessibility warnings
    // Handle all other warnings normally
    defaultHandler(warning)
  }
})

However, this approach suppresses all accessibility warnings, which might not be ideal. I really like your suggestion of implementing a more granular filtering mechanism as an enhancement request in the Svelte repository.

Currently, if we hardcode this logic directly into vite.config.js, it could become quite messy. For example, we would need to detect specific web components like <sl-button> and handle their warnings differently. Here's an example of what the warning output looks like:

warning InternalCompileWarning {
  name: 'CompileWarning',
  code: 'a11y_no_static_element_interactions',
  message: '`<sl-button>` with a click handler must have an ARIA role\n' +
    'https://svelte.dev/e/a11y_no_static_element_interactions',
  filename: 'src/components/Button/index.svelte',
  position: [ 93, 235 ],
  start: { line: 9, column: 0, character: 93 },
  end: { line: 14, column: 12, character: 235 },
  frame: ' 7: \n' +
    ' 8: \n' +
    ' 9: <sl-button size="medium" circle={text ? false : true} on:click>\n' +
    '                ^\n' +
    '10:   {#if icon}\n' +
    '11:     <sl-icon name={icon}></sl-icon>'
}
{
  warning: InternalCompileWarning {
    name: 'CompileWarning',
    code: 'a11y_click_events_have_key_events',
    message: 'Visible, non-interactive elements with a click event must be accompanied by a keyboard event handler. Consider whether an interactive element such as `<button type="button">` or `<a>` might be more appropriate\n' +
      'https://svelte.dev/e/a11y_click_events_have_key_events',
    filename: 'src/components/Button/index.svelte',
    position: [ 93, 235 ],
    start: { line: 9, column: 0, character: 93 },
    end: { line: 14, column: 12, character: 235 },
    frame: ' 7: \n' +
      ' 8: \n' +
      ' 9: <sl-button size="medium" circle={text ? false : true} on:click>\n' +
      '                ^\n' +
      '10:   {#if icon}\n' +
      '11:     <sl-icon name={icon}></sl-icon>'
  }
}

As you can see, handling these warnings on a case-by-case basis would require additional logic to identify specific components and their associated warnings. This could quickly become cumbersome and hard to maintain.

I think your idea of introducing a more flexible filtering mechanism in the Svelte compiler would be a great enhancement.

Also, even suppressing all accessibility warnings on the console, we keep having them in IDEs like VSCodium (VSCode), Zed, and so on. This means the false warnings are still visible during development.

[dominikg]

you should add this to svelte.config.js then svelte tooling will use it.

best workaround for now to detect sl- components would be to search for <sl- in the message or check the frame with a regex

[dominikg]

added sveltejs/svelte#15100