37 lines
5.5 KiB
Markdown
37 lines
5.5 KiB
Markdown
---
|
|
title: Inclusive Design
|
|
created: 2026-06-28
|
|
updated: 2026-07-02
|
|
type: concept
|
|
tags: [accessibility, inclusive-design, public-interest, design]
|
|
sources: [raw/articles/arun-japan-symbols-2026.md, raw/articles/aist-avatar-standardization-committee-2026.md, raw/articles/accessibility-conference-chiba-2026.md, raw/articles/smashing-accessibility-operational-capability-2026.md, raw/articles/w3c-accessible-names-descriptions-2026.md]
|
|
confidence: medium
|
|
---
|
|
|
|
# Inclusive Design
|
|
|
|
包摂的な設計は、身体や状況の違いを「本人が毎回説明する負担」にせず、周囲の人や仕組みが自然に配慮できる入口を作る考え方。Arun Venkatesan の日本の記号についての記事は、車の初心運転者標識、高齢運転者標識、聴覚障害者標識、身体障害者標識、電車やバスで使われるヘルプマーク、マタニティマークを、言葉なしで追加の配慮を促す記号として見ている。
|
|
|
|
特にヘルプマークは、外からは見えにくい障害、内部疾患、感覚の違い、精神疾患、妊娠初期などを、細かな診断名に閉じず「助けや配慮が必要かもしれない」という共有情報に変える。これは本人の事情をすべて公開させるものではなく、必要最小限の合図だけを出す設計である。
|
|
|
|
この資料で面白いのは、包摂性を個別の支援制度だけでなく、公共空間の情報設計として扱っている点。標識や札は、読める人だけに向けた文章ではなく、瞬時に見分けられる形と色で、周囲の行動を少し変える。公共の場で「何をすればよいか」を伝えるという意味では [[meaning-making-marks]] と重なり、社会的な判断材料を壊さず整えるという意味では [[information-integrity]] とも遠くつながる。
|
|
|
|
[[avatar-standardization]] は、包摂的な設計を XR/メタバース上の仮想身体にも広げる論点。アバターは外見、本人性、相互行為、文化表現を同時に担うため、ユーザ側と開発側の双方に意味のある規格を作る必要がある。
|
|
|
|
アクセシビリティカンファレンスCHIBA 2026 の案内は、包摂性を「講演で語るテーマ」だけでなく、会場設計と体験ブースに落とし込んでいる例として使える。通常版と情報保障版の YouTube 配信、手話通訳と UD トーク、バリアフリートイレやオストメイト設備の明記、平坦な導線・混雑・照明条件の説明は、参加前に必要な情報へ到達できること自体をアクセシビリティとして扱っている。^[raw/articles/accessibility-conference-chiba-2026.md]
|
|
|
|
Smashing Magazine の「Accessibility Is An Operational Capability」は、AI が UI を高速生成する時代のアクセシビリティを、事後監査や法務チェックではなく運用能力として扱う。問題は「画面上は動くが、意味のある HTML、キーボード操作、focus 管理、状態の露出が欠ける」コードが大量に増えることにあり、品質保証や [[ai-agent-command-safety]] と同じく、生成前の制約と生成後の検証を開発 loop に組み込む必要がある。^[raw/articles/smashing-accessibility-operational-capability-2026.md]
|
|
|
|
実装パターンとしては、design system の accessible component を再利用し、Definition of Done と PR review にアクセシビリティ確認を入れ、eslint-plugin-jsx-a11y、Pa11y、Storybook addon などを CI や component 開発に置く。これは [[e2e-coverage-metrics]] のような実行証跡を使う品質保証とも近く、アクセシビリティを「覚えていた人が頑張る」ものから、platform が継続的に維持する性質へ変える。^[raw/articles/smashing-accessibility-operational-capability-2026.md]
|
|
|
|
W3C APG の accessible name / description guidance は、その運用能力を component レベルに落とす具体的な基礎資料である。焦点可能・操作可能な要素には短く区別できる accessible name が必要で、見えるラベルを優先し、HTML の `label` や `caption` のような native technique を使い、`aria-label` / `aria-labelledby` が子要素の内容を隠す場面を理解して testing する必要がある。AI が UI を生成する場合も、見た目のボタンではなく assistive technology が読む名前・役割・状態まで検証しないと、[[agent-harness-engineering]] や [[e2e-coverage-metrics]] の browser harness は本当に使える UI を保証できない。^[raw/articles/w3c-accessible-names-descriptions-2026.md]
|
|
|
|
同イベントの体験ブースでは、Ontenna が音の特徴を振動と光に変え、エキマトペが駅の音を AI で識別して文字・手話・オノマトペで可視化する。これは [[meaning-making-marks]] のような公共空間の記号設計を、聴覚・身体感覚・文字情報へまたがる multi-modal interface に広げる実装例として読める。^[raw/articles/accessibility-conference-chiba-2026.md]
|
|
|
|
## 見るべき問い
|
|
|
|
- 本人が詳細を説明しなくても、必要な配慮だけが伝わる合図をどう作るか。
|
|
- 記号を知っている人と知らない人の差を、教育や普及でどう埋めるか。
|
|
- 見えにくい困難を可視化するとき、プライバシーと安全をどう両立するか。
|
|
- 標識、札、色、形、配置を、文章より先に読まれる公共の道具としてどう設計するか。
|