より多くの人に届けるために明日からできる
自作テーマ・受託プロジェクトの
アクセシビリティ入門2018

1. WordPressのアクセシビリティ対応
2. コーディングのアクセシビリティ対応
3. プロジェクトのアクセシビリティ対応

アクセシビリティは『品質』です。

皆さんのお手元にあって、もっとも手軽に
アクセシビリティを『意識』できるツールは
なんでしょうか？

スマホ

（Voice Over、Talkback）

特別なことはしていないけど、
ちゃんと読み上げられてるよ？

もちろん、「音声ブラウザに対応することが
アクセシビリティ対応できたこと」という
ことではないけれど

セマンティックにコーディングしていれば、
アクセシビリティ対策は難しくありません！！

• Web Developer
• Accessibility Developer Tools
• Alix for Chrome

• 各種チェックツール｜ツール｜エー イレブン ワイ［WebA11y.jp］

WordPressはコア自体から
アクセシビリティに対応しています。

• Codex 日本語版「アクセシビリティ」
• Slackチャンネル #accessibility

デフォルトテーマはWCAG 2.0に準拠しています。

• Web Content Accessibility Guidelines 2.1
• 「アクセシビリティ」対応テーマ
• 「アクセシビリティ対応」タグのあるテーマは
  アクセシビリティチームがチェックしています

アクセシビリティ対応を補助してくれる
プラグインもたくさんあります。

• jwp-a11y
• WP Accessibility

など

それならば、自作テーマをアクセシビリティ対応
させたいときに必要なのは？

1. セマンティックにコーディングする
2. JIS X 8341-3:2016への準拠
3. role属性、aria属性の活用
4. アクセシビリティ対応しているプラグインの活用

「マシンリーダブル」であること

• タイトルタグを正しく使う
• 文書構造を正しくマークアップ
• キーボードフォーカスを消さない
• 装飾画像の扱い

など

	
	
		
		検索
	
	

飾りのアイコンには「aria-hidden="true"」を！

	
	
		
			
		
		検索
	
	

こういう組み方でもOK。『alt=""』は必要！

アイコンの表示に擬似要素（::before、::after）の利用はおすすめしません！

【その理由】

• CSSが効かない状況ではコンテンツが無いものになってしまう
• 疑似要素は音声ブラウザで読み上げられてしまう
• プロパティ「speak」の実装が進んでいない

もしCSSで表示するなら「background-image」で！

  
	必須
  

CSSが読み込めないことも起こりえます。
意味のあるアイコンは「HTMLで正しくコーディング」を！
CSSに頼らず、HTMLだけで意味を伝えられるように

『高齢者・障害者等配慮設計指針 － 情報通信における機器、
ソフトウェア及びサービス － 第3部：ウェブコンテンツ』

• 対応国際規格『ISO/IEC 40500:2012』（W3C勧告『WCAG 2.0』）と一致した内容
• 総務省ウェブアクセシビリティ方針
• JIS X 8341-3:2016 試験実施ガイドライン（達成基準チェックリストの例）
  • ウェブアクセシビリティ基盤委員会

role属性

要素に役割を付与するもの

• ロールモデル
• ロールの分類

aria属性

様々なWebコンテンツをよりアクセシブルに『拡張』するもの

• WAI-ARIA

など

アクセシビリティ対応している
プラグインを使ってラクをしましょう。

• Contact Form 7

など

WordPressにはアクセシビリティ
コーディングスタンダードがあります。

• Accessibility Coding Standards
• Quick start guide

など

1. アクセシビリティは後回し？
2. アクセシビリティは儲からない？
3. どこまでを求めるのか

• コストがかかるから？
• 難しそうだから？
• わからないから？
• 必要ないから？

• 誰でもその立場になり得る
• コスト？それとも投資？
• ユーザー層を見誤っていないか？
• 売り上げを逃しているのでは？

• 最初に方針を定めましょう
• 「基準を知る」
• 公式ディレクトリ掲載テーマを使うという選択肢
• まずは必要最低限から

• 必ずプロジェクト全体で方針を決めること
• デザイン「だけ」ではアクセシビリティ対応はできない
• プログラミング「だけ」でもアクセシビリティ対応はできない
• クライアントも含めた方針の決定が先決

• ウェブアクセシビリティ方針策定ガイドライン
• まず理解を深める
• 三つの適合レベル（レベルA、レベルAA、
  レベルAAA）
• （可能なら）方針策定・達成期限を設ける

• 「アクセシビリティ」対応テーマを利用する
• 現時点のテーマディレクトリの「アクセシビリティ」タグ登録数は123件（デフォルトテーマ含む・2018年7月14日現在）
• 本当にサイトの訪問者が必要な情報はなにか？

なにより継続できることが大事

インターネットがアクセシブルだからこそ
この島にこんなにたくさんの人達が集まれたわけで、
その世界の30%以上を支えるWordPressで
いまアクセシビリティ対応を進めていくのは
意義のあることなんじゃない？