その中で、基本対応するものは一部AAAを含んだAAに絞りました。最初から全てを対応するとなると時間や作業コストがかかりすぎるという判断で、Webページに絞り対応をしていこうということになりました。AAAを全て満たそうとすると、PDFや映像にも手を加えなければならず人員的にも一旦保留という形で進めました。

技術的な詳細は別の記事で触れようと思いますが、個人的に興味深かったものを上げていきます。

HTMLの基礎がきちんと理解できていればさほど難しくないぞ

HTMLのマークアップをセマンティックに書くことを業務としてやっている僕や他のメンバーは、お作法通りにやってればほぼ特殊なことはしなくても大丈夫ってことが知れただけでも大きな収穫でした。

コントラストと文字サイズ

正直少し「めんどい」なとは思いましたが、Figmaのプラグインなどで対応していこうという話になりました。

デザイン作業に入る前段階の仕込み時点で、結構考えることが増えるなという印象でしたがよくよく考えると、デザイン作業に入る前段階の仕込みは結構あるので、パターン化できれば作業コストとしてはそこまで多くはないと思いました。

画面構成やデザインに係るコストがちょっとだけ上がりますが、一人で抱えるものではくチームでのチェック体制を持てれば、一人当たりの負担はさほどでも無いなと思いました。

キーボード操作の最適化

これはチェックが結構大変だなと思いました。特にマウスオーバーでサブメニューが出てくるようなメニューや、flexやgridで少しトリッキーなレスポンシブデザインをしてる場合など何かしらのスクリプトによる制御が必要かなと思います。

ただ、新規で作成するようなページならデザイン段階で、そこも考慮して作ればさほど怖がる必要もないかなと思います。

多分最難関altテキスト設定の重要性

画像のalt（代替テキスト）は最初から最後まで議題に上がり続けました。

こればっかりは、機械的なチェックだけだと片手落ちする印象でした。きちんと文脈に添い、スクリーンリーダなどを意識したaltを最適化していく作業はプロジェクトの最初から最後まで大変になるんではないかと思います。

ある程度頻出する図などはテンプレートテキスト化したり、AI等を使いalt生成したりして、メソッドやナレッジが貯まればコストも下げていけるのではないかと思います。

継続していこう

ウェブアクセシビリティは、例えばガイドラインを作成したら終わりではなく、ちゃんとアップデートをしていかないといけません。

弊社ではJIS X 8341-3をガイドラインとして話を進めましたが、これはWCAG2.0を基準に作られています。今後JIS X 8341-3もアップデートが来ると思います。それを見越して、ちゃんとWCAG2.2の内容も追いかけといた方が、「その日」が来た時あたふたしなくて済むんじゃないかと思います。