Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テストから始めるWebアクセシビリティ
Search
すずきゆーだい
October 09, 2024
Programming
0
21
テストから始めるWebアクセシビリティ
こちらで発表した内容は、以下の記事にまとめているのでぜひご覧ください。
https://zenn.dev/yumemi_inc/articles/2df0e3ae5ae9aa
すずきゆーだい
October 09, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
330
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
200
Асинхронность неизбежна: как мы проектировали сервис уведомлений
lamodatech
0
990
EC2からECSへ 念願のコンテナ移行と巨大レガシーPHPアプリケーションの再構築
sumiyae
2
440
[JAWS-UG横浜 #76] イケてるアップデートを宇宙いち早く紹介するよ!
maroon1st
0
510
Beyond ORM
77web
9
1.2k
ChatGPT とつくる PHP で OS 実装
memory1994
PRO
2
130
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
830
生成AIでGitHubソースコード取得して仕様書を作成
shukob
0
530
Kaigi on Railsに初参加したら、その日にLT登壇が決定した件について
tama50505
0
110
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
970
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
590
Featured
See All Featured
Making Projects Easy
brettharned
116
6k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
48
2.2k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Code Review Best Practice
trishagee
65
17k
Designing Experiences People Love
moore
138
23k
The Language of Interfaces
destraynor
154
24k
BBQ
matthewcrist
85
9.4k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
How GitHub (no longer) Works
holman
311
140k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
The Cost Of JavaScript in 2023
addyosmani
46
7k
Writing Fast Ruby
sferik
628
61k
Transcript
テストから始めるWebアクセシビリティ すずきゆーだい
すずきゆーだい @szkyudi 株式会社ゆめみ所属 主にWebフロントエンドエンジニア 秋になると柿を200個ほど食べます 今秋は9月から今日まで54個(ペース遅め)
アクセシビリティは誰のためにあるか アクセシビリティは特定の人だけではなく、 あらゆる人のためにあるものです。 というようなことをよく耳にすると思いますが、 いまいちピンときていない方も多いのではないでしょうか?
エンジニア自身も恩恵を受ける当事者 少しでもアクセシビリティに興味を持ってもらうために 「テストから始めるWebアクセシビリティという」テーマで お話しさせていただきます。
Webフロントエンドにおけるテスト テストにはさまざまな種類があると思います。 今回はその中でもUIコンポーネントのテストにおける アクセシビリティについて紹介します。
React Testing Library を用いて、 Pulldownコンポーネントをテストするときの サンプルコードを紹介したいと思います。 他の技術でもおおむね同じように応用できるはずなので、 適宜読み替えていただけると幸いです。 例として用いる技術とコンポーネント
None
アクセシビリティを考慮していない例
role=”button” role=”button” role=”button” role=”button” role=”button”
テストコード
role=”button” role=”button” role=”button” role=”button” role=”button” 1つだけ 2つ
アクセシビリティを考慮した例(不完全)
role=”listbox” role=”listbox” role=”option” role=”option” role=”option”
role=”listbox” role=”listbox” role=”option” role=”option” role=”option” 1つだけ 1つずつ
テストコード
aria-expanded=”false” aria-expanded=”true” aria-selected=”false” aria-selected=”false” aria-selected=”true” 開閉状態を伝える 選択状態を伝える
このPulldownはまだまだ不完全 わかりやすい説明をするために、対応するべき実装を 大幅に削って紹介させていただきました。 より詳しい解説やこの発表で紹介したコードは Zennにも公開予定(19:30)なので、ぜひご覧ください。 テストから始めるWebアクセシビリティ
テスタビリティ !== アクセシビリティ 不適切なWAI-ARIAの利用や HTMLの仕様をハックした使い方は、 かえってアクセシビリティを下げる場合もあります。 仕様についてよく調べてから活用するか、 不安なときは `data-testid` を利用するようにしましょう。
他の要素やライブラリの利用を検討してみる 複雑なUIになればなるほど、 アクセシビリティを考慮すべきポイントが増えてきて 実装やテストも難しくなります。 <select> や <option> などのネイティブな HTML 要素や
よく利用されているUIコンポーネントライブラリは アクセシビリティを考慮してくれている
これからも みんなでより良いプロダクトを! (SNSや対面でのご意見、ご感想もお待ちしています)