wcag

WCAG 2.3の話とかあるんだ > This is a proposed WCAG 2.3 change [...] wcag#5432

WCAG2.3ってまだやる可能性は残ってるんだ wcag#5432

disabled を aria-disabled に変えたら、別のWCAG基準が効き始めた ! 2作目のポートフォリオとして「Hubpin」（分散した発信を1か所に集めるハブサイト）を作りながら書いています。 リポジトリ: Matsutake29/hubpin Next.js（App Router） + Supabase + Tailwind CSS カードを並び替えるボタンで、こういう不具合がありました。 押した後にフォーカスが消える。 キーボードで操作している人は、ここで現在地を失います。 矢印ボタンを連打して並べ替えたいのに、1回押すたびにページの先頭へ戻される形でした。 切り分けで、仮説が1つ消えた 最初は「Server Action の再レンダリングで DOM ごと作り直されているのでは」と考えていました。 キーボードで一通り試したら、違いました。 消えるのは、移動先が1番目のときだけでした。 3番目から2番目へ動かしたときはフォーカスが残っています。 1番目のカードは、上へ動かせないので「上へ」ボタンを disabled にしていました。 つまり 押したボタンが、押した直後に disabled になる。 disabled な要素はフォーカスを保持できません。 これは HTML の仕様で決まっていることで、ブラウザの挙動の差ではありませんでした。 aria-disabled に変えた。ここまでは定石 WAI-ARIA の推奨どおり、disabled 属性をやめて aria-disabled="true" にしました。 aria-disabled は「無効だ」と支援技術に伝えるだけで、要素自体は生きています。 フォーカスは保持され、スクリーンリーダーは「無効」と読み上げます。 押せないボタンがそこにあること自体は伝わる、という考え方です。 ここまでは検索すれば出てくる話です。 詰まったのはこの後でした。 装飾をそのまま移せなかった 無効なボタンは disabled:opacity-40 で薄くしていました。 これを aria-disabled の側にそのまま移そうとして、手が止まりました。 WCAG 2.2 の達成基準 1.4.11（非テキストのコントラスト）は、UI 部品の見た目に 3:1 を求めます。 ただし例外があって、操作できない部品は対象外になります。 opacity-40 で薄くしていたのは、この例外に入っている前提でした。 aria-disabled にすると、その前提が揺らぎます。 要素は生きていて、フォーカスも当たり、DOM 上は操作できる状態のままだからです。 ここは W3C でも決着していなかった 調べてもらったところ、この点は仕様として決まっていませんでした。 1.4.11 の Understanding 文書が例外として挙げているのは、HTML の disabled 属性が付いた部品です。 aria-disabled が同じ扱いになるかは書かれていません。 W3C の議論（discussions#3502・issues#869）でも、 disabled 属性 → 確実に例外の対象 aria-disabled="true" → セマンティックには無効だが、要素はフォーカス可能で、機能を止めるのは開発者の仕事。例外の定義に完全には当てはまらない可能性がある という形で分かれたままになっています。 だから「aria-disabled は例外に入らない」とは書けません。 書けるのは、寄りかかる根拠が弱くなったということだけです。 判断としては、寄りかからないほうを選びました。 透明度を下げるのをやめて、色そのものを落として 3:1 を満たす形にしています。 弱く見えることは変わらず、基準は満たす。 グレーゾーンを避けるほうが、後から説明しやすいと思いました。 トレードオフが1つ増えた aria-disabled にしたことで、無効なボタンにも Tab が止まるようになりました。 disabled のときはスキップされていた場所です。 WAI-ARIA がこれを推奨しているのは「押せないボタンがそこにあると分かるように」という理由なので、意図どおりではあります。 ただ、押せないボタンを何度も通過することにはなるので、手数は増えます。 カードが10枚あれば、無効なボタンは上下の端に2つです。 この数なら許容できると判断しましたが、無効な要素が大量に並ぶ画面なら別の答えになると思います。 送信を止める手当ては要らなかった aria-disabled は見た目と支援技術への通知を変えるだけで、クリックを止めません。 だから普通は、押されたときに処理しない手当てを別途書く必要があります。 今回は要りませんでした。 Server Action 側が、先頭のカードを上へ動かす要求を最初の行で弾いていたからです。 // 端のカードは動かせない。ボタンを無効にしていても、Server Action は直接叩ける if (index === 0) return これは「ボタンを無効にしてもサーバーは直接叩ける」前提で書いてあったものでした。 ボタンの見た目を変える話とは別に、入口の側で先に守ってあったことになります。 直す、で終わりではなかった この工程で分かったのは、アクセシビリティの修正が別のアクセシビリティ基準を呼び込むことがある、ということでした。 フォーカスの問題を直したら、コントラストの基準が顔を出す。 そのコントラストの基準は、例外の適用範囲が決まっていない領域だった。 1つ直すと1つ増えるので、どこで止めるかを自分で決める必要がありました。 止め方としては「仕様で決まっていないところには寄りかからない」を選んでいます。 基準を満たす側に倒しておけば、あとで解釈が固まっても作り直しになりません。 opacity を1行変えるだけの話なので、ここは安いほうを選べました。

Wake up babe, new WCAG nugget: wcag#3029 I’ve updated my “Under-Engineered Responsive Tables” post already (because of the 4.1.2 thing where I tell readers to assign a role): adrianroselli.com #WCAG #HTML #accessibility #a11y