アクセシビリティ

BuildVuが出力するコンテンツがADA、EAA、AODA、AMAなどのアクセシビリティ関連法に準拠しているかどうか、よく質問を受けます。シンプルな質問ですが、答えは単純に「はい」または「いいえ」ではありません。これらの法律自体は多くのことをカバーしており、主に物理的な世界に関するものです。例えば、車椅子を使用する人が建物にアクセスできるようにすることや、聴覚障害者向けに電話サービスの代替手段を確保することなどです。

Webコンテンツのアクセシビリティに関しては、これらの法律自体が準拠するために何をすべきかについて具体的に規定しているわけではありません。例えば、1990年の Americans with Disabilities Act (ADA) では、インターネットについて全く言及されていません。幸いなことに、コンテンツをアクセシブルにするための指針となる他の標準が存在します。Web上では、これはWeb Content Accessibility Guidelines (WCAG) 2に準拠することを意味します。

目標が何であるかを理解したところで、私たちがあるフォーマットから別のフォーマットへ変換を行っていること（この場合、PDFからHTMLへ）を考慮することも重要です。あるフォーマットや言語から別のものへの翻訳と同様に、特定の機能に直接的な同等物が存在しない場合には、トレードオフを行う必要があります。さらに、入力（PDF）の品質が低い場合や、アクセシビリティ機能を利用していない場合、出力（HTML）の品質にも影響します。

ソースフォーマットとしてPDFを扱っているという事実は、特に重要なポイントです。PDFファイルフォーマットは、画面上でドキュメントを表示するフォーマットになる前に、印刷用のフォーマットとして誕生しました。これは、ファイルフォーマット自体が内部的に、ドキュメントがどこでも同じように見えることを保証するのに非常に優れた構造になっている一方で、コンテンツをアクセシブルな方法で保存するのにはあまり優れていないことを意味します。例えば、見た目には見出し、段落、または表として認識されるものが、実際には内部的には指定された座標に描画されるテキストの行や図形として保存されています。

PDFファイルフォーマットは、アクセシビリティをはるかに向上させる新機能を採用するように進化してきました（例えば、ドキュメント構造にタグを付ける機能など）が、すべてのドキュメントにその追加情報が含まれているわけではありません。特に古いドキュメントには含まれておらず、新しいドキュメントでもそれなしで作成されている可能性があり、ドキュメントのアクセシビリティが制限されています。さらに、PDFは固定レイアウトフォーマットであるため、フォントサイズや行の高さを増やすなどのアクセシビリティ機能は実現できません。機能に関係なく、作成者が読みにくいフォントを使用したり、コントラストの低い色を使用したりすることで、アクセシビリティの低いドキュメントを作成する可能性もあります。

BuildVuが生成する出力がアクセシビリティ関連法に準拠しているかどうかについては、ビューア自体とドキュメントのコンテンツという2つの領域に分けて説明しましょう。

ビューアのアクセシビリティ

BuildVu 2025.04リリースには、IDRViewer（特に’Complete’ UI）がWeb Content Accessibility Guidelines (WCAG) 2.0の要件を満たすことを保証するための変更が含まれています。これは、ADA、EAA、AMAなどの法律への準拠に関して、受け入れられている標準です。

例えば、‘Complete’ UIは以下の特徴があります：

色のコントラストガイドライン（WCAG AA）を満たしている
キーボードでアクセス可能
スクリーンリーダーなどの支援技術と互換性がある

コンテンツのアクセシビリティ

ドキュメントのコンテンツは、スクリーンリーダーがアクセスできる実際の選択可能なテキストを使用している限り、アクセシブルです。BuildVuは現在、提供されている場合でもドキュメントのタグ付け（見出し、段落など）を利用していません。これをより効果的に活用できるかどうかを調査する予定です。

変換されたドキュメントのアクセシビリティを保証することはできません。これは、ソースのPDFドキュメントがアクセシビリティ標準を満たしていることに依存するためです（アクセシブルでないPDFをアクセシブルなHTMLに変換することはできません）。

PDFドキュメントが適切に作成されており、アクセシビリティ標準を満たしている場合、変換されたHTMLもスクリーンリーダーなどの支援技術と互換性があると言えます。