アクセシビリティに関する改善点を情報収集する

[keiji]

要旨 / Abstraction

アクセシビリティに関係して不便になりそうな点、改善点についてアイデア・コメントを募集します。

たとえば、スクリーンリーダーで正しく読み上げられないボタンや、画面で可読性の悪い（文字の大きさの小さな）箇所がある。その他、利用者が不便を感じる（感じた）点などについて、アイデア・コメントを募集します。

寄せられたアイデアについて技術的に解決できそうなものであればIssue化して開発チームに共有します。

また必要に応じてGitHub Discussionの導入・移行も検討します。

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

幅広い利用者がいるCOCOAにとって、アクセシビリティが重要な課題の1つであることは間違いない。

これまで、いくつかの課題についてはコントリビューターからIssueとして投稿され、Twitterなどから収集してIssue化したものもある。これらはアクセシビリティ関連でありながら個別のIssueとして存在しているので、たとえばアクセシビリティの専門家による検証や優先順位設定の際にワンストップで確認できない。

解決策についてお書きください / Describe the solution you'd like

状況を総覧できる統合的なIssueを用意する。
また、アクセシビリティに関する課題をコメントとして受け付けることで報告のハードルを下げることができる。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

ラベル Accessibility を追加すると、Issueをフィルタリングできるようになる。
ラベルについてはこのIssueと排他の関係ではないので、どちらも実施するという選択肢もある。

その他 / Additional context

関連Issue

• 接触状況を表示する画面のピクトグラムで、「すべきこと」と「すべきでないこと」が無秩序に並んでいる #186
• [Android] フォースダークモードの時に表示が乱れる #135
• [Android] スクリーンリーダーで「陽性者との接触を確認する」ボタンが正しく読み上げられない #125
• [Android] OSのユーザー補助オプションが反映されない #50

[keiji]

一回こちらに置く（確認後、別途Issueにする）
#125 (comment)

[tatsu-jp]

iOSのDynamic Type機能と組み合わせて確認した結果を共有します。
(技術的に解決できるのかは未検討です)

問題

• Dynamic Type機能を利用(大きな文字に変更)すると、ボタンの文字が読めない
(省略されるのは仕方ないと思うが・・・)
• 文字の大きさが変化しない部分がある(デザイン維持のため？)
• 8桁の処理番号の入力内容を確認できない(placeholderが邪魔している)

iPhone12 iOS14.5シミュレータで確認

再現手順

1. [設定] > [アクセシビリティ] > [画面表示とテキストサイズ] > [さらに大きな文字] に移動
2. 機能をONにして、スライダーをMAXまで移動
3. アプリを起動（起動済の場合は一旦終了してから起動）

確認画像

ボタン

意味が分からないので怖くて押せないかもしれません。

メニュー

ギリギリ理解できそうです。

ヘルプの選択肢

途切れているように見えます(ボタンのように省略されない？）

処理番号の入力

1つ目のイメージは処理番号を入力しています(placeholderが大きすぎて隠れてしまっている)。
2つ目のイメージが分かりやすいと思います。

[heykuro]

@tatsu-jp ありがとうございます。私が不勉強で申し訳ないですが、さらに大きな文字の表示でMAXまでは対応できているべきかどうかというのはどう考えるのが良いでしょうか。

一定レベル以上の大きさになれば視覚的に差異は発生しないのであれば、少なくともその大きさまでは対応できるように調整、最大値まで対応できないと排除されてしまうユーザーが出るということであればそこまで対応、ということになると思いますが、もしガイドラインや推奨などご存知でしたら。

そもそも変わらないところについては確認します。ご指摘ありがとうございます！

[tatsu-jp]

@heykuroさん、コメントありがとうございます。

「みんなの公共サイト運用ガイドライン」には以下の記述があります。私の考えですので間違っていたらすみませんが、Cocoaはアプリの特性からすると「JIS X 8341-3:2016(ウェブアクセシビリティ規格)」を参考にして対応すべきではないかと考えています(関係の無い項目は除く)。

参考)ネイティブアプリケーションのアクセシビリティ
特定のコンピューターの機種やOS(オペレーティングシステム)上で動作するネイティブアプリケーション
(例:公的機関等が開発し提供するスマートフォン向けアプリケーションなど)は、ウェブアクセシビリティの対象ではありませんが、
今後開発提供を行う場合に、公的機関の情報アクセシビリティを確保する観点からJIS X 8341-6:2013を参照するなどにより、
アクセシビリティに対応することが望まれます。
※参考文献1.より抜粋

補足)JIS X 8341-6:2013 = 高齢者・障害者等配慮設計指針―情報通信における機器，ソフトウェア及びサービス―第６部：対話ソフトウェア 

テキストサイズについては、JIS X 8341-3:2016内に「1.4.4 テキストのサイズ変更」という基準があります。

1.4.4 テキストのサイズ変更：(レベル AA)
キャプション及び文字画像を除き、テキストは、コンテンツ又は機能を損なうことなく、支援技術なしで 200％ までサイズ変更できる。
※参考文献2.より抜粋

上記の基準を満たすには、Dynamic TypeのBody Styleのサイズを基準にして考えるとAX2までの拡大をサポートすれば良いのではないかと思います。上記基準を満たすことで多くのユーザーが救われると思うので、MAX対応は優先度が低くて良いと考えます(開発リソースがあれば対応)。

<Dynamic Type Sizes & Larger Accessibility Type Sizes>
- Large(Default): body size = 17 points
- AX2: body size = 33 points　// さらに大きな文字=ON, スライダーは最大(右端)から左へ3つ移動
- AX5(MAX): body size = 53 points　// さらに大きな文字=ON, スライダーは最大(右端)まで移動
※参考文献3.より抜粋。他スタイルは参考文献を参照してください。基準点の考え方によっては対応に差が出ると思います。

ただ、AX2でも同様の問題が発生します(AX5と比較すると問題箇所は減ります)。AX2対応の優先度を考える上で、JIS X 8341-3:2016のレベル概念を説明します。

- レベルA(25の達成基準)：アクセシビリティ確保に最低限必要なレベル
- レベルAA(13の達成基準)：諸外国でも公的機関に求められるレベル
- レベルAAA(23の達成基準)：レベルAAAを目標とすることは推奨しない
※参考文献4.より抜粋
(追記) 個数が間違っていたので修正

「みんなの公共サイト運用ガイドライン」では"テキストのサイズ変更"が該当するレベルAAまで準拠することを求められていますが、冒頭にあるようにネイティブアプリケーションについては必須ではありません。ですので、AX2対応についてはアクセシビリティ確保と言う観点で対応した方が良いと思いますが、不具合対応・機能エンハンス等と比較してどちらを優先すべきかは、プロジェクト状況に応じて判断すべきだと思います。

以上のように考えていますが、テキスト拡大の対応内容については異なる考え方や案もあると思います。Cocoa要件定義書にはアクセシビリティに関する記述がありますので、Cocoa開発メンバー内でもアクセシビリティの基準や考え等をお持ちではないかと思います。どのような方向性で改善していこうと考えているのか、GitHubコミュニティ側にも共有していただけると専門家のコメントを貰う機会が増えるかもしれないと思いました(すみませんが、私はアクセシビリティの専門家ではないです)。

参考文献

1. みんなの公共サイト運用ガイドライン(2016年版): https://www.soumu.go.jp/main_content/000439213.pdf
2. テキストのサイズ変更(達成基準1.4.4を理解する): https://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html
3. Apple Human Interface Guidelines(Dynamic Type Sizes&Larger Accessibility Type Sizes): https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/typography/
4. JIS X 8341-3:2016 概要: https://www.soumu.go.jp/main_content/000439181.pdf
5. JIS X 8341-3:2016 達成基準 早見表(レベル A & AA)：https://waic.jp/files/cheatsheet/waic_jis-x-8341-3_cheatsheet_201812.pdf
6. JIS X 8341-3:2016 解説: https://waic.jp/docs/jis2016/understanding/201604/

[heykuro]

ありがとうございます。COCOAではアクセシビリティについてJIS X 8341-3:2016を前提としていますので、ご指摘の通りだと思います。Dynamic Typeについてどうこうというよりは、そもそもどこまで満たすかという観点で考えるということですね。

どのような方向性で改善していこうと考えているのか、GitHubコミュニティ側にも共有していただけると

こちらもありがとうございます。ご指摘の通りなので、検討して皆さんに共有できるようにしたいと思います。

[i-maruyama]

1. ボタン内の文字列が省略される現象は、サポート外の多言語バージョンに長い文字がある場合にも発生する可能性があります。
2. 一方、 Android では文字拡大しても、ボタン内文字列は改行されて表示されるので問題ないのですが、処理番号入力部分は同様に見えなくなるようです。

以上です。

[keiji]

Google I/O Adventureの「Accessibility（A11Y）」エリアから展示リンクを回収してきた。

https://gist.github.com/keiji/d52ce35cc26821a2df0f7415be7a141d

[RyoAbe]

@keiji

はじめまして、freee株式会社でiOSアプリ開発をしている abe と申します。

まずはじめに、アプリ全体で現状どの程度アクセシビリティ対応できているのかの状況把握が大事なのではと考えました。
そこで、弊社の Webコンテンツ向けアクセシビリティガイドライン をベースに、モバイル向けにカスタマイズしたチェックリストを使用して、取り急ぎiOS版アプリの ホーム画面 のみチェックを通してみました。

iOS版COCOA アクセシビリティチェック - Google スプレッドシート

ホーム画面のチェック結果 をご確認いただき、アクセシビリティ対応のために有効そうでしたら他画面も進めようかなと考えております。

ご意見お待ちしてます。

[keiji]

@RyoAbe
アクセシビリティチェック拝見しました！　本当にありがとうございます。
Webコンテンツ向けアクセシビリティガイドラインそれぞれのチェック項目の解説リンクも、とても勉強になります。

縦画面固定については、ぼくはこれまで深く考えていなかったのですが、確かに車椅子などに端末を固定している利用者は不便ですよね。
早速Issueにしておきます。

もちろん他の画面でも（ご無理のない範囲で）情報をいただけるとうれしいです（いただいているシートを見ながらぼくも各画面を確認してみます）。

[RyoAbe]

@keiji 引き続きチェックを進めているところなんですが、質問させてください。
陽性者との接触が確認された場合の画面、陽性登録後の画面、こちら２画面が本アプリの重要な機能になるのかなと思うのですが、こちらはどのようにしてチェックすると良さそうでしょうか？

[RyoAbe]

@keiji ホーム に加えて、過去１４日間の接触 画面、陽性情報の登録 画面のチェックもやってみました。

チャックNGとなる項目の現時点での傾向が見えてきたので、共有します。ご参考まで🙇‍♂️

• VoiceOverの左右スワイプで次の要素に移動しないことがある
  • ホーム
    「周りの人達を守るために〜」にフォーカスがあたった後、その下の「陽性情報の登録」にフォーカスが移動しない
    https://drive.google.com/file/d/1d587AQY1j9Jx9jg7khudKXT2vqjokjpC/view?usp=sharing
  • 過去１４日間の接触
    画像から下のボタンにフォーカスが移動しないときがある
    https://drive.google.com/file/d/1pkfK5N3Qea6IJcBg6d75IkL0YdU3_zDA/view?usp=sharing
  • 陽性情報の登録
    「その通知が届いた人に」〜以降にフォーカスが移動しないことがある
    https://drive.google.com/file/d/1KHSpCKMfE4e_Kx1BvrvpBLpV8FR5chih/view?usp=sharing
• 設定から文字サイズ大きくするとボタンのラベルが「◯◯...◯◯」となり読めなくなる
  • ホーム
    https://drive.google.com/file/d/1wiQ9p19R5S5b_RnS-ezcOgc9xpIztg9M/view
  • 過去１４日間の接触
    https://drive.google.com/file/d/1kI4lB9Xjz--yMpKSWU2OC1VdaquNhwVp/view?usp=sharing
  • 陽性情報の登録
    https://drive.google.com/file/d/1IxhVvH0pslFjDSvLCleCo-JM16glIl-X/view?usp=sharing
• 画像に適切なラベルがセットされておらず「イメージ」と読み上げられる
  • ホーム
    https://drive.google.com/file/d/1d587AQY1j9Jx9jg7khudKXT2vqjokjpC/view?usp=sharing
  • 過去１４日間の接触
    https://drive.google.com/file/d/1pkfK5N3Qea6IJcBg6d75IkL0YdU3_zDA/view?usp=sharing
  • 陽性情報の登録
    https://drive.google.com/file/d/1mOXfVO-Rx1_qMNKcLpfn25xYAFNd0oYY/view?usp=sharing
• 画面回転しない
  こちらはすでに issue にして頂いてるかと思います🙇‍♂️ 画面回転に対応する #195

[i-maruyama]

読み上げは #125 も参考にされてください。（こちらは改善されたものが、もうすぐアップされるのかもしれません）

陽性者との接触が確認された場合の画面、陽性登録後の画面、こちら２画面が本アプリの重要な機能になるのかなと思うのですが、こちらはどのようにしてチェックすると良さそうでしょうか？

私が最も簡単だと思う方法は、デバッガでブレークポイントを設定して内部変数を書き換えて、アプリの機能を試すというものです。皆さん普通は、プログラムを書き換えておられると思います。

私も約１か月前、そういうことはプログラムしなくても簡単にできるようにした方が良いと思い、議論の中で以下のようなデバッグページが作られて、まだ取り込まれていないという現状です。
#160 (comment)
本当はページ以外にも、各種ユーザーへの通知も重要ですが、こういうのを簡単に見る仕組みもまだ議論中です。
#179 (comment)

[RyoAbe]

@i-maruyama 返事ありがとうございます。

読み上げは #125 も参考にされてください。（こちらは改善されたものが、もうすぐアップされるのかもしれません）

こちらは、Android版COCOAの読み上げ（TalkBack）対応ですかね？自分の方で直近アクセシビリティーチェックを進めているのはiOS版なので、Android版も別途チェック進めてみようと思います。
ちなみに、iOS版のアクセシビリティー対応は別issueで進んでたりするのでしょうか？

私が最も簡単だと思う方法は、デバッガでブレークポイントを設定して内部変数を書き換えて、アプリの機能を試すというものです。皆さん普通は、プログラムを書き換えておられると思います。

私も約１か月前、そういうことはプログラムしなくても簡単にできるようにした方が良いと思い、議論の中で以下のようなデバッグページが作られて、まだ取り込まれていないという現状です。
#160 (comment)
本当はページ以外にも、各種ユーザーへの通知も重要ですが、こういうのを簡単に見る仕組みもまだ議論中です。
#179 (comment)

なるほど。取り急ぎ、手元で実行して試してみようと思います🙏

[keiji]

@RyoAbe
画面のチェックありがとうございます！

陽性者との接触が確認された場合の画面、陽性登録後の画面、こちら２画面が本アプリの重要な機能になるのかなと思うのですが、こちらはどのようにしてチェックすると良さそうでしょうか？

こちらお返事が遅くなりました。要請登録後や接触履歴画面など、特定状況でしか表示されない画面については @i-maruyama さんが提案をしてくださっているDebugPageを使うのが良いと思います。DebugPageのPull Requestについては変更が大きくてmaster（main）に取り込まれるのは先になりそうなので、ひとまずcocoaリポジトリにfeature/debug_pageというブランチを作れば目に留まりやすいですから、そこで育てていくのもいいかもしれません。

[RyoAbe]

@keiji ありがとうございます。DebugPageというのがあるんですね。まずは手元でビルドできるよう環境を整えて確認してみます。

[Takym]

関連する Issue として他にも #107 (設定画面)もあったと思います。