ニュース

進行中のプロジェクト

最終更新：2026 年 10 月 31 日

進行中

v3：本格的な QA スイート

2026 年 9 月 27 日

DrupalCon Europe 2026 で発表

主な新機能

• テストコアを Sa11y と統合。共同開発した新しいルールセットにより、コアのコンテンツテストに開発者向けテスト、コントラストチェック、可読性スコアリングが加わりました。
• 多言語対応
• カスタムチェックビルダー
• ダッシュボードメンテナンスツール
• 新しい結果を追加するサイトクロールツール。
• 特定のテスト（この PDF はアクセシブルか？など）について、特定のロールに対してアラートをサイト全体で非表示にできます。
• 分割設定：開発者とコンテンツ作成者、それぞれのロールに応じたテストとレポート表示。

そして、プロジェクトの将来にとっておそらく最も重要なのが次の点です：

• このスポンサー組織を立ち上げて既存ユーザーをサポートし、今後のプロジェクトのアイデアの実現に資金を充てるための助成金を獲得しました。

v2：アラートの非表示とレポート

2023 年 3 月 2 日

2 年前、私たちは Editoria11y アクセシビリティチェッカーを紹介しました。Drupal にすぐ導入できるサイトプラグインで、作成者に自動で即座にフィードバックを返し、コンテンツを改善するための役立つヒントを提供するものです。

満たされていないニーズに応えられるはずだと考えていました。既存の選択肢はどれも、役に立てるにはトレーニングと地道な利用が必要でしたし、大規模な組織で何千人ものコンテンツ作成者をトレーニングして監視するのが効率的な解決策でないことは、経験からわかっていました。プログラムを成功させるには高度な自動化が欠かせず、よくあるミスを検出したときにコンテンツ作成者へ丁寧な「ジャストインタイムのトレーニング」を提供する必要があると確信していたのです。

うまくいきました。

Princeton では、私のコミュニケーションの向きがほぼ逆転しました。導入済みのプラットフォームでは、alt テキストやリンク、見出しの改善を求める同じようなメールをコンテンツ作成者に送る側だったのが、こんなに指摘されないようにするにはどう書けばよいのかという質問をコンテンツ作成者から受け取る側に変わったのです。

外部の反応は大歓喜でした：

自己完結型のヒントを書く

v1 のヒントでは「概要と詳細」方式を採りました。問題の短い説明と、詳細へのリンクです。

開発者向けに書かれたツールと比べれば、これは改善でした。ヒントは短く明快だったからです。しかし、どこにリンクするかは常に悩みの種でした。政府機関や高等教育機関のユーザーの中には、Princeton のドキュメントへのリンクを取り除こうとヒントを修正する必要に迫られる人もいて、余計な手間をかけることになっていました。そこで既定のヒントを、例をインラインで示す自己完結型に書き直しました。

赤のアラート（確実な問題）と黄色の警告（問題の可能性）の区別は、わかりにくく、ときに煩わしいものでした。

そこで黄色の警告を「手動チェック」に変更して意味を明確にし、作成者がアラートを非表示にできるボタンを追加しました。「無視」したアラートはクリックした本人にだけ非表示になり、「OK とマーク」したアラートはサイトの編集者全員に非表示になります。それぞれの操作を誰に許可するかは、サイト管理者が選択できます。

ダッシュボードの作成

サイトオーナーからよく聞かれた嘆きは、ツールはサイトのあちこちで問題をしっかり見つけてくれるのに、サイト全体のレポートを見る手段がない、というものでした。

今回の書き直しでは、検出結果をサイトのデータベースに同期するオプションを追加しました。サイトオーナーは検出結果をページ別または問題別に閲覧でき、どの問題が無視され、どの問題が OK とマークされたかを確認できます。納得できなければ、その問題を元に戻すこともできます！

開発者向け V2 コードツアー

V2 はほぼ全面的な書き直しでした。新機能の一部を紹介します：

• jQuery への依存をなくしたことで、より多くのプラットフォームにインストールできるようになり、パフォーマンスも 2 倍に向上しました。
• チェッカーは、ページ内の独立した複数の部分（記事の本文とページフッターなど）を検査するように設定できるようになりました。
• さまざまなウェブコンポーネントや JavaScript ライブラリで使われているシャドウ DOM 内の要素もテストできるようになりました。
• プラットフォームとの統合を容易にする新しいパラメーターを多数追加しました。たとえば、ページのコンテンツには責任を負わないものの、必要に応じて結果を確認したいユーザーに対して、特定のページの問題をすべて自動的に無視するといった設定です。
• チェッカーには複数の基本テーマが同梱され、色をカスタマイズするパラメーターも用意されました。
• 自動テストにより、コードのリグレッションを防ぎやすくなりました。

2024 年 A11yTalks

2024 年 6 月 11 日

Drupal GovCon 2023

2023 年 10 月 27 日

DrupalCamp NJ 2023

2023 年 3 月 28 日

v1：インラインヘルプ

2021 年 3 月 11 日

アクセシビリティの高いウェブコンテンツを作成するのは複雑で、まず大量のトレーニングから始まりがちです。

慣れ親しんだやり方をやめてもらう必要があります：

• テーブルを使って擬似的な段組みを作らない
• 本文のテキストを中央揃えや両端揃えにしない
• 視覚だけの書式（フォントの太さやサイズ）に頼って意味を伝えない。ユーザーはコンテンツを耳で聞いていたり、「リーダーモード」で見ていたりするかもしれない

新しいやり方を身につけてもらう必要があります：

• 画像には文脈に即した意味のある代替テキストが必要
• ページには本物の構造が必要
• リンクには意味のあるタイトルが必要

確かに、新しい概念を教えるためにトレーニングを実施している面もあります。しかし、どこかの時点でこう問う必要があります。新しいスキルの必要性のうち、概念が新しいことから生じているのはどれだけで、ツールを更新しないまま新しい期待を押しつけていることから生じているのはどれだけなのか、と。新しいからといって、直感的になれないわけではありません。

スペルの歴史から学ぶ教訓

フェーズ 1：作成者のせいにする

有史以来 1980 年代初頭まで、単語のつづりを間違えれば作成者のせいにされてきました。正しいつづりを身につける責任は作成者にあったのです。

では、どうやってつづりを上達させたのでしょうか？　聞き覚えのある話かもしれません：

1. 家庭教師のもとや教室でトレーニングを受けた
2. 一覧表やガイドライン、辞書を渡されて勉強した。その歴史は、粘土に刻まれた古代の楔形文字の語彙集にまでさかのぼる。

フェーズ 2：辞書のせいにする

しかし 1980 年代に変化が起こりました。「スペルのフェーズ 2」と呼ぶことにしましょう。広く使われていたワープロソフトがスペルチェックを搭載したのです。

では、責任のなすりつけ合いはどうなったでしょうか？　ほぼ一夜にして、矛先はツールに移りました：

• 単語のつづりがわからない？　当てずっぽうで入力し、候補が見つかることを祈りましょう。見つからなければ、辞書のせいです。
• 実在する単語なのに、辞書が知らないせいで指摘された？　ぶつぶつ言いながら、下線を無視するか、右クリックして辞書に追加するかを決めましょう。

スペルチェックでつづりの問題がすべて解決したでしょうか？　もちろん違います。それでも役に立ちました。そして、負担と責任の多くを作成者から機械へと移したのです。

ただ、話はここで終わりではありません……

フェーズ 3：作成ツールのせいにする

近年はさらに一歩進み、コンピューターが私たちの代わりにつづってくれるようになりました：

• 予測アルゴリズムは、次の単語や次のフレーズ、ときにはテキストメッセージの返信全体まで推測しようとします。
• 自動書式設定ツールは、アスタリスク、数字、文字をリストに変換したり、ショートコードを特殊文字や絵文字に変換したりしようとします。
• 音声入力ツールは、文脈を認識して同音異義語を選び分けようとします。

では、これがうまくいかなかったとき、責められるのは誰でしょう？　ツールです！

SNS のまとめサイトは、恥ずかしい「そんなつもりじゃなかったのに！」のスクリーンショットが大好きです。

Editoria11y はフェーズ 2 への一歩

私たちのトレーニングではテストについて多くを語り、かなり優れたテストツールをいくつか紹介しています。どのツールもすべてを検出できるわけではありません。「色や空間的な位置への言及で概念を説明しない」といったことは人間が確認する必要があり、ツールが検出できるのは通常、サイトに実際に存在する問題の半分弱です。それでも、編集コンテンツによくあるミスの多くを、ツールは非常にうまく検出します。

ただし、問題が 3 つあります：

1. ほとんどは手動ツールです。コンテンツ作成者は使い方を教わっていなければならず、コンテンツを書くときにその存在を覚えていなければならず、書き終えたら実行するのを忘れてはなりません。この 3 つの失敗ポイントが重なって、多くの（大半の？）コンテンツが未チェックのまま残されます。
2. 指摘が多すぎます。作成者がたった今犯したミスだけでなく、デザイナーによる色の問題、開発者による技術的な問題、情報提供目的の構造要素なども指摘します。そのためトレーニングのハードルが上がります。作成者はツールを理解するだけでなく、誤検知の一覧や、確かに実在するものの、今この記事を書いている自分が修正する責任のない問題を無視するよう教わらなければなりません。
3. 自動ツールは、サイトをクロールしてダッシュボードを見に行く、というパラダイムが主流です。ここでもまた、作成者がダッシュボードを見に行くよう教わっていて、それを忘れないことが前提になっています。

そこで Princeton は新しいものを作ることにしました。ウェブサイトに統合され、編集上のよくあるミスだけを見る自動チェッカーです。

自動というのは……難しいものです。

1. 自動チェッカーにはさりげなさが必要です。主張が強すぎれば作成者の作業を妨げて苛立たせ、控えめすぎれば簡単に無視される背景雑音になってしまいます。
2. 自動チェッカーには高いパフォーマンスが必要です。実行中にページがガクガクしたり引っかかったりすれば、作成者はその存在を疎ましく思い、無効にしてしまいます。
3. 自動チェッカーには初心者にやさしいヒントが必要です。多くの作成者にとって、コンテンツをよりアクセシブルにするタグ付け、構造、言葉遣いについて聞くのはこれが初めてでしょう。アラートは技術用語を避けた平易な言葉で、コンテンツを改善するための実践的なアドバイスとともに示す必要があります。

そこで、これらの目標に最も近いツールから始めました。Toronto Metropolitan University 発の Sa11y です。そのテストアーキテクチャと、情報パネルとツールチップを組み合わせたユーザーフレンドリーな手法を取り入れ、半年かけて改良しました。テストが常に自動で実行されるようにし、パフォーマンスを最適化し、ツールチップを調整し、開発者があらゆるプラットフォームにすばやく適応させられるよう多数の設定オプションを作成しました。

現在の様子は次のとおりです：

作成者がサイトにログインしていると、Editoria11y のトグルが各ページの問題の件数と種類（合格、手動チェックが必要、問題の可能性が高いものを検出）を示します。クリックすると、インラインのハイライトとヒントが表示されます。エラーが新しいもの、つまり編集したばかりのページを見ている場合は、パネルが自動的に開きます。

2021 年 3 月時点で、400 を超える Princeton のウェブサイトが次の項目を自動的にチェックしています：

• 適切な文書アウトライン
  • 見出しのレベルの飛び
  • 空の見出し
  • 非常に長い見出し
  • 実は見出しかもしれない、不自然に短いブロッククォート。
• テキストによる代替
  • alt テキストのない画像
  • alt テキストがファイル名になっている画像
  • alt テキストが非常に長い画像
  • 「〜の画像」「〜の写真」のような冗長な語句を含む alt テキスト
  • リンク内の画像で、alt テキストがリンク先ではなく画像そのものを説明しているように見えるもの
  • 通常はテキストによる代替が必要な、埋め込みのビジュアライゼーション
• 意味のあるリンク
  • テキストのないリンク
  • タイトルがファイル名になっているリンク
  • 「こちらをクリック」「詳しくはこちら」「ダウンロード」など、汎用的な語句だけをタイトルにしたリンク
  • 外部リンクアイコンなしで新しいウィンドウを開くリンク
• 全般的な品質保証
  • アスタリスク、数字、文字ではなくリストの書式が使われていることの確認
  • CAPS LOCK で打った大量の大文字テキスト
  • ヘッダーのないテーブル、およびテーブルヘッダー（<th>）の代わりに文書の見出し（「見出し 3」）を使っているテーブル
  • PDF などの文書へのリンク（ダウンロードファイルのアクセシビリティをテストするか、アクセシブルな代替形式を提供するようユーザーに促す）
  • 動画の埋め込み（字幕の追加をユーザーに促す）
  • 音声の埋め込み（トランスクリプトの提供をユーザーに促す）
  • ソーシャルメディアの埋め込み（alt 要素の提供をユーザーに促す）

JavaScript ライブラリをコミュニティに公開し、すぐに導入できる Drupal 統合を作成したほか、同じくすぐに導入できる WordPress 統合の作業にも着手しました。

フェーズ 3 へ：デフォルトでアクセシブルに

多くの点で、Editoria11y は応急処置です。検出するミスのほとんどは、コンテンツ作成者に新しい期待（「適切な構造でコンテンツをタグ付けしてください」）を課しながら、その逆を促すツールを渡してきたことから生じたものです。

進むべき道は、アクセシブルなコンテンツ作成をより簡単に、できるかぎり自動にすることです。それが具体的にどのような形になるかはまだ見えていませんが、おそらく次のようなことが含まれるでしょう：

• どのオプションを用意するかを見直す。たとえば、ウェブでテキストを両端揃えにしないようユーザーに言い続けるのなら、あの「両端揃え」ボタンはそろそろ引退させるべきでは？
• デフォルトのオプションを見直す。たとえば、ほとんどのコンテンツ管理システムの既定のテーブルにはヘッダーがありません。「プロパティ」をクリックしてアクセシビリティ機能を追加すべきだと知っておく責任はユーザーにあります。そろそろこれを逆にしてもよいのでは？
• 予測的な書式設定と「作業中のヒント」を検討する。ユーザーが行全体を太字にしたら、見出しにするよう提案できないか？　見出しを選ぼうとしたら、6 つの選択肢を示す代わりに、使いたそうな見出しレベルを推測できないか？　難しい概念についてジャストインタイムのトレーニングを提供できないか？