Remaining a11y checks

[Rich-Harris]

#815 added a bunch of these, but there are still some checks from eslint-plugin-jsx-a11y that aren't implemented yet:

• accessible-emoji rule is deprecated and shouldn't be implemented
• alt-text
• anchor-has-content
• anchor-is-valid
• aria-activedescendant-has-tabindex
• aria-props
• aria-proptypes
• aria-role
• aria-unsupported-elements
• autocomplete-valid rule is [deprecated] and shouldn't be implemented
• click-events-have-key-events
• heading-has-content
• html-has-lang
• iframe-has-title
• img-redundant-alt
• interactive-supports-focus
• label-has-associated-control
• media-has-caption
• mouse-events-have-key-events
• no-access-key
• no-autofocus
• no-distracting-elements
• no-interactive-element-to-noninteractive-role
• no-noninteractive-element-interactions
• no-noninteractive-element-to-interactive-role
• no-noninteractive-tabindex
• no-onchange
• no-redundant-roles
• no-static-element-interactions
• role-has-required-aria-props
• role-supports-aria-props
• scope
• tabindex-no-positive

[arxpoetica]

How do I—ahem—turn this off? I think you were right to say it shouldn't yell at someone like an error in your original post on this, but it sure is yelling at me a lot. :) This is definitely a helpful tool for accessible coding, but, like you said, can we have a flag or something to turn this off 100% for prototyping, etc.?

[Conduitry]

@arxpoetica For now, you can use a custom onwarn handler to filter out a11y-related warnings, with something like this:

{
...
onwarn(warning, onwarn) {
  if (!/A11y:/.test(warning.message)) {
    onwarn(warning);
  }
},
...
}

You can use other checks on the warning message if you want to only disregard certain a11y warnings. On the roadmap is a further feature to help provide a way to filter warnings by their type without searching for strings in their human-readable message field.

[taylorzane]

Not sure if this is the right place to make this comment, but I just encountered an interesting "bug" of the a11y implementation. I have a component that uses scope as the prop name, and I get a warning that The scope attribute should only be used with <th> elements. I feel that a11y should be disabled on component definitions. Here's the full error (including code)

src/Components/Foo/index.html (20:71) A11y: The scope attribute should only be used with <th> elements
18:   <div id="foo-id">
19:     <div class="foo-class">
20:       <Child scope="local"></Child>
                 ^
21:     </div>
22:   </div>

I can create a separate issue if you'd like.

[arxpoetica]

@taylorzane let's put it in a separate issue. This brings up the larger question on whether component variables are restricted to any given namespace not in use by the DOM in general? @Rich-Harris Is that documented somewhere?

[taylorzane]

@arxpoetica Fine by me, see: #1110

[Conduitry]

I don't think there is any issue with collisions between component parameters and existing DOM attributes. The only constraint I know of that we should be enforcing is that in #887. Svelte knows which elements are true elements and which are components (and can determine this at compile time) - it's just not taking that into account during a11y validation - which can be addressed in #1110.

[Rich-Harris]

Was pointed to this set of checks as well, which may contain some additional stuff we can implement https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md