Empowering developers to build amazing experiences.
Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.
モバイル アプリのアクセシビリティ テストでは、アプリがすべてのユーザー、特に障害のあるユーザーにとってアクセス可能であることを確認します。このプロセスでは、アプリケーションの設計、コンテンツ、機能を評価し、次のことを確認します。
WCAG (Web コンテンツ アクセシビリティ ガイドライン) アクセシビリティ標準に準拠しています。
スクリーン リーダー、音声コントロール、代替入力方法などの支援技術と互換性があります。
モバイル アプリのアクセシビリティ テストが必要な理由は次のとおりです。
WCAG (Web コンテンツ アクセシビリティ ガイドライン) 準拠は、障害を持つ人々がモバイル アプリにアクセスできるようにする上で重要です。もともと Web コンテンツ用に作成されたものですが、WCAG の概念と基準はモバイル アプリにも適用できます。
Principles of WCAG Accessibility
WCAG 準拠がモバイル アプリのアクセシビリティに与える影響は次のとおりです。
1. 知覚できる
写真やアイコンなどのテキスト以外の項目については、認識可能なテキストの代替を提供します。たとえば、写真やアイコンのラベルに代替テキストを含めると、スクリーン リーダーが視覚障害のあるユーザーにこれらの項目を伝えることができるようになります。
情報を失うことなく、コンテンツをさまざまな形式 (よりシンプルなレイアウトなど) で配信できるようにします。モバイル アプリの場合、アクセス可能な横向きモードと縦向きモードを提供することも含まれます。
テキストと背景色の間に十分なコントラストを確保し、アプリの操作を妨げることなくテキストのサイズと音量を変更する選択肢を提供することで、ユーザーが資料をより簡単に視聴および聴取できるようにします。
2. 操作可能
ユーザーがアプリ内を移動したり、コンテンツを見つけたり、現在地を確認したりするためのオプションを提供します。これには、明確にラベル付けされたボタンや一貫したナビゲーション パターンが含まれます。
3. 理解できる
ユーザーがエラーを防止し、修正できるように支援します。これには、明確なエラー通知と簡単にアクセスできる支援リソースが含まれます。
4. 堅牢
3 WCAG Conformance Levels
例1: スクリーンリーダーを使ったテスト
結果:一部のボタンに説明ラベルがないため、視覚障害のあるユーザーがボタンの目的を理解するのが難しい場合があります。
例2: 色のコントラストテスト
適切なツールを選択するためのステップバイステップのガイドを以下に示します。
以下に基づいてテストのニーズを理解します。
視覚障害、聴覚障害、運動障害、認知障害などの障害の種類。
ツールがサポートするプラットフォーム (iOS、Android、またはその両方)。
使いやすさ:特にアクセシビリティを専門としていない開発者やテスターにとって、ツールはセットアップと使用が簡単である必要があります。
統合機能:ツールが既存の開発、CI/CD、テスト ワークフローと統合されるかどうかを確認します。
レポートとドキュメント:ツールは明確で実用的なレポートを提供する必要があります。さまざまな形式でのレポートのエクスポート、問題追跡システムとの統合、問題の解決に関するドキュメントなどの機能を探してください。
サポートとコミュニティ:優れたカスタマー サポート、トレーニング リソース、アクティブなユーザー コミュニティを備えたツールを検討してください。
コスト:一部のツールは無料 (オープン ソース) ですが、サブスクリプションまたは 1 回限りの購入が必要なものもあります。予算と提供される機能に合わせて選択し、投資収益率 (ROI) のバランスをとってください。
無料トライアル:多くのツールでは無料トライアルまたはデモ版を提供しています。これらを使用して、テスト環境でのツールの有効性を評価します。
実際のテスト:アプリの小さなセクションでツールをテストし、実際のシナリオでどのように機能するかを確認します。
現在、市場では数多くの人気のモバイル アプリ アクセシビリティ ツールが使用されています。Android または iOS のどちらでも機能するものもあれば、クロスプラットフォームのものもあります。
Google ユーザー補助スキャナは、ラベルの欠落、タッチ ターゲットの小ささ、色のコントラストの問題など、一般的なユーザー補助の問題がないか Android アプリを自動的にスキャンします。Google から直接提供されるこのツールは無料で使いやすくなっていますが、基本的な問題の特定に限定されており、詳細なテスト機能はありません。
TalkBack アクセシビリティ: TalkBack アクセシビリティを使用すると、ユーザーは Android デバイスでスクリーン リーダーを使用できます。これは組み込みですが、手動のプロセスであり、徹底的にテストするには時間がかかります。BrowserStack アプリ アクセシビリティ ツールを使用すると、実際の Android デバイスで TalkBack スクリーン リーダーにアクセスできます。
Xcode アクセシビリティ インスペクター: iOS アプリのアクセシビリティ属性を検査およびテストするための Xcode の組み込みツールです。Xcode に統合されており、リアルタイムの検査とテストを提供しますが、iOS 開発環境に限定されており、自動テストはありません。
VoiceOver:これは iOS デバイスのネイティブ スクリーン リーダーで、アプリがスクリーン リーダー ユーザーとどのように対話するかをテストするために使用されます。これは組み込みですが、手動プロセスであり、徹底的にテストするには時間がかかります。BrowserStack App Accessibility Tool は、実際の iOS デバイスで VoiceOver スクリーン リーダーへのアクセスを提供します。
BrowserStack App Accessibility は、 Android および iOS フォンでクロスプラットフォームのアクセシビリティを備えたネイティブのような機能を提供します。BrowserStack App Accessibility ツールを使用して、スクリーン リーダー テストとともにアクセシビリティ スキャンを実行し、アクセシビリティを監視できます。主な機能は次のとおりです。
セットアップなしで実際の iOS および Android デバイスに即座にアクセスできます。
BrowserStack 独自のルール エンジンを搭載したワークフロー スキャナーにより、アクセシビリティ テストが 5 倍高速化されます。
TalkBack および VoiceOver スクリーン リーダーにワンクリックでアクセスでき、録音やスクリーンショットで問題をキャプチャできます。
注釈付きのスクリーンショットを備えた集中レポート ダッシュボードにより、簡単に解決するための洞察と実用的な修復手順が提供されます。
Mobile App Accessibility Testing Checklist
ステップ1. アクセシビリティ要件を計画する
ガイドラインを理解する: Web コンテンツ アクセシビリティ ルール (WCAG) やプラットフォーム固有のルール (Apple のアクセシビリティ ガイドラインや Google のマテリアル デザイン アクセシビリティなど) などのアクセシビリティ標準について学習します。
対象ユーザーを特定する:視覚、聴覚、運動、認知の制限など、さまざまな障害を持つユーザーの要求を考慮します。
テスト目標を設定する:スクリーン リーダーの互換性、色のコントラスト、タッチ ターゲットのサイズ、テキストの拡大など、テストするアクセシビリティ機能を決定します。
ステップ2. 適切なツールを選択する
手動テスト ツール: VoiceOver (iOS) や TalkBack (Android) などのスクリーン リーダーを使用して、視覚障害のあるユーザーがアプリをどのように操作するかを手動でテストします。
自動テスト ツール: BrowserStack App Accessibility や Google Accessibility Scanner などの自動ツールを使用して、一般的なアクセシビリティの問題を特定します。
ユーザー テスト ツール:障害を持つ実際のユーザーを対象にテストを実行するには、UserZoom や Loop11 などのプラットフォームの使用を検討してください。
ステップ3. レポートを確認する
生成されたレポートを分析して、改善できる領域を見つけます。これらのレポートには、違反の種類、違反が発生した場所、修復の推奨事項に関する情報が含まれることがよくあります。
ステップ4. 障害を持つユーザーを巻き込む
テスターを募集する:障害を持つ実際のユーザーを招待してアプリをテストしてもらいます。自動テストや手動テストでは得られない貴重な洞察が得られます。
コメントを収集する:ユーザーがアプリをどのように利用しているかを観察し、使いやすさや直面している障害についてコメントを求めます。
ステップ5. 問題を確認して修正する
調整を実装する:開発者と協力して、アプリのアクセシビリティを向上するために必要な調整を実装します。
ステップ6. 再テストと検証
継続的な監視:アクセシビリティ テストは継続的なアクティビティである必要があります。新しいアップグレードと機能を定期的にテストして、それらが引き続き利用可能であることを確認します。
ステップ7. 文書化とレポート
特定されたすべての問題、それらを解決するために実行された方法、および最終結果の完全な記録を保持します。
1. アクセシビリティガイドラインに従う | ウェブベースのコンテンツには、モバイル アプリにも関連するウェブ コンテンツ アクセシビリティ ガイドライン (WCAG) を実装します。また、Apple のアクセシビリティ ガイドラインや Google のマテリアル デザイン アクセシビリティ ガイドラインなど、モバイル プラットフォームが提供するアクセシビリティ ガイドラインも実装します。 |
---|---|
2. テストには実際のデバイスを使用する | さまざまな実際のデバイスでアクセシビリティ テストを実施し、さまざまな画面サイズ、解像度、オペレーティング システムのバージョンをキャプチャします。 |
3. 可能な場合は自動テストツールを実装する | Google Accessibility Scanner や BrowserStack App Accessibility などのツールを使用して、一般的なアクセシビリティの問題をすばやく特定します。自動化されたアクセシビリティ テストを CI/CD パイプラインに統合して、継続的な監視と問題の早期検出を実現します。 |
4. 障害を持つ実際のユーザーを巻き込む | 障害を持つユーザーにアプリのテストに参加してもらいます。彼らからのフィードバックは、自動テストでは見逃される可能性のある実際のユーザビリティの問題に関する洞察を提供します。これらのユーザーからのフィードバックを収集して分析し、現実世界のアクセシビリティの課題と改善の余地を把握します。 |
5. アクセシビリティの意識を高める | チーム内でアクセシビリティ意識の文化を育み、全員がインクルーシブ デザインの重要性を理解できるようにします。アクセシビリティを後付けではなく、ユーザー エクスペリエンス デザインの中心的な側面として優先します。 |
モバイルアプリのアクセシビリティを実現するための 5 ステップのチェックリスト
ARIA ランドマーク ロール (検索、ナビゲーション、コンテンツ情報、補足、バナーなど) を活用して、アプリまたはページを効果的に構造化します。
タッチ イベントの場合は、次のいずれかの条件に従ってください。
モバイル アプリ開発にアクセシビリティを組み込むことは、法的または倫理的な要件であるだけでなく、包括的なユーザー エクスペリエンスを提供するために必要な要素でもあります。確立された原則に従い、自動テストと手動テストの両方の方法を使用し、障害を持つ実際のユーザーを参加させることで、ソフトウェアがすべての人に利用可能であることを保証できます。タッチ ターゲット、色のコントラスト、情報表示はすべて、さまざまなユーザーの要求によりよく適合するように定期的に最適化できます。
BrowserStack のプラットフォームを使用すると、さまざまな実際のデバイスでアプリをテストして、さまざまな環境でアクセシビリティ機能が機能し、ユーザーフレンドリーであることを確認できます。この実践的なアプローチにより、より正確な評価が可能になり、自動化ツールだけでは見逃してしまう可能性のあるアクセシビリティの問題を特定して解決するのに役立ちます。