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

[maciekgrzybek]

Hello, is this still a valid ticket?

[antony]

@maciekgrzybek it is still open with incomplete items, so yeah. It's being slowly fixed as people open PRs

[avimar]

I'm curious, is there a reason this is integrated into the compiler, rather than being it's own project or e.g. inside eslint? Perhaps you need a plugin, e.g. https://github.com/jsx-eslint/eslint-plugin-jsx-a11y that's referenced to convert the language to be accessible to eslint.

It would seem to be useful as a separate project for non-svelte users, too.

Or is the goal to be an "ethical programmer" and while people are opting into svelte, let's nudge them to make the web a little bit better, without requiring them to set it up?

[antony]

@avimar Svelte aims to treat a11y as a first-class citizen, which is the way the web should be.

It is felt that accessibility shouldn't be a side-concern of web development, which people can opt-out of.

[avimar]

One of the things that modern form often break is using "enter" to submit the form, on the last element.
Is that an a11y concern? It seems to require wrapping the input elements in a form tag and having a <submit> or <button type="submit">.

(Just make sure to do a on:click|preventDefault if you have your form function set up in the on:click handler...)

[tborychowski]

How do I set/change these rules in my .eslintrc file?
e.g. the copied jsx plugin allows me to do this:

"rules": {
    "jsx-a11y/no-noninteractive-tabindex": "error"
}

So far I tried:

"rules": {
    "svelte-a11y/no-noninteractive-tabindex": "error",
    "svelte3-a11y/no-noninteractive-tabindex": "error",
    "jsx-a11y/no-noninteractive-tabindex": "error",
    "a11y/no-noninteractive-tabindex": "error",
    "no-noninteractive-tabindex": "error",
    "a11y-no-noninteractive-tabindex": "error"
}

but eslint throws errors that it doesn't understand either one of these.

[dummdidumm]

At long last all checkboxes have been checked! Thanks everyone who participated in implementing these rules 🎉