利益:
- 人工知能のサポートにより、カラーコントラスト、代替テキスト、キーボードアクセス、WCAG基準を制御および改善する機能
- 人工知能を使用して、スクリーン リーダー エクスペリエンス、代替テキスト、フォーム ラベルなどのアクセシビリティ テキストを生成および検証する機能
- 実際の支援技術とユーザーテストによる AI のアクセシビリティ推奨事項の検証の限界を理解する
アクセシビリティ (略して a11y) とは、障害のある人を含むすべての人が使用できる製品の機能です。視覚障害のあるユーザーはスクリーン リーダー (テキストを音声に変換する補助ソフトウェア) で操作でき、運動障害のあるユーザーはキーボードで何でもでき、色覚異常のあるユーザーは色に頼らずに情報を受け取ることができます。インクルーシブ デザインはより広範で、年齢、言語、文化、一時的な障害 (腕の骨折) または文脈上の障害 (太陽の下での画面) など、人間の多様性をデザインの中心に置きます。アクセシビリティは「追加」ではなく、ほとんどの国において基本的な責任であり、法的要件です。 AI は、この分野における強力な事前スクリーニング機能とドラフト生成機能を備えています。しかし、真のアクセシビリティは、実際の支援技術とユーザーテストによってのみ確認されます。
WCAG と主要な制御領域
WCAG (Web コンテンツ アクセシビリティ ガイドライン) は、アクセシビリティに関して国際的に認められた一連の基準です。一般的にはAAレベルが対象となります。それには 4 つの原則があります。コンテンツは知覚可能でなければならない、インターフェースは使用可能でなければならない、情報は理解可能で技術的に健全でなければなりません。実際に最も一般的な制御領域は次のとおりです。
- 色のコントラスト: テキストと背景の違いは十分ですか? (AA の場合、通常のテキストで少なくとも 4.5:1 の比率。)
- 代替テキスト (alt テキスト): 画像には、スクリーン リーダーに説明する同等のテキストが含まれていますか?
- キーボードアクセス: マウスなしで何かを行うことはできますか?フォーカスの順序は意味がありますか?
- 色のみの情報: 「赤いフィールドに記入してください」のようなフレーズは、色盲のユーザーを除外します。
- フォームのラベル: 各入力フィールドには、スクリーン リーダーが読み取るラベルがありますか?
- タッチ対象: ボタンは指で押しやすい大きさですか?
AI は、これらの領域の多くで簡単な予備スキャンを実行できます。テキストを与えて「コントラストは十分ですか?」と尋ねたり、画像の説明を与えて「代替テキストを提案してください」と尋ねたり、インターフェイスの説明を与えて「キーボード アクセスの問題は何ですか」と尋ねたりすることができます。
注意: AI が「アクセシブルに見える」と言ったからといって、アクセシビリティを保証するものではありません。自動チェックでは、WCAG エラーの一部のみが検出されます。残りは実際に使用することで明らかになります。
代替テキスト: 優れた代替テキストの秘密
視覚障害のあるユーザーのために、代替テキストが画像を置き換えます。適切な代替テキストは、画像の装飾的な詳細ではなく、画像の機能と意味を伝えます。 「カートに追加」アイコンの代替テキストは、ユーザーにとって重要なアクションであるため、「ショッピング カートの画像」ではなく「カートに追加」である必要があります。 AI はサブテキストのアウトラインの生成には優れていますが、コンテキストがわからないため、過度に説明的なテキストや無関係なテキストが生成される可能性があります。それぞれの代替テキストに「なぜこの画像がここにあるのですか?」と尋ねます。質問を切り取ります。
ビジュアル
弱いサブテキスト
強力なサブテキスト
カートアイコン（ボタン）
「カートアイコン、グレー色」
「カートに追加」
製品写真
「絵」
「青い冬用コート、正面図」
飾り線
「オーナメントライン」
(空白のままにしておきます - 装飾的)
グラフィックス
「グラフィックイメージ」
「2024 年の売上高: 四半期ごとに増加」
包括的な言語と範囲
アクセシビリティは技術的な制御に限定されません。言語も包括的です。性別を想定したテキスト（「ユーザーとその配偶者」）、能力に基づいて除外したテキスト（「一目見る」、「聞き取りやすい」）、または文化的な前提を含むテキストは、一部のユーザーを除外します。 AI はこの観点からテキストをスキャンできますが、AI が提案する「中立的な」言語が自然で理解しやすいものであることを確認する必要があります。修正しすぎるとテキストが不自然になる可能性があります。
ミニケース3個
ケース 1 — コントラスト エラーが早期に発見されました。チームは AI に 20 の画面の文字の色をスキャンさせ、7 か所でコントラストが AA のしきい値を下回っていると判断しました。修正は開発に入らずに行われました。その後の修正のコストが回避されました。しかし、チームは依然として実際のスクリーン リーダー テストを省略しませんでした。
ケース 2 — 色関連の情報のみが修正されました。あるフォームには、エラー フィールドが赤い枠線だけで表示されていました。 AIはこれにフラグを立てました。チームは各エラーにテキストとアイコンも追加しました。色盲のユーザーもエラーを確認できるようになりました。教訓: 色だけでは情報を伝えることはできません。
ケース 3 — AI による誤った承認。あるデザイナーは、AI を「アクセスしやすい」という理由でスクリーン リーダーのテストを省略しました。実際のテストでは、フォーカス順序が混乱し、一部のボタンがまったく読み込まれないことが判明しました。教訓: 自動確認が始まりです。実際の支援技術テストは必須です。
コピー可能なプロンプト
アクセシビリティについてこのインターフェイスの説明を事前にスキャンします。1) 色のみに基づいて伝えられる情報はありますか?2) クリック可能な各要素にテキスト ラベルはありますか?3) キーボードからアクセスできない要素はありますか?4) フォーカスの順序は意味がありますか?各問題と提案をリストします。 「実際のテストが必要」というメモを追加します。レシピ: <<テキスト>>
これらの画像の代替テキストを提案します。ルール: 装飾的な詳細ではなく、画像の機能/意味を伝えます。ボタンアイコンのアクションを記述します。装飾的な画像の場合は、「代替テキストは空白のままにする必要があります」と言います。コンテキストと画像の説明: <<リスト>>
これらのテキストで包括的な表現がないか確認してください。性別に関する前提、能力に基づいた排他的な表現 (「見る」、「聞く」など)、文化的な前提はありませんか?自然のままの代替案を提案します。過度に修正しないでください。テキスト: <<リスト>>
このフォームにアクセス可能なエラーとラベルのテキストを記述します。各フィールドの表示ラベル、スクリーン リーダーの説明、色に関係なくエラーを説明するメッセージ (テキスト + アイコン)。声と口調：<<カード>>フォームフィールド：<<リスト>>
弱いプロンプト / 強いプロンプト
弱: 「この画像の代替テキストを書いてください。」
結果: 機能を欠いた「画像」または過度に説明的なテキスト。
強力: 「これらの画像に代替テキストを提案し、画像の機能/意味を伝えます。ボタン アイコンのアクションを記述します。装飾的なアイコンには「空白のままにしておく必要があります」とマークします。」
その結果、コンテキストに基づいた、機能指向の、正確なサブテキストが得られます。
違い: 強力なプロンプトにより、機能重視 + ボタン規則 + 装飾的な区別がもたらされます。
よくある間違い
- 人工知能の承認をアクセシビリティの保証と誤解しています。これは実際のテストに代わるものではありません。
- 情報を色に読み込むだけです。色盲のユーザーは情報を見逃します。
- 代替テキストで機能ではなく画像を説明します。ボタンアイコンにはアクションを記述する必要があります。
- アクセシビリティは最後に残しておきます。ワイヤーフレームの段階で開始しないと、後でパッチを適用するのにコストがかかります。
- 過剰に修正された言語。自然さを失った包括的な言語は、わかりやすさも損ないます。
要約すると
アクセシビリティとは、誰でも製品を利用できることを意味します。それは余分なものではなく、不可欠なものであり、ほとんどの場所で法的責任となります。 AI は、コントラスト、代替テキスト、キーボード アクセス、および包括的な言語スキャンのための素早いプリフライトおよびドラフト ジェネレーターとして価値があります。ただし、自動承認は WCAG エラーの一部のみを検出します。実際のアクセシビリティは、スクリーン リーダーと実際の支援技術ユーザーによるテストによって確認されます。モデルをフロントブラウザとして使用し、実際のテストから証拠を取得します。
アプリケーションタスク
- 最初のプロンプトで、アクセシビリティについてインターフェイスの説明を事前にスキャンします。
- 色ベースの情報またはラベルのない項目のみを修正します。
- 2 番目のプロンプトを使用して、画面上のビジュアルに対する機能指向の代替テキストを生成します。
- 3 番目のプロンプトで、テキストに包括的な言語が含まれているかどうかを確認してください。
- 可能であれば、スクリーン リーダーを使用して実際のテストを試し、自動スキャンで見逃される部分に注意してください。
チェックリスト
- [ ] コントラスト、キーボード アクセス、ラベルを事前にスキャンしました。
- [ ] 色だけで情報を残したわけではありません。
- [ ] サブテキストは機能的な方法で書き、装飾的なサブテキストは空白のままにしました。
- [ ] 私は包括的な言語制御を行い、自然さを維持しました。
- [ ] 私は自動承認がアクセシビリティの保証であるとは考えていませんでした。
- [ ] 実際の支援技術テストを企画・実施しました。