二歩目のフロントエンド・ウェブアクセシビリティ

Transcript

1. 二歩目のフロントエンド・ ウェブアクセシビリティ フロントエンドカンファレンス関西2026 KAMIHARA Takumi / camiha
2. 自己紹介 • 神原 拓海（かみはら たくみ） • GitHub: @camiha X: @_camiha • 所属 • 株式会社アンティー・ファクトリー • フロントエンドエンジニア • アクセシビリティスペシャリスト • 好きなこと • 自作キーボード、自作3Dプリンタ、 温泉、料理、音楽 2 / 64
3. 取り組んでいること • フロントエンド開発 • デザインデータに対する、アクセシビリティレビュー • ウェブサイトに対して、アクセシビリティを満たしているかの試験 • 社内勉強会の運営 • アクセシビリティ関連の文章執筆 • イベントのボランティアスタッフ • OSS 3 / 64
4. 業務やイベントを通して感じること • 「アクセシビリティ」という言葉を聞く機会は増えている • フロントエンドエコシステムでは当たり前のように言及されている • アクセシビリティチェックを行うツール • コンポーネントライブラリ 4 / 64
5. 実際に遭遇したこと・質問を受けたこと等 • ライブラリを入れているので、アクセシビリティ準拠できています！ • どこまでは自動チェックできて、どこからは手動チェックになるのか？ • WCAG 読んでみたけど難しい、挫折してしまった • 具体例を踏まえながら、紐解いていきます 5 / 64
6. ハンバーガーメニューのアクセシビリティ改善 • 段階的にコンポーネントを改善 • その過程で、どういった問題が生まれるかを 確認していく • 今回は展開を制御する、ボタン部のみを題材 6 / 64
7. ハンバーガーメニューのアクセシビリティ改善 • 「アクセシブルネームがない」という問題が報告される • ページの中の要素を、支援技術に伝えるための名前 • 例えばスクリーンリーダーでの音声読み上げ時 • 「ボタン」とだけ読み上げられてしまう • 何をするボタンなのかわからない 7 / 64
8. スクリーンリーダーとは • 視力がない・ほとんどない場合、画面の内容を把握できない • 画面の内容を、音声で読み上げて伝える必要がある • スクリーンリーダーを利用して、音声読み上げができる • PC-Talker, NVDA, VoiceOver, TalkBack • 日本であれば、PC-Talker ユーザーが多い • 第4回支援技術利用状況調査報告書 | 日本視覚障害者ICTネットワーク • https://jbict.net/survey/at-survey-04 8 / 64
9. 9 / 64
10. ヘッドレスライブラリでの、ドキュメント内言及 • Accessibility – Radix Primitives • Ultimately it's up to you to provide those labels so that users have the proper context when navigating your application. • 正しく操作できるラベルを提供するのは、開発者の役割 10 / 64
11. ハンバーガーメニューのアクセシビリティ改善 • 今度は読み上げられるようになった • 一方で、開いているかどうかが分からない • 視覚的にはアイコンの変化で伝えているものの、支援技術には伝わらない 11 / 64
12. ハンバーガーメニューのアクセシビリティ改善 • 読み上げでも開いていることが確認できるようになった…? 12 / 64
13. ハンバーガーメニューのアクセシビリティ改善 • 読み上げでも開いていることが確認できるようになった…? • スクリーンリーダーによって挙動が異なる • 押したタイミングで、aria-label が更新されても、読み上げられない 13 / 64
14. ハンバーガーメニューのアクセシビリティ改善 • 状態を aria-expanded を用いて示すように • 二重で状態が読み上げられてしまうため、aria-label から状態表記を削除 • 問題なく操作できるように 14 / 64
15. コンポーネント改善はまだまだ続く • ホバーしたとき、色が薄くなるボタン • そもそも「ハンバーガーメニュー」ってなんだろう • この文言って、視覚的には伝わらないのでは？ • aria-label って button 要素につけるべき？ • svg 要素につけた方がいいのでは？ • svg 要素だったら title 要素も使える？ 15 / 64
16. レビューで指摘したことの一例 • SPA で画面遷移した際、ページタイトルが更新されない • 遷移したことが支援技術に伝わらない • リンクを button 要素で実装している • リンク一覧表示ができない • 右クリックで、リンクに応じたメニューが表示できない • aria-label で可視テキストを上書きする • 表示されている文言と、支援技術に伝わる文言が異なるケース • 音声コントロールでの操作に手間 16 / 64
17. 音声コントロールとは • 文字通り、音声認識で操作する • 手が動かせない、物理的な操作が難しいケース • 番号を表示させ、番号を呼ぶことでも操作できる • 可視テキストを用いることもできる • 「続けるをタップ」のように • 可視テキストと、支援技術に伝わる名前が異なると操作 が難しくなる可能性 17 / 64
18. ここまでの整理 • アクセシブルネームの有無はチェック出来る • でもそれが適切かどうかはわからない • 文脈に応じて、適切な名称を設定しなくてはいけない • ARIA 属性を利用したからといって、絶対アクセシブルになるわけではない • 正しく使える前提 • ARIA 属性を使わないことも検討する • 支援技術やサポート状況を踏まえた実装が必要 18 / 64
19. なるほど、じゃあ 生成 AI は？ • 適切に ARIA を使って、名前をつけるのは生成 AI で出来るんじゃないか？ • どの分野でも言われることですが • 学んだことが使えなくなっていくのは不安がある • その分野が取って代わられるのは心配 19 / 64
20. 生成 AI とウェブアクセシビリティ • WebAIM: The WebAIM Million - The 2026 report on the accessibility of the top 1,000,000 home pages • 人気ランキング（Tranco List）上位100万サイトを自動診断（WAVE） • 95.9% のページで WCAG 違反を検出 • 前年の調査から、ページあたりの平均エラー数は増加している • ARIA 属性を利用したコードは前年から増えている（1年で27%増加） • ARIA 属性を使っていないページより、使ってるページは平均エラー数が多い • 要因の一つに、Vibe coding があるのではないか、と締めくくっている 20 / 64
21. 生成 AI とウェブアクセシビリティ • AIMAC: The AI Model Accessibility Checker • アクセシビリティの指示なしで、AI モデルにウェブページを生成 • axe-core による WCAG 2.2 の自動チェックをさせ、スコア化 • 日々改善されているが、問題は 0 になっていない • A11y LLM Eval Report • スキルを使うと品質は向上した • 完全には解決しない 21 / 64
22. WCAG とは • Web Content Accessibility Guidelines • ウェブコンテンツのアクセシビリティに関する、国際的なガイドライン • 現在のバージョンは WCAG 2.2 • 達成基準と呼ばれる、検証可能な項目がある • A, AA, AAA のレベル • レベル AA を目標にしていることが多い • 適合したからといって「すべての人が使える」わけではない • 「一人でも多くの人が使える」ようになることは確か 22 / 64
23. 生成 AI とウェブアクセシビリティ • Screen Reader User Survey #11 Results • スクリーンリーダーユーザーの60.1%が、AI で画像の説明を生成 • Beyond Alt Text: Rethinking Visual Description in the Age of AI • 生成 AI が提供する画像説明が、ニーズを満たせてはいない • 説明に誤りがあるケース • 「〜が含まれる可能性があります」のような説明 • 周囲の文脈を踏まえて説明できていない • あくまでも補助的に活用し、人間が作成したものを優先すべき 23 / 64
24. ここまでの整理（2） • 自動チェックの通過は、問題がないことの保証にはならない • WCAG の一部、機械的に判断できるところだけ • AI によるレビューも同様 • WCAG を満たしたから OK、ではない • AI にアクセシビリティの担保を求めるプロンプトを書いても解決できない • アクセシビリティの担保を求めることと、実際にそうであるかの確認は別物 24 / 64
25. 冒頭の疑問に答える • ライブラリを入れているので、アクセシビリティ準拠できています！ • 入れるだけでアクセシビリティを満たすのは難しい • どこまでは自動チェックできて、どこからは手動チェックになるのか？ • ページを跨ぐような確認 • 支援技術に、正しく情報を伝えているかの確認 • 複数の支援技術や、サポート状況を踏まえて、適切な実装か判断 • 他にもたくさん 25 / 64
26. そもそも、こういった疑問が生まれるのはなぜ？ • エコシステム側の主張が年々強まっているのが一因なのではないか • 悪い部分だけではないと思っている • 学ぶハードルの高さもありそう 26 / 64
27. 多様化するアクセシビリティの入口 • 「アクセシビリティ」を知るきっかけは様々 • 誰かの悩み、自分の悩みだけじゃない • フロントエンドエンジニアに関しては「エコシステム経由で知った」という 人も少なくないはず • 学生さんからは「スマホゲームの自動化」をする過程で「アクセシビリテ ィ」という言葉を知った、という意見も 27 / 64
28. 多様化するアクセシビリティの入口 • 「アクセシビリティ」という言葉を知るきっかけには恵まれている • 次のステップに進むハードルはどうしても高いように思える • フロントエンドエンジニアを取り巻く環境が、そうさせてしまっているの ではないか • 入口なんて関係なく、興味を持ってくれたのはすごく嬉しいこと • だからこそ、本来の目的にしっかり向き合うのが大切 28 / 64
29. そもそも、アクセシビリティとは • アクセシビリティとは | ウェブアクセシビリティ基盤委員会（WAIC） • アクセスのしやすさ • 転じて、製品やサービスの利用しやすさ • さまざまな利用者が、さまざまなデバイスを使い、さまざまな状況でウェ ブを使うようになった今、あらゆるウェブコンテンツにとって、ウェブア クセシビリティは必要不可欠な品質 29 / 64
30. そもそも、アクセシビリティとは • さまざまな利用者 • 見え方の違い、聞こえ方の違い、体の動かし方の違い、理解の仕方の違い • さまざまな閲覧方法 • スクリーンリーダー、画面拡大、テキストサイズの変更、音声コントロー ル、点字ディスプレイ • さまざまな状況 • 明るい屋外、電車の中、片手で荷物を持っている、寝不足の時 30 / 64
31. そもそも、アクセシビリティとは • どんな人が、どのように使っているのか • これを知らなきゃ始まらない • 本来の目的を見失ってしまうと「どうしたらいいか」みたいな意見が生まれ やすいのではないか 31 / 64
32. 目的はわかった、じゃあどうすれば？ • 様々な利用者を交え、開発すること • 一つの目指すべき姿 • でも、今すぐに取り組めるか？というと、環境によって違う • 身の回りの課題に目を向けてみる 32 / 64
33. 私のお父さんの例 • 大きい文字に変更する • ブラウザの設定で拡大 • 老眼でも見やすい 33 / 64
34. 私のお父さんの例 • 実装によっては、文字サイズを拡大できなくなってしまう • vw 単位でフォントサイズ指定をする実装 • 拡大できても、折り返されず、横スクロールが生まれてしまう実装 • 文字画像で実装 • ピンチズームで拡大できるけれど、操作が増えてしまう 34 / 64
35. どうしても技術的な話に走りがちだけど • そもそも「老眼って何？」 • 「老眼ってどういうふうに見えるんだろう？」 35 / 64
36. どうしても技術的な話に走りがちだけど • そもそも「老眼って何？」 • 「老眼ってどういうふうに見えるんだろう？」 • こういうところにギャップがある場合も 36 / 64
37. 少しずつ、多様性を学んでいく • 多様な見え方 • 老視（老眼）、白内障、緑内障、網膜剥離、色覚異常 • 私も全ての人の見え方を、網羅して知っているわけではない • 一人でも多くの見え方を知っていく姿勢が必要 37 / 64
38. 少しずつ、多様性を学んでいく • メガネを忘れた時 • これも見え方の多様性の一つ • 一時的な障害という捉え方 38 / 64
39. 一時的な障害の例 • 文字のサイズが変更できる • メガネを忘れた時でも役に立つ • 動画に字幕があること • 聴覚に障害がある場合 • イヤホンを忘れた電車の中 • 大きいボタン • 手に震えがある • バスの中で振動が大きい 39 / 64
40. グラデーションのようにとらえるアプローチ • ペルソナ・スペクトラム • Inclusive 101 - Microsoft Inclusive Design • ペルソナスペクトラムツール - パナソニックホールディングス • 身の回りの課題から、その先に何があるのか、というのを考える機会に • もちろん、全ての障害がグラデーションのように当てはまるとは思わない • この枠に当てはまらないものを排除する、という考えではない点に注意 40 / 64
41. 出典：Inclusive 101（https://inclusive.microsoft.design/articles/inclusive-101-guidebook） 41 / 64
42. 私の話 • 色覚異常がある • 日本人男性の5% 日本人女性の0.2%（出典：公益社団法人 日本眼科医会） • 生まれつき、赤い色の区別が難しい（1型3色覚） • 日常生活 • お肉焼けたか、わからないのは結構困ってる • エンジニアを初めてすぐの頃 • 「赤い文字にする」というデザインを反映できていなかった 42 / 64
43. 問題のある例 • フォーム • 「赤字項目にエラーがあります」 • 色の判別ができないとエラーが分からない • 少し違うなーという手がかりから判別 • 辛い • 赤字を使うのが NG というわけじゃない • 赤字のみでエラーを伝えているのが問題 • テキストを併記する 43 / 64
44. WCAG における達成基準 • エラーであることを色だけで伝えている • 達成基準 1.4.1 色の用途 • 「エラーがあります」だけじゃ何をしたら いいか分からない • 達成基準 3.3.3 エラーの修正提案 44 / 64
45. 困るのは色覚異常を持つ人だけではない • スクリーンリーダーでの読み上げも同様 • 「赤字」ということは読み上げられず、伝達できない 45 / 64
46. 他にも問題がある • スクリーンリーダーに伝わらない • お名前（フリガナ） 46 / 64
47. 知ることで始まる、ウェブアクセシビリティ • 「悩み」を知っているからこそ改善ができる • 自分のこと、近しい人、始められるところから • 少しずつ、どういう悩みがあるかに向き合って、知見を増やしていく • WCAG、書籍、動画、イベント、自分が始めやすい手段から • 対面イベントは、新しい気づきがたくさんある 47 / 64
48. 行動につなげる • 自分の作ったアプリケーションを、支援技術で操作してみる • 自分の作ったアプリケーションに、ウェブアクセシビリティ試験をしてみる • デザインシステムに学ぶ 48 / 64
49. 支援技術の使い方を学んで、操作してみる • スクリーンリーダーを操作してみる • #2 西本 卓也&辻 勝利「スクリーンリーダーは怖くない！ NVDA & VoiceOver 10の基本テクニック」【GAAD Japan 2021】 • フットワーク軽く起動して、実装コードを検証するスキルは役立っている • 実際の使われ方を知ることも大事 49 / 64
50. 支援技術の使い方を学んで、操作してみる • 音声読み上げが全てではないことも念頭におく • 他の支援技術で使いにくくなってしまうことも • スクリーンリーダーでの読み上げを改善する過程で、過剰に情報を詰め込ん でしまうケース • aria-label を頑張って書きすぎる • 視覚的に表示されているものより、スクリーンリーダーに伝わる情報の方 が多かった、なんてことも • アクセシビリティの目的を思い出して、振り返る 50 / 64
51. ウェブアクセシビリティ試験をしてみる • ウェブページやアプリケーションが WCAG の達成基準を満たしているか確認 • 自動テスト • 手動テスト（目視・スクリーンリーダーで閲覧） • 項目ごとに満たしているか、そうでないかを確認していく • レポートにまとめる • 私はこれで学んだところも多い • とはいえ、業務で試験できる環境が全てではない 51 / 64
52. 試験を始めやすい形に分解してみる • 厳密にやるのはそこそこ大変 • 試験というボリュームを分解してみる • コンポーネント単位でのアクセシビリティレビューをしてみる • Storybook でコンポーネントを開き、スクリーンリーダーで操作 • WCAG を読みながら評価していく • アクセシビリティ・ガイドラインの歩き方（初心者編） • Ameba Accessibility Guidelines • AI レビューは内容をしっかり確認できて、過不足を指摘できるのであれば 52 / 64
53. コンポーネント単位で試験・改善してみる • ホバーした時、色が薄くなる • 達成基準 1.4.3 コントラスト (最低限) • 達成基準 1.4.11 非テキストのコントラスト • ターゲットサイズが小さい • 達成基準 2.5.8 ターゲットのサイズ (最低限) • 達成基準 2.5.5 ターゲットのサイズ (高度) 53 / 64
54. 確認する範囲を広げていく • そこからページ単位に • Storybook 単体で見た H3 • ページにしたら情報構造が壊れている • モバイルだけアコーディオンになるケースでよく指摘する • ランドマークが多すぎてスクリーンリーダーでジャンプしにくい • スクリーンリーダーを使ってみると、気付ける観点 • API 接続してわかることもある • エラーメッセージ、認証、制限時間 54 / 64
55. デザインシステムに学ぶ • 良いデザインシステムはたくさんある • アクセシビリティに言及した、ドキュメントが整備されているもの • 個人的によく見るもの • デジタル庁デザインシステムβ版 • GOV.UK Design System • GitHub's Primer Design System 55 / 64
56. ピックアップ：デジタル庁デザインシステムβ版 • テキストエリア • 文字数が上限を超えたとき、 エラーを表示する • ペーストした後に編集したい時 • 文字超過分が欠けてしまい、 手間取る時がある • 切り取らずに、エラーを表示し て修正の提案 出典：デジタル庁デザインシステムβ版 （https://design.digital.go.jp/dads/components/textarea/） 56 / 64
57. ピックアップ：GOV.UK Design System • Text input – GOV.UK Design System • <input type="number"> • ユーザー調査で必要性が確認されない限り使用しない • スピンボタンが出現する • スクロール時に誤って編集してしまう場合 • 対処法 • <input type="text" inputmode="numeric"> • スマホで数字のキーパッドを出現させるように 57 / 64 スクリーンショット：スピンボタンの例
58. ピックアップ：GitHub's Primer Design System • Tooltip | Primer • デフォルトでは非表示なので、最終手 段として利用する • Tooltip が引き起こす問題や、代替案 を解説している • Accessible noti cations and messages • トーストの利用は非推奨 fi 58 / 64 スクリーンショット：GitHub の Dashboard で、メニューボタン にホバーすることで、「Open menu」と記載されたツールチップ が表示されている
59. ウェブアクセシビリティに取り組む理由、取り組み方 • もし見つけることができたなら嬉しい • まずは言葉にしてみよう • 大切な人の困り事に応えたい • 一人でも多くの人に使って欲しい • ウェブの本来の目的に忠実でありたい 59 / 64
60. フロントエンドエンジニアの強みを振り返る • アクセシビリティ、という言葉に触れる機会が多いこと • アクセシブルな実装を、絶えず問うことができる立場であること • AI の可能性を、探求できる機会に恵まれていること • 色々な人と関わって、開発を進めること 60 / 64
61. フロントエンドエンジニアだけじゃできないこと • 例えば「文字のサイズ変更」「コントラスト」 • デザイナーさんと協業するチームであれば、フロントエンドエンジニアだ けの範疇に収まらない • 例えば「エラーメッセージ」 • バリデーションのライフサイクルや責務などを、バックエンドエンジニア と一緒に考えていく必要がある • どちらともコミュニケーションが不可欠な役割だからこそ、始められるアク セシビリティがあるはず 61 / 64
62. Frontend, Unbounded.
63. フロントエンドエンジニアの強みを活かして、 ウェブアクセシビリティを、 「みんなの話」にすること。
64. 二歩目のフロントエンド・ ウェブアクセシビリティ