あなたの推しコンパイラは？私はSvelteです
この記事はyamanoku Advent Calendar 2023の7日目の記事になります。
こんにちは。私の推しコンパイラはSvelteです。というわけで今日はコンパイラ視点でのSvelteの好きな部分の話をしていきます。
Accessibility warningsというアクセシビリティチェック機能
Svelteはコンパイル時にアクセシビリティに関する誤った記法があった際に警告を出してくれます。この機能こそが私がSvelteをコンパイラとして最も推せる理由です。
たとえばSvelteのコード内で<img>要素にalt属性がないものを書いてみましょう。
<img
src="https://i.gyazo.com/809a6f523937838d9ba5eaf20717feee.png"
width="320"
/>
するとalt属性を付けるように警告を出してくれます。これは「a11y-missing-attribute」というルールによるものです。
A11y: <img> element should have an alt attribute
これがESLintのプラグインとしてではなく標準のチェッカーとして設定されていることが非常に心強く感じました。
もちろん、実装上どうしてもルールを無視せざるを得ない場合もあります。もし警告を出したくない場合は<!-- svelte-ignore a11y-<code> -->というコメントを記述することで無視することができます。
<!-- svelte-ignore a11y-autofocus -->
<input autofocus />
アクセシビリティにまつわるルールは12月7日現在で28個のルールがあり、それらの詳細はドキュメントにまとまっています。
Svelte Summit Fall 2023の「Accessibility tips with Svelte solutions」で現時点のSvelteのアクセシビリティに関するルールについてEnrico Sacchettiが説明してくれています1。ざっくりと理解する上でも良い発表内容になっておりますので是非ご覧になってみてください。
Svelteを書きつつアクセシビリティを守れるようにしたい
ところでSvelteのコンパイラにこうした機能が導入されてるのは何故なのでしょうか。それはSvelteの作者であるRich Harrisが過去書いた「A11y and being a good citizen of the web」というIssueを見るとその意図が分かります。
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 thealtattribute, 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.
A11y and being a good citizen of the web · Issue #374 · sveltejs/svelte
Rich Harrisはアクセシビリティについては苦手意識をもっており、自身も障害は特になくアクセシビリティを意識したマークアップが苦手であると告白しています。Svelteにて<img>にalt属性を入れるようにアクセシビリティにまつわる指摘を導入することで、開発者自身がそのヒントを元にアクセシビリティを意識し、Webの良き市民となれるようにしたい、といったことが書かれています。
この内容が作者により示されていたことに、当時Svelteを知りたてだった頃の私は非常に感銘を受けました（アクセシビリティに関心があったからもありますが）。
余談ですが今年の4月にあった発表🌶️ IMHO 🌶️ - Rich Harris on frameworks, the web, and the edge.についてもほぼ同意できる内容でとても良かったです。最近はSvelteそのものよりもRich Harris自身のほうが好きになってきています。
コミュニティ内からは微妙な反応が…
いやぁSvelteは作者も含めて素晴らしいなぁ！ということで綺麗にこの話を終えたいと思っていたのですが、コミュニティ内からはこの部分について微妙な反応があることも知りました。この記事がSvelteコンパイラのアゲ記事だけにならないためにも、それらについても取り上げてみようと思います。
How can we disable svelte warnings? (a11y, etc) · Issue #650 · sveltejs/language-tools
1つめのIssueではVSCodeのSvelte拡張機能にてアクセシビリティやそれらにまつわる警告を無視する方法はないのか、という内容が議論がされています。VSCodeの設定を上書きしてsvelte.config.jsの設定を変更することで無視することができることが示されていますが、不満を持っている人も多いのかアクセシビリティに対して強めの発言をされているのが気になります。
Move a11y check to the eslint plugin · Issue #9485 · sveltejs/svelte
2つめのIssueではESLintプラグインとしてアクセシビリティに関するチェッカーを移行することについて議論がされ始めています。アクセシビリティのチェックはすでにESLintのプラグインとしていくつか実装されており、ESLintコミュニティの恩恵を得ることで車輪の再開発をする必要はないのではないか、という意見が出ています。
現在は非推奨となっているeslint-plugin-svelte3というESLintプラグインではsvelte3/compiler-optionsやsvelte3/ignore-warningsというルールでLinterの警告やコンパイル時の警告を無視することができました。それを現行のプラグインであるeslint-plugin-svelteにて同様の機能を実装できないか、という話もされています2。
コンパイラによるアクセシビリティチェックの難しさ
アクセシビリティやWebの力を強く信じている私ですが、こういった意見ややり取りをみると寂しい気持ちになる反面、コンパイラの都合に対してもどかしく思うのは分からなくはないという気持ちの両方があります。
私はかつてSvelteのアクセシビリティルールについて提案をしてみたことがあります。
svelte-checkにおける「a11y-label-has-associated-control」というルールは<label>要素がfor属性を持っているかどうかをチェックしてくれます。しかしfor=""でもバリデーションチェックは通ってしまいます。なぜならfor属性を持つかどうかだけをチェックしているだけだからです。
<input type="checkbox" value="hoge" />
<label for="">hoge</label> <!-- この状態でも問題ない判定 -->
この状態ではコンパイラとしては問題ないがフォームコントロールのアクセシビリティが確保できていないので精度としては微妙だと思いました。
そこで対応するコントロールのid属性とラベルのfor属性が一致すれば問題ないようなバリデーションはできないか提案しました。
しかしこの提案に対して「コンパイラとしてその判定をもつのは難しい」「誤検知につながりかねない」といった意見が出てきました。代わりにコンパイラ側ではなくaxe DevToolsといったツールでページ全体でそのチェックをすべきではないか、という意見も出てきてこの提案はクローズされました。
私自身、Svelteのコンパイラ開発に携わってないため、このような判定を作ることがいかに難しいのかどうかは正直わかっておりません。それと同時に機械的なものだけでアクセシビリティチェックをすることの限界についても理解しているつもりです。Svelteのコンパイラだけに頼るのではなく、実際にユーザーテストをするなど様々な観点でアクセシビリティをチェックできるようにすることが重要です。
おわりに
私が推しコンパイラとしてSvelteを選ぶ理由の1つにアクセシビリティに関するチェック機能があることを書きました。この機能がある事は私はとても良いことだと思ってはいますが、チェックが完全なものとして機能できていないことも分かっています。
今後もまたいくつかアクセシビリティにまつわるルールは出てくるかもしれません。その度にルールを設定でignoreするのではなく、コンパイラとしてなぜこのルールが今必要になるのか、それはどういう問題があるからなのかといった、コミュニティ内でアクセシビリティにまつわる部分を話し合っていくことが重要だと感じています。
Svelteは私にとって好きなOSSの1つです。今後もSvelteの動向を見守りつつ、Svelteにおけるアクセシビリティにまつわる議論が進んでいくことを願っています。