アクセシビリティ対応をやってみて分かったこと

Keychainでのデータ保護を見直したのをきっかけに、アプリの品質全般を見直す中で、「VoiceOver」というスクリーンリーダー機能の存在を思い出しました。視覚に障害のある方が音声で画面を操作する仕組みですが、自分のアプリで試したことは一度もありませんでした。

1. VoiceOverを初めてオンにして、自分のアプリが使えなかった

設定からVoiceOverをオンにして自分のアプリを操作してみたところ、ボタンを押しても「ボタン」としか読み上げられず、何のボタンなのか全く分かりませんでした。

Button(action: addItem) {
    Image(systemName: "plus")
}

アイコンだけのボタンには、視覚的には意味が伝わっても、音声読み上げ用の情報が何も付いていなかったのです。自分では便利に使えていたアプリが、別の使い方をする人にとっては全く機能していないという事実に、率直に驚きました。

調べてみると、SwiftUIには読み上げ用のラベルを指定する修飾子が用意されていました。

Button(action: addItem) {
    Image(systemName: "plus")
}
.accessibilityLabel("項目を追加")

このひと言を付けただけで、VoiceOverが「項目を追加、ボタン」と正しく読み上げるようになりました。見た目には何も変わらないのに、使える人の範囲が大きく広がるという体験は新鮮でした。

アイコンには意味を付けられるようになった一方、単なる背景装飾の画像まで律儀に読み上げられてしまい、逆に操作の邪魔になっていることに気づきました。

Image("decorativeBackground")
    .accessibilityHidden(true)

意味を持たない装飾要素にはaccessibilityHiddenを指定して、あえて読み上げの対象から外せると知りました。「全部に説明を付ける」のではなく、「意味のあるものだけに説明を付け、余計なものは隠す」という取捨選択が必要なのだと理解しました。

VoiceOverと合わせて、設定アプリの文字サイズを大きくして確認したところ、一部の画面でテキストが枠からはみ出して見切れてしまうことも発見しました。

固定のフォントサイズを指定していた箇所を、システムが管理する標準的なテキストスタイルに置き換えることで、文字サイズの変更にもある程度追従して崩れにくくなりました。VoiceOverだけでなく、文字を大きくして使う人への配慮も、同じ「アクセシビリティ」という枠組みの中にあるのだと気づきました。

自分が普段使う操作方法だけを基準にしていると気づけない課題が、実際に別の使い方を試すことで具体的に見えてくると実感しました。

本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。