全盲のクライアントとの仕事で明らかになった見えないアクセシビリティのギャップ

最近、契約に詳細なアクセシビリティ要件が盛り込まれたクライアントがいました。これは彼ら特有のもので、私たちの通常の業務とは異なります。彼らの従業員には、私たちが構築したものを使用する全盲および聴覚障害者がおり、それを真剣に受け止めてほしいと考えていました。最初はその姿勢を尊重していましたが、レビューセッションが1、2回あり、少し修正すれば大丈夫だろうと考えていました。せいぜい数時間で終わるだろうと。しかし、結果として18時間の作業が必要になりました。 プロジェクトは、MicrosoftのPower Automateで購買承認ワークフローを構築することでした。彼らの社内のアクセシビリティ専門家（彼女自身も全盲であり、この新しいワークフローの実際のユーザーの一人となる）がレビューを主導しました。私の計画は、彼女に私のブラウザアカウントにログインしてもらい、進捗状況を確認するために一通り操作してもらうことでした。しかし、それはうまくいきませんでした。 アクセシビリティ専門家によると、Microsoftのブラウザアプリはスクリーンリーダーとの相性が悪く、彼女が必要とする方法でナビゲートできなかったのです。それは大きな問題ではありませんでした。私は一歩引き、彼女が自分のアカウントからデスクトップアプリでテストできるように、別の権限セットを設定し、そこから開始してもらいました。私たちはまだワークフローを見ていませんでしたが、プラットフォームがすでに障害となっていたのです。 準備が整った後、Zoomでミーティングを行うことになりました（プラットフォームの選択は偶然ではありません。当初はMicrosoft TeamsやGoogle Meetで通話していましたが、彼女はZoomを最もアクセシブルなビデオ会議オプションと考えています）。テストセッションでは、彼女が画面を共有し、実際のユーザーのようにワークフローを操作しました。私は彼女と一緒に画面を見て耳を傾け、スクリーンリーダーがページを読み上げるのを聴きました。これにより、彼女がどのように聴き、自身を位置づけ、次にどこへ進むかを決定しているのかを知ることができました。ここで、それは抽象的な問題ではなく、現実の問題になったのです。 これらの通話のどこかの時点で、私が知っているインターネット――ちらっと見て、ざっと読んで、クリックしてナビゲートするインターネット――が、スクリーンリーダーを通して体験する人にとっては、ほとんど全く異なる場所であることを痛感しました。同じウェブでも、世界は全く違うのです。 問題 ここでタイトルの由来になります。私はSharePointでページを作成し、ユーザーはそこで申請が承認されたか、まだ保留中か、申請に関する一般的な情報を確認できるようにしました。特別なものではありませんでしたが、用は足りました。誰も誤って承認プロセスを変更できないように、ページは読み取り専用モードで共有する必要がありました。これは比較的標準的な要件ですが、SharePointがページを読み取り専用モードで共有すると、すべてのフィールドに「(read only)」という文字列が追加されます。 これは、それを読むことができる人にとっては問題ありませんが、聞いている人にとっては、すべての行、繰り返し、ページ全体でそのフレーズを聞くことになります。セリフの後に「（声に出して読み上げます）」と読み上げる声が聞こえる映画を見ていると想像してみてください。すぐに話の筋を見失うでしょう。スクリーンリーダーでこのページをナビゲートするユーザーは、まさにそのような感覚でした。そして、点字リーダーを使用するユーザーにとっては、単に退屈なだけでなく、デバイス上で物理的なスペースを取ることになります。すべての冗長な文字が、実際に役立つコンテンツを圧迫します。 私は解決策を探すのに長い時間を費やしました。タグを非表示にする方法、申請者に進捗状況を共有する別の方法、何でもです。最終的に、私はそれを修正できないという結論に至りました。それがSharePointの仕組みなのです。 それは何度も起こりました。私たちは何かを見つけ、私が掘り下げると、その答えは「問題は実装ではなく、プラットフォームにある」ということでした。TeamsのPower Automateのネイティブ承認アプリは、スクリーンリーダーでは全く認識されませんでした。JAWS（最も広く使われているスクリーンリーダーの一つ）は、Outlookで承認メールを読む際に互換性の問題がありました。SharePointは、単一のページに複数のH1見出しを生成し、これはスクリーンリーダーユーザーのナビゲーション方法を壊します。見出しは、見えない人にとって視覚的な選択肢ではありません――それは、人がテキストの太字部分をざっと見て場所を見つけるのと同じように、ページ上を移動する方法にとって極めて重要です。同じページに2つのH1があることは、偽のランドマークを作成します。これは、この経験をするまで私が考えもしなかった方法で、混乱を招くものでした。 私はMicrosoftを特に非難するためにこれを言っているのではありません。これは、アクセシビリティが誰か他の人の問題として扱われたり、後からチェックボックスを埋めるだけのものとして扱われたりする場合に、ソフトウェア業界全体で起こることです。Microsoftは多くの人がその上に構築するツールを作っているため、彼らのギャップは私たちのギャップになります。 私たちが取った対策 私が制御できる範囲では、変更を加えました。不要なラベルを削除しました。正確な代替テキストを追加しました――コンプライアンスのために埋められた代替テキストではなく、実際に説明的な代替テキストです。手が届く範囲で見出し構造を整理しました。 このプロジェクトのSharePoint追跡ページについては、完全に経路を変更しました。ユーザーにノイズと格闘させる代わりに、システムは承認の各段階でメール通知を送信するようになりました。リクエストごとに4〜5通のメールです。おそらく一部のユーザーには多すぎるでしょう。しかし、それを必要とするユーザーにとっては、アクセシビリティの低いページに触れる必要がなくなりました。 修正できなかったことについては、回避策を講じました。私たちは共同でトレーニング資料を作成しました――彼らのセットアップ、スクリーンリーダー、遭遇するであろう奇妙な点に特化したドキュメントです。私たちはそのドキュメントの正直なバージョンを作成しました：変更できなかったこと、そしてそれでも乗り越える方法です。書くのは満足のいくものではありませんでしたが、必要なことでした。 私は、このプロセス中に何度かスクリーンリーダーを自分で使用し、その経験をよりよく理解しました。最も驚いたのは、特定のバグや壊れたインタラクションではなく、ノイズでした。視覚的なユーザーが気づかずに完全にフィルタリングしているラベル、ステータスインジケーター、繰り返されるフレーズ、構造的な乱雑さの sheer volume です。ページを見ているのではなく聞いているとき、それらすべてが邪魔になります。余分な単語はすべて、実際に求めているものにたどり着く前に、聞かなければならないことです。 ほとんどのソフトウェアは、見たり聞いたりできる人々によって構築され、見たり聞いたりできる人々によってテストされています。それは非難ではありません――それは、私たちの業界が長年どのように運営されてきたかの正直な説明であり、実際にそれらを持って生きている人が現れて、あなたを案内してくれるまで、ギャップは見えないままになりがちであることを意味します。 私は、このクライアントがそのような人を持っていたこと、そしてこの種の作業に現実的な時間を契約に組み込むことを気にかけたことに幸運でした。すべてのプロジェクトにそれがあるわけではありません。ほとんどありません。しかし、それは何もできないという意味ではありません。 あなたが開発者であれば、アクセシビリティ標準は存在し、最後に監査するのではなく、最初からあなたの仕事に組み込む価値があります。あなたが会社でツールやプロセスを提唱できる立場にあるなら、あなたのチームが毎日使用しているソフトウェアが、そのチームの全員にとって実際に機能するかどうかを尋ねる価値があります。そして、壊れているもの――40回繰り返されるラベル、スクリーンリーダーが見つけられない承認ポップアップ――に遭遇したユーザーであれば、それを構築した会社に報告することが重要です。 より多くの人がMicrosoftに「(read only)」の問題を報告すればするほど、バックログに残しておくことが難しくなります。これらのどれも、開始するために特定の契約要件を持つクライアントを必要としません。それはただ、気にかけることと、それに注意を払う価値があると決めることを必要とするだけです。 もっと話したいですか？ 私たちは25年以上にわたり、クライアントのためにソフトウェアを構築してきました。あなたのチームや次のプロジェクトのために、ソフトウェアをより使いやすく、よりアクセスしやすくする方法に興味があるなら、私たちに連絡してください。喜んでご案内します。 ソフトウェアにおけるアクセシビリティについてもっと知りたいですか？ 以下に、学習を開始するためのリソースをいくつか紹介します。 アクセシビリティの基本 — W3C Web Accessibility Initiative WCAGクイックリファレンス — WCAG 2.0ガイドライン モバイルアクセシビリティの考慮事項 — W3Cモバイルマッピング アクセシビリティプロジェクト — コミュニティ主導のリソース Pa11y — 自動アクセシビリティテスト WAVE — ウェブアクセシビリティ評価ツール 手動テストガイド — ハーバードアクセシビリティテスト アクセシビリティ