「善意」のウェブアクセシビリティ

今月の頭にGood Will or Genuine Effort? The True Motivations Behind Accessibility Compliance – Barrier Free Canadaという記事を@caztcha@fedibird.comがトゥートしてたのが目に留まったので、これについて少し書きましたというお話。

この記事にはカナダ固有のことが書かれているわけでもないのですが、カナダの法律の現状を少し見ておきましょう。

W3C WAIのWeb Accessibility Laws & Policies曰く、カナダにはThe Accessible Canada Act (The Act to Ensure a Barrier Free Canada)という法律が、政府と連邦政府の規制部門(Government and all federally regulated agencies)を対象にしているそうです。カナダ政府公式の概説としてはSummary of the Accessible Canada Actがあり、Applicationのセクションの説明では、銀行、運輸、放送通信の民間部門が対象になっているということです。

技術的な観点では、SiteimproveWhat is The Accessible Canada Act?がわかりやすいかもしれません。What are the web accessibility requirements under the ACA?のセクションでは、欧州規格EN 301 549を採用する、つまるところWCAG 2.1を直接参照しているということになります。

細かいところについては、ここでは見ていきませんが、要するにカナダでは特定の部門では法的枠組みとしてWCAG 2.1に取り組む必要がある、ということになっているそうです。

さて、そういう法的枠組みがあってもなお、善意(Good Will)という単語が冒頭のBarrier Free Canadaの記事(今年9月に書かれている)で出てくるのは興味深いところではあります。

Yet, despite these legal frameworks, adherence to accessibility standards often feels like a voluntary gesture rather than a legal obligation.

ということが記事では書かれていますが「法的な義務というよりかは自発的な行為に感じられる」というのは、日本でも往々にして見られる光景ではないでしょうか…?

障害者差別解消法でもって、合理的配慮(reasonable accommodation、合理的調整とも)の前段としての環境の整備があり、ウェブアクセシビリティは環境の整備として位置付けらています。環境の整備は法的には努力義務であるわけですが、ごく一部の熱心な日本の民間企業が、この努力義務に基づいて積極的にウェブアクセシビリティに取り組んでいる現状になっているとわたしは捉えています。

記事の続きのThe Role of Good Willのセクションでは、次のように書かれています。

Good will certainly plays a significant role in the accessibility landscape. Many companies go above and beyond compliance because they genuinely care about inclusivity. They understand that accessibility is not just a legal requirement but a moral imperative. This altruistic approach can lead to pioneering innovations that benefit all users, not just those with disabilities.

However, the reliance on good will alone is problematic. It means that the level of accessibility a person experiences can vary greatly depending on a company’s individual commitment. This inconsistency can result in a patchwork of accessibility measures, where the quality of access is contingent upon the company’s internal values rather than a standardized legal requirement.

かなりの意訳が入ってますが、こんな感じでしょうか。

善意がアクセシビリティでは重要な役割を果たしており、企業は包括性(インクルーシブ)を気にかけていることからコンプライアンスを超えて行動をしています。そのような企業は、アクセシビリティが法的な義務だけではなく道義的な義務もあることをわかっており、この利他的なアプローチが、障害者だけでなくすべてのユーザーに利益をもたらすイノベーションにつながる可能性があるでしょう。

しかし、善意だけに頼ることには問題があって、つまるところはアクセシビリティ視点でのユーザー体験は個々の企業の取り組み次第になってしまいます。社会全体で見たときに、あるところではアクセシビリティがある程度担保されているものの、別のところではまったくといっていいほど担保されていないという状況になってしまいます。これは、法的な要件がないからにほかなりません。

というのはまあ、日本の今の状況にほかならないかなと。限られた一部のアクセシビリティの熱心な企業、あるいはウェブ制作に携わる人が、ボトムアップ的にアクセシビリティに取り組んではいるものの、社会全体で俯瞰したときに必ずしも好ましい状況にあるとはいえないのではないでしょうか。

建物のバリアフリーでたとえていうなら、車いすのユーザーが、エレベーターの備え付けられている商業施設だから、その店を選んでいるというのが現状です。そうではなく、どの商業施設も最低限エレベーターが備え付けられていて、その人個人の好みで店を選ぶのが健全な状況ではないでしょうか?だからこそ、最低限商業施設にはエレベーターを備え付けましょうというわけです(実際、特定の建物にはエレベーターがなければならないと日本では法律で決められています)。しかし、ウェブアクセシビリティを最低限こうしましょうという、建物のバリアフリーと対になるような法律は日本ではありません。

もしも、あまたのウェブサイト上で提供されているサービスの中からウェブアクセシビリティとしてマシだという理由で、そのサービスを選んでいるしたら、それは果たして健全といえるのでしょうか。点在する善意によるウェブアクセシビリティの取り組みに頼り過ぎではないでしょうか?

もちろん、法律がすべてを解決するとは思いませんが、技術的に(WCAG 2を基準とするような)ウェブアクセシビリティを強制させる法律がないことから、WCAG 2に取り組まないことがコンプライアンス上の問題にすらならないわけです(WCAG 2でよいのか?という話もあるかもしれませんが、それはさておくとして)。

…というような趣旨のことを、わたしはここ数年ずっと言っているんですけれども。ウェブアクセシビリティに取り組んでいる、ウェブ制作に携わってる人に対して共感を得られているかというと、感触として怪しいんですよね…まあわたしの力不足なだけなのですが。

さておき、ウェブアクセシビリティがわかるウェブ制作者を増やすという観点でも、現場のボトムアップだけでは足りなくて社会的なトップダウンでもやっていく必要がありますよね、ということは今後も飽きずに言及していきたいと思います。

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

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

「自分はこうやる」をぜひ#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:「奴は四天王の中でも最弱」をいってみたかっただけで、深い意味はないです。すいませんすいません…