パターン１
「この画像の代替テキスト『画像1』『画像2』はあんまりです、何とかなりませんか？」
「画像をDBで管理しているし、登録するシステムにも代替テキストを入れる項目がないので大改修になるんですよね」
パターン２
「この画像の代替テキストありません、何とかなりませんか？」
「このシステムは XXX というプラットフォーム上で作ってるのですけど、XXX にはそんな機能がないので、プラットフォームを直さねばならないです。そんなことできません。」
というようなこと。さらに言うと、「長い説明」が必要な画像でもあったら、さらに困難になります。
このような問題は、システムを設計するときにあらかじめ代替テキストについて考えていない、あるいは、開発のプラットフォームを選択するときにアクセシビリティへの対応具合を確認していない、というのが原因です。よく言われることですが、「アクセシビリティは企画段階から対応すべし」という原則を守らないことが、システム開発の最後の段階で響いてきて、開発の手戻り、コストを増大させる典型的な例でしょう。HTMLを修正すれば済む話ならば頑張ればできるのでしょうが、システムの変更となるとデバッグや機能試験などの工数も増える一方です。開発者の視点で見れば、できれば今からシステムを変更したくないというのは当然のことでしょう。納期も心配です。DBを変更するとなると簡単ではありません。代替テキストを保持できるフィールドを追加するだけで済む、というのは運の良いほうです。さまざまなコードに影響を及ぼして、別の場所に新たなバグを発生させてしまうということも十分にある話。
さて、そのような問題を解決するためにはどうすればいいのでしょうか。
- システムがオリジナルの設計である場合、画像、動画、音声をDBで管理するときは、代替テキストやタイトルをつけられるようにDBを設計しておく。また、登録、管理画面で入力できるようにしておく。
- プラットフォームを使う場合、そのプラットフォームがアクセシビリティに対応しているか確認しておく、場合によってはテストしておく。
というのが、その解決策です。プラットフォームを使うというのは現在のWebシステム開発では当然でしょうから、プラットフォームがどこまで対応できるかを見定めておくことが必要になります。
DBと関係しないところでも、プラットフォームが用意しているテンプレートやJavaScriptが悪さをすることも多いです。例えば、マウスでドラッグ＆ドロップしないと使えない、画面サイズを変更的できない、というのはよく経験することです。
プラットフォームにアクセシビリティ対応を追加するとなると、プラットフォームに手を入れることになります。しかし、そうするとプラットフォームのバージョンアップ時にまた変更とテストの工数がかかることになることを頭に入れておきましょう。
という
版の電子書籍がタダで 
から買えるようになっています。中身は VoiceOver での Kindle アプリの使い方です。日本語版もあるといいな。だれか出しませんか？
By Katie Cunningham の翻訳「アクセシビリティハンドブック」が出ています。米国リハ法508条を踏まえたものですが、アクセシビリティの入門書としては役立ちそうです。探してみましたが、日本語版は電子書籍のみのようです。