「A11yc APIのエンドポイント作成について」あらため「実装チェックリストとの出会い直し」（Web Accessibility Advent Calendar 2018）

2018年12月24日 更新 | タグ: アクセシビリティ

この記事はWeb Accessibility Advent Calendar 2018の12月22日にアップされるはずだった記事です。せっかく順調に続いていたのに、やらかしてしまった時代工房の柴田です。

本当は、小長井くん（@hajimekonagai）と、「同日に記事公開しようね」なんて言ってたのですが、ずっと仕事してて、気がついたら日付が過ぎちゃっていました（小長井くんは、きちんと更新していました。「VRで視覚障害者体験 BlindStation開発記 - Qiita」）。

A11ycのエンドポイントの話は？

しかもテーマ予定だった「A11yc APIのエンドポイント」は、エンドポイントそのものが未完成……。A11ycは、PHPで書かれていて、PHPのCMSなんかとは相性が良く、もともとWordPressと連携するようには作っていましたし、BaserCMSは、ベースがCakePHPでわかりやすかったこともあるのですが、さくっとプラグイン化できました。

でも、できれば、Ruby on RailsやMovable Typeとの連携なんかも視野に入れていきたいとなると、POSTを受け取って、JSONを返す仕組みは是非とも欲しい……ということで、開発に取り掛かり、このアドベントカレンダーを投稿する頃にはAPI仕様を公開する……と考えていたのですが、意外に仕事に時間を取られたのと、楽しい再発見にかまけて、全然開発できなかったわけです。

実装チェックリストとの出会い直し

で、その「楽しい再発見」とはなにかというと、WAICの「これから取り組むWebアクセシビリティ 2018 夏」の太田さんの「こうすればできる！ウェブアクセシビリティ実装のポイントと実装チェックリストの作り方」のスライド（PDF, 8.6MB）です。

ぼく、このスライドを見るまで、かなり実装チェックリストを軽視していました。

• そもそもJISが求める必須要件でなく、JISの試験のハードルをより高くしている。言い換えると、JISの試験を複雑にしていることで、あたらしく参入しづらくしている。
• 構築の現場では、障害者のウェブ利用の現状を想像しながら作れば、おのずとアクセシブルな実装になる。こまったら達成方法集を見れば良くて、わざわざ案件ごとに実装チェックリストを作っていたら、工数が無駄に増える。

というように思い込んでいたためです。

でも、太田さんのスライドを見て──というか、会社の仲間に読み解いてもらって、考えが変わってきました。太田さんのスライドでいうと、「早めに作る」と「みんなで作る」を読むことで、認識が変わってきました。

早めに作る

そもそもの柴田の誤解は、実装チェックリストはJIS試験で使うものなので、試験の際、「このあたりの実装を、今回の試験では確認事項にします」という宣言だと思い込んでいたことです。

試験の直前にわざわざこんなものを用意しなくても、サイトの試験はできるし、合否の根拠は、達成方法集とコメントで十分説明できる──ならば、要らん手間だと思っていました。

でも、「早めに作る」は、そういうことを言っていないのです。時代工房は小さい会社なので、サイトを作るときフロントの担当者は1名であることが多いのですが、場合によると2〜3名になることがありますし、さらに社外の人と組むこともなくはありません。そういったとき、実装チェックリストが共有されていれば、たしかに品質を担保できます。

これも会社の仲間に教えてもらった、FRESH LIVE Accessibility Guidelines なんかは良い例ですが、「構築していく上で、どのように実装していくか、仲間と共有する」という意図が明確に伝わってきます。

また「仲間で共有するものを作る」ということは、「深い理解や専門的な知識がなくても、実装できる」つまり、「試験ができる人を増やせる」ということにもつながり、裾野を広げる効果があります。

換言すると、ずっと作ってきた、早見表や要約集は、簡易な実装チェックリストを目指していたのかもしれません。

みんなで作る

ぼくは自分がたまたま長く勉強してきて、かつ会社の仲間もぼくほどドップリじゃないけど、アクセシビリティや障害者と情報技術に近い環境に居続けているため、（語弊があるかもしれませんが）「詳しくない人（ほとんどの場合クライアント）は、うちの任せておけば悪いようにしない」という態度で仕事をこなしてきました。

もちろん説明を求められたら喜んで解説をしていたのですが、あらかじめ多様な障害や高齢者の利用について、あまり踏み込んだ説明をすることはありませんでした。

あらかじめあまり詳しい説明をすると、「大切だってのはわかったけど、うちのサービスは、障害者・高齢者向けじゃないから、その『アクセシビリティ対応』は要らないわ（≒値引きしてよ？）」みたいなことがなかったわけでもありませんでした。

でも、時代はいつの間に進んでいました。今は、そんなことを言われることもなく、行政以外でも試験の依頼があるようにさえなってきました。クライアントを含めて、アクセシビリティに配慮した実装の意味を理解してもらえる段階が来たのかな、と太田さんのスライドから感じ取りました。

まとめ

「実装チェックリストは試験のため」という理解はやや短絡的で、

• 試験時でなく、実装より早めに作って、チームで品質を担保するのに役立つ
• クライアントに実装の必然性を理解してもらうのに役立つ

というなかなか良いものだったということかと思います。また、「試験のため」と思い込んでいたために、「前の試験の結果を、今後の実装に活かす」というPDCAの意味も再確認できました。

意義は再発見できたので、今後はいかに楽をして、良い実装チェックリストを作るかを考えていきたいと思っています。

というわけで、遅れてしまいましたが、2018年のアドベントカレンダーの記事としては以上です。本日の本当の担当は、きちんと間に合っているo_tiさん「アクセシビリティはあなたビリティ - dskd」。本当はぼくがバトンを渡すはずだったのは、SAWADA STANDARD DESIGNさんの「リーダブルな夜のテーマ - (Theme from) The Readable Night -」。でもって、明日は、Kazuhito Kidachiさんの「宇宙開発とWebアクセシビリティ」ですね。

みなさま、良いお年をお迎えください。

ツイートする