「最速[要出典]アクセシビリティチェック」でとりとめもなくなんかだらだら書いただけのやつ

最速[要出典]アクセシビリティチェック

「自分はこうやる」をぜひ#a11yfesやブログに書いて欲しい!読みたいです

ということなので一筆。とはいえ、アクセシビリティチェックってどうやってるの?ということで、実際にやってみた。(その1)で、「実際にやってみた」のをある程度見せているので、@magi1125のスライドを眺めながらつれづれなるままにコメントをしていく感じ…と思ったら、「こうやる」とはほど遠い、ただの感想文(箇条書き?)になってしまいました。

  • まあ身も蓋もない話をすると、そもそもチェック対象ページにアクセシビリティ上の問題がなければ、記録する時間が省けるので最速になります(真顔)
  • とはいえ、アクセシビリティチェックをするまでに問題を少なくするという努力をですね(遠い目)

スライド5:前提

  • 「WebサイトをWCAG2.2 レベルAAでチェック」をイメージしています
    • 対象・目的・状況によってやり方は異なるはず

まず、「ウェブサイトを」というのがキーポイントですかね。いろいろな対象があるでしょうが、思いつくままに…。

  • ウェブサイトということはそもそも、(ネイティヴ)モバイルアプリではないってことです
    • iOSではVoiceOverとXcodeのAccessibility Inspector、あとBluetoothキーボードでチェックすることになるでしょう
      • スマホでも…キーボードは使えるんだよ…
    • Androidは…TalkBackでがんばりましょう(UIAutomatorViewerって今使えますの?)
  • ひとくちにウェブサイトといっても、相当間口が広いと思われます
    • Googleスライドのような(?)ウェブアプリケーションと、典型的なCMSにのっけるような静的なウェブサイトで状況は違うでしょう
    • 静的なウェブサイトでもBtoBよりBtoCのほうがハードな傾向があると思います
  • 自分のところで完結するだろう事業会社の現場と、受託制作の現場とで状況が違うでしょうたぶん
    • 既にデザインがfixしたデザインカンプが降ってきて、だとどうしようもないこともあるかと
      • 実装する前からコントラスト比が明らかに詰んでいる、ウェブ技術で実装するのが酷く困難なUI、どう考えても紙メディアのことしか考えてない(以下省略)
  • あとはまあ、CMSインターフェイスそのもののアクセシビリティをやっていくとか
  • 一般のウェブ制作を想定するとして、これを読んでる読者のロールでや(れ)ることが違うでしょう
    • ディレクター、ビジュアルデザイナー、実装者(フロントエンド)、バックエンド、QAでや(れ)ることは違うと思います
    • あるいは間接部門ということもあるかもしれませんし、もしかしたら発注者ということがあるかもしれません(?)
  • PDF、動画は典型的なウェブ制作から外れることからして、別物と捉えましょう
    • 動画はMaking Audio and Video Media Accessibleを読みましょう
    • PDFはMS WordあるいはPowerPointのようなオフィススイートがソースなら「比較的」楽な気がします
      • きちんとオフィススイートの構造をつかめば、ですが、まあウェブアクセシビリティの勘所がわかればどうとでもなります。Microsoftのリソースを信じましょう
    • InDesignあたりがソースだと、Acrobatでめちゃくちゃがんばればどうにかできるレベルだとまだマシなほうで、PDFファイルだけ(元ソースなし)だとどうにもできないのがデフォルト、元ソースから(第三者で)わかる人がやっても直せないということもあるかもしれません
      • なんにせよAcrobatで泣きながらがんばってください…
        • なお、Adobeはたいしたリソースを提供してくれません
      • あきらめてHTMLによる代替コンテンツを作ってしまうか、最初からHTMLで作りましょう(?)
  • あとはまあ、非ウェブなソフトウェアにもWCAG 2は当然適用できるのでどうのこうの…
  • 構築フェーズなのか、運用フェーズなのかでも話が違ってくる…もごもご…
    • だいたいの場合、運用者は適切なマークアップがそもそもできない(専門家でもないから仕方ないね…?
    • MS Wordでアクセシビリティをやっていくには、人類は早すぎた

それから、目的にもよりますよね

  • WCAG 2.2レベルAAを必達しなければならないのか、WCAG 2.2レベルAAをできる限りがんばるのかによって当然違ってきます
    • 別にレベルAの一部の達成基準だけを、がんばれる範囲でがんばる、とかでもぜんぜんよいと思います
    • レベルAA「準拠」を必達の目標にするから、アクセシビリティチェックで血祭りにあげて、情け容赦なく斬っていく必要があるだけです
  • 制作段階でセルフチェックするのか、QA段階で「最後の砦」としてチェックするのか、第三者の視点で他社の作ったサイトのアクセシビリティをチェックをするのか、JIS試験をするのか

長くなりましたけど、まあいろいろな対象・目的・状況が想定できると思います。 まあ、toBなコーポレートサイトを、第三者視点でアクセシビリティチェックをする、というような視点を基本の線として進めましょう。もとのGoogleスライドもそのような前提だと思いますし…?

スライド9:おおもとの基準を確認する

  • Section 508とか、EN 301 549のことは聞かないでください
  • 情報アクセシビリティ自己評価様式のことは忘れましょう

スライド10~12:チェック結果記録シートを作る

  • これはまあ、適当なシートを使えばいいと思いますけど、別にセルフチェックをする前提ならそんなに細かいものを使わなくてもよいという説もありますわね
    • 制作がセルフチェックをするなら、チェックリスト方式が限界だと思います
    • 本当に達成基準にかっちり仕分けて、問題を記録する必要がありますか?
  • ディレクターやビジュアルデザイナーのロールがこれをこのまま使うってことはおそらくないわけで
    • 受託のディレクターロールは顧客に画像の代替テキストを用意させましょう…(難しいと思うけど)。達成基準 1.1.1「非テキストコンテンツ」と真正面から向き合うには通る必要のある道だと思います
    • 情報設計で、PC/SPのレスポンシブサイトで明らかに実装できないようなポンコツワイアーフレームを引いてはいけません。情報設計時点でリタイアしないようにしましょう…
    • ビジュアルデザインは、色の全部の組み合わせを出し尽くしましょう…
      • レベルAAで達成基準 1.4.3「コントラスト (最低限)」、達成基準 1.4.11「非テキストのコントラスト」を満たす必要があるならなおさらです
      • UIはアクティブ、ホバー、フォーカス時のパターンはもちろんのこと、開閉メニューの開閉状態からモーダルダイアログ、カルーセルまでサイトで使うあらゆるウィジェットのパターンをデザインしましょう…
    • というか実装者とコミュニケーションをとりましょう…
  • チェック結果を記録するシートは一発でまとまりませんから、メモ書きできるシートを作って、あとで所定の書式にまとめ直しましょう
    • たとえば、達成基準1.1.1「非テキストコンテンツ」をチェックしてたら、達成基準4.1.2「名前 (name)・役割 (role)・値 (value)」として記録すべき事項が出てきた、みたいなことがありますので

スライド12:自動チェッカーを掛ける

  • 実装者はCIぶん回してエラーをつぶしましょう、axe DevToolsを使いましょう、いいからaxe DevToolsを使いましょう(大事なことなので2回言いました)
    • axe DevToolsでエラーを吐くようなコードをQAに渡さないようにしましょう…
      • ほんとうにおねがいしたいです
    • ベストプラクティスはDequeがそう言ってるだけなので、好きにするといいです
  • 制作会社は自社でNu Html Checkerサーバーを立てましょう?
    • 実装者にNu Html Checkerのエラーをつぶさせるだけでもアクセシビリティは向上します。本当です
    • XHTML1を知っている世代の人はXML構文のことを忘れましょう。わたしたちはHTMLを書いています
      • <br />とか書くとwarningsで怒られる時代です
        • 素のHTMLで、ですあくまで。ReactとかJSXはそうじゃないっていうツッコミがあったので一応*1
    • XHTML1ってなんですか?というわかものは、コンテンツモデルを知りましょう
      • しっているか、a > h2とは書けるがbutton > h2とは書けないんだゾ
  • Markuplintのデフォルトルールは@cloud10designsの趣味が入ってたりすると思うので、信じる信じないはあなた次第…というのが私見です
    • というかまあlinterってだいたいそういうものだと思いますけど
    • さいきんのバージョンはそうでもないらしいです*2

小まとめ?

  • QAロールの仕上げ目前のページに対する目視によるアクセシビリティチェックをする前に、潰せる箇所を潰すのが最速アクセシビリティチェックの必要条件です…(?)
  • そのためには、アクセシビリティチェック部門を、デザインや(何を持ってそう呼ぶのかは会社それぞれでしょうが)モジュール、テンプレートの各フェーズに介入させるのがひとつの手でしょう、たぶん…
    • 本気でWCAG 2をやるなら、ですけど
  • ちからこそパワー

どんどん横道にそれて、なんか全然アクセシビリティチェックと関係ない話になってきてますね…

スライド14~:2. 部分的なところから確認する

  • これって、要件にそもそも「ないよね」って確認しておく系と、共通ヘッダー・フッターのようなコンポーネント単位でチェックしておく系が混じっているような?
    • そもそも論として動画は個別にチェックしたさ
      • ページに埋め込まれている動画に対してWCAG 2の問題があります、といっても動画はHTMLじゃないんだからチェック結果を見て即座に直せないでしょう?
  • フォームで見るべき達成基準自体はやまほどあります
  • ちなみに第三者アクセシビリティチェックをするときに、達成基準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)」で気づくことになると思います
      • 何がどこにあるのか把握できてない状態なので
  • 達成基準3.1.1「ページの言語」で、達成基準上の問題にならないものの、だいたいみんな中文の美しい指定ができてないっていう…

スライド20:達成基準の番号はチェックしやすさと無関係

  • あー達成基準の番号に意味を見出そうとする…
    • なんとなくのまとまりもなくはない…ですけど、アクセシビリティチェックで番号に意味を見出すのってしないですよね…
    • ガイドライン1.2「時間依存メディア」ですとかガイドライン3.3「入力支援」とかはまだ有意義かもしれないですけど
    • 1.1.1、1.3.1、4.1.2って言い出すと、ようこそこちら側へ
  • 余談ですが、その達成基準上の問題がどの程度の深刻性なり、重大性なりがあるのかと、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
    • やっぱり画像かを確認する方が楽ですね…(?)
  • 「キーボードでフォーカス移動させながらまとめて確認」はまあ、そのとおりだと思いますが、
    • フォーカスのインジケーターがChromeで見えるけどFirefoxで見えないとかいうの、どうにかなりませんか
  • 「ランドマークと見出しレベルをツールでまとめて確認」
    • んー見出しがあればブロックスキップは満たせているようなものなので、見出しのアウトラインを先に見て、見出しの入り方が怪しかったらランドマーク(ロール)かなぁ…
      • Nu Html CheckerのOutlineっぽく視覚的にアウトラインがきれいに出るツールを知りませんか(?)
        • あっ、スライド31でWeb Developerにこんな機能あるんだ(知らなかった

スライド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)

  • 「「「それな」」」
    • Nu Html Checkerのエラーをつぶせっていっているのは、これらをつぶしていくことにつながるからです
    • もちろんaxe DevToolsで引っかかったものもつぶします
    • 結局はHTML Standard、ARIA in HTML、WAI-ARIAARIA APGとのたたかいです

特に達成基準4.1.2を避ける?ためには…

しまらないまとめ

「こうやる」というよりかは、中途半端に「何を見ている?」になってますけど、まあいいか…。
いろいろダダ漏れ…というか半分ぐらい愚痴になっているような気もしますけど…。

*1:https://x.com/debiru_R/status/1832398434047029653

*2:https://fedibird.com/@SaekiTominaga/113096358780246311

*3:「奴は四天王の中でも最弱」をいってみたかっただけで、深い意味はないです。すいませんすいません…

(メモ)地方自治体のアクセシビリティJIS試験の提示について

ある方面ではおなじみの調査、自治体サイトWebアクセシビリティ調査 2024 – 有限会社ユニバーサルワークスについて、ざっくり眺めた感想とか。

今年5月に公開された「みんなの公共サイト運用ガイドライン(2024年版)」では、実際のウェブアクセシビリティ品質と公開されている試験結果や準拠状況との間に差異があるとの指摘がなされています。今回の調査は、自治体公式サイトにおける試験の実施状況と試験結果に関する書式や記載内容を明らかにし、規格や指針に即していない点、今後の取り組みを進める中で優先してほしいことなどを記しました。

まあ、みんなあんまり気にしてないけど、障害者基本計画(第5次)の関連成果目標にも公的機関のウェブサイトの情報バリアフリーに関するJIS規格への準拠率がある以上、「レベルAA準拠」としたい意向というのは避けられないものがあると思っており。そもそもこの目標設定がよろしくないことは繰り返し言っていきたいところ*2

*1:JIS X 8341-3:2016 解説あたりを参照

*2:現実味を出そうとして「目標を下げる」というのは反発があると思うけど…