［連載］植木 真の「こんなブログ記事見つけました！」
第49回:iOSアプリにおけるアクセシビリティの概観メモ

iOS のアクセシビリティ

さてさて、前回は「Android アプリのアクセシビリティガイドライン概観メモ」という記事をご紹介しましたが、いかがでしたでしょうか。

今回ご紹介する記事はこちら。

• iOSアプリにおけるアクセシビリティの概観メモ

Android アプリのアクセシビリティガイドライン概観メモ ::ハブろぐ の続きです。前回、iOS のドキュメントをうまく見つけられなかったので Android だけ目を通しましたが iOS も読んでみます。

ということで、そうです。前回ご紹介した記事の続編です。ということで、iOSのアクセシビリティについて書かれた記事を見ていこうと思います。

プログラミングガイド

iOSアクセシビリティプログラミングガイドは、幸い日本語が用意されてるので読みやすくて安心です。英語版は PDF でありませんが Accessibility Programming Guide for iOS と About Accessibility Verification on iOS に相当するものと思われます。

「[iOSアクセシビリティプログラミングガイド(https://developer.apple.com/jp/documentation/iPhoneAccessibility.pdf)」は、日本語です！　これは有難いですね。アクセシビリティ関連のこういったドキュメントは、英語版しかないことが多いので、いざ読もうと思うと相当の集中力が要求されますから、ホント助かります。

Apple いわくアクセシビリティは正義

上から順にふんふんと読み進めた果てに正しいことであるの断言。英語では"It's the right thing to do"と書かれていました。この姿勢がアクセシビリティのブランディングを一部で敗北せしめた根源では...？という気がしなくもありませんが、それは別の機会に述べるとして Apple さまがおっしゃるならジャスティスです。

はい、最初からいきなりカウンターパンチが飛んできました。いわゆる「right thing to do」問題です。外国のWebアクセシビリティのプレゼンテーションなんかでも、時折使われるフレーズです。ま、別に間違いではないんですけど、うーん、たしかに正直これでは人はなかなか動かないですよね、というのが個人的な実感。筆者は「それは別の機会に述べるとして」とおっしゃっているので、ワタクシもその「機会」を待ちたいと思います。

UI Accessibilityプログラミングインターフェイス

UIKit の上に UI Accessibility API のアクセシビリティ属性を提供し、VoiceOver がそれらを解釈することで UI はアクセシブルなものになります。主たる属性は次の5つです。

このあたりは、何となくHTMLチックであり、WAI-ARIAチックな感じがしますね。このへんは、VoiceOverで合成音声に変換するためには...という視点で書かれているので、余計にそうなのかもしれません。要は「マシンリーダブルにしよう！」ということであって、アクセシビリティを確保するための基本は、HTMLのWebページと同じ考え方だと言えるかと思います。

ラベルやヒント作成のためのガイドライン

Web でもそうですが、UI コンポーネントが本来もっている読み上げ可能な情報との干渉を考慮しつつ、適度なテキスト情報を付与するには思ったよりも配慮が必要です。iOS の実装ガイドラインにはラベリングに関するアドバイスがあり、次のリストはラベルテキストに関するアドバイスです。

記事では、さらに「ヒントテキストに関するアドバイス」も紹介しています。こういうガイドラインがあるところは、何となくAppleっぽいですね。「動詞で始め、主語を省略する」なんていうのは、英語には適用できるけど、日本語の場合は語順として動詞を先頭にもってくるのは厳しいかも？

とはいえ、どれもなるほどと思わせることばかりですし、これはどんなWebページやWebアプリにでも使えそうですね。

Traits ( 特性 ) の指定

インターフェイスの Traits ( 特性 ) は次のような選択肢が用意されてあります。たとえばタップすると特定の URL を開く画像は、Image であり、Link でもあります。Traits の候補で説明可能な特性は、Traits として情報をべきで示すべきありラベルやヒントと重複するべきではありません。

"Traits"という聞きなれない単語が出てきました。"Trait"を辞書で調べると、「特徴、特色、特質」と出てきますが、WAI-ARIAなんかでよく使われている"role"（役割）みたいなものでしょうかね。

「iOSアクセシビリティプログラミングガイド」のほうも読んでみると、こんなふうに書いてあります。

ボタンやテキストフィールドなどの標準のUIKitコントロールは、Traits属性用のデフォルトの内容を用意しています。アプリケーションで標準のUIKitコントロールのみを使用している（かつその動作をまったくカスタマイズしていない）場合、これらのコントロールのTraits属性を変更する必要はありません。

はい、やはりHTMLでいうところの"role"と同じみたいですね。例えば、HTMLのa要素にはリンクというroleがデフォルトで設定されています。このa要素を使って、その本来のroleであるリンクとして実装していれば何もしなくていいのと同じです。

WAI-ARIAでは、role属性を用いることによって、このデフォルトのroleを上書きすることができます。例えば、a要素を使っているけど、role="button"を指定すれば、それはデフォルトのroleのリンクではなく、ボタンに生まれ変わるのと同じです。

ただ、何でもかんでもrole属性で変更すればいいわけではなくて、標準の要素がある場合はそれを使いましょう。ボタンなら、リンクのa要素を使ってrole="button"を指定するのではなく、最初からbutton要素を使いましょうという原則があります。

つづきはメルマガで……。