2023年10月20日の「クラスメソッドのReact事情大公開スペシャル」にて発表した資料です。

1. アクセシビリティから考える
Reactアプリの品質向上
クラスメソッド 持田 徹

2. 自己紹介
● もっちー @motchie 持田 徹
● 2018年7月入社
● CX事業本部Delivery部デリバリーマネー
ジャー
● 受託開発案件のプロジェクトマネージャー
・ スクラムマスター
● 2002年からアクセシビリティの研究・
執筆・講演・コンサルティング
2

3. アクセシビリティ(a11y)とは?
● アクセス可能な度合い、アクセスしやすさ
● 障害者や高齢者を含む、より多くのユーザーが、
より多くの利用環境から、より多くの場面で利用で
きるようにしていきたい
● より多くの人が利用できる状態＝「アクセシブル」
3

4. アクセシビリティはソフトウェア品質評価の要素
4
独立行政法人情報処理推進機
構（IPA）技術本部 ソフトウェ
ア高信頼化センター（SEC）
『つながる世界のソフトウェア
品質ガイド あたらしい価値提
供のための品質モデル活用の
すすめ | 書籍・刊行物』より

5. Q. Reactアプリを
アクセシブル(高品質)にするには？
A. スクリーンリーダについて
知ることがカギ
5

6. ITの支援技術(Assistive Technology; AT)
PCやスマホなどを使う際に支援が必要なユーザーに、
そのニーズに合う機能を提供するソフトウェアや
ハードウェア、デバイスなどの総称
● スクリーン・リーダー(VoiceOver, TalkBack など)
● 画面拡大、色反転、ジョイスティック、トラックボール、
キーボードガード、...
6

7. macOSのVoiceOverの基本
● 起動と終了: Command＋F5キー
● VoiceOverカーソル: 読み上げ・操作対象を選ぶ
● VoiceOver修飾キー:
Caps Lock または Control＋Option に設定
○ VO＋F8: VoiceOver修飾キーとF8の組み合わせ
● VoiceOverローター(VO＋U):
○ Webページ内の特定の場所への移動を簡単に
7

8. macOSのVoiceOverのデモ
8

9. Accessibility Object Model(AOM)/Tree
9
from: Accessibility Object Model | aom

10. 主なAccessibility node properties
10
名前(name)
「アクセシブルな」名前。label要素で関連づけ
られる場合も。
description
説明。nameより詳細な説明。title属性などで
付与される。
役割(role)
ボタン、リストといった役割。この値によって振
る舞いが変わる。必ず存在する項目。
状態(state)
オブジェクトがチェックされている、展開されて
いるなどの状態をあらわす。

11. Chrome DevToolsでのAOMの確認方法
11

12. 画面はHTMLのセマンティクスで表現する
12
from: What Is
Semantic Markup
and Why You
Should Use It | by
Sumudu
Siriwardana |
CodeX | Medium

13. 例題: このコードサンプルの問題点は?
import React, { useState } from "react";
function App() {
return (
<header>
<LikeButton />
</header>
);
}
function LikeButton() {
const [count, setCount] = useState(999);
return <span>♥ {count}</span>;
}
export default App;
13
from: Reactでいいねボタンを作ろう の途中のサ
ンプルを改変

14. Reactコンポーネントで考慮すべき点(1)
● JSXは、コンポーネントが、どんなHTMLセマンティクスで表現さ
れるのがベストかを考慮して実装する。「とりあえずdiv、とりあえ
ずspan」は避ける
● 画面全体がHTML Standardに準拠しているか常に確認する
● アクセシビリティの問題は機械チェックだけでは検知できない。
「Storybookにa11yチェックプラグインを入れたらOK」などの
「アクセシビリティは理解したくない、仕組みでカバーする」運用
は、現在のところできない。人による設計やチェックが必須
14

15. Q. タブ、ハンバーガーメニューなどは、
HTMLでは表現できないのですが...?
15

16. A.WAI-ARIAを使います
16
● W3CのWeb Accessibility Initiativeが策定する
Accessible Rich Internet Applications (WAI-ARIA)
仕様
● HTMLにない役割、性質、状態をrole属性、aria-*属性を使っ
て追加・拡張することができる
● role=”tab”、role=”tabpanel”、role=”tablist”、...
● かなり高機能、ただし乱用はかえってアクセシビリティを低下さ
せてしまう

17. ARIA Authoring Practices Guideについて
17
from: ARIA Authoring
Practices Guide |
APG | WAI | W3C

18. Reactコンポーネントで考慮すべき点(2)
● キーボード操作、フォーカスマネジメント、色のコントラスト、
TabIndex、適切なWAI-ARIAの利用など、アクセシブルなコン
ポーネント開発には考慮点が多いため、自分でUIを作ることは極
力避ける
● dialog要素、Popover APIなど最新HTMLの恩恵を利用する
● 既存のReact Component Librariesにある
”Accessibility out of the box”は鵜呑みにしない方がよい
● UnstyledなHeadless UI、AdobeによるReact Ariaを組
み合わせる方向か
18

19. その他に考慮すべき点
● スクリーンリーダーでは、見た目上のページが切り替わったことに
気づくことができないため、React Helmetなどを用いてペー
ジタイトルを適宜変更する
○ Astro3.2などには、<ViewTransitions /> に”Route
Announcer”が追加された
● 動的に画面が更新される部分には、ARIA live regionsを利用
して支援技術に更新を通知する
19

20. 少しずつ始めていきましょう！
● JSXでのマークアップをセマンティックに、Roleを意識する
● 画面全体のHTMLが仕様に準拠するように
● HTMLで表現できない部分は、最低限のWAI-ARIAで
● 独自UIは避け、アクセシブルなコンポーネントライブラリを利用
● 動的な更新部分はARIA live regionsを利用
● ページ遷移はRoute Announcerで通知
● スクリーンリーダーでテスト、キーボード操作、文字拡大 etc.を確
認
20

21. ありがとうございました！
21