[翻訳] より良いアクセシビリティの構築 primitives_html/css_WEB-ITnose

原文: http://www.zcfy.cc/article/607

私たちが構築する Web サイトが徐々にアプリに似てくるにつれて、Web プラットフォームも開発者に必要なものを提供する必要があります。 . アクセシビリティの高いユーザー エクスペリエンスを作成するためのツールは重要です。

最近、作成したコンポーネントに適切なキーボード サポートを追加することが非常に難しい 2 つのシナリオに遭遇しました。多くの実験と調査を行った結果、Web プラットフォームに不足しているプリミティブがいくつかある可能性があることがわかりました。これらのプリミティブが利用可能であれば、私の作業はより簡単になるでしょう。両方のシナリオについて説明し、両方の問題を解決する方法についていくつかのアイデアを取り上げます。

質問 1: モーダル ウィンドウ

モーダル ウィンドウはページ上に表示されるダイアログ ボックスで、通常は背後のコンテンツを覆うマスク レイヤーが付いています。モーダル ウィンドウが表示されている場合、ユーザーは Web ページ上で他の操作を行うことができません。

モーダル ウィンドウをアクセシブルにしようとしたことがあるなら、たとえ無害に見えても、モーダル ウィンドウは実際にはウェブ上のアクセシビリティの主役であることを知っているはずです。彼らはあなたを食べて骨を吐き出すでしょう。たとえば、適切なモーダル ウィンドウには次の特性が必要です:

• キーボード フォーカスはモーダル ウィンドウに移動され、ウィンドウが閉じられると以前にフォーカスされていた要素に復元される必要があります。

• ユーザーが誤ってタブ キーを押してフォーカスをモーダル ウィンドウの外に移動できないように、キーボードのフォーカスをモーダル ウィンドウに限定する必要があります。

• 誤ってモーダル ウィンドウから離れることを避けるために、画面読み取りソフトウェアもモーダル ウィンドウに制限する必要があります。

画面読み上げソフトを制限するには大量の aria-hidden 組み合わせ変換が必要であり、TAB を制限するにはフォーカス切り替えの管理も必要であり、上記 3 点を達成するのはかなり困難であると言えます。 これが私が見つけた最良の例です。この例では、モーダル ウィンドウがメイン コンテンツと同じ DOM 内にあることを前提としているため、メイン要素に aria-hidden を適用するだけで済みます。ただし、モーダル ウィンドウがメイン コンテンツと混在している場合 (おそらく配置上の理由により)、それは実際には少し難しく、メイン コンテンツ内のすべての要素に aria-hidden を適用する方法を見つける必要があります。モーダル ウィンドウ (またはその親コン​​テナ)。確かに予想より大変でした。

を使ってみてはいかがでしょうか?

HTML 仕様では、上記の問題をすべて魔法のように解決する

要素を使用するというアイデアが提案されています。問題は、これまでのところ Chrome だけがこの機能を実装しており、他のブラウザ ベンダーは無関心であるように見えることです。また、

は適切な解決策ではない可能性があります。別の例を考えてみましょう:

サイドバー メニューは、レスポンシブ Web サイトで非常に人気のある UI パターンです。しかし、サイドバー メニューは

と同じでしょうか?サイドバーメニューも上記の3点を遵守する必要がありますが、これをダイアログと呼ぶのは少しカジュアルすぎます。私の予感では、多くの開発者はサイドバー メニューを作成するとき、それを

とは考えていないのではないかと思います。

考えられる解決策:blockingElements

目標を達成するために

のセマンティクスをひねるのではなく、同じ魔法を提供する JavaScript API を公開しましょう。このようにして、独自のカスタム要素を作成し、この API を利用して必要なものを取得できます。このアイデアは、whatwb/html GitHub リポジトリの「ブロック要素のスタックを公開する」で議論されています

想定される API は次のようになります:

// put element at the top of the blocking elements stackdocument.blockingElements.push(element);  document.blockingElements.pop();  // see https://github.com/whatwg/html/issues/897#issuecomment-198565716document.blockingElements.remove(element);  document.blockingElements.top; // or .current or .peek()

実際には、blockingElements スタックの最上位に要素を配置します。ページ上の他のすべてを意味します。は無効になります (そのため、キーボードがフォーカスされ、スクリーン リーダーがモーダル ウィンドウを離れる危険はありません)。要素がスタックからポップされると、フォーカスは自然に以前にフォーカスされた要素に戻ります。これにより、

の動作を説明できるようになり、コンポーネント作成者がそれを使用して必要な効果を作成できるようになり、これは拡張可能な Web 運動の理念に沿ったものになります。これを行うことによる自然な副産物として、追加のアクセシビリティ機能が多数得られることになります。開発者は、aria-hidden 属性やキーボード制限をページ全体に記述する必要はなく、代わりに、最適な API を使用してダイアログを作成することができ、良好なアクセシビリティが自然に実現されます。これは完全な勝利だ。

現在、blockingElements はまだ新しいアイデアであり、新しいアイデアは壊れやすいものです。そのため、GitHub の問題で文句を言い、舌戦を始めたいという衝動を抑えてください :blush:。次のステップは、blockingELEments を Web Platform Incubator Community Group (WICG) に移動して、アイデアを磨き続けることです。 WICG への移行時には必ずこのブログ投稿を更新して皆様にお知らせいたします。

質問 2: tabindex を無効にする

先ほどのサイドバー メニューをもう一度見てみましょう。このメニューを左側からアニメーションさせて 60fps を達成するには、このメニューに別のレイヤーを用意する必要があります。これは、 will-change:transform のような CSS プロパティを設定することで実行できます。これで、transform を使用してメニューを画面に表示できるようになり、不必要な描画やレイアウトがトリガーされなくなりました。このビデオはこのテクニックを非常によく説明しています: Paul Lewis の I/O プレゼンテーション

1 つ問題: これを行うには、メニューを DOM ツリーに保持する必要があります。これは、フォーカス可能な子要素が画面の表示領域の外側に存在することを意味します。そのため、ユーザーがページ内をタブ移動し続けると、非表示の要素にフォーカスがあり、ユーザーはそれがどこにあるのか分からないため、最終的にはフォーカスが消えます。私はいつも、レスポンシブなウェブサイトでこれが起こっているのを目にします。これはほんの一例であり、opacity: 0 を使用して要素の表示と非表示をアニメーション化する場合、または大きなリストのカスタム コントロールを一時的に無効にする場合は、tabindex を無効にする必要があります。また、他の人が指摘しているように、カバーフローのようなインタラクションを作成しようとすると、壁にぶつかることになるでしょう。この形式の UI では、次の要素をプレビューできる必要がありますが、それを直接操作することはできないからです。

aria-hidden を使ってみてはいかがでしょうか?

aria-hidden を使用すると、アクセシビリティ ツリーから要素とそのすべての子を削除できます。これは素晴らしいです

これにより、スクリーン リーダーの問題が解決されます (マーシー サットン氏は、これで問題が完全に解決されるわけではなく、フォーカスは得られるもののアクセシビリティ情報が欠如する「ゴースト コントロール」につながる可能性さえあると指摘しています)。残念ながら、ARIA はページの動作に影響を与えることを禁止されており、セマンティクスのみを処理できます。また、tabindex はセマンティクスとはまったく異なる概念です。ただし、視覚障害のあるユーザーはタブ キーを使って Web ページを移動するため、tabindex は重要です。インタラクティブな要素の複雑なツリーがあり、それらをすべてタブ オーダーから削除する必要がある場合、唯一の選択肢は、ツリーを再帰的に走査して (または、すばらしい querySelectorAll 文字列を作成して)、フォーカス可能な各要素セットに tabindex="-1 を与えることです。 」。また、画面の表示領域に戻ったときに復元できるように、明示的な tabindex

値を覚えておく必要もあります。これも予想以上に大変でした。

pointer-events: none を使用してみてはいかがでしょうか?

ポインター イベントを設定すると、要素をクリックできなくなりますが、タブ オーダーから要素は削除されないため、キーボードを介して要素を操作することはできます。

サイドバーメニューを表示: なしに設定してみてはいかがでしょうか?

サイドバーメニューが表示されない場合は、表示: なしまたは可視性: 非表示に設定できます。これにより、フォーカス可能な子要素がタブ オーダーから削除されます。残念ながら、これにより GPU レイヤーも破壊され、アニメーションのすべての最適化が失敗します。メニューが十分に単純であれば、ユーザーがメニューを再度開いたときにレイヤーを再構築するコストを無視できますが、メニューがより複雑な場合 ( m.facebook.com など)、これらすべての再描画によりアニメーションが発生する可能性があります。点滅します。開発者は 60fps アニメーションと優れたアクセシビリティのどちらかを選択する必要はないと思います。

考えられる解決策: inert=""

HTML に inert 属性を追加することについては、以前ここで議論がありました。基本的な考え方は、要素に inert 属性を設定すると、その要素とその子孫がすべて非対話型になるというものです。このソリューションは、画面上に表示されていないいくつかの要素を描画し、それらの要素を inert に設定でき、ユーザーがキーボードを介して誤って操作することを心配する必要がないことを意味するため、サイドバー メニューに最適です。

残念ながら、 inert の元のユースケースは主にダイアログを中心に構築されているようで、現時点では

の提案が広く出回っているため、保留されています。

私の感覚では、inert を非推奨にするのは一歩後退する可能性があります。提案されているblockingElements APIは、開発者がアクセシブルなダイアログをより適切に作成するための方法だと思います。なぜなら、「私以外のすべては不活性である」と言っているからです。逆に、上記のアニメーションの例では inert="" が使用されていますが、何かを描画して DOM に挿入する必要があるが、インタラクティブにしたくない (つまり、「怠惰である」) 場合にも役立ちます。 。アクセシビリティの向上に取り組んでいる人々にとって、タブ オーダーから要素を削除するだけでなく、アクセシビリティ ツリーからも要素を削除するため、より強力な aria-hidden のように機能します。 開発者は、最適な API を使用してコンポーネントを構築し、優れたアクセシビリティを自由に実現できます。 ZOMG 完璧な勝利ですね！

ディスカッション スレッドの他の誰かが、新しい CSS プロパティ (つまり inert - 翻訳者注) がより良い解決策である可能性があると述べたことを付け加えておきます。それも素晴らしいと思いますが、私の (非常に限られた) 知識に基づいて提案することはできません。これは開発者にとって非常に悩みの種です。そこで私は Chrome のバグを報告し、Chrome チームが inert を実装するプロセスの再起動を試みるかどうかを確認しました。これらの使用例について書くことで、その有用性を他の人に納得してもらえることを願っています。何か進展があれば、必ずフォローアップ記事を書いて皆さんにお知らせします :bee:

英語の原文: http://robdodson.me/building-better-accessibility-primitives/