accrefs

Webアクセシビリティの参考資料まとめ

カラーモード

フロント実装（HTML・CSS・JS・WAI-ARIA）

アクセシビリティ改善中！ LIFULL HOME'S スマートフォンサイト

株式会社 LIFULL のフロントエンドエンジニアが、スマートフォンサイトのアクセシビリティ向上に取り組んだ結果を紹介。ボタンの正しい実装や、追加コンテンツのフォーカス管理などに取り組んだことが挙げられる。ボタンの実装に関しては、WAI-ARIA を用いて役割を上書きした上で、キーボード操作を可能にする工夫をしている。また、追加コンテンツのフォーカス管理にも取り組んでおり、フォーカスが失われないよう改善を行った。カルーセルの自動再生をやめて表示順をランダムにした話は参考になる。

WAI-ARIAを学ぶときに整理しておきたいこと

このテキストでは、ARIA 属性を使用する前に知っておくべき重要な事項について詳しく説明している。まず、HTML 要素に対応する暗黙のロールを理解し、プロパティやステートを設定する前に適切なロールを把握することが重要である。また、role 属性を使用する際には、上書きできないロールが存在すること、既に要素に対応する適切なロールがある場合はそれを使用すべきであること、暗黙のロールを明示的に宣言する必要はないこと、そして抽象ロールにも注意を払う必要があることを知っておく必要がある。これらの指針を頭に入れながら、ARIA 属性を適切に使用することが重要である。

WAI-ARIA中級編 ロールの決まり方

WAI-ARIA では、要素には暗黙的なロールが与えられており、role 属性を使用することでこれを上書きすることができる。ただし、上書きできないロールも存在する。要素の種類、属性、構造によって暗黙的なロールが決まるため、これらを考慮して暗黙的なロールを理解する必要がある。また、role 属性を使用して明示的なロールを指定することもできるが、仕様にないロールや抽象ロールは無視される。

【アクセシビリティ】WAI-ARIAを完全に理解した。

WAI-ARIA（Web Accessibility Initiative Accessible Rich Internet Applications）は、W3C が策定したアクセシビリティ向上のための仕様であり、HTML では表現できない意味を属性で補完することができる。これにより、スクリーンリーダーなどの支援技術を利用して、障害を持つ人々に対しても適切な情報を提供することが可能となる。WAI-ARIA では、role 属性や aria 属性が定義されており、これらを適切に活用することでアクセシビリティを向上させることができる。ただし、WAI-ARIA は必要な場面でのみ使用することが推奨されており、HTML 要素の意味を変えないように注意する必要がある。また、フォーカス可能な要素には role=presentation や aria-hidden=true を使用しないようにすることも重要である。

タブ型UIのアクセシビリティを向上させてみよう！｜bonji810｜note

今回は「タブ型 UI」に関する記事で、Web サイトや Web アプリ開発者向けにタブ型 UI のデザインと実装方法について解説している。タブ型 UI はアクセシビリティを考慮することで、ユーザーに情報を効率的に伝えることができる。記事では、タブボタンとタブパネルのアクセシビリティを向上させるための方法について詳しく説明している。

アコーディオンUIのアクセシビリティを改善してみよう！｜bonji810｜note

今回は「アコーディオン UI」に関する内容を取り上げる。アクセシビリティを向上させることで、キーボード操作によるアコーディオンパネルの開閉やスクリーンリーダーの使用が容易になる。記事では、マークアップの方法やアクセシビリティの向上策について説明している。公開されている URL を参照し、キーボードやスクリーンリーダーを使って操作してみると良い。

カルーセルUIのアクセシビリティを向上させてみよう！｜bonji810｜note

カルーセル UI をアクセシブルにすることで、ユーザーの利便性が向上する。スクリーンリーダーを使用する場合でも、アクセシブルなカルーセル UI の実装が重要である。本記事では、マークアップの方法やスライドの操作、スライドコントロールボタンやスライドコントロールタブなどに関するアクセシブルな実装方法について説明する。

table要素内にth要素が必要な理由

スクリーンリーダーを使用して Web ページから情報を取得する際には、テーブルからの情報取得に工夫が必要である。テーブルの th 要素を設定すると、スクリーンリーダーはデータセル（td 要素）の内容を読み上げるだけでなく、対応する見出しセルの内容も読み上げる。たとえば、カレンダーでは、th 要素を設定することで曜日と日付を関連付けて確認できる。また、列方向への移動も可能であるが、スクリーンリーダーやブラウザの組み合わせによっては利用できない場合がある。th 要素はスクリーンリーダーユーザーが情報を正確かつ迅速に取得できるようにするために重要である。

<dialog>内でautofocus属性がほぼ必須になる話

HTML Standard の dialog 要素に関連する変更があり、Scott O'Hara 氏の提案の一部がマージされた。追加された autofocus 属性は、ユーザーがすぐに対話することが予想されるダイアログの子孫要素または dialog 要素自体に使用することが推奨される。ただし、まだ各ブラウザで実装されていない箇所もあり、改善が必要な部分も存在する。また、dialog 要素の概要も変更された。

アクセシブルじゃないクリックイベントを発見する

このスクリプトはアクセシビリティのチェックとデバッグに使用される。スクリプトを実行することで、アクセスできないクリックイベントを持つ要素を特定することができる。視覚的には、要素に赤い枠線が強制的に表示され、I_AM_NOT_ACCESSIBLE というクラスも追加される。このスクリプトは DevTools のコンソールから実行されることを前提としているが、同様のテストを自動化する場合は acot を使用することをおすすめする。

react-modal のアクセシビリティまわりの実装を読む

React-modal のアクセシビリティに関する内容を調査した。アクセシビリティには、app element、Keyboard Navigation、ARIA attributes の 3 つの機能がある。app element は、スクリーンリーダーを使用するユーザーのための機能であり、モーダルが開いている間、ページコンテンツを非表示にする役割を果たす。Keyboard Navigation は、モーダルが開いている時にキーボード操作をモーダル内に制限する機能である。このアクセシビリティには注意点もあるが、推奨される使い方に従えば問題なく利用できる。

アクセシブルなアコーディオンの実装について考える

この記事では、アコーディオン UI の実装について考察している。アコーディオンは、垂直方向に積み重ねられた見出しとコンテンツから構成される UI であり、ページのスクロール量を減らすために使用される。記事では、HTML タグの修正、キーボード操作、WAI-ARIA の実装などについて考察している。アクセシブルなアコーディオンの実装を行う際には、ARIA Authoring Practices Guide (APG)を参考にすることが推奨されている。

アクセシブルなモーダルダイアログの実装について考える

モーダルダイアログの実装について、WAI-ARIA 1.2 と ARIA Authoring Practices Guide (APG)を参考に考察した。モーダルダイアログは、アクティブなダイアログウィンドウの外にある不活性なコンテンツを視認性を低くする。ユーザーは不活性なコンテンツを操作できず、Tab キーや Shift + Tab キーでもダイアログの外にフォーカスを移動させない。また、Escape キーでダイアログを閉じ、ダイアログを閉じた時には通常呼び出した要素にフォーカスを戻す。モーダルダイアログ要素には role=dialog と aria-modal=true を付与する。また、ダイアログのタイトルを参照するために aria-labelledby 属性や、主な目的やメッセージを説明する要素を参照するために aria-describedby 属性も使用できる。

SPA(Next.js)のスクリーンリーダーによる画面遷移で工夫したこと

Single Page Application (SPA) の画面遷移に関する問題を紹介している。問題としては、Route Announcer が次ページのタイトルを読み上げることでページ遷移したことをユーザーに知らせるが、ユビー AI 受診相談ではページごとにユニークなタイトルを設定するのが難しいという問題がある。また、Route Announcer にはスクリーンリーダーのカーソル位置を修正する機能がないという問題もある。解決策としては、Next.js の Route Announcer を無効にして、独自実装した見出しにフォーカスを当てる機能を採用することで問題を解決した。

React で h1-h6 を正しく使い分ける

React などのコンポーネントベースのライブラリを使用する際に、HTML の見出し要素 h1-h6 が正しくマークアップされていないことによって生じるアクセシビリティや SEO 上の問題を説明している。見出し要素はウェブページの構造を示し、スクリーンリーダーや検索エンジンによって理解される。また、見出し要素は階層構造に対応しており、一定の順番で使用する必要がある。本記事では、見出し要素の不適切な使用によって生じる問題と解決策を紹介している。

今からでも遅くない！誰も教えてくれなかった React とアクセシビリティーの世界

Front-End Study #3 で発表されたライブコーディングの内容を記事にしたものである。記事では、React と Next.js を用いてアクセシビリティについての普遍的な事実を紹介している。記事には、基本事項、セマンティック、スタイリング、アクセシブルな名前の設定、ランドマークと見出し、隠し要素などが含まれている。読者は、アクセシビリティに関する普遍的な事実を学ぶことができる。

アクセシビリティ第一歩、labelが超重要な話。~ placeholderじゃダメなの？~

アクセシビリティにおいて、label 要素は重要な指標の一つであり、適合レベル A に達していないと支援技術を使ってもサービスを利用できないことを意味する。label 要素によって選択が容易になり、音声読み上げが可能になる。一方で、label 要素がない場合、スクリーンリーダーの使用者は入力欄の項目名を知ることができず、エラーの解決方法も分からなくなってしまう。代わりに placeholder を使っても、ユーザーの短期記憶に負荷をかけたり、入力内容を確認できないというデメリットがある。

React Testing Libraryでテスト駆動アクセシビリティ改善

React Testing Library には、アクセシビリティをテストする機能はないが、公式ドキュメントを読んで API の利用方法を理解し、アクセシビリティの高い状態にすることが正しいアプローチである。React Testing Library には、いくつかのクエリメソッドが用意されており、DOM 要素を取得するために使用できる。高い優先順位のクエリでは、タグの種類や aria-role を利用して DOM を検索することができるため、アクセシビリティに配慮したテストを記述することができるようになる。

「１文字ずつ表示」させただけで終わるのはエアコンつけたまま実家に帰るのと同じ【アクセシビリティ】

1 文字ずつ表示する演出はよく要求されるが、アクセシビリティを考慮したコードが重要である。大量生成された span に aria-hidden=true を指定し、スクリーンリーダーユーザーに配慮する必要がある。また、隠れている部分を clip-path で実現する方法が紹介されている。

読書アシストの実装方法について考えてみる

読書アシストの「4. 冒頭文字を階段状に字下げする表示方式」の実装方法について説明している。CSS シェイプ（shape-outside プロパティ）を使用して、図形にテキストを回り込ませる方法を解説している。最大字下げ、最初の字下げ行数、続きの字下げ行数を CSS カスタムプロパティとして設定し、多角形を作るために polygon()を使用している。行の高さもカスタムプロパティに設定し、汎用化にも考慮している。

label で input[type='file'] を装飾するな

ファイル選択の装飾において、よく見られる誤った label 要素の使い方に対して、正しい方法を紹介している。input 要素を非表示にし、button 要素を使用してクリック時に input の click イベントを発火させる方法が、アクセシビリティに優れている。この方法は Twitter や react-dropzone などでも採用されている。button 要素が適切でない場合は、role 属性と tabindex 属性を使ったアクセシビリティに配慮した div 要素を使用することも考慮すべきである。

実装しながら理解するモーダルのアクセシビリティ with React

アクセシビリティ要件を満たすモーダルの実装方法を説明している。実装する要素には、WAI-ARIA 属性の付与、フォーカスの自動移動、フォーカスのトラップ、Esc キーでのモーダル閉じる機能、モーダル外クリックでの閉じる機能が含まれている。また、モーダルが開いている間は、モーダル以外の要素に aria-hidden 属性が付与され、スクロールも無効化される。これらの機能を実装することで、アクセシビリティの高いモーダルを作成することができる。

Xtend UI　A11y規格、アクセシビリティにも配慮されているフロントエンドライブラリ

フロントエンドライブラリ Xtend UI は、シンプルでカスタマイズ性が高く、A11y 規格にも準拠した UI 設計をサポートしている。内部では Tailwind.css、vanilla.js、Gsap を使用し、基本的なコンポーネントや機能を提供している。カスタマイズは tailwind.config.js の設定変更やユーティリティークラスの追加によって行える。ただし、TailwindCSS や Gsap の知識が必要となる。リリース後も頻繁に更新されており、今後も注目されるライブラリとなっている。

テキストのサイズ変更やリフロー、400％拡大にまつわる話

axe-core の活用やコーディングについて取り組みが紹介されている。JIS X 8341-3:2016 の適合レベル AA 準拠の Web サイトコーディングを担当し、達成基準 1.4.4 のテキストサイズ変更に関して疑問が生じた。この問題はアクセシビリティよりもユーザビリティに関連しており、リフローによるコンテンツの改善が達成基準 1.4.10 と関連していることが分かった。結果として、400%拡大時でも横スクロールなしで閲覧できることが確認された。

拡大に強くなる！アクセシビリティ実装の紹介

アクセシビリティ改善に向けた拡大表示に関する CSS テクニックを紹介している。初心者でも理解しやすく、WCAG 達成基準とブラウザ拡大機能について説明し、実装ポイントとして rem の使用を推奨している。rem はブラウザの文字サイズ設定を基準とした相対単位であり、拡大機能に対応することができる。さらに、Media Query においても相対値で指定することで、拡大表示に適切に対応できるが、Safari ではバグが確認されている。

PWA Night vol.35 yamanoku 登壇資料

PWA の活用方法や PWA のミライについて考えていく会「PWA Night」。そのなかでのアクセシビリティ回の登壇資料。PWA の実装を行う上でのアクセシビリティについて解説している。

WAI-ARIA勉強会

WAI-ARIA 一点集中の勉強会。基礎から、ブラウザやスクリーンリーダーなどの支援技術のサポート状況、実際の UI の実装、テストへの応用、そして W3C や WHATWG の仕様策定はどうのようになっているのかまで解説。

高まるウェブアクセシビリティの需要〜フロントエンド最前線〜

Web アクセシビリティの専門家である桝田草一氏と平尾ゆうてん氏によるパネルディスカッション。「ウェブアクセシビリティを知ってはいるが、まだ本格的に始められていない、フロントエンドの知見を増やしたい」という人向けに、明日から活用できる学びを提供する。

なぜ「タブ」はスクリーンリーダーで読めない？ タブをアクセシブルにする | 弁護士ドットコムがアクセシビリティに本気で取り組む狙い

ユーザーテスト結果から、タブの問題がスクリーンリーダーでのアクセシビリティに影響を及ぼしていることが判明した。HTML は「タブ」インターフェイスをサポートしていないため、ウェブ上のタブは正しく扱えない。目標は、「スクリーンリーダーのユーザーにも情報が伝わるようにする」ことであり、適切な対応策を選択する必要がある。

なぜテーブルを使うのか？STUDIOのCMSテーブルで学ぶ｜akiho｜note

STUDIO CMS テーブルの使い方とその理由を紹介している。ボックスレイアウトと CMS テーブルの違いは、スクリーンリーダー利用時の体験が異なる。CMS テーブルでは 2 次元の操作が可能で、見出しセルとデータセルが組み合わせられる。CMS テーブル利用時のポイントは、見出しセルを使うことと、テーブルの直前に見出し要素を配置することだ。これにより、スクリーンリーダー利用者にとって理解しやすい情報が提供される。

アクセシブルなWebサイトを作ってみた：その2。STUDIO PARTNERSとフォーム編｜いっちゃの雑記｜note

アクセシブルな Web サイト作成におけるフォームの改良について紹介している。STUDIO PARTNERS 公式サイトのフォーム制作過程で、使いやすさやスクリーンリーダー対応などの工夫が取り入れられ、アクセシビリティの向上が図られた。記事では、必須項目の視覚化、縦の流れの明確化、プレースホルダーの使用を避けるなどのポイントが解説されている。

アクセシブルなWebサイトを作ってみた：その1 STUDIO PARTNERSとマシンリーダビリティ編｜いっちゃの雑記｜note

STUDIO PARTNERS 公式サイトのリニューアルオープンに伴い、マシンリーダビリティとアクセシビリティに焦点を当てたデザイン手法を紹介している。記事では、ボックス構造、見出し、フォーム、alt 属性、アニメーションなどの実装方法を解説しており、Web サイト制作者がすぐに応用できる内容が含まれている。アクセシビリティを重視し、多くの人が快適に利用できる Web サイトを目指すことが重要だ。

aria-expandedのよくある間違い

WAI-ARIA の中でもよく使われている属性で、コンテンツが展開されているかどうかの状態を表す aria-expanded を使う際によく見られる間違いの事例が 2 つ紹介されている。

アクセシビリティを高めるCSS

CSS で対応できるアクセシビリティ改善例が紹介されている。フォーカスリングを消さないこと、ヒットエリアを広げるテクニック、order プロパティでマークアップを変えずに要素の並び順を制御するテクニック、テキストフィールドで placeholder を使わずに placeholder のように表現できるラベルのテクニックが紹介されている。

2019年のWebアクセシビリティを振り返る：WCAG 2.1の標準化とWAI-ARIAの落とし穴

2019 年のアクセシビリティ関連の動向をまとめた連載の 1 回目。WCAG 2.1 が標準化されても JIS X 8341-3:2016 が更新される見込みは薄いこと、WCAG2.1 は WCAG2.0 から追加はあっても削除された達成基準のない上位規格なので、日本向けのプロダクトでも WCAG2.1 を満たすことを目標にして良いこと、WAI-ARIA の利用は広まってきたが、ライブリージョンを利用する場合は注意が必要であることが紹介されている。

品質と開発速度を両立させるために捨てたものと守ったもの @wadackel @masuP9

株式会社サイバーエージェントのウェブアプリケーション『WinTicket』の開発に関するスライド。p69 からアクセシビリティについてのセクションで、開発速度を上げるためアクセシビリティ対応に Must と Usual を設定し、レビュー基準とした話が紹介されている。適切な要素選択を目指しつつも徹底はしない話、十字キーのフォーカス移動をやめ全てタブキーでできるようにした話が印象的。

マークアップで改善するウェブアクセシビリティ

アクセシビリティを損なうよくある HTML の問題点と、visually-hidden を使った読み上げ可能な非表示テキスト、クリック時にアウトラインを表示しない what-input.js の利用、aria-labelledby を使った触知可能なアイコンボタンの実装など、それを改善する方法が紹介されている。

制作者のためのHTML

HTML は「画面を実装するためのフレームワーク」と「デザインを検証するためのフレームワーク」の 2 つの見方が出来るのではないかという話が述べられている。前者は適切な要素選択によってネイティブの機能を提供できること、後者は HTML で見出しのアウトラインを思考することでデザインカンプをより理解できることを理由にしている。この 2 つの側面を意識してウェブサイトを構築すれば結果的にアクセシブルになると言う。

状態遷移時にアニメーションを伴うUIのアクセシビリティ周りの実装について

ディスクロージャーを例に、アニメーションを伴う状態遷移時の WAI-ARIA の扱い方がコード付きで解説されている。セマンティクス上、アニメーションは存在を意識させず、ユーザーアクションを起点とした状態遷移時には、アニメーションを無視して即座に WAI-ARIA のステートを更新すべきという。

マークアップの最適解を見つけ出す方法

何のためにマークアップするのか？といった基本から、マークアップには正解がない中で、最適解に近づくためにはどう考えたら良いのか？といった現場での優先度決めなどの考え方を紹介しているスライド