Webアクセシビリティやろうぜ！！を実践するためにWebサイト構築チェックシートにこっそり盛り込んだ話
本日から全国的にお仕事再開ですねこんばんはー！！
Webサイトを構築するとき、様々なフェーズでチェックする項目がたくさんあるかと思いますがみなさんはどのようにしてこれらをクリアにしているのでしょうか？
そんなわけで、手始めに僕がWebサイトを構築する際にチェックをしていく項目とその補足を紹介して、みなさんにこうしたら良いよ、足りないよ、と教えてもらいたいなって思います。
僕がチェックするポイントは約300ほど。
これらの殆どは息を吸うようにチェックしています。嘘です、結構抜けます。
みなさんこんばんは。
宮城県仙台市にてWebのちからで様々な情報にアクセスしやすくし、様々なパフォーマンス改善をしちゃったりする時にはWebディレクター、時にはWebプランナー、時にはWebエンジニア、時にはWebデザイナー。
世界中のWeb業界で働く若者の味方、ma-sanです。
僕が所属している会社では多くのチーム及びクライアントごとに最適化されたチームビルディングが行われているため、「クライアントのサービスに特化したWebサイトの運用・構築」を主なサービスとしています。
その主要サービスを支えるために多種多様なスキルをサービス化し、子会社が生まれたり、個々の強みとして更に会社全体が向上していく、という流れです。
割りかし泥臭いやり方でもありますが、これらは「ド安定」させることはなかなか難しいのではないでしょうか？
今現在、僕が所属している会社で僕が死んでも誰でも同じことができるように、結構多くのナレッジシェアをしています。
10年ほど前でしたら僕が最も得意な領域は直接手を動かす「フロントエンドエンジニアリング」でしたが、いまでは「データ・経験則に基づいた設計・構築」が得意な領域になっています。
個人的な課題としては、如何にして所属している企業に自分自身でマネタイズできるか、というものですが、とりあえず失敗しまくったろか、という気概です。
このようにして、自分自身の領域を展開していっているかというと「自分自身でやれるようになったことはあとは廃れていくだけ」という認識を持っていて、「できた！」となった瞬間に「自分がこれで食っていけるのはあと何年かな」という計算に移ります。
僕は当初「Flash」で食っていました。20年ほど前の学生時代、Web業界デビューはFlashでとある企業の「Flashバナー（超死語）」を1点数万円で作ったりしたことです。
こんな楽しくってかんたんなことでこんなにもらえるなんてWeb業界ってちょろいなーとか思っていたのですが、Web業界にいる方々はご存知の通り、Flashは一瞬で駆逐されます。
社会に出てすぐに「あ、スキルって使い捨てなんだ、きっつ」と思いました。
そんなこんなで色々な領域に手を出しまくった結果、「自分のやりたいことは自分で手を動かす必要がないんじゃね？というか動かしてたら間に合わないんじゃね？」と思うようになりました。
僕がどうしても実現したいことは「Webアクセシビリティの実現による情報格差の解消」ですが、これがもうマネタイズの難しいのなんの。
なもんで、もう泥臭いけどコツコツ積み重ねてやろう。
僕の関わった案件はちゃっかりアクセシブルだぜ！という作戦に移行します（そして、案件なので自分の実績として外部に紹介できない罠がある）。
僕はフロントエンドエンジニアリングが得意な構築ディレクターとして会社でお仕事をしていますが、プランニングもしますしディレクションもします。
それらはすべて、僕が最初から関われば自然とアクセシブルな案件になる、と信じているからです。
というわけで前談が長くなりましたが、僕がWebサイトをアクセシブルにするために「Webサイトを構築する際にチェックするポイント」をまとめておきました。
それでは死ぬほど長いチェック項目となりますが、お納めください。
なお、これは項目と補足なので本当であれば別の形でフォーマット化した上で仕事で使用し、全社的に展開してたりします。
興味を持った方はぜひ、僕が働いてる会社に入社してくださいな。
僕が働いているWeb制作会社：株式会社メンバーズ
https://www.members.co.jp/
ページ内リンク
プランニング・ディレクションのチェック項目
| プロジェクト計画 | |
|---|---|
| 目的共有 | プロジェクトの目的を見失うとすべての判断基準が狂うため、これを共有する。 |
| 工数設計 | 我々はビジネスとして成果と利益の両立を目指す。そのためにプロジェクトのコンディションを正しく把握する必要がある。 |
| プロジェクト進行 | どのようなプロジェクトでもアジャイルの思想にのっとり、タスクの可視化をした上で作業に取り組む。可能ならスプリント運用 |
| 必要資料の共有 | 資料が不足するとすべての判断基準が狂うため、これを常に見えるところで共有する。 |
| プロジェクトファシリテーション | |
| MTG | 進捗をお互いに報告できるようにしている。 |
| 完了の定義 | 曖昧なタスクの完了は、負債を将来にまわしているだけである。 |
| 情報共有 | プロジェクト進行にともなって増える資料は、随時まとめ、共有する必要がある。 |
| テキストコミュニケーション | コミュニケーション方法の統一は、履歴の検索性を高める。 |
| 要件定義 | |
| 開発スコープ | やること・やらないことを明確にし、無駄のないスピーディーな開発を行う。 |
| 制作要件 | 作る段階で、納品を考慮した開発を行う。 |
| 要件定義書 | クライアントへの説明が必要な場合、またはこれを元に開発を進めていくという約束事。開発要件、品質、パフォーマンスの定義などもこちら。 |
| ワイヤーフレーム | デザイン前にどのような形になるのか、どうするべきかを考える必要がある。場合によってはこれが原稿そのものになる。 |
| 動作環境 | 動作環境がわからないと使える技術もわからない。だから決める |
| 進行管理 | |
| タスク管理 | タスク管理はプロジェクトの要 |
| タスク粒度 | 大きすぎるタスクは、タスク範囲を曖昧にし、また進捗が見えづらくなる。 |
| 時間計測 | スキル面にしてもスケジュール面にしても、建てた計画と実働の差を分析することで改善につながる。 |
| バックログ | 今やることとは別にこれからやることも計画性は必要である。その上でスケジュールを建てる |
| 開発環境 | |
| 構築設計 | 設計のすり合わせは、不要な手戻りを防ぐ |
| 開発環境の整備 | 各案件によって開発環境が異なる。制作者が自由に行うのではなく、開発環境の共有を行い合意を取ること |
| 本番環境の有無 | 本番環境がどのようになるのかを必ず確認すること。 |
| サイトマップの有無 | サイトマップがあるか。ハイレベルサイトマップだけではなく、詳細が明記されているサイトマップであれば望ましい。 |
| バージョン管理 | バージョン管理が無いプロジェクトなんてありえない。 |
| コーディングルールの定義 | チーム内での共通認識、個人差を埋める |
| 質問管理・課題管理・修正管理 | プロジェクト単位で必ず問題は発生する。問題が発生した際、どのような課題があるか、質問があるかをストックしていくこと。 |
| http/https | ドメインの影響を確認 |
| 外部サービスの利用 | API、ASPなど |
| .htaccess | サーバー側で何ら化の設定をしたい場合確認 |
| JSライブラリの実装 | jQueryなどを使用する場合 |
| JSの実装 | ページ固有のJSの実装が必要な場合 |
| フレームワークの採用 | Bootstrapなどのフレームワークを使用する場合 |
| 品質管理 | |
| テスト計画 | 作るものの定義と同時にテストも計画する |
デザインフェーズのチェック項目
| デザイン実施前 | |
|---|---|
| 設計の確認 | 設計からデザインデータ（psd、ai、png、sketchなど）の内容を確認できる状態にできる。 |
| 実装可否の確認 | 実装をする際、不可能なことはほとんどないが要素に応じて相談が必要な箇所が存在する。 |
| 各端末の挙動について | リキッド、レスポンシブ対応など |
| デザイン・イラスト・画像・写真データの支給の有無 | 使用可能なデータの確認 |
| デザイン・イラスト・画像・写真データの著作権、肖像権の確認 | 支給されるデータの著作権、肖像権に問題がないか、または制作側に不備がないか確認 |
| デザインガイドラインの有無 | デザインガイドラインが存在するか、または作成が必要か確認 |
| モジュール・コンポーネントの有無 | 共通のパーツを用いてデザインが構成されている。 |
| 余白の指定 | 余白は機能であり、バラバラと都度設定、勝手に判断・変更しないこと |
| エラー箇所と修正方法を明示 | ユーザーがエラーを認識し、どこをどのように修正すれば良いか設計されている |
| 動画の取り扱い確認 | 動画がある場合、支給されるか、どのように取り扱うか |
| 動画のキャプション（字幕）を提供するか | 動画がある場合、音声を聞くことができなくてもコンテンツを理解できるか |
| ホバー・アニメーションの有無 | 何らかのインタラクションが存在する場合は指示をもらうこと。 |
| デザイン品質 | |
| 全体のデザイン確認 | デザインを確認し、Webでの再現性があることを前提とする |
| 全体のサイズ確認 | デザインのサイズを確認し、指定のサイズ及び統一されていることを前提とする |
| 文字サイズ | 各種文字サイズが実装可能か、改行をしても耐えられるデザインか確認。 |
| 余白 | 余白に矛盾がないか、CSSフレームワーク、グリッドシステムなどと矛盾がないか確認。 |
| カラー | 文字色、リンク色（デフォルト、ホバー、アクティブ、アウトライン）、背景色に不備がないか確認。文字色、背景色のコントラスト比に注意すること。コントラスト比を 3:1 以上にする。 |
| 情報を伝える色の使い方に注意する | 色だけで情報を伝えようとしていないか（グラフなど、色のみで差別化している、など）確認。 フォームなどのエラーなどで色のみで必須などを伝えようとしていないか。 |
| 要素の抜け漏れ | 設計から要素の抜け漏れがないか確認。制作者側で要素を勝手に削らないこと。 |
| 繰り返し処理 | 繰り返し処理をするような箇所がないか確認。繰り返した場合に表示が崩れる可能性があるかなど。リスト、サムネイル表示、文章表示がこれに該当する。 |
| クリック範囲 | デザインだけではどこがクリックできる箇所なのか、判断できない場合がある。明らかなボタンなどは良いが、画像にリンクを貼るのか、テキストはリンクなのか。リストのクリック範囲はどこなのか、など。 |
| CSS | CSSで再現が可能な角丸、ボーダー、グラデーションなどは可能な限り実装することを確認し、背景画像、アイコン、透過が必要な画像などを区別をつけておくこと。 |
| RWD | 対応しない。もしくはRWDか、リキッドかの確認し、ブレイクポイントまで確認をしておくこと。 |
| コンテンツの拡大縮小がされても問題がないか | コンテンツが拡大されると表示が崩れるなど発生しないか確認が必要。 |
| 画像の書き出し品質 | |
| RWDチェックポイント | |
| 画像比率 | 各デバイスで画像の比率があっているか。画像の出し分けをどのようにするのか確認。 |
| 背景画像の扱い | 背景画像の出し分けが必要か、ある程度画像がはみ出ても問題ないレイアウトか確認。 |
| 情報設計の矛盾 | デザインを確認し、情報設計に矛盾がないか確認。HTML＋CSSのワンソース・マルチユースで成立しない場合はソースの二重表記が許容されるか確認すること。 |
| PC、SPの要素出し分け | PCのときだけ、SPのときだけなど、各デバイス限定で表示する要素の有無を確認。場合によってはアコーディオン、ハンバーガーメニュー、カルーセルなどの切り替えが必要。 |
| レイアウトの切り替えが3パターン程度耐えられるか | PC、SPだけではなく、タブレット、または縦横比率が逆転した際など、最低でも3パターン程度の切り替えが考えられる。工数の問題で、2パターンが限界なことが多いためすり合わせが必要。 |
| 固定サイズではなく、コンテンツ量が常に変動する前提のデザインか | メニュー、リスト、テーブル、カラムなど、テキストの量や画像サイズが統一されない場合を考えられているか。 |
| 改行位置 | よくよく見るとPC、SPのデザインで改行位置が違う。ということがよくある。 |
| コンテキストの矛盾 | デバイス変更時、文章や状況に矛盾がないか確認。例で言えば文中に左側、と言いつつSP時には画像は上にあるなど。 |
| テーブルのレイアウトに無理がないか | テーブルはレイアウトの変更に弱い。SPからデザインしたほうが良い。表の情報がクライアント支給の場合は紙媒体、セルのマージがされることを前提に考えること。 |
| JSの動作確認 | PCで動作したあとにSPサイズにすると表示が崩れる、というのはよくある。逆もまた然り。 |
コーディングフェーズのチェック項目
| HTML開発 | |
|---|---|
| 文字コード | 指定がない際はUTF-8を推奨 |
| 改行コード | CR+LFなど |
| 文字コード指定方法 | <meta charset=”UTF-8″>など |
| 拡張子 | .html / .css / .js / .jpg / .gif / .png / .svg / .pdf /など決めておく。 |
| HTMLファイル名 | サイトマップに準拠。指定がない場合はすり合わせ。 |
| HTML規格 | HTML5 |
| DOCTYPE宣言 | <!DOCTYPE HTML>など。小文字大文字も決めておく。 指定がない際は提案。 |
| ブレイクポイント | Media Queriesを使用したスクリーンサイズによるレイアウト振分け |
| 文書規格 | 半角カタカナ・全角英数字・機種依存文字は使用しない（英語サイトの場合は半角英数厳守）など |
| ページタイトル | title、h1などのルール |
| META Description | 入力するディスクリプション |
| META Keywords | 入力するキーワード |
| Viewportの指定 | Viewportをどのように指定するのか |
| アクセス解析タグ | Googleアナリティクス、Adobeアナリティクスなどの実装が必要か否か |
| ソーシャルタグ関連 | Facebook、Twitterなどのタグが必要か否か |
| ディレクトリ構成 | img、css、jsなどの格納ルール |
| 画像などの代替テキスト | imgのalt属性について |
| リンクの設定 | リンク先が分かる文言か、hrefやtargetの設定について |
| お問い合わせ（form）の使用確認 | formについて |
| フォームコントロールのラベルや説明のマークアップ | コントロールのラベルや入力方法、入力例を操作と関連付けができているか |
| 音声ブラウザ対応の有無 | voiceoverなども含む |
| バリデーションチェック | HTMLの品質担保のため、使用するバリデーションを定義しておく。 |
| CSS開発 | |
| 命名規則 | BEMなど、命名規則が決まっている。もしくは案件ごとに規定がある。 |
| CSS格納ルール | すべてのCSSファイルを一つにまとめるか、importするかを決めておく。 |
| CSSスプライトの使用可否 | 画像が多ければ多いほどリクエスト数が増えてしまう。 |
| フォントサイズの指定 | pxなのか、emなのか、%なのか、vwなのか、決めておく。 |
| フォント指定 | font-familyの指定があるか |
| Webフォントの指定 | インポートする必要のあるフォントはあるか、ある場合はどのように実装するか決まっているか。 |
| 行間の指定 | すべて統一とは限らない、状況に応じて変化できるように想定しておく。pxでの指定はフォントサイズとの兼ね合いで基本はNG。 |
| 調整用CSS | mgn_0やpdn_top_10など |
| 名前空間を利用しない | top-XXXX、header-xxxxなど、空間に依存するid、class名は使用しないこと。 |
| 繰り返し現れるブロックを囲む要素を設ける | ループ処理の際、あとひとつ、divでくくっておけば、、、という状況は多数存在する。最低限のブロック要素だけで実現できるとしても親となる要素を指定すること。親となる要素はdivを推奨。ulやdl、sectionなどはセットとなる子が必要なので非推奨。 |
| sectionにスタイルを指定しない。 | 全体のレイアウトに影響するようなスタイルをsectionに指定しない。 |
| アウトラインが無効化されていないか | フォーカスやアウトラインが認識できないようなCSSになっていないか |
| ベンダープレフィックス | 対応範囲の決定 |
| リセットCSS | 様々なリセットCSSが存在するので、決めておく |
| プリントCSS | 印刷時の対応は要件にあがらないことが多い。必ず確認しておくこと。 |
| CSSハック | 原則使用しない。旧ブラウザの対応で必要に迫られれば対応。 |
| JS開発 | |
| jQueryについて | バージョンなど確認しておくこと。jQueryにかぎらずライブラリを使用する際は必ず確認。ブラウザの要件と併せて確認だが、可能な限り最新版を実装する。対応ブラウザがIE9以上であればjQuery 2.X系を使用など。 対応ブラウザにIE8以下が含まれる場合はjQuery 1.X系を使用。$.browserを使っているプラグインを使う必要がある場合には、1.8.3を使用する必要があり。 |
| ライブラリ、プラグインを利用する場合の使用可否 | 世の中のコードにはライセンスが存在する |
| JSの記述位置 | head内には記述しないこと。ただし、各プラグインの仕様によっては容認する。 |
| 共通のJSファイル | 複数のページで使うことが想定されるものはcommon.jsにまとめてください。 |
| フォーカスについて | 例としてページトップへ戻るを選択した際、ファーカスの位置は適切な位置に移行しているか。ページ内のレンダリング、レイアウト変更すべてに適用すること。アコーディオンなども同様。 |
| No Script対応 | JSが読み込まれない場合の対応 |
| ウィンドウ幅切り替えによる誤動作 | ウィンドウ幅によって制御を変える際、予期せぬ挙動が発生する可能性がある。主にサイズの変更や要素の表示/非表示など。 |
| 解析タグや計測ツールの動作確認 | JSを実装した際、解析タグなどが反応しなくなってる場合もありえる |
テストフェーズのチェック項目
| 制作後チェック内容 | |
|---|---|
| テキストの整合性 | 原稿と実装した内容が一致しているか。抜け漏れがないか。 |
| レイアウト・デザインの整合性 | ページによって適用するHTMLやCSSに違いがないか |
| 適用モジュールの妥当性 | リストであるべき箇所がリストになってないなど、適用するモジュールの妥当性を確認 |
| レイアウト・デザインの表示崩れの有無 | 表示崩れがないか |
| 拡大縮小による表示崩れの有無 | 拡大縮小によって表示が崩れないか。定義ができているか。 |
| ウィンドウ幅による表示崩れの有無 | 定義したサイズの中間サイズなど、崩れることも多い。 |
| ウィンドウ幅によるレスポンシブ表示切替 | メディアクエリの統一がされているか |
| 画像内テキストの妥当性と可読性 | 画像に存在するテキストとaltの設定など |
| クリック（タップ）の動作 | リンクなど、必ずチェックすること。CSS、JSの書きぶりによってはアクションしないこともままある。 |
| マウスホバーの動作 | PCなどは特にホバーやアウトラインはしっかり確認をしておくこと。 |
| ページ内リンクの動作性 | ページトップに戻る、途中の見出しに遷移するなど、しっかりと動作するか確認をすること。 |
| 拡大縮小後の動作不具合の有無 | 特にカルーセル、アコーディオン、表示非表示系の動作 |
| ウィンドウ幅変更後の動作不具合の有無 | 特にカルーセル、アコーディオン、表示非表示系の動作 |
| リンクの妥当性 | 指定したリンクが正しいか。デッドリンクが発生していないかなど。 |
| パス指定の整合性 | 相対パスか、ルートパスか、絶対パスかなど。 |
| 別ウィンドウの設定 | 外部サイトやPDFなどは別ウィンドウで表示するなど決まっている場合。 |
| ポップアップ・モーダルの動作性 | 表示されるか、した際の動作に不備がないか |
| TELリンクの有効/無効 | 未実装の場合はリンクされるので、無効にするか否かを決めておく |
| キーボードだけでも操作ができるか | マウス、タッチパネルではなくキーボードやVoiceOverでも操作できるか |
| 画像情報の妥当性（サイズ） | 変倍がかかっていないか、Retinaディスプレイなどでぼやけていないか |
| HTML文法の妥当性 | なんらかのバリデーターを利用すること |
| JS文法の妥当性 | コンソールエラーがデていないか確認 |
| ファイル配置の妥当性 | HTML、CSS、JS、画像などの格納先に誤りがないか |
| 印刷プレビュー | 印刷時に問題がないか確認 |
| ゴミファイルの有無 | thumbs.dbなど。Gitなどバージョン管理を行っている場合は余計なファイルがないか確認。 |
| 納品ファイルの確認 | 納品ファイルに不整合がないか確認すること |
まとめ
上記のチェック項目はかなり膨大ですが、業界の方からすればごくごく普通のことが中心です。
それを敢えてチェックする、というのは当たり前の行為でありますが、Web業界で働いたことがない人、働きたての人にとってはちょっと参考になるのではないか、と思って記事を書きました。
Webアクセシビリティは誰にでも必要なものであり、ターゲティングを意識するものではありません。
僕にとってWebアクセシビリティというのはWebで働くものにとっての「プロ意識」であるとも信じています。
ここだけの話
ここまで読んでる方はかなり奇特な人だと思うので、ここだけのお話です。
僕が所属している会社は現在、多くの仲間を募集しています。
いや、なんだったらWeb業界そのものが多くの仲間を募集しています。
これからが革命のときでして、いままでは都内に集中していた大企業を中心としていましたが、全国にオフィスができてきたということもあり、より多くの企業とお仕事をしていきます。
そのため、地方拠点、僕が所属している仙台オフィスでも、九州オフィスでも、もっともっと多くの人材が必要です。
Webアクセシビリティを実現したい、というにはもっともっと多くの「文脈を共有した人」が必要です。
今でこそWebアクセシビリティの重要性に気がついている方は少数だと感じていますが、あまりにも当たり前の「大前提」であり「品質」であり、敢えてなにかをする！というにはみなさんの力が必要です。
Webアクセシビリティに興味のある方はおれんとこ、こないか？！いや、Webアクセシビリティやるなら別にどこでだっていい！
俺と一緒に頑張らないか？別の会社に所属している状態でもいいので！
気軽にツイッターなりFacebookなりで僕にアクセスしてみてください。
とか勝手に僕が考えてるだけなので、所属している企業の公式な声明ではありません。
もしかしたら怒られるかもなー、でもまぁ、いっか！！
採用情報｜メンバーズ
https://recruit.members.co.jp/
