「サポートの範囲外です」：Google のアクセシビリティ窓口はなぜバグ報告を届けられないのか

数日前、Google のアクセシビリティサポートチームにバグを報告したときのことを書いた。そのバグは、端末を再起動しない限り Android 上のすべてのスクリーンリーダーでタッチ探索が使えなくなるというもの。返ってきたのは、TalkBack をオフにしてからオンにし直し、使ってもいないアプリのキャッシュを消して、それから再起動しろという指示だった。再起動が唯一の一時的な回避策であることは、最初の時点でこちらが伝えている。まだ読んでいないなら、経緯はすべて「TalkBack をオフにしてオンにし直してみましたか？」に書いてある。読んでいないと、この記事は分かりにくい。

その後もいろいろあった。一つずつ書いていく。結末は、私が作り話で書けるどんなものより面白い。ただ、この件についての感想は四文字で言い切れるので、先に言ってしまおう。

要するに、ふざけるな、である。

前回までの話

最初の記事を公開したとき、Google のサポートチームから来た質問にはすべて答えた。提示されたトラブルシューティングは、役に立つはずがないと分かっているものも含めて全部試し、結果を報告した。それをやり終えれば、ケースを内部チームに回してさらに調査できる、と彼らは言っていた。だから全部やった。あとは回されるのを待った。

待つだけではなかった。翌朝またバグが出たが、今回は準備があった。端末が固まった瞬間に、完全なバグレポートを取得した。すべてのログバッファを残した。あの偽の指がなぜ画面に残るのかも突き止めた。TouchExplorer が有効なポインタを一つも持たないままドラッグ状態に入り込み、ポインタを含まない up イベントを組み立てようとして MotionEvent が例外を投げ、その例外が握りつぶされ、指を離すはずだった up イベントが永遠に送られなくなる。再起動以外に何をしても消えない理由も分かった。入力ディスパッチャーは注入されたポインタの記録を verifier に保持していて、その verifier はディスプレイが取り外されたときにしか破棄されない。だからアクセシビリティを切っても、すべてのアクセシビリティサービスを切っても、input filter を丸ごと外しても無駄だった。ここまでは実機で確認済み。シェルから cancel イベントで消す方法と、スクリーンリーダーが特別な権限を一切必要とせずに消す方法も見つけた。そのうえで修正を書いた。frameworks/base のアクセシビリティコードに対するパッチと、frameworks/native の入力ディスパッチャーに対するパッチの二つ。ここまでの内容を要約してケースに送り返し、ファイルをエンジニアに渡せる手段を再度求めた。あのフォームは今もスクリーンショットしか受け付けず、それ以外は一切受け付けないからだ。

根本原因、復旧方法、二つのパッチ、そしていつでも発火できる再現手順。すべて無償で、自分の時間を使って、まともに操作することも難しい自分の端末の上で仕上げた。

二人目のサポート担当者

次の返信は、前の担当者から引き継いだ別のサポート担当者から来た。ここは公平に書いておきたい。公平でありたいからだ。これは私が受け取った中で最良の返信だった。送った内容を本当に読んだ人間が書いた文章に見えた。正確な用語で問題を正しく要約していた。TouchExplorer が無効なドラッグポインタ状態に入った後、注入したポインタを解放できず、続いて InputDispatcher が後続のホバーイベントを拒否する、と。スクリーンリーダーユーザーへの影響も理解している、と言った。私の三つの質問については、検証していない技術的回答はしたくない、これらのフレームワークコンポーネントを担当するチームが答えるべきものだ、とも言った。最後に、トラブルシューティングの手順は出し尽くしたと理解している、と述べた。

彼に言えなかったのは、エンジニアリングチームの誰かが実際にこれを見るのかどうか、ということだった。アップロード用のリンクも、エンジニアリング側の窓口もなかった。ファイルは手元に置いておいてくれ、いつかケースに送る手段ができるかもしれない、と言うだけだった。丁寧で、知らないことには正直だった。だが、その後は何もなかった。

だから待つのをやめて、自分でバグを報告した。

102 分

Android には公開のイシュートラッカーがある。誰でも投稿でき、Android Accessibility というコンポーネントも用意されている。そこに全部書いた。端末とバージョン、自然な形での発火方法とシェルからの確実な再現手順、発火中にログで何が起きているか、なぜ再起動でしか復旧しないのか、実機での検証結果、スクリーンリーダー側で使える回避策、そして二つのパッチ。再現用の補助スクリプトも添えた。金曜の朝 08:17 に投稿し、リンクをサポートチケットにも送って、添付して回してもらえるようにした。

09:59、開発チームに転送したというコメント付きで、Google のエンジニアにアサインされた。

1 時間 42 分。その時点で、Disability Support はこのチケットを 4 日間抱えていた。そして 4 日間かけてエンジニアのところまで届かなかった。トラッカーは、私が二杯目のコーヒーを飲み終える前にやってのけた。

話はまだ進んでいる。これを書いている時点でステータスは Assigned、Severity は S2、Priority は P2。5 つの hotlist に入っている。114 人が +1 を付け、そのうちの一人はこの問題が「ずっとユーザーを苦しめてきた」とコメントしている。Blind Android Users などのフォーラムでも報告がある。つまり、私の端末だけの問題でも、私一人の問題でもない。視覚障害のあるユーザーはこの問題に長く悩まされ、端末を再起動し、それでも何も進まない。Google が示す経路がそもそも通じないからだ。

サポート対象外です

そして土曜の深夜、Disability Support から最後の返信が来た。

メールには、社内チームとともに私のケースを再確認したと書かれていた。チームの説明によると、Google Disability Support は「主に Google 製品内の既存のアクセシビリティ機能および支援技術の不具合、たとえば異常な動作や機能の停止のトラブルシューティングを支援する」という。

この一文をもう一度読んでほしい。私が報告した問題を正確に言い表しているからだ。タッチ探索は既存のアクセシビリティ機能だ。Android に組み込まれていて、Android は Google の製品だ。TalkBack も Google の製品で、この問題が起きると TalkBack は他のあらゆるスクリーンリーダーも巻き込んで動かなくなる。タッチ探索はシステム全体で動作を停止し、再起動するまで戻らない。誰の定義に照らしても、これは機能の停止だ。私はサポート範囲に収まっているどころか、まさに教科書通りの事例そのものだ。

ところが、そのすぐ次の段落にはこうある。「技術開発、カスタムアクセシビリティサービスのコーディング、カスタム Android フレームワークのパッチはサポート対象外です」と。つまり彼らはパッチをレビューできず、私が提案したフレームワークの修正を確認することもできない、というわけだ。

私は一度も Disability Support にパッチのレビューを頼んだことなどない。頼んだのは――これで四度目になるが――バグレポートをコードの責任者に転送することと、ログを送る手段を用意することだけだ。パッチはエンジニアリングチームに宛てたものだ。修正とは本来そう扱われるべきものだから、つまり使える相手の手に渡るべきだからだ。「カスタムアクセシビリティサービスのコーディング」とはおそらく Backtalk のことだろうが、それはこのバグとは何の関係もない。最初のメールでそう書いたし、二通目でも、三通目でも書いた。このバグは TalkBack で起きている。Google の TalkBack が、Google の Android 上で、Google のタッチ探索を使って動いているときに。

動けば動くほど、ケースは彼らの職務範囲から押し出されていく。ログを添えてバグを報告すれば、キャッシュを消せと言われる。キャッシュは無関係だと示せば、まず自分で切り分けろと言われる。切り分けて原因を突き止め、修正まで書けば、バグ修正はうちの仕事ではないと言われる。このループのどこにも、報告をエンジニアに転送するステップはない。これからも現れない。ただ、私がずっとそのステップを探し続けているだけだ。

そして返信にはリンクがいくつか添えられていた。Android Developers のアクセシビリティガイド――開発者向けに、自分のアプリをスクリーンリーダーに対応させる方法を説いた文書で、入力ディスパッチャー内のバグとの関連性はレシピ本と大差ない。追加のアクセシビリティリソースのページ。それから Android Accessibility Help Community。ここで「発見したことを共有し、タッチ探索の動作について議論し、他のアクセシビリティ開発者と交流できます」と書いてあった。フォーラムだ。他のユーザーが無償で互いに質問に答え合っている場所――このバグが何年も放置されてきたのはまさにそのせいであり、今も残っている理由でもある。

メール全体を通して、issue tracker には一言も触れていない。前のメッセージで私はそのリンクを送ったばかりだった。彼らがこのメールを書いた時点で、その issue はエンジニアの手元に丸一日半あった。私のケースを審査した人物は、リンクを見落としたか、あるいは見たうえで、バグがすでに Google のエンジニアにアサインされている視覚障害のある開発者に最も伝えるべきことは、サポートフォーラムに投稿しろということだと判断したのだ。

締めの一文がすべてを物語っている。「Google のアクセシビリティ機能に関する具体的な機能障害が発生した場合、またはアクセシビリティ体験の改善についてご提案がある場合は、お気軽に再度ご連絡ください」。

連絡した。この一件はまさにそれだ。

これが意味するもの

最初の記事で書いたが、私はこのサポート担当者たちを責めていない。今も責めていない。二人目の担当者は実際まともだったし、最後のメールは彼が書いたものではないと見ている。社内チームの決定が現場に降りてきて、名前だけ載せたように読める。彼らはシステムの中で働いていて、そのシステムが彼らのできることを決めている。

そのシステムが何のためのものなのか、今なら最初から最後まで見通せる。

Google Disability Support は、Google のアクセシビリティ機能の使い方に答えるヘルプデスクだ。設定が見つからなければ探し方を教える。TalkBack の読み上げが速すぎれば、どこで遅くするかを教える。そういうのは確かに得意なのだろうし、それ自体に価値はある。だが、Google にアクセシビリティのバグを報告する窓口ではないし、なることもできない。その道をたどっても、バグを直せる人には決してたどり着かないからだ。視覚障害のあるユーザーが機能が壊れたと伝えれば、TalkBack をオフにしてオンにし直す方法を教えることはできる。それも通じなくなったら、自分たちの管轄外だと言ってフォーラムへ送るしかない。

そしてサポート窓口が存在する唯一の理由は、まさにそれがやらないことにある。障害報告を受け取り、直せる人のところへ届けることだ。

今度は私ではなく、別の誰かがこの問題に遭ったとしよう

これを、めでたしめでたしの物語として読むのはたやすい。バグは結局エンジニアの手に渡り、私は Disability Support を完全に迂回してそれを成し遂げた。だから教訓は issue tracker に issue を立てろ、と。次からはヘルプデスクに頼るな、と。

違う。ふざけるな。

このバグに実際にぶつかるのは誰か考えてほしい。adb とノート PC があって、入力パイプラインを理解している開発者ではない。視覚障害のある人で、Android を使い始めたばかりかもしれず、年配かもしれず、そのスマホがメールを読み、家族と話し、タクシーを呼ぶための主要な道具で、ある日を境に画面を触っても何も見つけられなくなった人だ。その人は TouchExplorer が何かを知らず、input dispatcher という言葉も聞いたことがなく、自分の画面に偽の指が一本貼りついていることも知らない。しかも知る術がない。教えてくれる道具はどれも、PC とケーブルと開発者オプションとコマンドラインを必要とするからだ。

そこでその人は Google の言うとおりにした。Disability Support に連絡し、「スマホのタッチスクリーンが読み上げない。スワイプは効く。再起動すれば直るが、すぐ再発する」と伝えた。

これは完全に合格点のバグ報告だ。症状があり、回避策があり、再発することも書いてある。ユーザーがここまで出せれば十分で、正直なところ、ほとんどの人にはこれすらできない。

結末ももう分かっている。ユーザーは 9 つの質問をされ、TalkBack をオフにしてからオンに戻すよう言われ、近くに視力のある介助者を置くよう指示される。Android Accessibility Suite を更新してキャッシュを消去するよう言われ、そのとおりにする。指示した人間が何をしているか分かっていると信じているから、一つずつ慎重に従う。再起動して直り、復旧したと報告し、チケットは「解決済み」で閉じられる。一週間後にまた出て、また最初からやり直す。あるいは、もう無駄だと悟って諦め、スマホが壊れるまで一日に何度か再起動し、Android で視覚障害者として生きるとはそういうものだと受け入れる。

「再起動」という答えを受け入れず、食い下がったとしても、返ってくるのはせいぜい私が受け取ったあのメールだ。範囲外です。開発者ドキュメントを読んでください。フォーラムで質問してください。

この人に、自分で Android の課題トラッカーを探せというのか。アカウントを登録し、数百あるコンポーネントから正しいものを選び、エンジニアが真面目に読む報告書を、デバイスの指紋と再現手順付きで書けと。しかも本人には入手しようがないログまで添えて。もちろん違う。ユーザーにそんな要求をすること自体が理不尽であり、障がい者向けに設けられたサポート窓口を通じて、障がいのあるユーザーにそれを求めるのは言語道断だ。視力のある人がスマホの画面が突然反応しなくなったとき、開発者トラッカーにバグを報告しろと言われるとは誰も思わない。Google か Samsung か、スマホを売った店が何とかするはずだと思う。それを最も困難を抱えた人に押しつけ、尋ねてきたら範囲外と突き放す——問題のすべてがこの一言に凝縮されている。

まさにそこが、私の経験よりたちが悪い点だ。私はこの仕組みを迂回する力がある。それでも丸 4 日、ブログ記事 1 本、根本原因の分析 1 本、パッチ 2 つを要した。他の人たちには、この仕組みしかない。そして「タッチ探索が壊れた」という問題に対する仕組みの最終的な答えは、タッチ探索が壊れている、うちの管轄ではない、だった。

だから答えは「課題トラッカーに報告しろ」ではない。Disability Support が報告するべきなのだ。それは Google だ。社内の他の部署と同じく、同じ社内バグ管理システムにアクセスできる。障がいのあるユーザーが Google のアクセシビリティ機能の不具合を報告してきたら、このチームの誰かがそれを書き留め——ユーザーが出せる情報だけでも——その機能を担当するチームに起票し、起票したとユーザーに伝えるべきだ。それが仕事だ。「エスカレーション」とは本来そういう意味だ。このチームに研修もツールも権限もないというなら、それはユーザーに「対象外」と告げる理由ではなく、チームを立て直す理由だ。

Google は障がい者を Disability Support へ誘導する。ヘルプページのあの窓口、有人対応のアクセシビリティ窓口、機能が使えないときに頼るべき場所がそれだ。ところが、誰にでも影響する問題を抱えた当事者がそこへ来ると、まったく対応できない。そこにいる人が無能だからではない。Google がこの職務に定めた範囲が、本当に役に立てる場所のちょうど手前で終わっているからだ。

このバグに遭遇したら

Android を使う視覚障害者で、タッチ探索が突然効かなくなり、スワイプとタップはまだ正常というなら、それはこのバグだ。あなたのせいでも、スクリーンリーダーのせいでもない。今のところ再起動で一時的に復旧する。

少なくとも一件は報告済みだ：TouchExplorer leaves injected pointers down; InputDispatcher then rejects all touch exploration events until reboot。Google アカウントがあって構わなければ、ログインして+1 を付けてほしい。情報を補足できるなら、たとえば端末が Samsung でない、特に Pixel だとか、Android のバージョンだとか、問題が出たときに何をしていたかとか、コメントを残してほしい。本来あなたがやるべきことではない。だが、この報告が実際に直せる人の手に届く唯一の場所であり、同じ問題に遭ったという人が増えるほど優先度は上がる。

他のアクセシビリティのバグに遭い、対象外と言われたことがあるなら、報告したのは間違いではないし、求めたものも間違っていない。責任ある立場の人間に仕事をしろと言っただけだ。

はっきり言おう。Google、ふざけるな。バグを直せ。そして窓口も直せ。次にこれにぶつかった視覚障害者が、声を届けるために君たちのエンジニアの仕事を代わりにやらなくて済むように。