納品物を標準でアクセシブルにするために

すでに、 アクセシビリティ対応強化のお知らせ でも触れています通り、ミツエーリンクスでは2011年4月より当社で新規構築を行なうWebサイトに対して、クライアントから特別なご要望や費用をいただかずとも、WCAG 2.0 レベルA相当のアクセシブルなコンテンツとなるように設計・実装する取り組みを行なっています。

具体的には、対象となる新規構築案件ではWebサイトの規模を問わず、全てのページに対してアクセシビリティの専任スタッフによる検証が実施されます。望ましくない設計・実装が行なわれている箇所については制作担当者へフィードバックされ、差し戻された問題点は、可能な限りページをアクセシブルに修正した上でクライアントの元へ納品するフローを取っています。この取り組みを社内では「アクセシビリティ標準対応」と呼んでいます。

それまで、当社で制作するページのアクセシビリティの検証を行なうのは、特にご要望をいただいた案件に限られておりましたので、基本的にはアクセシビリティの重要性に理解のあるクライアントのWebサイトが中心でした。しかし、新規構築されるWebサイトをアクセシビリティ案件としたことで、クライアントも制作担当者もアクセシビリティをあまり意識していないサイトを検証する機会が増えてきました。それにともない、細かな部分のアクセシビリティはおざなりにされていることがまだまだ多いということに気づかされることとなりました。

例えば、短納期のランディングページや現行サイトの内容をそのまま移行するリニューアル案件に多いのが、箇条書きのビュレットをテキストの「・」（なかぐろ）を文頭に置くことで代用していたり、見出しに見出し要素を使わずに【】で囲うことで表現していたりするケースです。社内のスタッフは箇条書きにはul要素を用いることも、見出しはh要素を使用することも知っています。それにもかかわらず、なぜ正しい要素が使われていないのでしょうか？

案件によりその原因は異なりますが、多くの場合「時間的な制約」があり、「現行サイトの見た目を再現すること」が最優先されるとき、こうした「代用」かつ「お手軽」な実装が発生する傾向があるようです。

制作期間に限りがあり、納期やスケジュールを優先するためにアクセシビリティ対応が軽視される、というのは残念ながらよくある話です。こうした実装でページが全く読めなくなるわけではありませんが、アクセシビリティを軽視していくことは、サイト全体の品質向上を目指す上で決してプラスにはなりません。では、どうすればこのような問題を減らしていくことができるのでしょうか？

最もシンプルな解決方法は、「繰り返すこと」ではないかと思います。

「アクセシビリティ標準対応」という取り組みを約半年間続け、代替テキスト不足、適切な要素を使用しないマークアップ、色に依存した表現、キーボード操作のみで使用できない機能など、サイト内の様々な部分に数多くのアクセシビリティに関するフィードバックを行なってきました。

しかし、制作スタッフが二度、三度とアクセシビリティ対応を経験するごとに、「どのような実装がアクセシビリティ上望ましいか」という知識や経験が少しずつ根付いていき、最近では最初からアクセシブルな設計や実装が行なわれているケースが増えてきたように思います。

検証する側であれば、問題が起こるたび、繰り返し、繰り返し、正しい方法を伝えていくこと、制作する側であれば、本当はどのような方法が適切か都度認識して修正すること—地道な方法ながらも、この繰り返しと積み重ねこそが、アクセシビリティのナレッジの基盤を強化していく上では何よりも効果的なのではないかと、そう感じています。

今後の課題は、設計より前の初期段階で確認しなければ修正が難しい点や、原稿やワイヤーフレームを作成する段階でアクセシビリティを意識させるような仕組みづくりだと考えています。設計/実装など、コーディングに関する部分は後からでもある程度修正できますが、要件定義や原稿上の問題は納期が迫った検証段階では修正が不可能なことも多く、この部分を今後どのように対応していくかが課題だと考えています。

まだまだ改善すべき問題や課題はありますが、一つずつ問題を解決し、経験を積み重ねながら、より品質の高いWebサイトを提供できる体制づくりを続けていきたいと思います。