アクセシブルな公共データ設計をコードで語る：データの「見える化」だけじゃ足りない理由

どうも〜おかむーです！今日は公共データの“アクセシビリティ”をエンジニア視点で掘り下げますよ〜

• 政府APIやCSVは増えてるけど、障害のある人に届く形で公開されてないケースが多い
• 要するに「機械可読」だけじゃなく「誰でも使える」メタデータとエンドポイントが必要です
• 技術的にできる改善（メタデータ拡張・自動テスト・公開API）を具体提案します

結論

アクセシビリティは見た目の配慮だけじゃなく、データとAPI設計レイヤーで担保する必要があります。要するに、データセットに“代替情報（alt）”“フォーマット優先順”“機械判定可能なアクセシビリティメタ”を付けて、公開パイプラインで自動検証するのが最速で効果的です。

レポート本文

背景：いまの状況（資料参照）

政府の行政APIカタログ（https://api-catalog.e-gov.go.jp/info/ja/apicatalog/list）やe-Govポータル（https://www.e-gov.go.jp/digital-government/api）を見れば、API化の取り組みが進んでいるのは明らかです。ただ、データそのものがPDFに埋め込まれていたり、CSVに必要な代替テキストが欠けていたりと、アクセシブル配慮が抜けているケースが散見されます（例：病院データCSVの公開例 https://www.digital.go.jp/.../xxxxxx_hospital.csv を参照）。

エンジニア的に言うと、これは「メタデータ不足」と「公開ワークフローの検証不足」の問題なんですよね。

問題点を技術的に整理する

• フォーマット偏重：CSV/JSONはあるけど、図表の代替テキストや音声用トランスクリプトがない
• メタデータ欠落：DCATやschema.orgでアクセシビリティ情報を表現していない
• 検証パイプライン不在：CIでアクセシビリティ項目を自動チェックしてない

要するに、データ公開は「ファイルを置く」フェーズで止まってるんです。

実装提案：機械可読アクセシビリティを設計する

1) データセットメタにアクセシビリティフィールドを追加

• 推奨スキーマ（JSON-LD / DCAT拡張）例（これ見てくださいよ）:

{
"@context": "https://schema.org/",
"@type": "Dataset",
"name": "自治体施設データ",
"accessibility": {
"accessMode": ["text","visual"],
"accessModeSufficient": ["textToSpeech"],
"altTextAvailable": true,
"altTextFields": ["image_alt","chart_description"],
"transcriptAvailable": true
}
}

要するに「このデータセットは目や耳に障害がある人向けにどんな代替情報を持ってるか」がすぐわかるってことです。

2) APIでのアクセシビリティ自己宣言エンドポイント

• 例: GET /datasets/{id}/.well-known/accessibility → JSONで状態を返す
• これで自動クライアント（支援ツールや検索エンジン）が判定できます

3) CIパイプラインでの自動テスト（GitHub Actions例）

• チェック内容例：altText列の有無、PDFに埋め込まれた表のCSV化、有効なlang属性
• Pythonでの簡易チェックスニペット（これもコード書く人ならわかると思うんですけど〜）:

import csv

def check_alt_column(path):
with open(path, newline='') as f:
r = csv.DictReader(f)
return 'image_alt' in r.fieldnames

print(check_alt_column('xxxxxx_hospital.csv'))

4) フロントの配慮：WCAGに沿ったデータビジュアライズ

• グラフには必ずテーブル版を用意
• 機械可読なCSV/JSONに加え、音声向けの要約（short/long）を提供

政策評価との接続

総務省のオープンデータ戦略（https://www.soumu.go.jp/.../opendata03.html）で言及されている標準API規格に、このアクセシビリティ拡張を入れると運用しやすいです。政策KPI（例：公開データのアクセシビリティ対応率）を定義しておけば、数値目標と実績のギャップも定量的に追えます。

実運用の注意点

• ライセンスと個人情報は別レイヤーで検討する（アクセシビリティ情報は公開の範囲で）
• 小さな自治体には負担になるので、テンプレートとツールを提供するのが現実的

まとめ

アクセシビリティは単なるUIの話じゃなく、データ設計・API・公開ワークフロー全体の話です。要するに「誰でも使えるデータ」を目指すなら、メタデータ拡張、自己宣言API、CIによる自動検証の3本柱を入れていくのが現場で効くアプローチです。

おかむーから一言

テクノロジーで社会をアップデートするって言うなら、最初にやるべきは“誰でも使える形で出す”ことです！小さなチェック項目をコードに落とし込んで、公開フローに組み込んでいきましょう〜