アクセシビリティと文書編集：欧州アクセシビリティ法がソフトウェアにもたらす意味とONLYOFFICEの取り組み

デジタル製品に求められるアクセシビリティの要件は、ヨーロッパを中心にでますます重要になっています。ソフトウェアを選ぶ組織にとって、アクセシビリティはもはや単なる追加機能ではありません。調達要件や組織のポリシーの一部となることもあれば、対象となる製品やサービスによっては法的な義務にもなり得ます。

文書編集ソフトウェアの場合、この問題は特に複雑になります。なぜなら、生産性スイートは、テキストを入力するためだけのものではないからです。そのユーザーはツールバーやメニューを操作し、表やスプレッドシートを扱い、プレゼンテーションを作成し、フォームに入力し、PDFを編集し、同僚と共同作業を行い、さまざまな種類のコンテンツの間を行き来します。こうしたワークフローのどこか一か所にアクセシビリティ上の障壁があるだけで、本来なら日常的な作業を完了できなくなってしまうことがあります。

継続的なアクセシビリティへの取り組みの一環として、ONLYOFFICEはアクセシビリティ適合性ステートメントの準備を進めています。このステートメントでは、エディタで現在利用できるアクセシビリティ機能、対応を拡大中の領域、そして正式な適合性評価に対する当社の方針を説明します。ONLYOFFICEを検討しているユーザーや組織、特にアクセシビリティ要件を持つ方々に、より明確な全体像をお伝えすることを目的としています。

欧州アクセシビリティ法とは

欧州アクセシビリティ法（EAA）とは、指令（EU）2019/882のことで、欧州連合において特定の製品やサービスに共通のアクセシビリティ要件を定めるために採択されました。

この指令の対象は、消費者向けのコンピューターハードウェアやオペレーティングシステム、電子書籍とその専用ソフトウェア、電子商取引サービス、消費者向け銀行サービス、そして一部の電子通信サービスや交通関連サービスなど、明確に定められた範囲の製品とサービスです。対象となる製品とサービスについては、2025年6月28日から要件が適用されています。

この法律の目的は、個々のインターフェース要素をアクセシブルにすることを求めるだけにとどまりません。EU加盟国ごとに異なるアクセシビリティ要件によって生じる障壁を減らし、障害のある人々にとって製品やサービスをより利用しやすくすることを目指しています。

特定のソフトウェア製品や導入形態が、EAAの適用範囲に厳密に含まれるかどうかは、製品、サービス、事業者、そして利用ケースによって異なります。オフィスソフトや文書エディタのように、さまざまな形で、さまざまなサービスの一部として提供され得るソフトウェアでは、この点が特に重要になります。

そのため、組織はアクセシビリティステートメントが存在すること自体を法令順守の証明とみなすのではなく、自らの法的要件と調達要件を個別に確認する必要があります。

EAA、EN 301 549、WCAGの違い

これらの用語はよく一緒に使われますが、同じ意味ではありません。EAAは欧州の法律であり、指令の対象となる製品とサービスに対するアクセシビリティ要件を定めています。

EN 301 549は、ICT製品とサービスのアクセシビリティ要件を定めた欧州の技術規格です。現在整合規格となっているEN 301 549 v3.2.1は、WCAG 2.1を大きく取り入れていますが、WCAGには含まれない要件も含んでいます。

WCAG（Web Content Accessibility Guidelines）は、W3Cが策定したアクセシビリティのガイドラインです。WCAG 2.1では、コンテンツとインターフェースは知覚可能、操作可能、理解可能、そして堅牢であるべきという4つの原則にもとづいて、アクセシビリティの要件が整理されています。

ソフトウェアを評価する際には、この違いが重要になります。WCAGの個々の達成基準を満たしていても、それだけでEN 301 549の該当するすべての要件への適合が示されたことにはなりません。同様に、アクセシビリティ機能の一覧を公開することと、正式なアクセシビリティ監査を完了することは別のものです。

そのため、意味のある適合性評価のプロセスでは、該当する要件を特定し、製品の関連するワークフローをテストし、その結果を文書化する必要があります。

文書エディタならではのアクセシビリティの課題

現代のオフィススイートは、実質的に複雑なアプリケーションの集合体です。文書エディタを例に考えてみましょう。ユーザーは見出し、表、コメント、リンク、脚注、画像などのオブジェクトの間を移動する必要があります。スプレッドシートになると、2次元のグリッド、数式、グラフ、フィルター、データ構造が加わります。プレゼンテーションエディタでは、スライド、オブジェクト、アニメーション、発表者ノートが登場します。

PDFには、また別の課題があります。特に、文書に注釈を付ける、ページ間を移動する、フォームに入力する、スキャンしたコンテンツを扱うといった場面です。

つまり、アクセシビリティは、製品に「ハイコントラストモード」があるかどうかや、特定のボタンにキーボードで到達できるかどうかを確認するだけでは評価できません。ワークフロー全体を考慮する必要があるのです。

ONLYOFFICEですでに利用できるアクセシビリティ機能

ONLYOFFICEは、エディタをさまざまなユーザーに合わせやすくするための仕組みをすでに数多く提供しています。

視覚面のアクセシビリティとしては、50%から500%までの拡大縮小プリセットに加え、編集領域をページ幅や画面幅に合わせるオプションを用意しています。また、視覚的な情報量を減らしたいときには、ツールバー、ステータスバー、ルーラーといったインターフェース要素を非表示にすることもできます。

エディタにはライトとダークのインターフェーステーマがあり、グラフの要素には、色だけに頼らず幾何学的なパターンなどで区別をつけることができます。

言語も、アクセシビリティの一部です。ONLYOFFICEは25以上のインターフェース言語に対応しており、インターフェースの言語は文書の言語とは別に設定できます。

エディタは右から左に書く言語や双方向テキストにも対応しています。アラビア語、ヘブライ語、ペルシャ語、ウルドゥー語などの言語を、左から右に書くことを前提としたインターフェースの制約に合わせてコンテンツを組み直すことなく扱えます。

キーボード操作はエディタの主要な部分で利用でき、さらにSpeech Inputプラグインを使えば、音声という別の方法でテキストを入力することもできます。

モバイルプラットフォームでは、iOSのVoiceOverやDynamic Type、AndroidのTalkBackといった技術への対応も含まれています。

ただし、これらの機能だけで、特定のアクセシビリティ規格への完全な適合が成り立つわけではありません。いずれも、より広いアクセシビリティへの取り組みを構成する個々の要素です。

今後さらに取り組みが必要な領域

アクセシビリティステートメントで最も重要な部分のひとつは、まだ完了していないことを明記することです。

ONLYOFFICEにとって、スクリーンリーダーへの対応は引き続き重点的に開発を進めている領域です。文書、スプレッドシート、プレゼンテーション、PDFの各エディタにおいて、WindowsのNVDAやJAWS、macOSのVoiceOverへの対応拡大に取り組んでいます。

キーボードによるアクセシビリティも拡充を進めています。特にPDFエディタとフォーム入力のインターフェースは、文書エディタやスプレッドシートエディタと比べて、現時点ではキーボード操作への対応が限られています。このほか、ディスレクシアに配慮したフォントの選択肢や、動きを抑える設定なども検討しています。

こうした制約を明示することは、ソフトウェアを評価する組織にとって重要です。アクセシビリティの要件はユーザーによって大きく異なり、あるワークフローでは十分な機能が、別のワークフローでは十分でない場合もあるからです。

ONLYOFFICEが正式な適合性評価を準備している理由

次のステップは正式な評価です。ONLYOFFICEは、エディタ全体を対象としたWCAG 2.1 レベルAAのアクセシビリティ監査に向けて取り組んでおり、調達目的のためのVPAT／アクセシビリティ適合性レポートの準備も進めています。正式なレポートは、一般的なアクセシビリティステートメントとは異なる水準の情報を提供します。

製品がキーボード操作やスクリーンリーダーに対応していると述べるだけでなく、アクセシビリティ適合性レポートでは、個々のアクセシビリティ基準を検証し、評価方法にもとづいて、それぞれが「対応」「一部対応」「非対応」「該当なし」のいずれであるかを示すことができます。

組織にとって、この種の文書はアクセシビリティの評価をはるかに実務的なものにしてくれます。調達部門やIT部門は、大まかなアクセシビリティの主張に頼るのではなく、具体的な要件を製品と照らし合わせて比較できるようになります。また、製品チームにとっても、より明確な開発目標となります。

アクセシビリティは製品開発のプロセスそのもの

複雑な生産性ソフトウェアでアクセシビリティへの取り組みに時間がかかる理由のひとつは、製品に変更が加わるたびにアクセシビリティを考慮する必要があることです。

エディタに新機能が加われば、新しいキーボード操作が生まれる可能性があります。ツールバーのデザインを変えれば、ナビゲーションに影響することがあります。新しいダイアログには、スクリーンリーダー向けの追加情報が必要になるかもしれません。新しいPDFのワークフローは、フォームやフォーカス管理に関する新たな要件を生むこともあります。

そのため、アクセシビリティは開発の最後に一度だけ確認するチェックリストとして扱うことはできません。要件定義、設計、実装、テスト、フィードバック、そしてその後のリリースという、製品ライフサイクル全体の一部である必要があります。

正式な適合性評価とユーザーからのフィードバックが補い合う関係にあるのも、このためです。監査は定められた基準に沿った体系的な評価を提供し、ユーザーは限られたテストシナリオでは見えにくい実際の障壁を明らかにしてくれます。

アクセシビリティ適合性ステートメントでわかること

新しいONLYOFFICEのアクセシビリティ適合性ステートメントは、これらの要素をひとつにまとめたものです。

現在利用できるアクセシビリティ機能を記載し、既知の制約を明らかにし、開発中の領域を説明したうえで、認知されたアクセシビリティ規格に対する正式な評価への当社の方針を示しています。完全に適合しているという包括的な主張としては、あえて提示していません。

特定のアクセシビリティ要件を持つ組織にとって最も役立つ情報は、製品にアクセシビリティのラベルが付いているかどうかではなく、どのワークフローに対応しているのか、どのような制約が残っているのか、そしてどのような根拠が示されているのかであることが少なくありません。それこそが、このステートメントの目的です。

今後に向けて

ONLYOFFICEのアクセシビリティへの取り組みは、この文書の公開後も続いていきます。

優先事項には、スクリーンリーダーへの対応拡大、キーボード操作の拡充、さまざまな認知面・視覚面のニーズを持つユーザーのための追加オプション、そして関連するアクセシビリティ要件に対する正式な評価が含まれます。

より大きな目標はシンプルです。誰もが、自分に合った操作方法や支援技術を使って、文書の作成、編集、確認、共同作業を行えるようにすることです。

教育、ビジネス、行政など、さまざまな組織で毎日使われるソフトウェアにとって、これは二次的な検討事項ではありません。デジタルな職場がそもそも使えるものであるための、前提の一部なのです。