WordPress アクセシビリティ

WordPress3.8になり、公式テーマディレクトリにも、accessibility_ready タグが追加されました。

WordPress3.8に付属するデフォルトテーマTwentyfourteenは、accessibility_readyタグを使った最初のテーマです。

wordpress.orgにホストされるいわゆる公式テーマは、アクセシビリティ　ガイドラインに、準拠していないと、このタグを利用できないことになっています。

アクセシビリティに関する情報は、アクセシビリティBlogなどで見つけることができますが、WEB標準やアクセシビリティという言葉自体、最近　あまり言及されないように私は思っていましたが

Twentyfourteenでは、キーボードアクセスを可能にする取り組みなどがひっそりと行われています。

日本語でのTwentyfourteenのレビューなどでは、まだまだ紹介されることがほとんどないわけですが、ChromeやFirefoxブラウザであれば、tab移動で、キーボードからのアクセスが可能なので、試してみてください。

私が作っている Raindropsというテーマでも、ちゃっかりとaccessibility_readyタグをつけて、「一般テーマでは、世界初 accessibility_ready テーマ」なんて思っていたら、サポートフォーラムに、accessibility_ready tagというスレッドが立ち、英語がわからない私にも、「アクセシビリティレビューしてなかったので云々」ということで、先日アップロードしなおす事になった。

「きゃー」みたいな、

そんなこんなで、キーボードアクセスができていないとか、WAI-AREAの対応しろとか、ご指導を頂き、Raindrops1.162がライブになりました。

何度となく、Functional Accessibility Evaluator 2.0や　FirefoxのAccessibility Evaluation Toolbarなどで、コードの改修をしながら、脳裏をよぎっていったものを、メモに残しておきたいと思います。

アクセシビリティのチェックツールが頼りの、コードの最適化。

何がどうあるべきかという事を示してくれるAPIやツールがないと、コードの改修も立ち行かない。

しかし、チェックツールがちょっと古かったりする。

例えば、tableにはsummary属性が必要だとか、「おい、html5ぞ!」と叫んでも、APIには届かない。

「h1何回も使うんじゃないぞ」といわれても、「おい、html5ぞ!」とつぶやく他ない。

準拠してユーザーが、「チェックツールでチェックしたら、100点じゃないやん」と指摘されても、

「チェックツールが間違っている」といったところで、冷笑されるだけだろう。

W3Cのhtmlvalidateなどでも、常に最新ではない。

ツールを使うことで、たいていよい方向に向かうことになるのだけれど、完全なものにはならない。