アクセシブルなフロントエンド開発のこれまでとこれから
https://gyazo.com/ed63f64bc8865a476c009b73a76384d3 https://jsconf.jp/2021/talk/the-past-and-future-of-accessible-front-end-development
さらなる体験の強化
参加者を増やしていく
これまでの対応
代替テキストの挿入
機械が翻訳・理解できるようにする
「状態表現」をもたないパーツ
アプリケーションは変化するものを迎合する
アクセシブルではないものもある
input type="number"
確認方法
これからの対応
クライアントサイドの状態管理を伝える
バリデーション対応
aria-invaild対応
aria-live 対応
LiveAnnouncer
キーボードショートカット
キーボード・インタフェースに依存する全てのデバイスが、キーボード・ショートカットをサポートできるわけではありません。
ショートカットに割り当てるキーを選択するときは、考慮すべき要件が非常にたくさんあります。
ID と aria-describedby で紐付けするなど、のやつ
コンポーネント内と紐づくIDが一意である保証はないので、対応できない
こういうものは Axe を通じて全体チェックするのが良い インタラクションにこだわる
Details部分は見えてはならない
これから期待するアプローチの紹介
UIとしての意味づけ
見た目
レンダリング結果に影響されるものがある
display: blockのテーブルがテーブルとして認知されない
振る舞い
振る舞いを提供するUI
見た目は問わない
https://www.youtube.com/watch?v=_eOPgxepC_w
SPAでのApp機能とHTMLとしてのDocs機能 <canvas>と<table>
https://www.youtube.com/watch?v=860d8usGC0o
...so instead i've started referring to them as #transitionalapps. it comes from the interior design school that combines elements from traditionalist and modernist camps. 一方、JavaScriptで記述されたものなど、標準的なHTML以外のコンポーネントを利用する場合、適切にHTMLでマークアップした場合同様に、支援技術が適切にコンテンツを解析し、ユーザーに提示できるようにする必要があります。 支援技術が適切にコンテンツを解析し、ユーザーに伝えられるようにするために、コンテンツの内容に応じたセマンティクスを表す適切なマークアップを行うことが極めて重要です。 支援技術が、例えばJavaScriptで実装されているような独自のコンポーネントを問題なく扱えるようにする。 例えば開閉できるメニュー、タブなど、標準的なHTMLだけでは実装できないようなコンポーネントについて、スクリーン・リーダーがそれはどのようなコンポーネントで、どのような状態にあのかを正確にユーザーに伝え、かつユーザーの操作を可能にする。 ユーザーの操作によってコンポーネントの状態が変化する場合は、その変化が認知できるようにする。