以下の文章は、Marco Arment さんによる Apple’s App Review Should Test Accessibility – Marco.org の日本語訳です。翻訳をご許可いただきありがとうございました。
The following is the Japanese translation of Apple’s App Review Should Test Accessibility – Marco.org by Marco Arment. Thank you Mr. Arment, for letting me translate his writing.
Apple のアプリ審査はアクセシビリティをテストすべき
Reuters の記者 Christina Farr が書いた記事 はひどい。どれほどひどいか知りたい人は、John Gruberのブログ記事を読んでみるといい。Apple が提供しているアクセシビリティ関連の機能は、業界標準のずっと先を行ってる。
一方、そのひどい記事からは読み取りにくいけれど、問題が残っていないわけではない。
アプリがうまく使えないと、生活がまわらなくなってしまうこともあるです。Jonathan Lyens さん(サンフランシスコ市に雇われていて、重度の視覚障害認定を受けている)は、職業検索サイト LinkedIn での職探しにとても苦労しています。
「あのアプリはひどいよ。ボタンがラベル付けされてないから、画面操作がすごく難しい。」Lyensさんによれば、ソーシャルメディアアプリにいたっては新しいバージョンのリリースごとに別の問題が生じるようで、「アップデートボタンを押すとき、いつも不安なきもちになってる」そうです。
いまでは、Apple や Google が開発者向けガイドラインでアプリのアクセシビリティを高める方法を示しています。ガイドラインには、ボタンにラベル付けをしておけばApple の VoiceOver が読み上げてくれる、などの内容が含まれています。
けれども、両社ともにアクセシビリティを必須とはしていません。一方、下品なコンテンツを含むアプリを禁止するなどのルールを厳密に課しています。アクセシビリティを評価する仕組みもありません。関係者からは、それがあれば大きな違いになるのに、といった意見も出ています。
標準的なアプリのUIはそのままでアクセシビリティが最高レベルになる。Apple はアクセシビリティの低さを理由にアプリを拒否したりしないし、お客さんの大半はアクセシビリティの仕組みに依存していないので、ほとんどの開発者にとって、アクセシビリティに関する苦情を耳にする機会は生まれなくなる。
しかも、アプリのリリース、アップデートの提供を急ぐあまり、UI変更の VoiceOver 対応をテストするとき、変更のいくつかを見過ごしてしまうことはよくある。自分だって、何度も見過ごしてしまったことがある。
けれど、アクセシビリティの問題がアプリの利用者数のわずかにしか影響しないとしても、実際に影響を受けるお客さんからすれば、「アプリが使えなくなる」という被害は甚大だ。致命的な被害になることだってある。
アクセシビリティの欠陥は、開発者にとって恥じるべきことだ。というのも、その欠陥はたいていすぐに直せるものだからだ。問題の大半は、カスタムコントロールやイメージボタンにラベルテキストを付与するだけで解決できる。めったにないような「複雑な」問題でも、1時間もかからず解決できるだろう。
個人的には、アクセシビリティを正しく提供できるよう努力しているつもりだ(忘れることもあるけれど)。自分が使うデバイスの「ホームボタン3度押し」ショートカットは、すぐにテストできるよう、いつも VoiceOver に設定してある。VoiceOver の利用者もベータテストに可能な限り入ってもらうようにもしている。今年の WWDC のラボでは、思慮に富んだとてもありがたいレビューをアクセシビリティ絡みで受けることができた。それでも、ラベルなしのボタン、埋もれてしまったビュー、アクセシビリティ機能から参照不可なカスタムビューをときどきリリースしてしまう。
実装が下手、もしくは用をなさないアクセシビリティ機能こそ、Apple のレビューチームが気を配るべき問題だ。それは、開発者の多くがテストするのを忘れるが、レビュー時に一緒にテストしてしまうのは Apple にとっては容易だし、不備の修正も簡単だ。
お客さんの目線に立ってみれば、それはより明確になる。Apple がアプリをレビューするから、最低限の品質とセキュリティが確保されていてお客さんは安心してアプリを買えるし、開発者にとっても得るものは多い 。 App Store のアプリケーション審査ガイドライン によると、審査の基本はとてもわかりやすい。
2.2 バグがあるアプリはリジェクトします
2.3 開発者の申請どおりに動作しないアプリはリジェクトします
そりゃそうだ。お客さんは、「謳い文句どおりのアプリが手に入るんだ」という認識を持っていいはずなんだ。
上述のルールはアクセシビリティには当てはまらないが、かといって VoiceOver を使ってるお客さんにとっては、ラベルなしのボタンや回避不可能な画面は「バグ」に他ならないし、アクセス出来ない機能があるアプリは「謳い文句どおりのアプリ」とは言いがたい。
こうなってしまうと、誰(Appleや開発者やお客さんたち)のためにもならない。特にアクセシビリティ機能に依存しているお客さんたちの場合がひどくて、そうと知らずにひどいアプリを選んでしまった場合、やりたいこともできなくなって、今後アプリを買うときには App Store を信用できなくなってしまうだろう。
ただ、ゲームを含むすべてのアプリに完璧なアクセシビリティを要求するのはおそらく無理難題だろう。とはいえ、他にもやり方はある。以下のようにすればいい。
- アクセシビリティのテストを希望する開発者向けに、アプリを申請する度に iTunes Connect でテストを申し込めるようにする。暗号化関連の画面で申し込めるようにすれば、申し込みの要否を必ず入力することになって、開発者が自覚できる。
- App Store のアプリのページにバッジを出す。それはアクセシビリティのテストを通過したことを意味し、お客さんがアプリ購入を検討するときの判断材料になる。
テストを通過するには、以下が順守されなければならない。謳われている内容がアクセシビリティを利用してすべてアクセス可能であること。利用可能なコントロールすべてに正確なラベルが付与されていること。回避不可能な画面や画面遷移中の行き止まりといった「UIナビゲーション上の罠」がないこと。 - 利用者が VoiceOver を有効にしている場合、アクセシビリティのテストを受けていないアプリのダウンロードや、テスト済みバージョンから未テストバージョンへのアップデート時に警告を出す。ユーザーは警告を受けて、そのまま続けるか中止するかの意思表示をする。該当者にとっても有意義だし、開発者にとってもアクセシビリティのテストに申し込むいいきっかけになるだろう。
現在進行形のこの問題に対して Apple ができることはたくさんあるし、ここに書いたような仕組みがあれば状況は劇的に改善されるだろう。
初出公開： 2014年7月15日、 最終更新日： 2014年7月15日