「しまった、アプリが成功したのにアクセシビリティを考慮していなかった」

 (jacobbartlett.substack.com)
10 ポイント 投稿者 GN⁺ 2024-03-20 | 3件のコメント | WhatsAppで共有

SwiftUIでa11y（アクセシビリティ）を素早く適用する

  • SwiftUIアプリでアクセシビリティを見落としていた場合に、これを迅速に解決する方法を提示。
  • アクセシビリティはユーザーの16%が必要とする重要な機能であるにもかかわらず、開発中にしばしば無視される。
  • アクセシビリティを考慮していないアプリは、ユーザーに否定的な印象を与える可能性がある。

アプリのアクセシビリティを検査する

  • 実機でアクセシビリティをテストすることが重要。
  • コントロールセンターを最適化し、アクセシビリティ機能をすばやく適用できるように設定する。

テキストサイズの検査

  • iOSでは12種類のテキストサイズが提供されており、これをテストしてアプリが各サイズに適切に対応しているか確認する。
  • 最も大きいテキストサイズでもUIが正常に機能するか確認が必要。

スクリーンリーダーの検査

  • スクリーンリーダーを使うユーザーのために、VoiceOverのようなツールを使ってアクセシビリティを検査する。
  • 画像にアクセシビリティラベルを追加するといった簡単な修正でも、大きな改善が可能。

アクセシビリティを素早く適用する

  • 問題を把握したら、1つずつ迅速に解決する。

スクロール可能なコンテンツ

  • テキストサイズが大きくなったとき、コンテンツをスクロールビューに拡張して問題を解決する。
  • a11yScrollView() というカスタムビュー修飾子を使い、必要なときだけコンテンツをスクロール可能にする。

空間確保のコードスメル

  • Spacer() の代わりに frame() 修飾子を使って、より信頼性の高いレイアウトを構成する。

画像およびアイコンのサイズ調整

  • @ScaledMetric プロパティラッパーを使い、ユーザーのテキストサイズに応じて画像やアイコンを動的に調整する。

コンテンツの整列

  • ユーザーのテキストサイズに応じてコンテンツを整列できる A11yHStack を使う。

スクリーンリーダーの改善

  • accessibilityLabel、accessibilityElement(children:)、accessibilityRepresentation などを使って、スクリーンリーダーとの互換性を高める。

ネイティブコンポーネントの使用

  • 可能な限りネイティブのSwiftUIコンポーネントを使用して、パフォーマンスとアクセシビリティを向上させる。

ステークホルダーを説得する

  • アクセシビリティを重要視してもらうために、組織内で影響力を発揮する方法。
  • 法的要件とビジネス上の利点を強調し、アクセシビリティの重要性を際立たせる。

結論

  • アプリのアクセシビリティ問題を特定し、解決する方法について全体的な流れを説明。
  • アクセシビリティ向上のためにSwiftUIが提供するさまざまなツールと技術を紹介。

GN⁺の意見

  • この記事は、アプリ開発者にとってアクセシビリティが重要な理由と、実際に改善する具体的な方法を提供しており非常に有益。
  • アクセシビリティを考慮していないアプリはユーザー体験を損ない、法的問題を招く可能性があるため、開発初期段階からアクセシビリティを考慮することが重要。
  • SwiftUIのようなモダンなフレームワークを使う場合は、ネイティブコンポーネントの利点を最大限活用して、パフォーマンスとアクセシビリティを同時に向上させられる。
  • アクセシビリティ改善のために、コミュニティが提供するライブラリやツールを活用するのも良い方法であり、これによって開発プロセスを簡素化し効率を高められる。
  • アプリのアクセシビリティを改善することは、単なる技術的課題を超えて社会的責任と包摂性を実践することでもあり、すべてのユーザーが平等にサービスを利用できるようにすることが重要。

関連記事

3件のコメント

 
aer0700 2024-03-21

アクセシビリティを考慮することが、自分のサービスに忠実な顧客を生み出す方法になるのかもしれませんね
似た競合サービスがその機能をサポートしていない中で、自分たちのアプリだけがそれをサポートしていれば、顧客は私たちのものを使うはずです
 
godrm 2024-03-20

おお、これはLet’s Swiftでも紹介しないといけませんね（笑）
 
GN⁺ 2024-03-20
Hacker Newsの意見

  • 1番目のコメント要約:

    開発者は、「アプリを誰もが使えるようになるまで止まらない」という筆者の主張には同意していない。自分が開発したすべてのアプリは、ビジネス要件やアプリの重要・中核的な側面を犠牲にしない範囲で、できるだけ多くのユーザーに合わせて開発されている。そうでなければ、使えない製品になってしまう。

  • 2番目のコメント要約:

    開発者は、自分のアプリを視覚障害のある人でも使えるよう最善を尽くしている。最近のアプリでは、障害のない人にも使いやすく、障害のある人にも恩恵のある方法を見つけた。UIのどの要素でも長押しすると、その要素を説明するポップオーバーが表示される「ロングプレスヘルプ」機能を追加した。この機能はアクセシビリティラベルとヒントを使ってうまく動作する。

  • 3番目のコメント要約:

    実用的な記事として高く評価している。アクセシビリティは重要だが、アプリを最初からアクセシブルにしない開発者を怠慢だと非難するのは問題があると考えている。学ぶべき概念は多く、優先順位は衝突し、慣れるべきツールもあり、アクセシビリティのビジネスケースを作る必要もある。ほとんどの開発者やデザイナーはWCAGのルールをよく知らない。色のコントラスト要件を満たすブランドカラーを見つけるのも難しい。

  • 4番目のコメント要約:

    開発者はFlutterを使ってアクセシビリティを考慮せずにアプリを作ったが、アプリを6か月使っていた視覚障害のあるユーザーから苦情を受けた。Flutterはアクセシビリティの大半を自動で処理してくれ、カスタム機能も視覚障害のあるユーザー向けに大幅な修正をしなくても十分に動作した。

  • 5番目のコメント要約:

    なぜアクセシビリティオプションを視覚的に優先し、精密でタッチ密度の高いメディアに注釈を付ける必要があるのかという疑問を呈している。「低視力」版や「低タッチ精度」版のように、アクセシビリティを必要とするユーザー向けにカスタマイズされたアプリを提供するほうがよいかもしれない。

  • 6番目のコメント要約:

    新しいアプリやスタートアップが予想よりはるかに早く成功した場合の法的責任や猶予期間についての疑問。アイデアが機能するか確信が持てない段階では、アクセシビリティは大きな懸念ではないかもしれず、カリフォルニア州以外では、予想外の成功後にアクセシビリティの問題を解決するためにリソースを割り当てても、法的に大きな問題にはならないだろうと考えている。

  • 7番目のコメント要約:

    開発者は、父親が脳卒中により電動車いすを使うようになった経験を共有している。ADA準拠の重要性を実感し、開発者として世界をよりアクセス可能にするうえで大きな役割を果たせることを強調している。開発者に対し、自分の仕事をできる限り多くの人が利用できるよう努力してほしいと呼びかけている。

  • 8番目のコメント要約:

    iPhoneの「さらに大きな文字」と「ディスプレイズーム」オプションを有効にしているユーザーの体験の共有。これは障害のある人だけでなく、すべてのユーザーが自分の使い方に合わせてインターフェースを調整できる柔軟性とコントロールの問題でもある。ときには画面を見たくないときに読み上げてほしかったり、特定の部分だけを読んでほしかったりすることもある。

  • 9番目のコメント要約:

    アクセシビリティを必要とするコミュニティは、一般的にはまず要望を出し、その後で訴訟を起こす傾向がある。ADAは強力な法律だが、努力していれば通常は問題にならない。2000年ごろ、弁護士の監督のもとでアクセシビリティガイドを書き、その後も視覚障害のあるユーザーと協力してアプリにアクセシビリティを追加してきた。誰かに頼まれたら手を貸せばよく、そうすれば自分の仕事に対する強力な支持者を得られるかもしれない。

  • 10番目のコメント要約:

    アプリが成功した理由は、アクセシビリティ（a11y）や国際化（i18n）のような不要なものに時間を無駄にしなかったからだという意見。歴史的に見ても、成功した製品はどれも最初からアクセシビリティや国際化に注力していたわけではない。いまやアプリは成功しているのだから、アクセシビリティについて考え、そこにリソースを投入できる。