Elisa Bandy は、Google の社内ツールのウェブ アクセシビリティとドキュメントを担当している社員です。
この投稿では、アクセシビリティを学ぼう！の一環として、コミュニティ エキスパートを紹介します。詳しくは、Google のユーザー補助に対する取り組みと研究をご覧ください。
Alexandra Klepper: あなたを同僚と呼べることを光栄に思います。ここで、自己紹介と仕事内容をどのように説明しますか？
Elisa Bandy: Elisa と申します。Google の内部ツールとインフラストラクチャのドキュメントを作成しています。
Alexandra: 素晴らしい仕事ですね。何人でお仕事をされていますか？
Elisa: チーム全体では 40 人ほどで、テクニカル ライター、インストラクショナル デザイナー、プログラム マネージャーなどが含まれます。6 年前に私がチームに加わったとき、チームのメンバーは 4 人だけでした。
Alexandra: Google に入社する前は何をされていましたか？
Elisa: 平日は、ビデオゲームの開発に携わっていました。週末は靴の修理の仕事をしていました。
Alexandra: Google に入社してからウェブ アクセシビリティの仕事に携わるようになったのですか？
Elisa: はい。ただし、1 年半ほど経ってから、副業として始めました。Google の内部ドキュメントのアクセシビリティ エンジニアリングを担当しています。この作業を行う前は、ドキュメントはユーザー補助を考慮して設計されていませんでした。アクセス可能だったドキュメント機能は、偶然の産物です。
リンクの色のコントラストがまったく不適切であるなど、大きな問題がありました。表はめちゃくちゃでした。拡大しても、rem ではなくピクセルで定義されていたため、すべて同じサイズでした。私はそれらのすべてを修正することを申し出ました。そして、さらに多くのことを修正し続けました。5 年経った今でも、私はこの仕事を続けています。
Alexandra: アクセシビリティに関する専門知識とスキルを身につけ、修正が必要な問題を解決する決意を持っています。
Elisa: そうですね [笑]。私自身も障害者であるため、ユーザー補助機能の配慮を求めることがいかに難しいかを知っています。同僚や同業者にアクセシビリティの配慮がなかったことに、私は本当に腹を立てました。他の誰も直してくれなかったのです。そこで、私はそれらを修正しました。
ユーザー補助をリクエストする必要はないと思います。最初から組み込まれている必要があります。
ユーザー補助機能のユースケースに優先順位を付ける
Alexandra: ウェブ アクセシビリティについて考えると、さまざまなレイヤがありますよね。障害の種類によってニーズが異なり、矛盾することもあります。何をすべきかの優先順位はどのように決めますか？
Elisa: 私の仕事の多くは優先順位付けです。たとえば、特定のユースケースが 100% 完全にアクセス可能であることは、どれほど重要でしょうか。私は多くのデータを見ています。人口の何パーセントが障がい者ですか？特定のユーザー補助機能に関する問題を抱えているユーザーは何人いますか？
たとえば、Chromebook に組み込まれたスクリーン リーダーである ChromeVox を使用しているユーザーのサブセットがあります。ChromeVox で問題が発生した場合は、ChromeVox、Jaws、NVDA、VoiceOver のユーザー数を比較する必要があります。
外部では、ChromeVox を使用しているユーザーは多くありません。Google では、多くの人が Chromebook を主な仕事用デバイスとして使用しているため、ChromeVox は社内ドキュメントにとって非常に重要です。ChromeVox のバグが VoiceOver のバグや NVDA のバグよりも少し優先順位が高くなることもあります。
一般的に、私はまず主要なスクリーン リーダーの問題を修正しようとします。特にハイコントラスト モードでは、色付けの問題を回避する拡張機能が多数存在するため、色付けは当たり外れがある傾向があります。
Alexandra: Google ではデータが非常に重要であるとおっしゃいましたが、「アイデアをデータで裏付けろ」という言葉をよく耳にします。Google ではアクセシビリティに関するデータをどのように収集していますか？
Elisa: Google の Disability Alliance が収集したデータを活用しています。また、WebAIM のアンケートと照らし合わせることもよくあります。
アクセシビリティの文化
Alexandra: Google のユーザー補助機能の文化について教えてください。
Elisa: 非常に急速に成長し、資金調達と広範囲にわたる懸念事項を抱えるものになりました。ほとんどの人が正しいことをしたいと思っていることがわかりました。同僚は、正しいことを行う方法やアクセシビリティを優先する方法に関する教育リソースを求めています。
アプリやウェブサイトなどを、間違った方法で実装した後にアクセシビリティ対応にするのは難しいことです。そのため、プロダクトの構築前に、初期設計にユーザー補助機能を組み込むことをエンジニアに考えてもらうことも私の仕事の一部です。人々はそれに対して非常に好意的で、熱心です。
ユーザー補助機能の組み込みに実際に抵抗があったのは一度だけですが、それも比較的簡単に解決できました。
Alexandra: それについて詳しく教えていただけますか？
Elisa: アクセシビリティ エンジニアリングに初めて参加したときは、時間の 20% しか費やしていませんでした。アクセシビリティに注力している理由を理解していない人もいました。「障がい者は人口の 1% にすぎない」という人がいました。私は自分の立場を主張しました。それは正しいことだから、やるべきだと。そして、それは私の時間であり、私が適切だと考える方法で使うべきだと。
もちろん、障害者は重要ではない、障害者は少数派だ、などと聞くのはつらいことです。
Alexandra: 特に、その人口集団に属している場合はそうです。対象ユーザーを把握する
Elisa: 「これは 1% にすぎません」という言葉は聞きたくありません。「のみ」という言葉は、重要性を軽視しているように聞こえます。しかし、世界人口を考えると、それは非常に多くの人々です。Google には多くの人が働いています。また、多くの障害が過小報告されています。
Alexandra: 人口の 1% をはるかに超える人々が障がいの影響を受けていることはわかっています。WHO の報告書によると、10 億人以上が障がいを抱えており、22 億人がなんらかの視覚障害を抱えています。もちろん、視覚障がいの程度はさまざまであり、視覚障がいのある人の中には、自分を障がい者とは考えていない人もいます。しかし、これらの障害はウェブ上の操作に影響します。
Elisa: そのとおりです。
独自の専門知識セットを構築する
Alexandra: アクセシビリティの仕事に就く前に知っておきたかったアドバイスはありますか？
Elisa: すべてのことを知らなくても大丈夫です。アクセシビリティは、広大で広範な空間です。知らないことがたくさんあることはわかっています。私は非常に特殊なスキルを持っています。ユーザー補助に関するベスト プラクティスに関する情報がどこにあるかを知っています。
スクリーン リーダーや色のコントラストなど、自分の専門分野でも、毎日新しいことを学んでいます。私は耳が聞こえませんが、クローズド キャプションのユーザー補助の専門家ではありません。自分にとって何が効果的かはわかっていますが、他の人にとって何が効果的かはわかりません。質問されたら、ベスト プラクティスを調べる必要があります。
Alexandra: あらゆる種類のユーザー補助機能のエキスパートである必要はありません。エンジニアがアクセシビリティ パターンを学習するのをどのようにサポートしますか？
Elisa: アクセシビリティに関心のあるエンジニアと緊密に連携しています。バグを渡して、修正方法を説明します。その後、ベスト プラクティスについて説明します。他のドキュメントを見て、あるアプローチが推奨されていることを確認したものの、XYZ という理由でそのアプローチが機能しない場合があります。
ウェブ アクセシビリティには、具体的なコード例があまりありません。同じ機能を同じ方法で構築する人はいないからです。そのため、応急処置的な解決策を講じる可能性があります。多くの人は、すべてが組み合わされるまでアクセシビリティについて考えません。その時点でどうしますか？すべてを分解して組み立て直し、すべてのテストを書き直すのですか？いいえ、そうではありません。何かをホチキスで留める。
つまり、障害のあるユーザーがアプリケーションに期待する機能を理解し、その機能を実行するようにコードをモデル化する必要があります。完璧なコードサンプルや包括的なコンポーネントに見えないかもしれませんが、最終的には、同じ機能を確実に実行できる限り問題ありません。
Alexandra: 最終的に良い結果が得られることが、その過程を気にすることよりも重要だと言っているように聞こえます。
Elisa: はい。このケースでは、目的が手段を正当化するからです。スクリーン リーダーのユーザーやその他の障害のあるユーザーがこの機能をどのように利用することを想定しているかを理解することが非常に重要です。
ARIA ロールは 10 億個もあり、すべてを把握することは不可能です。さらに、一部のスクリーン リーダーでは動作しないものもあります。そのため、ユーザーのニーズを把握して、ユーザー向けに構築する必要があります。
Alexandra: 内部ドキュメントの作成や Google エンジニアへのサポートの提供で、よく使用する外部リソースはありますか？
Elisa: W3C ガイドラインに大きく依存しています。WebAIM は、必要な作業を把握するのに非常に役立ちます。技術的な実装に関しては、WebAIM の方が少し優れていると思います。Mozilla のドキュメントも気に入っています。10 回中 9 回は、何かを検索すると MDN Web Docs に答えがあります。
inclusive-components.design は、アクセシビリティ対応のコンポーネントのライブラリが必要な場合に最適です。
Deque University には、多くのベスト プラクティスが掲載されています。バグを報告するときや、特定のパターンに従う方法を教えるときに、参考資料として使用しています。
ユーザー補助ツールを実際に体験する
Alexandra: ユーザーへの影響を把握するにはどうすればよいですか？色覚異常の方やスクリーン リーダーのサポートが専門とのことですので、そこから始めましょう。
Elisa: 色覚異常や色覚障害については、シミュレータやエミュレータがあります。他の人がどのように見ているかは、自分で見てみないと本当に理解できません。彩度が非常に高いことに気づいた場合、シミュレータで実行すると、まったく識別できないことが確認できます。
スクリーン リーダー ユーザーをサポートするには、実際にスクリーン リーダーを使用するのが一番です。まずチュートリアルを読むことが重要です。電源を入れていじってみるだけでは、使い方を学ぶことはできません。5 分、10 分、20 分以上必要な場合。少なくとも 1 時間使用して、このテクノロジーに依存しているユーザーが直面している不満を明らかにします。
私は、誰もが人生のどこかでアクセシビリティ技術を必要とするようになると確信しています。たとえば、最近手首を痛めてマウスを使えなかったため、数週間キーボードを使用しました。本当にイライラしました。このような演習は、健常者の世界を生き抜こうとする障がい者の立場を理解するのに役立ちます。
シミュレータは便利ですが、障害と同等ではありません
Alexandra: シミュレータを使用する私の経験や他のデベロッパーの経験は、視覚障がいのある方の経験とは明らかに異なります。
Elisa: 障害のある人に話を聞いて、その経験について知ることはいつでもできます。共感を生み出す際には、これらのツールを頻繁に使用している人は、あなたよりも常にそのツールを使いこなしていることを忘れないでください。障害のある人は、自分のスペースを移動するのが常に得意です。なぜなら、それがその人が生きている体だからです。
私が懸念しているのは、共感の練習（適切な言葉が見つからないので、こう呼びます）をした人が、他人の経験を正確に理解したと思い込んでしまうことです。突然、その経験の専門家になったと思い込むのです。その体験のエキスパートはあなたではありません。健常者である場合、スクリーン リーダーの専門家にはなれません。私はこの分野で働いていますが、色覚異常の専門家ではありません。私はスクリーン リーダーの専門家ではありません。
私は難聴の経験に関する専門家です。私は補聴器の必要性や、日々の経験を乗り越えることについて専門家です。しかし、それは私が他人の難聴の経験の専門家であることを意味するものではありません。
アクセシビリティ エンジニアリングで最悪なのは、エゴを持つことです。何をやっても、何かを台無しにしてしまう。障害のニーズは人それぞれなので、落胆する必要はありません。アクセシビリティや障がいに対する見解は人それぞれです。すべてを 100% 達成することはできませんが、だからといって努力を怠るべきではありません。完璧になることはありませんが、それでも完璧を目指しましょう。
「あなたのプロダクトはアクセシビリティに対応していない」といった厳しいフィードバックを受けることもあります。
Alexandra: シミュレータは、障害のある方が経験する可能性のある問題に直面しながら、製品をデモするという、異なる学習スタイルをサポートします。しかし、ユーザーが毎日使用しているユーザー補助ツールを使って自分のプロダクトを体験することとは異なります。
Elisa: 音をオフにして字幕を読んでいた人が、自動生成された字幕がひどいことに突然気づくとき、私は少しイライラします。ええ。字幕はそうしたものではありません。障がいのある人の中には、障がいのない人が障がいのある人の経験をエミュレートして、ツールを必要としていないにもかかわらずツールについて不満を述べているのを見て、ご不便をおかけして申し訳ございません。
しかし、聴覚障がい者としての経験を何度も何度も説明しなければならないのは嫌です。毎回、健常者に私たちの経験を理解してもらいたいのであれば、その経験に対する彼らの反応に耐える必要があります。
ただし、ブラインド レストランでの食事やワインの試飲などの「体験」は、私を怒らせます。障害をコスプレするようなものです。しかし、ユーザーが機能をどのように使用しているか、読者がページをどのように読んでいるかを把握したい場合はどうすればよいでしょうか？問題ありません。実際には、それが最小値です。1 時間ほどお客様の立場になって、これらの機能が実際にどのように動作するのかを考えてみましょう。これは非常に重要です。
ユーザーがサイト内をどのように移動しているかを把握します。「すべてのリンクが新しいタブで開くことを示す警告バナーを上部に表示すればいいのではないか？」と思われるかもしれません。バナーからページを読み始める人がいるとは限りません。障がいのあるユーザーを念頭に置いて設計する。
1 つだけ: 無限スクロールの構築を中止する
Alexandra: エンジニアがサイトのアクセシビリティを高めるためにすぐにでも取り組んでほしいことはありますか？
Elisa: 無限スクロールは有害であり、誰も使用すべきではありません。見つからないと困るんです。パフォーマンスに悪影響を及ぼします。
また、DOM 内で視覚的にアイテムを移動させるのは非常に面倒です。タブの順序は、特にキーボード ユーザーにとって重要です。
詳しくは、Google のユーザー補助に対する取り組みと研究をご覧ください。Learn Accessibility のウェブ開発リソースに加えて、Google はユーザー補助機能に関するドキュメント作成コース（Tech Writing for Accessibility）を作成しました。
Google のユーザー補助チームの Twitter アカウント（@GoogleAccess）と Chrome チームの Twitter アカウント（@ChromiumDev）をフォローしてください。