アクセシビリティのガイドラインを念頭に置いたワイヤーフレームの設計
これに対する明確な答えがあるかどうかはわかりませんが、ただ捨てるつもりだと思いました...
508のセクションガイドラインに従ってアクセスできるようにする必要がある連邦組織のサイトの再設計に取り組んでいます。私が得た推奨事項の1つは、後で問題が発生しないように、ワイヤーフレーム自体の設計中にアクセシビリティガイドラインを組み込むを確認することです。
私が知りたいのはアクセシビリティの原則をワイヤーフレームに組み込む方法に関する推奨ガイドラインがある場合（実際のビジュアルおよびhtmlデザインフェーズでアクセシビリティを組み込む方法についてできる限り読んだ）しかし、私はワイヤーフレーム設計のために何をすべきか、そして何がチェックポイントであるべきかについて空白を描いています。
いくつかのガイドライン について述べているこの興味深い記事を見つけましたが、それらはかなり一般的です。記事を引用するには：
直感的な階層：150以上のリンクを持つWebページは、ユーザーがリンク名を聞いていても視覚的に読んでいても、タブ移動に非常に長い時間がかかります。これにより、直感的な階層がさらに重要になります。適切な階層構造は、サイトの各ページに表示されるリンクが少なく、関連するリンクのみが次のレベルのページに表示されることを意味します。リンクが意味があり関連性がある限り、階層または構造は、利用できる関連性のあるリンクの数が少なくなるため、ユーザーが行うべきタブキーの押下が少なくなることを意味します。
Navigational aides：視覚障害のあるユーザーは、AからZのインデックスまたはサイトマップによって非常に助けられることがよくあります。これらのナビゲーション補助機能は、画面の拡大や大きなテキストサイズで簡単に表示できる長いリストでコンテンツを表示します。
意味のあるリンクを使用する：概要コピーにリンクを埋め込むことで、コンテンツプランナーはユーザーの主要な情報への道のりをサポートできます。埋め込みリンクは、メニュー内の孤立したナビゲーションリンクよりもページについて理解を深めることができるため、優れています。埋め込みリンクを使用すると、論理階層のより深いレベルで、埋め込まれたコンテンツに直接アクセスできます。
誰かが研究の特定のガイドラインに出くわしたのか、それとも自分の経験から出てきたのかと思いました。
私はUXチームと協力して、早い段階でアクセシビリティを含めること、およびワイヤーフレームとデザインのいくつかの問題を文書化することに関して、優れた実践を確立する手助けをしてきました。
Matt Obeeは上記の重要な問題を取り上げました。彼のリストに私も追加します：
- 構造：ページの見出し構造がどのように機能するかを理解します。リストは、WAI ARIAランドマークとデータテーブルです。主な見出し、副見出しなどを示すだけで、コーディングの開始時に設計が論理的な見出し構造を確実にサポートするようになります。
- 色と意味：意味を強調するために色を使用するのは良いことです。色を認識できないユーザーのために色を定義する別の方法があることを確認してください。形や大きさも同じです。
- 色のコントラスト：これは、WCAGからの色のコントラストの最小値、およびスタイルガイドで定義されている前景色と背景色を満たす必要があります。
- フォーカス状態：ホバーとフォーカス状態は、すべてのフォーカス可能な要素に対して定義する必要があります（同じスタイル設定が適切に機能し、ブラウザーのデフォルトよりも望ましいです）。また、選択した状態がホバー/フォーカス状態に固有であることを確認してください。
- コンテンツ/フォーカスの順序：すぐに明確でない場合は、関連する情報のグループが分割されないように、ワイヤーでコンテンツの順序を述べる作業です。これはスクリーンリーダーのユーザーにとって不可欠です。
上記のすべては、ワイヤーフレームとスタイルガイドに注釈を付けることができます。全体像を見ると、次のアクセシブルなUX設計原則について考えることがUXの役割であるとも言えます。
選択：複雑または非標準のやり取りを完了する2つの方法を提供する
制御：システムのアクセシビリティ設定を抑制しないか、要求されていないときにユーザーにコンテンツを強制しません。たとえば、ピンチズームを抑制したり、マルチメディアの自動再生を強制したりします。
親しみやすさ：標準のデザインパターン、一貫したラベル付け、デバイス全体の代替案を視覚的および代替テキストの両方で使用する。
価値：機能の優先順位を含めて、障害のあるユーザーにとってのメリットを尋ねます。すべてのユーザーにとって良いことは、障害のあるユーザーにとって大きなメリットになる可能性があります。たとえば、ユーザーが最新、人気などで並べ替えできるように、リストメカニズムに並べ替えメカニズムを追加します。これにより、コンテンツをたどって目的の場所にたどり着く手間を省くことができます。
Smashing Magでこのいくつかについて、私たちがどのように BBC iPlayer上のUXへの統合されたアクセシビリティ のケーススタディで書いた。
ワイヤーフレームのアクセシビリティドキュメントを作成するという点では、これはワイヤーフレームの目的ではありません！
ワイヤーフレームがそうであるように設計されていない他のもの：
- コンテンツリポジトリ
- インタラクションデザイン仕様
- ビジュアルデザイン仕様
- 永久的な記録
- 等.
:)
私のポイントは、UXチームがワイヤーフレームを記録のドキュメントにするという願望を押し戻すことが重要であることだけです。ワイヤーフレームは、アイデアを視覚的にスケッチする方法です。それが彼らの意図です。それ以上のことを彼らに依頼することは、一般的ではありますが、非能率に満ちています。
特にアクセシビリティに関しては、それらはすでに文書化されています。ご指摘のとおり、508またはWCAGガイドラインはその例です。
アクセシビリティの鍵は、誰もがそれを理解し、それを認識する必要があることです。 UXチームはそれを理解している必要があります。そうすることで、彼らがアクセスしやすくするのが難しいソリューションを意図的に設計していないのです。開発者はそれを理解する必要があります。それにより、開発者が使用しているプレゼンテーションレイヤーマークアップとJavaScriptは、最初からアクセス可能です。
ワイヤーフレームにアクセシビリティ要件の伝達を依頼することは、HTMLのベストプラクティスを伝達するように依頼されるワイヤーフレームに似ています。これは、サイトのビルダーが持つべきスキルセットです。彼らがそのスキルを持っていない場合、それはトレーニング/教育の問題であり、UXワイヤーフレームの問題ではありません。
つまり、具体的な質問に答えるという点で、これらすべてに基づいて：
アクセシビリティの原則をワイヤーフレームに組み込む方法
ワイヤーフレームを扱うUXデザイナーは、アクセシビリティのベストプラクティスに関する知識が必要です。常にコンテキスト中心になるため、注意すべきマスターリストはありません。また、常に議論の余地があります。そのため、UXチームにある程度のアクセシビリティトレーニングを確実に受けてもらうことが最善の解決策であることをお勧めします。理想的には、アクセシビリティの問題の専門家であるUXスタッフを呼び込みます。
ワイヤーフレームの段階で特に注目する価値のある508またはWCAGガイドラインのリストを作成した人を知りません。色のコントラストやテキストサイズなどの一部の視覚的な側面、およびHTMLマークアップなどの実装の技術的な詳細は、ワイヤーフレーミングの段階ではほぼ確実に範囲外です。とは言っても、考慮すべきことはまだたくさんあります。 機能性と構造に関してワイヤーフレームで行う決定は、ほぼ確実にアクセシビリティに影響します。
質問で引用された3つの領域（直感的な階層、ナビゲーション補助、および意味のあるリンク）に加えて、次の春が思い浮かびます。
- 複雑なコントロールや異常なインターフェースをワイヤフレーム化するときは、キーボード（およびタッチ）のアクセシビリティについて考えてください。マウスを信頼できると思い込まないでください。
- ユーザーは自分がどこにいるかをどのようにして知るのでしょうか？たとえば、パンくずリストを含める必要がありますか？
- コンテンツを自動的に移動および更新するには、ユーザーが一時停止/停止できる方法を検討してください。
- オーディオおよびビデオコンテンツの場合、インターフェイスがテキストのトランスクリプトへのアクセスを提供する方法を検討してください。
- 手順や重要な情報を提供するために、形状、サイズ、または視覚的な場所に依存しないでください。
- 適切な行の長さを考慮してください（短すぎず、長すぎません）。
- フォームの検証-必須フィールドをどのように示し、エラーメッセージをどのように表示しますか？
- インターフェイスはさまざまなユーザー入力にどのように応答しますか？たとえば、フィールドに入力すると、ページが自動的に変更されますか？これらの変更をユーザーにどのように伝えますか？
これらの考慮事項はワイヤーフレームを誰が作成および消費しているか、およびその目的に応じて異なりますであることは注目に値します。デザイナーや開発者に方向性を与えるためにワイヤーフレームを作成する場合、それらが高レベルの概要を提供するために使用されている場合（おそらくクライアントの場合）よりも、おそらくアクセシビリティの詳細をよりよく考える必要があります。