「自分はこうやる」をぜひ#a11yfesやブログに書いて欲しい！読みたいです
ということなので一筆。とはいえ、アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その1）で、「実際にやってみた」のをある程度見せているので、@magi1125のスライドを眺めながらつれづれなるままにコメントをしていく感じ…と思ったら、「こうやる」とはほど遠い、ただの感想文（箇条書き？）になってしまいました。
- まあ身も蓋もない話をすると、そもそもチェック対象ページにアクセシビリティ上の問題がなければ、記録する時間が省けるので最速になります（真顔）
- とはいえ、アクセシビリティチェックをするまでに問題を少なくするという努力をですね（遠い目）
スライド5：前提
- 「WebサイトをWCAG2.2 レベルAAでチェック」をイメージしています
- 対象・目的・状況によってやり方は異なるはず
まず、「ウェブサイトを」というのがキーポイントですかね。いろいろな対象があるでしょうが、思いつくままに…。
- ウェブサイトということはそもそも、（ネイティヴ）モバイルアプリではないってことです
- ひとくちにウェブサイトといっても、相当間口が広いと思われます
- Googleスライドのような（？）ウェブアプリケーションと、典型的なCMSにのっけるような静的なウェブサイトで状況は違うでしょう
- 静的なウェブサイトでもBtoBよりBtoCのほうがハードな傾向があると思います
- 自分のところで完結するだろう事業会社の現場と、受託制作の現場とで状況が違うでしょうたぶん
- 既にデザインがfixしたデザインカンプが降ってきて、だとどうしようもないこともあるかと
- 実装する前からコントラスト比が明らかに詰んでいる、ウェブ技術で実装するのが酷く困難なUI、どう考えても紙メディアのことしか考えてない（以下省略）
- 既にデザインがfixしたデザインカンプが降ってきて、だとどうしようもないこともあるかと
- あとはまあ、CMSインターフェイスそのもののアクセシビリティをやっていくとか
- あんまり一般的ではないと思います
- Authoring Tool Accessibility Guidelines (ATAG) 2.0をがんばって読みましょう
- 一般のウェブ制作を想定するとして、これを読んでる読者のロールでや（れ）ることが違うでしょう
- ディレクター、ビジュアルデザイナー、実装者（フロントエンド）、バックエンド、QAでや（れ）ることは違うと思います
- あるいは間接部門ということもあるかもしれませんし、もしかしたら発注者ということがあるかもしれません（？）
- PDF、動画は典型的なウェブ制作から外れることからして、別物と捉えましょう
- 動画はMaking Audio and Video Media Accessibleを読みましょう
- PDFはMS WordあるいはPowerPointのようなオフィススイートがソースなら「比較的」楽な気がします
- InDesignあたりがソースだと、Acrobatでめちゃくちゃがんばればどうにかできるレベルだとまだマシなほうで、PDFファイルだけ（元ソースなし）だとどうにもできないのがデフォルト、元ソースから（第三者で）わかる人がやっても直せないということもあるかもしれません
- あとはまあ、非ウェブなソフトウェアにもWCAG 2は当然適用できるのでどうのこうの…
- WCAG2ICT Overviewを眺めておくとよいかもしれません
- 構築フェーズなのか、運用フェーズなのかでも話が違ってくる…もごもご…
それから、目的にもよりますよね
- WCAG 2.2レベルAAを必達しなければならないのか、WCAG 2.2レベルAAをできる限りがんばるのかによって当然違ってきます
- 制作段階でセルフチェックするのか、QA段階で「最後の砦」としてチェックするのか、第三者の視点で他社の作ったサイトのアクセシビリティをチェックをするのか、JIS試験をするのか
長くなりましたけど、まあいろいろな対象・目的・状況が想定できると思います。 まあ、toBなコーポレートサイトを、第三者視点でアクセシビリティチェックをする、というような視点を基本の線として進めましょう。もとのGoogleスライドもそのような前提だと思いますし…？
スライド9：おおもとの基準を確認する
- Section 508とか、EN 301 549のことは聞かないでください
- 情報アクセシビリティ自己評価様式のことは忘れましょう
スライド10～12：チェック結果記録シートを作る
- これはまあ、適当なシートを使えばいいと思いますけど、別にセルフチェックをする前提ならそんなに細かいものを使わなくてもよいという説もありますわね
- 制作がセルフチェックをするなら、チェックリスト方式が限界だと思います
- 本当に達成基準にかっちり仕分けて、問題を記録する必要がありますか？
- ディレクターやビジュアルデザイナーのロールがこれをこのまま使うってことはおそらくないわけで
- 受託のディレクターロールは顧客に画像の代替テキストを用意させましょう…（難しいと思うけど）。達成基準 1.1.1「非テキストコンテンツ」と真正面から向き合うには通る必要のある道だと思います
- 情報設計で、PC/SPのレスポンシブサイトで明らかに実装できないようなポンコツワイアーフレームを引いてはいけません。情報設計時点でリタイアしないようにしましょう…
- ビジュアルデザインは、色の全部の組み合わせを出し尽くしましょう…
- というか実装者とコミュニケーションをとりましょう…
- チェック結果を記録するシートは一発でまとまりませんから、メモ書きできるシートを作って、あとで所定の書式にまとめ直しましょう
- たとえば、達成基準1.1.1「非テキストコンテンツ」をチェックしてたら、達成基準4.1.2「名前 (name)・役割 (role)・値 (value)」として記録すべき事項が出てきた、みたいなことがありますので
スライド12：自動チェッカーを掛ける
- 実装者はCIぶん回してエラーをつぶしましょう、axe DevToolsを使いましょう、いいからaxe DevToolsを使いましょう（大事なことなので2回言いました）
- axe DevToolsでエラーを吐くようなコードをQAに渡さないようにしましょう…
- ほんとうにおねがいしたいです
- ベストプラクティスはDequeがそう言ってるだけなので、好きにするといいです
- axe DevToolsでエラーを吐くようなコードをQAに渡さないようにしましょう…
- 制作会社は自社でNu Html Checkerサーバーを立てましょう？
- Markuplintのデフォルトルールは@cloud10designsの趣味が入ってたりすると思うので、信じる信じないはあなた次第…というのが私見です
- というかまあlinterってだいたいそういうものだと思いますけど
- さいきんのバージョンはそうでもないらしいです*2
小まとめ？
- QAロールの仕上げ目前のページに対する目視によるアクセシビリティチェックをする前に、潰せる箇所を潰すのが最速アクセシビリティチェックの必要条件です…（？）
- そのためには、アクセシビリティチェック部門を、デザインや（何を持ってそう呼ぶのかは会社それぞれでしょうが）モジュール、テンプレートの各フェーズに介入させるのがひとつの手でしょう、たぶん…
- 本気でWCAG 2をやるなら、ですけど
- ちからこそパワー
どんどん横道にそれて、なんか全然アクセシビリティチェックと関係ない話になってきてますね…
スライド14～：2. 部分的なところから確認する
- これって、要件にそもそも「ないよね」って確認しておく系と、共通ヘッダー・フッターのようなコンポーネント単位でチェックしておく系が混じっているような？
- そもそも論として動画は個別にチェックしたさ
- ページに埋め込まれている動画に対してWCAG 2の問題があります、といっても動画はHTMLじゃないんだからチェック結果を見て即座に直せないでしょう？
- そもそも論として動画は個別にチェックしたさ
- フォームで見るべき達成基準自体はやまほどあります
- 勘所はアクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その3）#お問い合わせフォームあたりに書いてあります
- ただ、昨今のサイトってだいたいヘッダーあたりに検索欄があると思っているので、そういう意味では逃れられないんじゃないかなぁ…
- ちなみに第三者がアクセシビリティチェックをするときに、達成基準2.5.2「ポインタのキャンセル」（とか）が本当にないかどうかは、作った人に聞かないとわかりません
スライド17：部分的に出現するものをチェック
- 部分的に出現するものをチェックするということは、部分的にしか出現しないことをチェックしておかないといけないんですよ（まがお）
- 意外とだるい、というかだいたいわからなくなります
- 達成基準2.1.2「キーボードトラップなし」は、キーボード周りを見るときに一緒に見るかなぁ…
- そうはならんやろ、っていうキーボードトラップが稀によくあります
- 達成基準2.4.11「隠されないフォーカス」もキーボードまわりで一括で見る感じかしら…
- 達成基準2.2.1「タイミング調整可能」って本質的にはバックエンドに聞いてみないとわからなくなくないですか…
スライド18：共通部分＆横断部分をチェック
- ヘッダー・フッターが共通だと思うでしょう？
- モジュールの管理ができてないのか、理由はよくわからないのですけど、よのなかのサイトって往々にして微妙に違うってことがあるんですよ…
- きっと運用で秘伝のタレみたいになっちゃってるんだろうね…
- モジュールの管理ができてないのか、理由はよくわからないのですけど、よのなかのサイトって往々にして微妙に違うってことがあるんですよ…
- そういう意味で、達成基準3.2.4「一貫した識別性」あたりは思わぬ形で出てくることがあります
- けれども、だいたい達成基準1.1.1「非テキストコンテンツ」か達成基準4.1.2「名前 (name)・役割 (role)・値 (value)」で気づくことになると思います
- 何がどこにあるのか把握できてない状態なので
- けれども、だいたい達成基準1.1.1「非テキストコンテンツ」か達成基準4.1.2「名前 (name)・役割 (role)・値 (value)」で気づくことになると思います
- 達成基準3.1.1「ページの言語」で、達成基準上の問題にならないものの、だいたいみんな中文の美しい指定ができてないっていう…
- （メモ）同じ繁体字でも台湾と香港ではグリフが違う話に昔なんか書きました
スライド20：達成基準の番号はチェックしやすさと無関係
- あー達成基準の番号に意味を見出そうとする…
- 余談ですが、その達成基準上の問題がどの程度の深刻性なり、重大性なりがあるのかと、WCAG 2のレベルとは無関係でもあります
- とりあえずWCAG 2を作った人たちがそう決めたのにすぎないのじゃ…という認識です
スライド21：達成基準単位で複数画面を見る
- 分担してチェックを進めていくとするなら、達成基準ごとに分割するしかないと思われます
- ページ単位で分担してしまうと、チェック担当者によるブレと、複数ページにある問題が認識できなくなってしまう的な
- まあ、達成基準ごとでも、達成基準にまたぐような問題をうまく書けない、みたいなことが発生しますが
- プロセスだけ切り出す（一連のフォームをまとめてしまう）とかならありかも？
- ページ単位で分担してしまうと、チェック担当者によるブレと、複数ページにある問題が認識できなくなってしまう的な
- 「コンテキストスイッチが減るし、チェックツールの切り替えも要らず」
- 達成基準の切り出し方次第じゃないかなぁ…
- スライド22の「複数の達成基準を一緒に見る」で結局あちこちに行き来するのにはあんまり違いないような
- 問題を発見したけど、よく考えたら（axeが既に指摘してる、他の人が担当する達成基準の問題だったので）書く必要がないよね、になりませんか
- つまるところ、やっているはずの達成基準からいつの間にか逸れて、メモしなくていいものを、メモしかけてしまうっていう（ダメ）
- 達成基準の切り出し方次第じゃないかなぁ…
スライド22：複数の達成基準を一緒に見る
- 1.4.5 文字画像＋1.1.1 非テキストコンテンツ
- 「そもそも画像か?を確認」するの、意外と難易度高くないですか？
- そういう意味では、画像の代替テキストを（ブラウザー拡張で画面に表示させて）見ていきながらになってくると思います
- 代替テキストが
<img alt>とは限らない…<svg><title></title></svg>かもしれないので、そもそもsvg要素がそこにあるかを視認できる必要がありますね<svg aria-label>ってパターンも（いいとは思わないけど）
- CSS
backround-imageと隠しテキストのコンボとか- 何か最近はもうCSS無効とか考えなくてよくなくない？とか思ったり思わなかったり
content: url("image") / "alt text";とかもこれから考える必要がありますか…？<i role="img" aria-label></i>とか本当にもうね…いやな世の中ですね…<input type="image" alt>「隠しテキストがやられたようだな」<area alt>「フフフ、奴は代替テキストの中でも最弱…」<object>alt text</object>「aria-labelごときに負けるとは代替テキストの面汚しよ…」<canvas>alt text</canvas>「…」*3
- 代替テキストが
- やっぱり画像かを確認する方が楽ですね…（？）
- 代替テキストの妥当性判断は、まずaltディシジョンツリーからどうぞ
- 「キーボードでフォーカス移動させながらまとめて確認」はまあ、そのとおりだと思いますが、
- 「ランドマークと見出しレベルをツールでまとめて確認」
- んー見出しがあればブロックスキップは満たせているようなものなので、見出しのアウトラインを先に見て、見出しの入り方が怪しかったらランドマーク（ロール）かなぁ…
- Nu Html CheckerのOutlineっぽく視覚的にアウトラインがきれいに出るツールを知りませんか（？）
- あっ、スライド31でWeb Developerにこんな機能あるんだ（知らなかった
- Nu Html CheckerのOutlineっぽく視覚的にアウトラインがきれいに出るツールを知りませんか（？）
- んー見出しがあればブロックスキップは満たせているようなものなので、見出しのアウトラインを先に見て、見出しの入り方が怪しかったらランドマーク（ロール）かなぁ…
スライド23～：ツールで手動チェックを補助する
- Accessibility Visualizer、自分は特に使っていないので良し悪しはなんとも
- まあ、見えるなら何でもいいとは思います
- Web Developerは定番の拡張ですわね
- 多機能すぎて使いこなせてるかというと…
- Accessibility Insightsも便利ですわね
- Tab stopsはたまにポンコツになるので、（フォーカスの順序を確認するためだけに）結局Firefoxの開発者ツールで見てますね…
- Accessible Nameは画面が「うるさく」なるので使いどころが…
- ただ、開発者ツールのHTMLコードから自力で名前計算をして最近ミスってたので、ちゃんとアクセシビリティツリーの名前の計算結果を見ようね？（自戒）
- コントラスト比のざっくりな洗い出しはColor Contrast Analyzerがべんり
- って、この拡張サポートされなくなるの…
- Responsive Viewerをはじめて知りました。かなり使えそうな予感
- テキストの間隔はまあ、適当なツールを使えばええ、って感じですわね
スライド37：マークアップ系の手動確認
ラスボス
1.3.1 情報及び関係性、4.1.2 名前 (name) ・役割 (role) 及び値 (value)
- 「「「それな」」」
特に達成基準4.1.2を避ける？ためには…
- 実装者は自前でコンポーネントを書かないようにしましょう、書くならARIA APG Patternsを読みましょう
- 何も考慮しない自前でコンポーネントより、BootStrapを使うほうが100万倍マシかもしれません、しらんけど…
- これは裏を返すと、アクセシビリティのことを考えてないコンポーネントを選定するとそこで終了ってことです
- Open UIのDesign systemsにいろいろあります、どこまで使えるのかは知らないですけど…
- 「サイトでARIA使ってはいけません！」
しまらないまとめ
「こうやる」というよりかは、中途半端に「何を見ている？」になってますけど、まあいいか…。
いろいろダダ漏れ…というか半分ぐらい愚痴になっているような気もしますけど…。
*1:https://x.com/debiru_R/status/1832398434047029653
*2:https://fedibird.com/@SaekiTominaga/113096358780246311
*3:「奴は四天王の中でも最弱」をいってみたかっただけで、深い意味はないです。すいませんすいません…
