Svelte: A11y and being a good citizen of the web

[Rich-Harris]

Just a thought I wanted to get down in writing before I forget — something to consider in the near future.

Personal confession: I suck at a11y. I have 20/20 vision, no colour blindness, good hearing, and no disabilities. Because of that I'm bad at remembering to write accessible markup — the non-accessible web seems fine to me.

Svelte could help me with that, because of what it is and how it works. For example it could yell at me if I add an <img> tag and forget the alt attribute, and it could do all that at compile time. I don't think it should be an error, because then it will just get in the way of rapid prototyping and drive people mad, but it would be useful to get a printout of accessibility hints when a component is compiled, for example.

We can help educate developers about a11y and make a strong statement about the kind of web we want to be a part of — I think we should.

[Ryuno-Ki]

Could you add a [Help Wanted]?

I've learned a few bits on a11y (and i18n), so I can give some tipps/resources. Ping me if you're about to learn more (preferably a few days in advance).

[Rich-Harris]

done

[Ryuno-Ki]

IIRC @Rich-Harris is from U.K. In this case the work of Home Office could be a good first high-level entrance (it happens to be on GitHub as well).

Technically those checks come to my mind:

• warn, if user has no type attribute on <button>. (Defaults to type="submit", which isn't what the author intended in most cases)
• error, if <img> has no alt attribute (it can be set to an empty string, but must be present)
• error, if <a> has no href attribute (there was some SEO related buzz around this recently).

About the <a> I think it is debatable. I see many awful code with it. Personally I'd like to ban javascript:void 0 calls on it as well. The javascript protocol is used for Bookmarklets, so shouldn't error in general.

There are some automated A11Y testing tools out there already, but you can't rely on them alone. Does Svelte offer a way for those tool to take part in the compilation process to run their checks?

[Rayraegah]

We could inherit a lot of the features these linters and tools provide, most of them list validation rules.

Linters:
https://github.com/evcohen/eslint-plugin-jsx-a11y

Testing tools:
https://github.com/GoogleChrome/accessibility-developer-tools

On web components (all about being able to navigate web component via keyboard. useful into for the svelete custom element plugin)
https://www.webcomponents.org/community/presentations/making-polymer-elements-accessible

On vdom:
https://facebook.github.io/react/docs/accessibility.html

[morewry]

The first thing that comes to mind for me is interactive functionality on elements that aren't interactive by default and where the author hasn't done anything to make it accessible with ARIA etc. For example, if there is a div with an on:click that doesn't have a role="button" tabindex="0" or other equivalent attention paid to its accessibility.

[Rich-Harris]

Thanks for all the really helpful pointers everyone. The best plan of action seems to be to implement versions of the checks in https://github.com/evcohen/eslint-plugin-jsx-a11y (thanks @Rayraegah) — I made a solid start in #815 and have opened #820 for all the rest, so I'll close this.