アクセシビリティについて

アクセシビリティ法規制とBuildVuの関係性

BuildVu は、ADA、EAA、AODA、AMA などのアクセシビリティに関する法律に準拠した出力を生成するのか、という質問をよく受けます。これは簡単な質問ですが、答えは「はい」または「いいえ」と簡単に答えられるものではありません。これらの法律は、主に物理的な世界において、例えば、車椅子の人も建物にアクセスできることを確保したり、聴覚障害のある人向けに電話サービスの代替手段を確保したりするなど、さまざまなことをニーズとして網羅しています。

ウェブコンテンツのアクセシビリティについて、これらの法律は具体的な遵守要件を定めていません。例えば、1990年の米国障害者法（ADA）にはインターネットに関する言及が一切ありません。しかし幸いなことに、コンテンツのアクセシビリティを確保するための別の基準が存在します。ウェブにおいては、これはウェブコンテンツアクセシビリティガイドライン（WCAG）2への準拠を意味します。

PDFからHTMLへの変換における課題

目標が明確になったので、フォーマット間の変換（このケースではPDFからHTML）について考えてみましょう。他のフォーマットや言語間の変換と同様に、機能が直接対応していない場合は妥協点を探る必要があります。また、入力PDFの品質が低かったり、アクセシビリティ機能が使われていない場合、出力されるHTMLの品質も低下します。

ソースフォーマットがPDFである点は特に重要です。PDFファイル形式は、もともと印刷用として開発され、その後、画面表示用の形式としても普及しました。このファイル形式は、文書が表示される場所に関係なく同じ見た目を維持できるように最適化されていますが、アクセシブルな形式でコンテンツを保存する面では十分ではありません。例えば、私たちの目にはタイトル、段落、表として認識される部分も、PDFの内部では単なるテキストの行と座標による描画形状として保存されているのです。

PDFファイル形式は、ドキュメント構造へのタグ付けなど、アクセシビリティを大幅に改善する機能を備えて進化してきました。しかし、すべての文書にこれらの追加情報が含まれているわけではありません。古い文書では特にその傾向が強く、新しい文書でさえも追加情報なしで作成されることが多くあり、アクセシビリティが制限される結果となっています。また、PDFは固定レイアウト形式であるため、フォントサイズや行の高さの変更といったアクセシビリティ機能の一部が使用できません。さらに、文書作成者が読みづらいフォントや低コントラストの色を使用した場合、機能の有無に関わらずアクセシビリティの低い文書となってしまいます。

BuildVuの出力結果のアクセシビリティ法への準拠については、ビューア自体と文書内容という2つの観点から検討する必要があります。

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

BuildVu 2025.04リリースでは、IDRViewer（特に「Complete」UI）をWebコンテンツアクセシビリティガイドライン（WCAG）2.0の要件に準拠するよう改良しました。これは、ADA、EAA、AMAなどの法規制で認められた標準規格です。

「Complete」UIは以下の機能を備えています：

• 色のコントラストに関するガイドライン（WCAG AA）に準拠
• キーボードによる完全な操作が可能
• スクリーンリーダーなどの支援技術に対応

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

このドキュメントのコンテンツは、スクリーンリーダーで読み取り可能な実際のテキストを使用している場合に限り、アクセス可能となります。現在のBuildVuは、ドキュメントに見出しや段落などのタグ付けが存在する場合でも、それらを活用していません。この機能の有効活用について検討を進めています。

変換後の文書のアクセシビリティは、元のPDF文書がアクセシビリティ基準を満たしているかどうかに依存します。アクセシビリティに準拠していないPDFを、準拠したHTMLに変換することはできません。

ただし、PDF文書が適切に構成され、アクセシビリティ基準を満たしている場合、変換されたHTMLはスクリーンリーダーなどの支援技術で問題なく利用できます。