ビルド時のアクセシビリティlint導入の検討

[magi1125]

改善詳細 / Details of Improvement

• アクセシビリティ試験を行い、レベルAA準拠となったため、この状況を今後も維持したい
• 現在は 機械的アクセシビリティテストの組み込み #500 によりvue-axeが動いているが、あくまでコンソールにチェック結果が出る形に留まっている
  • なお、 yarn dev でローカルサーバーをブラウザで表示できるまでにとても時間がかかる #3177 によりチェックには一部調整が入っている

期待する見せ方・挙動 / Expected behavior

• eslint-plugin-vuejs-accessibility を導入するなど、CI時点でlintを行い、不適切な実装が合った場合は修正後のコミットを求める形はどうか。
• 現在の実装として実施可能な状況か、また実行した場合のリスクなどを踏まえて議論したい。

[yamanoku]

静的HTML生成結果においてAccesslintを導入するとかできたらいいかもしれません。
実際にうまく機能できるかはわからぬのでアイデアとして。

[yamanoku]

プルリクエスト作成時に eslint-plugin-vuejs-accessibility が走って違反していた場合マージできないという仕組みがあるのはいいかもですね。

ただ eslint でのアクセシビリティチェックについては「コンポーネント単位」で違反していないかを見るに留める温度感で運用したほうがいいかなと。ページ全体のチェックはそれで補うには力不足なので。

[yamanoku]

現在のルールをみるに必要そうなのは以下かなぁと思っています。

ルール	おおまかな内容
alt-text	代替の内容が必要な際にalt、aria-labelなどがあるかのチェック
aria-props	定義されていないaria属性（タイポ含む）をチェック
aria-role	存在しないもの、abstractなroleの使用をチェック
aria-unsupported-elements	aria属性を使用できないタグで使用していないかチェック
form-control-has-label	フォームコントロールに対してラベルが必ず付与されているかチェック
heading-has-content	見出しタグや見出しコンポーネントに対して内容が含まれているかチェック
no-redundant-roles	タグに重複したroleを付与していないかチェック
role-has-required-aria-props	roleの使用において必要になるaria属性があるかチェック
tabindex-no-positive	tabindexに0以上の数値が入っていないかチェック

インタラクティブコンテンツのためのルールチェックもあるのですが、UIの振る舞いについてどこまで定義しているか分からなかったのでここでは含まないようにしてみてます。

[kaizumaki]

@yamanoku さん、フォローありがとうございます！

静的HTML生成結果においてAccesslintを導入するとかできたらいいかもしれません。

見た感じ、すごくよさそうですね。ただ細かな設定というのはできないのでしょうかね。
であれば、 eslint-plugin-vuejs-accessibility を運用した方がいいかもしれません。

[kaizumaki]

あ、そうか、Accesslint は静的html生成結果においてでしか意味をなさないのですね。

[yamanoku]

あ、そうか、Accesslint は静的html生成結果においてでしか意味をなさないのですね。

ですです。なのでそのビルドフローがあれば導入してみてもいいかなという感じですね。

[kaizumaki]

@yamanoku ありがとうございます！
ではyamanokuさんがリストアップしていただいたルールをもとに、 eslint-plugin-vuejs-accessibility を導入してみましょうか。

[Da-1kun]

@magi1125 @yamanoku @kaizumaki
PR作成しましたのでご確認いただきたいです！

[kaizumaki]

@Da-1kun おお、ありがとうございます！助かります！ 🙏