Slide 1

Slide 1 text

他人事じゃない Web アクセシビリティ入門 松村 有博

Slide 2

Slide 2 text

アクセシビリティとは

Slide 3

Slide 3 text

アクセシビリティとは 能力や環境にかかわらず全員を同一に扱い、 同じ機会を与えること ”The Power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Tim Berners-Lee, W3C Director and inventor of the World Wide Web Webの力はユニバーサル性にある。障害の有無に関わらず誰でもアクセスできることがWebの本質である。 Copyright© 2024 dotD All Rights Reserved.

Slide 4

Slide 4 text

視覚:全盲、弱視、色覚障害 利用状況 配慮が必要な「不利な条件」とは?(1/4) ・弱視・ロービジョンの人は、視力が弱い、視野が狭いなどの理由で見えにくく、眼鏡等での矯正にも限界がある ・全盲の人は画面の表示内容を知覚できない ・色覚障害の人は、隣り合う色同士の区切りを見分けることができず、情報の解釈を誤ることがある ・OSやブラウザのズーム機能や拡大鏡などを使って、文字や画面を拡大して利用する ・スクリーンリーダ等の支援技術を使用して、画面の状況や今行える操作、入力した文字を把握する ・マウス操作をやりやすくするため、マウスポインターを拡大する場合がある ・ダークモードや色の反転、カラーフィルターやハイコントラストモードなどによる色変更を行っている Copyright© 2024 dotD All Rights Reserved.

Slide 5

Slide 5 text

配慮が必要な「不利な条件」とは?(2/4) 聴覚:ろう、中途失聴、難聴 ・自動再生の音に気づかない ・動画や音声コンテンンツを利用することが難しい、または利用できない 利用状況 ・文字起こしソフトウェアを使って自力でテキスト化するが、精度が良くない可能性がある Copyright© 2024 dotD All Rights Reserved.

Slide 6

Slide 6 text

配慮が必要な「不利な条件」とは?(3/4) 運動:腕、手、指の喪失や麻痺・衰弱など ・マウスやキーボードを使うことが困難 利用状況 ・特殊なハードウェアやソフトウェアによる支援を利用するが、細かいポインティングが出来ない可能性がある 代替マウス マウススティック カメラ入力(mac) Copyright© 2024 dotD All Rights Reserved.

Slide 7

Slide 7 text

配慮が必要な「不利な条件」とは?(4/4) 認知:認知障害、学習障害、うつ病や統合失調症などの精神疾患 ・同時に記憶できる項目が1~3個に限られる ・見慣れないアイコンやインタフェースを覚えられない ・集中力の維持が難しく、気が散ったり中断が多いと、簡単なタスクでも完了することができない ・複雑で多段階の作業に対して認知的疲労を感じやすい。 利用状況 ・コンテンツを部分的にクリップし保存しておけるツールを使う ・アイコンや画像をテキストに変換して理解する ・テキストを読みやすくするモードを使い、情報を絞って集中できるようにする ・雑音を打ち消す環境音やホワイトノイズを再生して集中できるようにする ・アニメーションや透過表現を止めるオプションを設定する Copyright© 2024 dotD All Rights Reserved.

Slide 8

Slide 8 text

・陽の光が眩しくて画面の色を認識しづらい ・外出先でワイヤレスイヤホンの電池が切れてしまった ・手指の怪我や腱鞘炎でマウスが使いづらい ・マウスまたはキーボードが壊れてしまった ・体調不良や睡眠不足で集中力が続かない ・普段からマウスよりもキーボード操作の方が好き ・スマートフォンの小さい画面で操作していて、物理キーボードより入力に時間がかかる ・旅行先のネットワーク環境が悪く、サイズの大きい画像や動画が見れない 日常生活の中にある「不利な」状況 一時的な「不利な状況」 Copyright© 2024 dotD All Rights Reserved.

Slide 9

Slide 9 text

Webアクセシビリティに対応する理由 すべての人のユーザー体験を改善する アクセシビリティには、「理解しやすい」、「操作しやすい」というの観点も含まれており、 対応することで障害がない状態でのユーザビリティも改善する。 市場を開拓することができる 平成28年の調査で、日本の身体障害者は約429万人、視覚・聴覚・肢体不自由に限っても258万人。 アクセシビリティの向上により、これまで使えなかった人が使えるようになることで、新規市場を開拓できる可能性がある。 権利を守り、法を遵守できる アクセシビリティに対応することで、企業の倫理観を示すことができる。 また、日本を含む世界各国でアクセシビリティに関連する法整備が進んでおり、対応しない場合訴訟リスクにつながる。 Copyright© 2024 dotD All Rights Reserved.

Slide 10

Slide 10 text

障害者差別解消法 障害者差別解消法(2024年4月改正) この法律では、下記の3つのことを求めています。 「不当な差別的取り扱い」 禁止 この法律では、国・都道府県・市 町村などの役所や、会社やお店な どの事業者が、障害のある人に対 して正当な理由なく障害を理由と して差別することを禁止していま す。 例)車椅子の方がレストランへの 入店を拒否される、など。 「合理的配慮の提供」 努力義務→義務 障害のある人から、社会の中にあ るバリアを取り除くために何らか の対応を必要としているとの意思 が伝えられた時に、負担が重すぎ ない範囲で対応すること。 例)車椅子の方が電車に乗車する 際に駅員にスロープを設置して乗 車の手助けをしてもらう 「環境の整備」 努力義務 行政機関や事業者に対して、合理 的配慮を的確に行えるようにする 「環境の整備」を努力義務として 定めています。 例)アクセシビリティを担保した ウェブサイトなどを作成する

Slide 11

Slide 11 text

海外でのWebアクセシビリティを取り巻く状況 アメリカ、カナダ、イギリス、フランス、ドイツ、イタリア、スペイン、オーストラリア、中国、韓国、インドなど※1で、 公的機関だけでなく民間企業に対してもアクセシビリティ基準を満たすことを義務づけており、罰則規定が存在するケースもある アメリカでは、Webアクセシビリティの基準を満たしていないという理由で提起された訴訟件数は、 2015年は57件だったが、2018年には約2,300件、2021年には4000件を超えている。 本社をアメリカ以外に置いている会社が対象になるケースも発生している。 ※1「Web Accessibility Laws & Policies」:https://www.w3.org/WAI/policies/

Slide 12

Slide 12 text

アクセシビリティの基準・ガイドライン

Slide 13

Slide 13 text

WCAG(Web Content Accessibility Guidelines) World Wide Web Consortium(W3C)が策定しているガイドライン。 1999年5月に初版となる「WCAG 1.0」を勧告(現在は廃止)。 現在は2023年5月に勧告された「WCAG 2.2」が最新版となっている。 また、「WCAG 3.0」が策定中となっており、公開中のドラフト版ではWeb XR(拡張現実、仮想現実、複合現実)や 音声入力などの新しいテクノロジーをカバーされている。 アクセシビリティの基準・ガイドライン(1/4)

Slide 14

Slide 14 text

国際規格「ISO/IEC 40500:2012」 国際標準化機構(International Organization for Standardization)は、2012年に「WCAG 2.0」を 国際規格(ISO/IEC 40500:2012)として承認した。 アクセシビリティの基準・ガイドライン(2/4)

Slide 15

Slide 15 text

アクセシビリティの基準・ガイドライン(3/4) 日本工業規格「JIS X 8341-3:2016」 国際規格になっている 「WCAG 2.0」の日本語訳に、日本語特有と思われる事項を追記したもの。 日本の公的機関や一般企業のWebアクセシビリティ方針では、 「JIS X 8341-3:2016のレベルAAに準拠する」のように、目標が定められていることがある。 デジタル庁 ウェブアクセシビリティ https://www.digital.go.jp/accessibility-statement 函館市 ウェブアクセシビリティ方針 https://www.city.hakodate.hokkaido.jp/docs/2017033100056/ KDDIグループウェブアクセシビリティ方針 https://www.kddi.com/co r po r ate/s u stainability/society/accessibility/webaccessibility/

Slide 16

Slide 16 text

アクセシビリティの基準・ガイドライン(4/4) 企業ごとのガイドライン アクセシビリティへの取り組みを進める各社が、WCAGをベースとしつつ、 わかりやすさや読みやすさを改善した独自のガイドラインやチェックリストを公開している。 公表することにより、利用者に安心感を提供することと、開発・運用側に向けて守るべき基準を明確にすることで、 制作品質の向上に繋げている Ameba Accessibility Guidelines https://a11y-guidelines.ameba.design/ SmartHR Design System ウェブアクセシビリティ簡易チェックリスト https://smarthr.design/accessibility/check-list/ freee アクセシビリティ・ガイドライン https://a11y-guidelines.freee.co.jp/index.html

Slide 17

Slide 17 text

WCAGの4つの原則 WCAGは、4つの原則とそれを分解した個別のガイドラインと達成基準、という構成になっている。 知覚可能 情報及びユーザインタフェースコンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない 操作可能 ユーザインタフェースコンポーネント及びナビゲーションは操作可能でなければならない 理解可能 情報及びユーザインタフェースの操作は理解可能でなければならない 堅牢 コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢(robust)でなければならない Copyright© 2024 dotD All Rights Reserved.

Slide 18

Slide 18 text

WCAGの3つの適合レベル WCAGの達成基準には、A / AA / AAA の3つの適合レベルがある。 レベルA 最低レベルであり、この基準を満たすと、ユーザーが支援技術を駆使すればWebサイトにアクセス可能になるレベル。 逆に言うと、この基準を満たしていなければ、人によってはまったくアクセスできない場合がある。 レベルAA 公的機関に求められるレベル。この基準を満たすと、ユーザーはコンテンツの内容の理解や操作にかかる時間が短くなり、 利用を諦めてサービスから離脱する可能性が低減する。 レベルAAA 「A」「AA」をさらに強化する項目。最も高いアクセシビリティを目指したレベルだが、コンテンツや機能によっては 「例外なく達成」することが難しい場合がある。そのため、通常はAAAへの適合を達成目標にはしない。 Copyright© 2024 dotD All Rights Reserved.

Slide 19

Slide 19 text

アクセシビリティの改善のポイント

Slide 20

Slide 20 text

色とコントラスト Copyright© 2024 dotD All Rights Reserved.

Slide 21

Slide 21 text

1.4.1 色の使用 ・色は、情報を伝えたり、行動を示したり、視覚的要素を区別したりする唯一の手段として使ってはならない 色の使用 レベルA ️OK 氏名 メールアドレス ※必須 ※必須 テキストで情報を伝えている 氏名 メールアドレス 青枠内は必須入力です NG 色のみで情報を伝えている Copyright© 2024 dotD All Rights Reserved.

Slide 22

Slide 22 text

網膜細胞の機能によって、色の感じ方には違いがある。 色だけで情報を伝えていると、人によっては、情報を読み取れなかったり、誤解してしまう可能性がある。 色覚特性 C型(一般型): すべての錐体が十分に機能している P型: L錐体(黄緑〜赤)が機能していない、または弱い D型: M錐体(緑〜橙)が機能していない、または弱い T型: S錐体(紫〜青)が機能していない、または弱い A型: 1つの錐体しか機能していない、 または全ての錐体が機能していない Copyright© 2024 dotD All Rights Reserved.

Slide 23

Slide 23 text

1.4.3 コントラスト(最低限) 1.4.11 非テキストのコントラスト 1.4.6 コントラスト(強化) ・大きいサイズ※1のテキストのコントラスト比を3:1以上にする ・それ以外のテキストのコントラスト比を4.5:1以上にする ・ユーザーインタフェースコンポーネント※2やグラフィカルオブジェクト※3のコントラスト比を3:1以上にする ・大きいサイズ※1のテキストのコントラスト比を4.5:1以上にする ・それ以外のテキストのコントラスト比を7:1以上にする コントラスト レベルAA レベルAA レベルAAA ※1大きいサイズのテキスト:18px以上、または14px以上の太字 ※2ユーザーインタフェースコンポーネント:テキストボックスやラジオボタンなど、利用者が単一のコントロールとして近くするもの ※3グラフィカルオブジェクト:コンテンツを理解するために必要な図版など Copyright© 2024 dotD All Rights Reserved.

Slide 24

Slide 24 text

コントラスト比とは、隣り合う色との輝度の差のこと コントラスト比が低すぎると、色の差を感じる力が弱いまたはそのような環境にいる場合に、情報へのアクセスが難しくなる。 コントラスト比 3:1 あのイーハトーヴォのすきとほった風、夏でも底に冷たさをもつ青いそら、うつくしい森で飾られたモーリ オ市、郊外のぎらぎらひかる草の波。 またそのなかでいっしょになったたくさんのひとたち、ファゼーロとロザーロ、羊飼のミーロや、顔の赤い こどもたち、地主のテーモ、山猫博士のボーガント・デストゥパーゴなど、いまこの暗い巨きな石の建物の なかで考えていると、みんなむかし風のなつかしい青い幻燈のように思われます。 4.5:1 あのイーハトーヴォのすきとほった風、夏でも底に冷たさをもつ青いそら、うつくしい森で飾られたモーリ オ市、郊外のぎらぎらひかる草の波。 またそのなかでいっしょになったたくさんのひとたち、ファゼーロとロザーロ、羊飼のミーロや、顔の赤い こどもたち、地主のテーモ、山猫博士のボーガント・デストゥパーゴなど、いまこの暗い巨きな石の建物の なかで考えていると、みんなむかし風のなつかしい青い幻燈のように思われます。 7:1 あのイーハトーヴォのすきとほった風、夏でも底に冷たさをもつ青いそら、うつくしい森で飾られたモーリ オ市、郊外のぎらぎらひかる草の波。 またそのなかでいっしょになったたくさんのひとたち、ファゼーロとロザーロ、羊飼のミーロや、顔の赤い こどもたち、地主のテーモ、山猫博士のボーガント・デストゥパーゴなど、いまこの暗い巨きな石の建物の なかで考えていると、みんなむかし風のなつかしい青い幻燈のように思われます。 Copyright© 2024 dotD All Rights Reserved.

Slide 25

Slide 25 text

StarkのFigmaプラグイン https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-tools Chrome DevToolsでのコントラスト比表示 チェックポイント Starkなど、デザインツールのプラグインを使用して、コントラスト比を自動計算する 同様に、色覚特性ごとの色の見え方を事前にチェックする 実際のページ上で見たければ、ブラウザの開発者ツールでコントラスト比のチェックや、色覚特性のシミュレートが可能 Copyright© 2024 dotD All Rights Reserved.

Slide 26

Slide 26 text

テキストのスタイル Copyright© 2024 dotD All Rights Reserved.

Slide 27

Slide 27 text

テキストの間隔 1.4.12 テキストの間隔 ・行の高さをフォントサイズの1.5倍以上にする ・段落に続く間隔をフォントサイズの2倍以上にする※ ・文字の間隔をフォントサイズの0.12倍以上にする※ レベルAA 行間/文字間が狭く、読みづらい あのイーハトーヴォのすきとほった風、夏でも底に冷たさをもつ青いそら、うつくしい 森で飾られたモーリオ市、郊外のぎらぎらひかる草の波。 またそのなかでいっしょになったたくさんのひとたち、ファゼーロとロザーロ、羊飼の ミーロや、顔の赤いこどもたち、地主のテーモ、山猫博士のボーガント・デストゥパー ゴなど、いまこの暗い巨きな石の建物のなかで考えていると、みんなむかし風のなつか しい青い幻燈のように思われます。 ️ 行間/文字間/段落の間隔が適切に設定され、読みやすい あのイーハトーヴォのすきとほった風、夏でも底に冷たさをもつ青いそら、うつ くしい森で飾られたモーリオ市、郊外のぎらぎらひかる草の波。 またそのなかでいっしょになったたくさんのひとたち、ファゼーロとロザーロ、 羊飼のミーロや、顔の赤いこどもたち、地主のテーモ、山猫博士のボーガント・ デストゥパーゴなど、いまこの暗い巨きな石の建物のなかで考えていると、みん なむかし風のなつかしい青い幻燈のように思われます。 ※あまり間隔を開けすぎるとかえって読みにくくなる可能性がある Copyright© 2024 dotD All Rights Reserved.

Slide 28

Slide 28 text

テキストのスタイル デジタル庁のデザインシステムでは、見出しや本文のレベル別に、 フォントサイズ、行の高さ、文字の間隔が指定されている。 デジタル庁デザインシステム https://www.figma.com/file/OLjjQrB1Hq0JHIWFuzU9kp/Design-System-1.3.2-(Community) Copyright© 2024 dotD All Rights Reserved.

Slide 29

Slide 29 text

テキストのサイズ 1.4.4 テキストのサイズ変更 ・テキストはコンテンツの機能を損なうことなく、最大200%までサイズを変更することができる レベルAA Chromeのフォントサイズおよびズームサイズ変更機能 Copyright© 2024 dotD All Rights Reserved.

Slide 30

Slide 30 text

font-sizeの単位rem 文字の大きさを絶対単位(px, ptなど)で指定すると、ブラウザの文字サイズ変更機能の設定が反映されない。 rem はルートである要素のフォントサイズを基準とする単位。デフォルトでは 1rem = 16px となる。 Chrome の場合、フォントサイズを極大にすると、1rem = 24pxとなる。 フォントサイズだけでなく、フォントサイズに応じて大きさを変えたい箇所(例えばボタンの幅や高さ)も相対単位を使用する。 ブラウザのフォントサイズが反映されないボタン 保存 .save-button { font-size: 16px; min-width: 80px; height: 32px; } ️ブラウザのフォントサイズによって大きさが変わるボタン 保存 .save-button { font-size: ; min-width: ; height: ; } 1rem 5rem 2rem Copyright© 2024 dotD All Rights Reserved.

Slide 31

Slide 31 text

チェックポイント 行の高さ(line-height)をフォントサイズの1.5倍以上にする 文字の間隔(letter-spacing)を適切に指定する フォントサイズやフォントサイズに応じて変化するサイズには相対単位を指定する 実際のサイト上で、拡大表示した時に文字が見切れたり重なったりしないか確認する Copyright© 2024 dotD All Rights Reserved.

Slide 32

Slide 32 text

フォーム入力 Copyright© 2024 dotD All Rights Reserved.

Slide 33

Slide 33 text

3.3.2 ラベルまたは説明 適切なラベルと説明 レベルA ・コンテンツにユーザー入力が必要な場合、ラベルや指示が提供される。 ️OK 半角英数字で入力 氏名 メールアドレス ※必須 枠外にラベルと説明がある placeholderで説明している NG 氏名 メールアドレス 半角英数字で入力 国語 数学 理科 社会 英語 横並びでかつ接近している NG 国語 数学 理科 社会 英語 縦にならべてラベルを整列させる ️OK Copyright© 2024 dotD All Rights Reserved.

Slide 34

Slide 34 text

チェックポイント ラベルはフォームコントロールの外に配置する 長い説明や重要な説明はフォームコントロールの外に配置する ラベルと説明がどのフォームコントロールに関係しているかわかりやすく配置する labelタグでフォームコントロールとラベルと説明を関連付ける 静的解析ツールでラベルがないフォームコントロールを検出する Copyright© 2024 dotD All Rights Reserved.

Slide 35

Slide 35 text

3.3.1 エラーの特定 エラーの特定 レベルA ・入力エラーが自動的に検出される場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される Copyright© 2024 dotD All Rights Reserved.

Slide 36

Slide 36 text

エラー表示のアンチパターン モーダルでエラーを表示すると、モーダルを閉じた時にどこを修正すれば良いかが確認できなくなってしまう。 エラー箇所のすぐ近くに表示し、どう対応すれば良いかを具体的に指示するのが望ましい。 ️OK 氏名 メールアドレス 氏名 メールアドレス / NG ・氏名 ・メールアドレス 入力内容に誤りがあります 閉じる 1文字以上入力してください emailアドレスの形式で入力してください Copyright© 2024 dotD All Rights Reserved.

Slide 37

Slide 37 text

チェックポイント エラーメッセージはエラー発生箇所の近くに配置する エラーを視認しているユーザーとスクリーンリーダーを利用しているユーザー双方に、エラーの発生を知らせる エラーの修正方法が理解しやすいエラーメッセージにする 入力の制約を必要最小限にする Copyright© 2024 dotD All Rights Reserved.

Slide 38

Slide 38 text

キーボード操作 Copyright© 2024 dotD All Rights Reserved.

Slide 39

Slide 39 text

2.1.1 キーボード キーボード操作 レベルA ・コンテンツのすべての機能は、キーボードを通じて操作可能でなければならない 2.4.7 フォーカスの可視化 ・キーボード操作可能なユーザーインタフェースには、フォーカスインジケーターを表示できる レベルAA 2.4.3 フォーカスの順番 レベルA ・フォーカス可能なコンポーネントは、意味や操作性を保持する順序でフォーカスを受ける Copyright© 2024 dotD All Rights Reserved.

Slide 40

Slide 40 text

フォーカスの可視化 Chrome Safari Firefox フォーカスインジケーターとは、操作可能なインタフェースにフォーカスが当たった時に表示される枠線 フォーカスが表示されないと、キーボード操作をしている人にとっては、マウスカーソルが消えたのと同じような状態になる。 デフォルトのフォーカスインジケーターのスタイルは、OSやブラウザによって異なる。 独自に実装することもできるので、背景に対して十分なコントラスト比が保てるようにデザインすることが望ましい。 各ブラウザのデフォルトフォーカスインジケーター(mac) Copyright© 2024 dotD All Rights Reserved.

Slide 41

Slide 41 text

キーボード操作できないボタン キーボード操作できないボタン
ボタン
️キーボード操作できるボタン < onClick=”...”>ボタン< > button /button tabindex属性や、onKeydownイベントを駆使すればキーボード操作できるようにするこ とも出来るが、コード量は増える。 タグを使えば、これ以上何も書かなくても、キーボードフォーカスされ、Enter キーでclickイベントを発火させることができる。 divタグはonClickイベントを付与しても、キーボードフォーカスできず、操作できない。 操作可能なインタフェースは、buttonやinput、aタグなどのインタラクティブ要素を使用すること。 Copyright© 2024 dotD All Rights Reserved.

Slide 42

Slide 42 text

フォーカスが表示されない(outline非表示) フォーカスできないボタン
ボタン
button { outline: none; } ️ フォーカスできるボタン ボタン button: focus { } outline: #000082; ブラウザデフォルトのフォーカスはCSSのoutline属性で表現されている。 outline:none; などで非表示にしていると、フォーカス表示ができなくなってしまう。 Copyright© 2024 dotD All Rights Reserved.

Slide 43

Slide 43 text

フォーカスが表示されない(インタラクティブ要素が非表示) ️フォーカスできないチェックボックス 同意する .checkbox { display: none; } ️フォーカスできるチェックボックス 同意する .checkbox { } appearance: none; opacity: 0; // または チェックボックスやラジオボタンの見た目をカスタムするために、input要素を非表示にすることがあるが、 その際に、HTMLのhidden属性や、CSSのdisplay: none; を使うと、フォーカスされなくなってしまう。 Copyright© 2024 dotD All Rights Reserved.

Slide 44

Slide 44 text

チェックポイント ボタンやフォーム要素、リンクについて、フォーカスインジケータのデザインを作成する 実際のページ上で、tabキーでフォーカスインジケータが表示されるか確認する EnterキーやSpaceキーでキーボード操作できるか確認する 静的解析ツールで非インタラクティブ要素にクリックイベントやマウスイベントが付与されていないことを確認する Copyright© 2024 dotD All Rights Reserved.

Slide 45

Slide 45 text

スクリーンリーダーへの対応 Copyright© 2024 dotD All Rights Reserved.

Slide 46

Slide 46 text

スクリーンリーダーを使用すると、Webサイトのコンテンツを音声で読み上げることができる。 以下の2つは文字情報だけでなく、操作も読み上げる NVDA Windows用のフリーウェア https://www.nvda.jp/ VoiceOver macOSに標準搭載されているスクリーンリーダー システム設定 > アクセシビリティ > VoiceOver スクリーンリーダー Copyright© 2024 dotD All Rights Reserved.

Slide 47

Slide 47 text

HTMLのタグは、h1〜6は見出し、pは段落、ulはリスト、tableは表といった意味を持っている。 スクリーンリーダーはただテキストを読み上げるだけでなく、意味に合わせて読み方を変える。 HTMLのセマンティクス 意味論が実装されていないHTML
銀河鉄道の夜 『銀河鉄道の夜』(銀河鐵道の夜、ぎんがてつどうのよる)は、宮沢賢治の童話作 品。
孤独な少年ジョバンニが、友人カムパネルラと銀河鉄道の旅をする物語
あらすじ 一、午后の授業 銀河系の構造についての授業。天の川について先生に質問されたジョバンニは、答え を知りつつ気もそぞろに答えることができない。次に指されたカムパネルラも、答えな い。 意味論が実装されているHTML < > < >銀河鉄道の夜< > < >『銀河鉄道の夜』(銀河鐵道の夜、ぎんがてつどうのよる)は、宮沢賢治の童話 作品。< > < >孤独な少年ジョバンニが、友人カムパネルラと銀河鉄道の旅をする物語< > < > < >あらすじ< > < > < >一、午后の授業< > < > 銀河系の構造についての授業。天の川について先生に質問されたジョバンニは、 答えを知りつつ気もそぞろに答えることができない。次に指されたカムパネルラも、答 えない。 < > < > < > < > section h1 /h1 p /p p /p section h2 /h2 dl dt /dt dd /dd /dl /section /section Copyright© 2024 dotD All Rights Reserved.

Slide 48

Slide 48 text

WAI-ARIAは、HTMLのセマンティクスを補完するために、W3Cが発行している仕様。 「メニューバー」「タブ」「ツールチップ」「ツールバー」などはそれを表現するタグが現状のHTMLにはないので、 視覚的にこれらのウィジェットを作ってもスクリーンリーダーには情報を伝えることができない。 WAI-ARIAが定める属性をHTMLタグに付与することで、前述のウィジェットの役割や状態を、スクリーンリーダーをはじめとす る支援技術に通知することができる。 WAI-ARIA Copyright© 2024 dotD All Rights Reserved.

Slide 49

Slide 49 text

WAI-ARIAを用いて実装されたタブUI WAI-ARIAを用いて実装されたタブUIの実装例
ソフトウェア基本情報 ライセンス情報
...(ソフトウェア基本情報のコンテンツ)
...(ライセンス情報のコンテンツ)
role=”tablist” role=”tab” aria-selected=”true” role=”tab” aria-selected=”false” role=”tabpanel” aria-labelledby=”software-tab” aria-hidden=”false” role=”tabpanel” aria-labelledby=”license-tab” aria-hidden=”true” ・タブUIを構成するパーツに で役割(tablist, tab, tabpanel)を設定する ・タブの選択状態を として設定する ・タブパネルの表示状態を として設定する ・タブとタブパネルの関連性を で指定する role属性 aria-selected属性 aria-hidden属性 aria-labelledby属性 Copyright© 2024 dotD All Rights Reserved.

Slide 50

Slide 50 text

非テキストコンテンツ 1.1.1 非テキストコンテンツ ・利用者に提示される全ての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。 ・非テキストコンテンツが、純粋な装飾である、見た目の整形のためだけに用いられている、  又は利用者に提供されるものではない時、支援技術が無視できるように実装されている。 レベルA Copyright© 2024 dotD All Rights Reserved.

Slide 51

Slide 51 text

imgタグに対しては、alt属性で代替テキストを設定する。 画像の代替テキスト(1/2) ”株式会社dotD” ”図の中心に人に優しいデジタル化と書かれていて、 例1)画像化したテキスト 画像内の文字と同等の内容を設定する。 会社のロゴであれば、会社名を設定する。 例2)コンテンツの理解に欠かせない図表など 図表を要約した内容を設定する。ただし本文中で同様の内 容が説明されている場合は省略可能。 文字数に制限は無いが、可読性を考慮すると80文字が目 安。それ以上になる場合は、本文に書き起こすことを検討 する。 C opy right© 2024 dotD A ll R ights Re se rve d.

Slide 52

Slide 52 text

imgタグに対しては、alt属性で代替テキストを設定する。 画像の代替テキスト(2/2) ”” いいね 例4)装飾やテキストつきの画像 テキストつきの場合、altを設定すると同じ内容が2回読み 上げられてしまうので、altを空にする。 alt属性自体を省略すると、ファイル名やパスが読み上げ られてしまうので、省略ではなく、必ず空にする。 いいね ”メンバーを追加する” 例3)アイコンのみのボタン ボタンの機能を記述する。 Copyright© 2024 dotD All Rights Reserved.

Slide 53

Slide 53 text

チェックポイント 意味的に正しいHTMLを書く(見出しはh1~6タグ、リストはul、ol、dlのいずれか、表はtableタグなど) 実際のページをスクリーンリーダーにかけて、正しく読み上げられるかチェックする 画像やアイコンに対して適切な代替テキストを設定する 静的解析ツールで、HTMLの構造や代替テキストの有無を自動チェックする Copyright© 2024 dotD All Rights Reserved.

Slide 54

Slide 54 text

アクセシビリティの検証 Copyright© 2024 dotD All Rights Reserved.

Slide 55

Slide 55 text

アクセシビリティの自動評価ツール Lighthouse Chromeのデベロッパーツールに含まれるツール 「Performance」「Accessibility」「SEO」などの観点で100点満点で評価し、具体的な問題点を指摘してくれる Copyright© 2024 dotD All Rights Reserved.

Slide 56

Slide 56 text

アクセシビリティの自動評価ツール 静的解析ツール html/css のバリデーターや静的解析ツールを使って、ソースコードを解析してエラーや警告を表示することができる。 storybook-addon-a11yでは、storybookで作ったコンポーネントカタログに対して、 コントラスト比などデザイン的な指摘される。 ・markuplint ・stylelint ・eslint-plugin-jsx-a11y ・storybook-addon-a11y Copyright© 2024 dotD All Rights Reserved.

Slide 57

Slide 57 text

デザインシステムとアクセシビリティ Copyright© 2024 dotD All Rights Reserved.

Slide 58

Slide 58 text

組織の中で一貫性のあるデザインを実現するために、どのようなルールに基づいて作られるべきかを体系的に整備した ドキュメントや部品、ガイドライン、制作プロセスなどの総称のこと。 多くの場合、以下のものが含まれる。 デザインシステムとは? デザイン原則 製品やそれを作る組織が重視する価値観、判断基準を定義する。 組織によってはブランドとして表現したいこと(ブランドアイデンティティ)なども含む。 スタイルガイド 製品が使用するアイコンやタイポグラフィ、カラーパレットなどが定義される。 パターンライブラリ 製品が使用するUIコンポーネントや製品が提供する機能、ユーザーへの見せ方などを、ライブラリとして再利用可能にしたもの storybookなどのツールを使って、ソースコードも含めて公開しているケースもある。 Copyright© 2024 dotD All Rights Reserved.

Slide 59

Slide 59 text

デザインシステムとアクセシビリティの関係性 デザインシステムにアクセシビリティが取り込まれていると、 そのデザインシステムに含まれるスタイルガイドやパターンライブラリを使ってデザインや実装を行う際に、 担当者が都度細かい対応内容を調べたり考える必要がなくなる。 Copyright© 2024 dotD All Rights Reserved.

Slide 60

Slide 60 text

デザインシステムにアクセシビリティを織り込む デザイン原則に織り込む 例えば「WCAGのレベルAAを満たす」など、具体的な目標を掲げておく。 アクセシビリティに関する知識がなく、目標達成の難易度を評価することも難しい場合は、アクセシビリティに取り組む意思を 明確にする。 スタイルガイドに織り込む カラーパレットを定義して製品内で利用する色に一貫性を持たせつつ、それらをどう組み合わせればコントラスト比を満たせる のかを示す。 適切な見出しをつけたり、画像に代替テキストを付けることもスタイルガイドに盛り込んでおく。 用語集やエラーメッセージの表示方法など、文章表現の一貫性を保つために、細かい方針を決めておく。 パターンライブラリに織り込む UIコンポーネント実装のライブラリを作るのであれば、linterを導入して問題を機械的にチェックする。 さらにCIに組み込んで自動化することで、同じ問題を繰り返さないようにする。 Copyright© 2024 dotD All Rights Reserved.

Slide 61

Slide 61 text

アクセシビリティに配慮したデザインシステムの事例 IBM Carbon Design System - https://carbondesignsystem.com/ 序文で、障害に対してデザイナーがどう対処すべきか、そしてそれが障害のないユーザーにとってどんなメリットになるのかを紹 介している。 コンポーネントやパターンごとにも、どのようにアクセシビリティ面の問題を解消しているのかを解説されている。 Adobe Spectrum Design System - https://spectrum.adobe.com/ コンポーネントがReact SpectrumというReactによる実装が用意されている。さらに各コンポーネントの振る舞いは、React AreaやReact Statelyというパッケージに抽象化して実装されている。 SmartHR Design System - https://smarthr.design/ SmartHRのブランドガイドラインも内包したデザインシステムであり、内部にプロダクトのUI向けコンポーネントライブラリで あるSmartHR UIがある。 Cyber Agent Ameba Spindle - https://spindle.ameba.design/ Amebaのブランドガイドラインも内包したデザインシステムで、Storybookでコンポーネントカタログを公開している。 Copyright© 2024 dotD All Rights Reserved.

Slide 62

Slide 62 text

参考文献

Slide 63

Slide 63 text

参考文献 Webアプリケーションアクセシビリティ ──今日から始める現場からの改善 (WEB+DB PRESS plus) https://amzn.asia/d/1gwdThX Copyright© 2024 dotD All Rights Reserved.

Slide 64

Slide 64 text

こちらもお読みください 障害者差別解消法の改正:ビジネスに新たな機会をもたらすウェブアクセシビリティ https://note.com/daisuk_dax/n/n608223236ffd デザインから考えるウェブアクセシビリティ https://note.com/masato_gucci/n/nefe40908203e Copyright© 2024 dotD All Rights Reserved.

Slide 65

Slide 65 text

ご清聴ありがとうございました Copyright© 2024 dotD All Rights Reserved.