良い、良い、最高：アクセス可能なパターンの複雑な世界を解きほぐす

マーク・ベニオフは、テクノロジー業界で唯一不変なのは変化であると記憶に残っています。 15年以上テクノロジーに携わってきたので、これを確認できます。 仲間のハイテク恐竜は、初期のWebの動作方法が、私たちの多くが想像していたものとは大幅に異なることを証明できます。

テクノロジー業界におけるこの絶え間ない変化は、今日私たちが目にする革新と進歩をもたらしましたが、それはまた、選択の概念を導入しました。 選択は、表面的には本質的に前向きなことのように見えるかもしれませんが、必ずしも虹やバラに等しいとは限りません。 技術の変化の流入はまた、コーディング言語の分裂とプログラミングの「熱さ」の終わりのない味をもたらします。 時々、この豊富な選択肢が過剰選択に変わることがあります。これは、選択肢が多すぎるために人々が決定を下すのが難しい、よく研究された認知障害です。

この記事では、アクセス可能なパターンの複雑な世界を一歩ずつ解き明かそうと試みます。 現在のアクセシブルなパターンとライブラリを確認することから始め、次に一般的なパターンのニーズと潜在的な制限を検討し、最後に一連の批判的思考の演習を行って、アクセシビリティのパターンをより適切に評価する方法を学びます。

私たちが織り成すもつれたウェブ

Overchoiceは、単純なチェックボックスから複雑な動的モーダル、そしてその間のすべてに至るまで、デジタル作品を構築するために使用するパターンやライブラリを含む、テクノロジーのあらゆる側面に浸透してきました。 しかし、選択肢が非常に多い場合、どのパターンまたはライブラリが適切であるかをどのようにして知ることができますか？ ユーザーが毎日遭遇する確立されたパターン/ライブラリを使用する方が良いですか？ それとも、より楽しいユーザーエクスペリエンスのために、まったく新しいパターンを作成する方がよいでしょうか。

利用可能なオプションが無数にあるため、選択肢が多すぎるとすぐに麻痺する可能性があります。 しかし、一歩下がって、デジタル製品を最初に構築する理由（つまりエンドユーザー）を検討する場合、最大数の人々に最大の価値を追加できるパターンまたはライブラリを選択することは意味がありません。 ？

パターンやライブラリを選択することはすでに十分に困難なプロセスであると思った場合、これはあなたが心配し始めるポイントかもしれません。 しかし、心配する必要はありません。アクセス可能なパターン/ライブラリを選択することは、ロケット科学ではありません。 テクノロジーの他のすべてと同様に、この旅は、少しの知識、試行錯誤の膨大な山積み、そしてすべてのユーザー、状況、またはフレームワークに適合する完璧なパターン/ライブラリが1つだけではないという理解から始まります。

どうすればこれを知ることができますか？ さて、私は過去5年間、A11yスタイルガイド、DequeのARIAパターンライブラリに取り組み、人気のあるSVGパターンを評価しながら、さまざまなタイプのアクセス可能なパターンを調査、構築、テストしてきました。 しかし、私はまた、考えられるすべてのフレームワーク/プラットフォーム上の多くのクライアントパターンとライブラリを確認しました。 この時点で、私は、あなたが十分に長く見たときに発達し始めるパターンアクセシビリティのための生来の階層があると言うことができます。 そして、絶対に避けるべきパターンが時折ありますが、それは必ずしもそれほど明確ではありません。 アクセシビリティに関しては、ほとんどのパターンが良い、良い、最高の勾配に分類されると私は主張します。 難しいのは、どのパターンがどのカテゴリに属する​​かを知ることです。

パターンについて批判的に考える

では、アクセシビリティに関して、どのパターンが優れているか、優れているか、最良であるかをどのようにして知ることができるでしょうか。 場合によります。 デジタルアクセシビリティコミュニティから頻繁に呼び出されるこのフレーズは、コップアウトではありませんが、「最良の答えを提供できるようにするには、より多くのコンテキストが必要です」の省略形です。 ただし、コンテキストは必ずしも明確ではないため、パターンのアクセシビリティを構築および評価する際に、私が尋ねるいくつかの基本的な質問には次のものがあります。

• 使用できる確立されたアクセス可能なパターンはすでにありますか？
• どのブラウザと支援技術（AT）デバイスをサポートしていますか？
• 考慮すべきフレームワークの制限または他の統合/要因はありますか？

もちろん、あなたの具体的な質問は私のものとは異なるかもしれませんが、重要なのは、パターンを評価するときに批判的思考スキルを使い始める必要があるということです。 これを行うには、最終的な決定にジャンプする前に、最初に各パターンを観察、分析し、次にアクセシビリティのランク付けを行います。 ただし、その前に、最初の質問についてもう少し詳しく見ていきましょう。

すでに確立されたアクセス可能なパターンはありますか？

新しいフレームワークごとに、まったく新しいパターンのセットが得られるように見えるのはなぜですか？ 新しいパターンの選択によるホイールのこの絶え間ない再発明は、特に通常そうする必要がないため、開発者を混乱させ、苛立たせる可能性があります。

私を信じないの？ さて、このように考えてみてください。アトミックデザインシステムに加入すると、コードのいくつかの小さな「アトム」が集まって、より大きなデジタル製品を作成することがわかります。 しかし、科学の世界では、原子は生命の最小の構成要素ではありません。 各原子は、陽子、中性子、電子などの多くの亜原子粒子でできています。

同じロジックをパターンに適用できます。 存在するさまざまなフレームワークで利用可能なすべてのパターンを詳しく調べると、実際に使用されているコーディング言語に関係なく、コアの素粒子構造は基本的に同じです。 これが、技術的および設計上のニーズに基づいて構築できる、アクセス可能なパターンを備えた合理化されたコーディングライブラリに感謝する理由です。

注：最近公開されたアクセス可能なパターンのリスト（および記事の最後にあるパターンとライブラリのより詳細なリスト）に加えて、いくつかの信頼できるソースには、包括的コンポーネント、アクセス可能なコンポーネント、Gov.UKデザインシステムが含まれます。 。

サポートしているブラウザと支援技術（AT）デバイスは何ですか？

動作する可能性のあるいくつかの基本パターンを調査した後、ブラウザーと支援技術（AT）デバイスのサポートの質問に進むことができます。 それ自体では、ブラウザのサポートは冗談ではありません。 ATデバイスとARIA仕様をミックスに追加すると、物事はトリッキーになり始めます…不可能ではなく、すべてを理解するために必要な時間、労力、思考プロセスがはるかに多くなります。

しかし、それはすべて悪いニュースではありません。 HTML5アクセシビリティやアクセシビリティサポートなど、現在のブラウザとATデバイスのサポートについての理解を深めるのに役立つすばらしいリソースがいくつかあります。 これらのWebサイトは、利用可能なさまざまなHTMLおよびARIAパターンのサブ要素の概要を示し、オープンソースのコミュニティテストを含み、デスクトップとモバイルの両方のブラウザー/ATデバイスのパターンの例をいくつか提供します。

考慮すべきフレームワークの制限または他の統合/要因はありますか？

いくつかのアクセス可能な基本パターンを選択し、ブラウザー/ ATデバイスのサポートを考慮に入れたら、パターンとその環境に関するよりきめ細かいコンテキストの質問に進むことができます。 たとえば、コンテンツ管理システム（CMS）でパターンを使用している場合、またはレガシーコードを考慮している場合、特定のパターン制限があります。 この場合、少数のパターンの選択肢をすばやく1つまたは2つに減らすことができます。 反対に、一部のフレームワークはより寛容で、あらゆるパターンを受け入れることができるため、フレームワークの制限について心配する必要がなく、最もアクセスしやすいパターンを選択することに集中できます。

これまでに説明したすべてのことに加えて、パフォーマンス、セキュリティ、検索エンジン最適化、言語翻訳、サードパーティの統合など、パターンを選択する際に考慮すべき多くの追加の考慮事項があります。 これらの要素は間違いなくアクセス可能なパターンの選択に影響しますが、コンテンツを作成する人々についても考慮する必要があります。 選択するアクセス可能なパターンは、エディターで生成されたコンテンツやユーザーで生成されたコンテンツに関する潜在的な制限を処理するのに十分な堅牢な方法で構築されている必要があります。

アクセシビリティのパターンの評価

コードは言葉よりも雄弁であることがよくありますが、そのすべてに飛び込む前に、次のパターンの例が各状況で利用できる唯一のパターンではなく、グループ内で「最良」と見なされるものも、アクセス可能なパターンの全世界。

以下のパターンデモでは、パターンの各グループをそれ自体と比較している架空の状況を想像する必要があります。 これは現実的な状況ではありませんが、これらの批判的思考の演習を実行し、アクセシビリティのパターンを評価することで、現実の世界でパターンの選択に遭遇したときの準備を整えることができます。

アクセシブルなボタンパターン

アクセシビリティについて確認する最初のパターンのグループは、ほとんどすべてのWebサイトまたはアプリに遍在しています：ボタン。 最初のボタンパターンはARIAボタンの役割を使用してボタンを模倣し、2番目と3番目のボタンパターンはHTMLの<button>要素を使用します。 3番目のパターンでは、 aria-describedbyとCSSを追加して、視覚的に物事を非表示にします。

良い： role="button"

 <a role="button" href="[link]">Sign up</a>

より良い： <button>

 <button type="button">Sign up</button>

ベスト： <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

最初のパターンは一見単純に見えますが、アクセシビリティの問題を引き起こします。 たとえば、最初のボタンパターンでは、HTMLの<button>要素の代わりにARIA role="button"が「good」パターンで使用されていることがわかります。 アクセシビリティの観点から考えると、HTML <button>要素がHTML4で導入されたことがわかっているので、すべての主要なブラウザーの最新バージョンで完全にサポートされており、ほとんどのATデバイスでうまく機能すると合理的に推測できます。 しかし、さらに深く掘り下げてARIA role =“ button”のアクセシビリティサポートを見ると、支援技術の観点からわずかな利点がありますが、HTML <button>要素には、特に考慮した場合、ブラウザーとATのカバレッジの一部の領域がありません。音声制御のサポート。

では、なぜARIAパターンが「より良い」カテゴリに含まれないのでしょうか。 ARIAはそれをよりアクセスしやすくしませんか？ いいえ。 実際、このような場合、アクセシビリティの専門家はしばしばARIAの最初のルールを引用します—ARIAを使用しないでください。 これは、可能な限りHTML要素を使用するという簡単な言い方です。 ARIAは確かに強力ですが、悪意のある人にとっては、善よりも害を及ぼす可能性があります。 実際、WebAIM Millionレポートには、「ARIAが存在するページは、存在しないページよりも平均して60％多くのエラーが発生する」と記載されています。 そのため、ARIAを使用するときに何をしているのかを知っておく必要があります。

この状況でARIAを使用することに対する別の攻撃は、必要なボタン機能をrole="button"パターン用に構築する必要がある一方で、その機能はすでに<button>要素にプリベークされていることです。 <button>要素も100％ブラウザーをサポートしており、実装が簡単なパターンであることを考慮すると、最初の2つのパターンを評価するときに、階層の少し前にエッジがあります。 うまくいけば、この比較が、ARIAを追加するとパターンがよりアクセスしやすくなるという神話を打ち破るのに役立つでしょう。多くの場合、その逆が当てはまります。

3番目のボタンパターンは、CSSで視覚的に非表示になっているID要素にリンクされたaria-describedbyと結合されたHTML <button>要素を示しています。 このパターンは少し複雑ですが、ボタンと目的の間に関係を作成することにより、コンテキストの点で多くを追加します。 疑わしい場合は、状況にコンテキストを追加できるときはいつでも良いので、正しくコーディングされていれば、これらの特定のボタンパターンのみを比較する場合に最適なパターンであると想定できます。

アクセス可能なコンテキストリンクパターン

レビューするパターンの2番目のグループは、コンテキストリンクです。 これらのパターンは、画面に表示されている情報よりも多くの情報をATユーザーに提供するのに役立ちます。 最初のリンクパターンはCSSを利用して、追加のコンテキスト情報を視覚的に非表示にします。 2番目と3番目のリンクパターンはARIA属性をミックスに追加します：それぞれaria-labelledbyとaria-label 。

CarieFisherによるペン[AccessibleLinkPatterns]（https://codepen.io/smashingmag/pen/VwmRJYv）を参照してください。

良い： visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

より良い： visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

ベスト： aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

3つのコンテキストリンクパターンはすべて同じように見えますが、コードを検査したり、ATデバイスでテストしたりすると、明らかな違いがいくつかあります。 最初のパターンは、CSS手法を使用して、視力のあるユーザーにはコンテンツを視覚的に非表示にしますが、視力のないATユーザーには非表示のコンテンツをレンダリングします。 この手法はほとんどの場合機能しますが、リンクと追加情報の間に実際の関係は形成されないため、接続はせいぜい暫定的なものです。 そのため、最初のリンクパターンは適切な選択ですが、3つの中で最も堅牢なリンクパターンではありません。

次の2つのリンクパターンは、評価するのが少し難しいです。 W3CのARIA仕様によると、「 aria-labelの目的は、 aria-labelledbyの目的と同じです。 オブジェクトの認識可能な名前をユーザーに提供します。」 したがって、理論的には、両方の属性が同じ基本機能を持つ必要があります。

ただし、仕様では、ユーザーに伝達するアクセシブルな名前を決定する際に、ユーザーエージェントがaria-labelよりもaria-labelledbyを優先することも指摘されています。 調査では、自動翻訳とaria-label属性に関する問題も示されています。 つまり、 aria-labelledbyを使用する必要があるということですよね？

まあ、それほど速くはありません。 同じARIA仕様では、「インターフェイスが画面に表示可能なラベルを表示できないようなものである場合（または、表示可能なラベルが目的のユーザーエクスペリエンスではない場合）、作成者はaria-labelを使用する必要があり、使用しないでください。 aria-labelledbyを使用してください。」 紛らわしいことについて話してください—では、どのパターンを選択する必要がありますか？

大規模な翻訳が必要な場合は、視覚的な側面を変更して、完全なコンテキストが表示されたリンクを書き出すか（たとえば、「この素晴らしいことについてもっと読む」）、 aria-labelledbyを使用することを決定する場合があります。 ただし、大規模な翻訳のニーズがなかったか、合理的でアクセス可能な方法でそれらのニーズに対応でき、ビジュアルを変更したくなかったとしましょう。

現在のARIA1.1の推奨事項（ARIA 1.2でのaria-labelの翻訳が約束されている）に加えて、開発者がaria-labelledbyよりもaria-labelの実装が少し簡単であるという事実に基づいて、aria- aria-labelを重み付けすることを決定できます。パターン評価でaria-labelledby 。 これは、アクセス可能なパターンの選択においてコンテキストが非常に重要である場合の明確な例です。

アクセス可能な<svg>パターン

最後に、もちろん重要なことですが、アクセシビリティについてSVG画像パターンのグループを調べてみましょう。 SVGはコードを視覚的に表現したものですが、それでもコードです。 これは、 role="img"がパターンに追加されない限り、ATデバイスが非装飾的なSVG画像をスキップする可能性があることを意味します。

次のSVGパターンが本質的に情報提供であると仮定すると、 role="img"がそれぞれに含まれています。 最初のSVGパターンは、 <title>と<text>をCSSと組み合わせて使用​​して、目の見えるユーザーからコンテンツを視覚的に隠します。 次の2つのSVGパターンには、 <title>要素と<desc>要素が含まれますが、最後のパターンにaria-labelledby属性が追加されています。

良い例： role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

より良い： role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

ベスト： role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

まず、 <title>と<text>および視覚的に隠されたCSSを使用して最初のパターンを見てみましょう。 パターン内の以前の目に見えて隠されたテキストとは異なり、 <title> >要素と<text>要素は同じSVG要素の傘の下にグループ化されているため、これらの要素の間には固有の関係があります。 ただし、この関係はそれほど強くありません。 実際、SVGパターンに関する私の調査を振り返ると、8つのブラウザー/ATの組み合わせのうち3つだけが完全なメッセージを聞いたことがわかります。 （注：豚のパターン＃1は電球のパターン＃7と同等です。）

これは事実ですが、動作中のW3C SVG仕様では、 <text>要素を「テキストで構成されるグラフィック要素…描画される文字は文字データとして表現されます」と定義されています。 その結果、SVGコンテンツのテキストデータは視覚障害者が簡単にアクセスできます。」 この最初のパターンは問題ありませんが、もっとうまくいくことができます。

2番目のパターンは、 <text>要素を削除し、それを<desc>要素に置き換えます。 W3CSVGの仕様は次のように述べています。

「 <title>子要素は要素の短いテキストの代替を表します...そして<desc>要素は説明などの要素のより詳細なテキスト情報を表します。」

SVGの<title>要素と<desc>要素の意味は、 <img>要素で従来から見られる代替テキストと長い説明のオプションを画像化するのと同じように使用できます。 <desc>要素を2番目のSVGに追加すると、8つの組み合わせのうち3つが完全なメッセージを聞くという、同様のブラウザー/ATサポートが表示されます。 （注：豚のパターン＃2は電球のパターン＃10と同等です。）これらのテスト結果は最初のパターンを反映しているように見えますが、このパターンが「より良い」カテゴリに分類される理由は、コードの実装が少し簡単だからです。最初のパターンはあまり人気のないブラウザ/ATの組み合わせをサポートしていましたが、JAWS、VoiceOverデスクトップ、VoiceOverモバイルで機能したため、より多くのATユーザーに影響を与えます。

3番目のパターンも<title>要素と<desc>要素を使用しますが、現在はaria-labelledbyとIDがミックスに追加されています。 同じSVGテストによると、この追加のコードを追加することは、8つのブラウザー/ATの組み合わせのうち7つを完全にサポートできることを意味します。 （注：豚のパターン＃3は電球のパターン＃11と同等です。）3つのSVGパターンのうち、この3番目のパターンはほとんどのATデバイスをサポートしているため、「最良」です。 ただし、このパターンには、一部のブラウザーとATの組み合わせを使用する際の欠点があります。 このパターンの画像のタイトル/説明の内容が重複しているのが聞こえます。 ユーザーに迷惑をかける可能性はありますが、重複したコンテンツを聞く方が、まったく聞こえないよりも一般的には良いと思います。

まとめ

私たちは皆、確かにテクノロジーの選択を大切にしていますが、オプションが多すぎるために、次に何をすべきかについて麻痺し、混乱している時点に到達したのではないでしょうか。 アクセス可能なパターンの選択に関しては、パターン/ライブラリオプション、ブラウザ/ ATデバイスのサポート、フレームワークの制限などについて簡単な質問をすることができます。

適切なデータが手元にあれば、これらの質問に答えるのは簡単です。 ただし、パターンを超えて、実際にそれらを使用している人々を考慮すると、少し複雑になります。 それから、私たちの選択がユーザーの成功能力に与える影響を認識します。 ジョージ・デイ教授が雄弁に述べているように：

「インクルージョンは、人々を既存のものに引き込むことではありません。それは、新しいスペース、すべての人にとってより良いスペースを作ることです。」

パターンについて批判的に考え、最もアクセスしやすいパターンを選択するためにもう少し時間をかけることで、間違いなく、より多くのユーザーにリーチするためのより包括的なスペースを作成します。

関連リソース

ツール

• アクセシビリティサポート、Michael Fairchild、a11ysupport.io
• HTML5アクセシビリティ、Steve Faulkner

パターンライブラリ

• アクセシビリティプロジェクト
• アクセシビリティスタイルガイド
• アクセシブルコンポーネント、スコットオハラ
• アクセス可能なdrag-and-dropリスト再注文プラグイン、Harris Schneiderman
• DequeのARIAパターンライブラリ
• DequeのアクセシブルなReactライブラリ
• GOV.UKデザインシステム
• 包括的コンポーネント、ヘイドンピカリング
• 米国のWebデザインシステム（USWDS）
• Webアクセシビリティチュートリアル