【Biome】Web Accessibilityへの取り組み方として、OSSコントリビュートという選択

2024年9月14日 02:55

こんにちは、Webエンジニアをしている江端です。普段はTypeScriptを書いています。

先日、アクセシビリティカンファレンス名古屋というイベントにオフラインで参加しました。
アクセシビリティのオフラインイベントには初めて参加したのですが、とても刺激を受け、そこで自分なりのアクセシビリティへの取り組み方が言語化されました。
その言語化されたものを、このnoteに書いていきます。

自分の、アクセシビリティへの取り組みが色々と言語化された2日間だった。
どこかで何かに書く、Qiitaかnote
— EbaRyo (@ebaryo43) September 7, 2024

結論: Biomeにa11yのLint Ruleをコミットする

結論から書くと、Biomeという Rust製のLinter/Formatterツールがありまして、そこにa11yのLint Ruleをコミットしていこうと考えています。

他のLinterでは、ESlintなどが多くのシェアを占めていますが、次世代のLinterとして非常に注目されているのがBiomeです。

TS Kaigiでコアコントリビューターのunvalleyさんが Biomeの発表をされてから、一気に注目が集まりました。
このツールの最大の強みは「速さ・軽さ」にありますが、今回はそこには触れません。

この次世代のLintツールに豊富なa11yのLint Ruleが実装されてこそ、意味があるのだと考えました。

アクセシビリティの重要性は日に日に高まってきています。
ただ、デザイン・開発段階で網羅するのは難しく、QAエンジニアによる確認作業まで行ってから、アクセシビリティの指摘が入り手戻るケースは多いようです。

これによってDeliveryに影響が出てしまうと、営利企業にとってアクセシビリティは「コストのかかる対応」という認識になってしまいます。

これを解決するためには、もっとアクセシビリティをシフトレフトさせ、デザインや開発段階で網羅しやすくなるような動きが大切になってきます。

Linterツールは、コーディングの最中でも警告を出してくれるため、開発時にa11yを網羅しやすくなるツールだと言えるでしょう。

実はこの考えが言語化される前から、自分はBiomeにいくつかコミットをしています。

Biomeの1周年アニバーサリーリリースに含まれているもので言うと以下です。

これはHTML要素が持つRoleに対して、無効なaria-*属性が付与された際に警告を出すルールです。

<!-- 警告が出る例 -->
<input type="text" aria-checked>

このようなルールを、BiomeはBiome自体に導入する意思があります。

比較対象としてESlintを挙げますが、ESlintでこのルールを扱う際には、eslint-plugin-jsx-a11yというプラグインを別途用意する必要があります。

つまり、

というステップが必要になります。
アクセシビリティという領域を知らない開発現場では、そもそもこのプラグインまで辿り着かないのです。

その点Biomeは、導入理由が速さであれ、軽さであれ、プロダクトに採用されればa11yルールが入った状態になります。
recommended(Biomeの初期設定)にa11yルールが入っていればデフォルトでlintされます。

ちなみに先ほど紹介したuseAriaPropsSupportedByRoleというa11yの Lint Ruleは、デフォルトで効きます。

ただ、Biomeを入れたら全てアクセシブルになる、というのは不可能です。

BiomeはJSXなどをParseして、静的解析を施すツールであり、ブラウザで表示される視覚情報には関与できません。
例えば、点滅する動画はもちろん、コントラスト比などを確認することも難しいです。

これらに関しては、他のツールで確認するなど、Biomeではない方法をとる必要があります。
詳しい紹介は省かせていただきますが、例えばAccessibility Visualizerやaxe-dev-tooltipなどが挙げられます。

しかし先ほど説明した通り、アクセシビリティを知っていなければこれらのツールには辿り着けません。
なので、開発者に向けた啓蒙などはやっていく必要があります。

自分にはまだ発信力はありませんが、微力ながらDiscordコミュニティやカンファレンスへの積極的な参加をし、少しでもアクセシビリティを広げる活動を続けていきたいと思います。

ここまで読んでいただき、ありがとうございました。