ウェブアクセシビリティとは、「ホームページの利用しやすさ」のことです。国立国語研究所ではアクセシビリティを「利用のしやすさ」と言い換えるように提案しています。
ウェブアクセシビリティの基本3要件は、「見出しの使用」「画像に代替テキスト」「読みとばし機能」です。この3つだけでもまずはクリアすることで、ウェブの使いやすさは大幅に向上します。
★2005年11月25日の「ウェブ アクセシビリティ導入のポイント」（「視覚障害者と共に歩む会ハーモニー」ちよだプラットフォームスクウェア）で発表したものです。
ウェブ アクセシビリティのページ
誰でもわかる！パソコン用語 マイクロソフト
スタイルシート用語集Mitsue-Links
とほほのスタイルシート入門（基礎知識）
ハイフン（-）とアンダーバー（_）は混同しやすいので避ける；kb_mn kb-mn。
一般にキーボードで操作できるページは音声ブラウザでも正しく読みあげられる。
構造のための要素や属性と、表現のための要素や属性が分離されていない場合、自作スタイルシート利用者には、スタイルシートが正しく適用されない。
とくにマークアップ言語を次のような構造のために用いないようにする。
スタイルシートには3通りの適用の方法がある。
もともとHTMLはテキスト表現のために考案されたもので、見栄えを定義する機能はなかった。今後はXHTML＋CSSがウェブサイト制作の主流になっていく。
また、一般のブラウザや音声ブラウザの中には、スタイルシート未対応なものがあり、スタイルシートで、表示順序を指定しても、音声ブラウザで反映されないことがある。スタイルシートの指定を無効にしても、内容が充分に把握できるようにする。positionやfloatなどはとくに注意する。
使用言語が日本語（ja）の場合には、下線部のように記述する。
<html lang=”ja”>
<meta http-equiv="content-type" content="text/html;
charset=Shift_JIS">
charset属性（文字符号化方式）には、Shift_JISの他にiso-2022-jpなどがある。
ページ内で他の言語を使用する場合には、<span lang="en">、<p lang="en">、<q
lang="en">、<div lang="en">などと指定することが望ましい。こうすると音声ブラウザでは、指定言語に従った発音をする。
とくに自治体のサイトは、高齢者、初心者、外国人などのさまざまなユーザーが利用するので、使用言語には細心の注意が必要である。
html文法に準拠した記述をおこなうのは基本中の基本である。html文法に準拠した記述であるかどうかは、「Another HTML-lint gateway」などのチェッカーでチェックすることができる。
Another HTML-lint gateway 簡易版html文法の採点
ファイルサイズ採点 ファイルのサイズと評価
ColorDoctor ：無償でダウンロード色のアクセスビリティをチェック。富士通
ページテンプレートをつくっておくと、以降効率的なページ制作が可能になり、また新規ページの作成も容易となり、アクセシビリティも確保しやすくなる。
ユーザーの閲覧環境は、閲覧マシン、画面解像度、ディスプレイの表示色数、OS、ブラウザ、ブラウザのカスタマイズ、回線速度、支援技術の種類など多様である。極力どのような環境でも正しく表示されるような設計をする。
html文法に準拠した記述をおこなうのは基本中の基本である。html文法に準拠した記述であるかどうかは、「Another HTML-lint gateway」などのチェッカーでチェックすることができる。（注7：Another HTML-lint gateway）
<head>区間にキーワード（keywords）を入れておく。キーワードは下のように半角カンマで区切る。
<meta name="keywords" content="図解術,辞事典,東南アジア,ウェブアクセシビリティ"/>
<head>区間にはページ概要（description）も入れておく。ページ概要は全角100文字程度を目安とする。
<meta name="description" content="桑原政則オンラインはコラム、図解術、健康、沖縄、東南アジア、アメリカ、検索術、コンピュータ（ワード、エクセル）、ホームページ作成、総合情報のサイトです。" />
ページタイトルは画面上端のタイトルバーに表示され、次のような重要な役割がある。
タイトル名が不適切な場合には、本文の内容が把握できない。タイトル要素が未記入だとURLが表示されてしまい、音声ブラウザの利用者は内容を把握できない。タイトル名は通常は、「<title>桑原政則オンライン：ウェブアクセシビリティのページ</title>」のように、「サイト名：ページタイトル」あるいは「ページタイトル名：サイト名」が望ましい。字数は全角30字までを目安とする。
スプラッシュページは、訪問者にとっては余計なステップなので避ける。スプラッシュページとは、Flashなどアニメーションだけが表示されるトップページのことで、実質的なトップページはこの次のページとなる。訪問のたびに飾りページをみせられるとビジターはうんざりする。スプラッシュページ以外でも、アイキャッチ重視の単なる装飾目的のコンテンツを好まないユーザーは多い。とくに行政サイドにおいては、平凡でも使い勝手のよいサイトを心がけるべきである。
ページのファイルサイズは100キロ以下、画像サイズは、50キロ以下を目安とする。画像には、width属性とheight属性を指定する。表（テーブル）の入れ子を多用しない。横罫線（<hr>要素）、表、フレームは相対単位で指定する。これによりインターネットエクスプローラの場合、[表示]―[文字のサイズ]で変更が可能となる。
ウェブは、検索エンジンを利用すれば、東京から沖縄、沖縄からサンフランシスコへとサイトの中のページに一気にジャンプできる地図のない世界のようなものである。いわば建物の玄関を通さずに、建物の中の部屋へ直接入ることになるので、ユーザーは自分の位置を見失いがちである。そのため「（現在位置）：○○のトップページ＞ 製品一覧＞ 製品の概要＞ 詳細仕様」などと「Yahoo!カテゴリ」などで採用されているように現在位置や階層構造を示すパンくずリスト（breadcrumbs）を各ページに表示する。
パンくずリストとは、『ヘンゼルとグレーテル』で迷子にならないようにパンくずを落としていったことに由来する。
音声ブラウザでは「＞」などの記号を無視する傾向があるので、記号と文字の間にはスペースを入れる。通常、パンくずリストは、[トップ] [使い方ガイド] [コラム] [サイトマップ]）などといったメニュータブ（ナビゲーションバー）の下に置く。
縦に長すぎるページは、上下のスクロールが多くなりすぎて、ユーザーに負担をかける場合がある。とくに弱視者や上肢障害者は、スクロール操作が困難な場合がある。ページの縦幅450ピクセルを1画面として、3画面分までを最長とする。これ以上長くなりすぎる場合は、「ページトップへ」などとページ内ナビゲーションを用意する。 ざっとながめるニュース、エンタメ（エンターテインメント）などのページは短く、エッセイ、マニュアルなどのテキスト主体のページは高くする。テキストページの場合は短すぎると、印刷がかえって煩雑になる。
メニュー項目の数が多すぎると、音声ブラウザ利用者は、すべての項目を参照するまでに時間がかかる。項目数は7±2を目安とし、多くなるときはグルーピングする。深さは4階層までとする。サイトマップを書物の索引とすれば、メニューは目次である。目次の各章は7節以内が望ましい。
なお行政サイドでは、メニューやサイトの分類を制作側からみてわかりやすいカテゴリに分けてしまう傾向がある。 JavaScriptを用いてプルダウンメニューを作成する場合には、キーボードでも操作できるように、実行ボタンを付ける。プルダウンには、ポイントしているときだけ表示されるもの、離しても表示されるものがあり、また選択しクリックして実行できるものと実行ボタンをクリックして実行されるものがあり、統一した操作がないのが現状である。
音声ブラウザなどでは、左からよみあげるのでメニューは左側に置く。あるいはメニュータブとして上端に置く。広告など見なくても不都合がおきないものは、右欄に置く。
ページ数が多い場合にはトップページに検索ページへのリンクではなく、検索ボックスをおく。ボックスは全角10字以上入力できるサイズにする。サイト内検索機能があれば、音声ブラウザ利用者は、音声読みあげにかかる時間を短縮し、必要な情報にすばやくアクセスできる可能性が高い。
検索には、検索ボックスの他にメニュー、パンくずリスト、サイトマップ、リンク集が利用される。
コンテンツの多いサイトの場合、トップページなどにサイトマップへのリンクを設ける。 サイトの分類項目としては、50音別、地域別、用途別、商品名別、年代別、ターゲット別などがある。サイトマップはすばやく検索するためのものだから、画像は多用しない。ページ数の少ないサイトの場合は、サイトマップの代わりにページ共通のメニューバーを設けるのも一法である。
ページ共通のメニューバー、パンくずリストなどは、音声ブラウザの使用時にスキップできるよう<id>属性で読みとばし機能を設定する。あるいは透過gifに「alt="本文へ"」などとする。こうすると「本文へ」項目でEnterキーなどを押すとメニューなどをスキップして本文へ入るようにする。 全盲者は、次のようにいろいろの操作で読みとばしながら目的の箇所へたどりつく。
更新日の記載で情報の鮮度を明示することができ、また誤解を防ぐことができる。制作者側の備忘録にもなる。日付は「2006年10月17日」などと「年月日」入りで記述する。
ページが自動的に更新されると、音声ブラウザ読みあげ時などには、再度最初から読まなければならなくなることがある。また更新を認識できないことがある。
やむをえず更新する場合は、あらかじめ「このページは10分ごとに最新情報を更新します」などとそのことを告知しておく。ただし、URL変更の場合のリダイレクト（ページ転送）のためだけに用意されたページからの自動移動は許される。この場合には、自動移動未対応ブラウザに配慮して異動先URLを記載しておく。
必要な場合には、日本語以外の言語のページも用意し、基本情報やその他の情報を提供する。
ステータスバーには次の理由で制作者側の作成した情報を表示しない。
ページのURLを変えると、ユーザーはリンクを貼っておいたりブックマークに登録しておいたページが削除されていると、目的のページにアクセスできない。ページはできるだけ移動、削除、リネームしない。
移動、削除した場合は、「このページは下に移りました」「このページの最新情報は○○をごらんください」などと補足情報を入れておく。
ページのURLを変えると、ユーザーはリンクを貼っておいたりブックマークに登録しておいたページが削除されていると、目的のページにアクセスできない。ページはできるだけ移動、削除、リネームしない。
移動、削除した場合は、「このページは下に移りました」「このページの最新情報は○○をごらんください」などと補足情報を入れておく。
文字のフォントは、背幅が一定のゴシック系を使用し、アンチエイリアスをオフにする。画面拡大の場合、明朝体では線がギザギザとなる。
フォント（書体）関連の指定はCSSなどのスタイルシートで下の要領でおこなう。スタイルシートではフォントへの対応状況が安定している。こうすると効率的でメンテも楽である。ユーザースタイルシートでフォントを変更できる。
フォント（書体）関連の指定はCSSなどのスタイルシートで下の要領でおこなう。スタイルシートではフォントへの対応状況が安定している。こうすると効率的でメンテも楽である。ユーザースタイルシートでフォントを変更できる。
注釈記号に「＊」「※」などは用いない。音声ブラウザでは意味不明となりがちなので「注1」などと記述する。絵文字（ASCIIアート）は文字や画像に置き換える。「○」「×」は「○（まる）」「×（ばつ）」のように記述する。あるいは、画像としalt属性で「まる」「ばつ」を指定する。
「①、Ⅰ、㍍、㎞、㍻」などの機種依存文字は使用しない。マッキントッシュでは、「①」は「（日）」に、「Ⅰ」は「（特）」に変換されてしまう。別の文字に置き換えて表示するか、画像で表示する。半角カタカナは使用しない。「公務員Ⅱ種」などの機種依存文字の使用は官庁に多く見られる。
特殊語、外国語、専門用語、省略語、職場用語、難語、固有名詞を乱用しない。辞書にない用語は音声ブラウザで正しく認識されないことが多い。
文字の装飾を使用している場合、音声ブラウザは装飾の有無を読みあげない。<s>要素、<strike>要素、<del>要素、text-decoration: line-throughなどの文字装飾を使用する場合、その意味をテキストでも併記する。取り消しを示す<s>要素、<strike>要素は、使用しない。
音声ブラウザは、単語内にスペースや改行が入っていると、意図どおり読みあげない。「日 本」は「ひ ほん」と誤読されるおそれがある。行政サイドに多い。
音声ブラウザ用に次の点に配慮する。
数字は、ローマ字とともにすべて半角文字で表記する。（このやり方をはやくデファクトにしたいものです。）
見出しタグは重要である。音声ブラウザでは、見出しタグはジャンプのためのランドマークである。見出しタグが適切に用いられているページは、快適なブラウズができる。見出し1、見出し2などで音声を変えたり、サウンドをならしたりする。
見出しをフォントサイズや色などで代用すると混乱といらいらがおきる。見栄えは極力スタイルシートでおこなう。
1ページに<h1>要素は1つとする。<h1>は、書籍では「章」、<h2>は「節」、<h3>は「小節」にあたる。
ディスプレイのテキストは、閲覧範囲が狭く、読むのに時間がかかり、目が疲れやすく印刷物より可読性が低い。そのため原稿作成の段階からわかりやすさや表現に注意する必要があある。
下では1行が26字程度にしぼられています。
cf. もしもしＱさんＱさんよ
インターネットでは文の可読性が印刷物よりも低いため、ひとつの文には、ひとつのトピックだけを記すようにします。
パラグラフのあとは1行あける。字下げはしなくてもよい。1パラグラフは10行以内におさえる。
パラグラフ（文章の１つのまとまり）のあとは、見やすくするために空白行を入れる。
インターネットの文書では、パラグラフの始まりで字下げはおこなわず、パラグラフ間に空白行を入れます。
Wordで、字下げを避けるには次のようにします。
[ツールメニュー]―[オートコレクトのオプション]―[入力オートフォーマット]―[Tab…：チェックをはずす]
（この文書では、紙媒体へ移すことを予定しており、字下げをおこなっています。）
ディスプレイのテキストは、読みにくく、目が疲れやすく、印刷物より可読性が低い。そのため情報量を少なくする。
項目が3項目以上の場合には、箇条書きにする。
箇条書きには、<li>などのリスト要素を用いる。
リンクのあるテキストは、アンダーラインを消去しない。リンク箇所以外では、青色や下線を使わない。また本文の一部分だけの色やサイズを変更してあるとリンクと勘違いされるおそれがある。
リンクのある画像は、枠をつけたり、影をつけたりするなどしてボタンに見えるようにする。写真のような画像のリンクや下線のないテキストリンクの場合、リンクの存在を見落とすことがあるので注意する。
リンクテキストでリンク先を推測できない場合、とくに上肢障害者は必要なリンクを選択することが困難である。音声ブラウザにはリンク部分だけの読みあげ機能があるので、例えば「ここ」などと指示代名詞だけにリンクを付けた場合意味不明となる。
「詳細はここをクリックしてください」ではなく、「詳細はここをクリックしてください」とする。「より詳細な説明は、クリックしてください」のようにリンク範囲を広げることも効果的である。画像文字やアイコンは、ボタンの機能を正しく推測できる内容にする。
別ウィンドウには次のような問題がある。
ただし、次の場合や新しくウィンドウを開いたほうが内容を参照しやすい場合は、この限りではない。
画像にリンクをつけた場合は、alt属性によりリンク先の内容がわかるような説明を付加する。画像の説明は副次的なものである。画像の内容を説明する必要がある場合は、「この画像は川越からの富士山です。2005年11月」などとテキストで記述する。リンクのある画像の場合、alt属性が指定されていないと、音声ブラウザは、リンク先のURLを読みあげてしまう。
本文中にリンクテキストを埋め込むと元の文章の閲覧と操作を断ち切ることになり好ましくない。またリンクを読みとばされるおそれがある。本文とは別に後方にリンクだけをまとめた方が視認性が高まる。
適度なリンク範囲を確保する。「□リンク先A」ではなくて、「□リンク先A」などと文字列全体にリンクを設定する。隣接するリンクの間に「□リンク先A ｜ □リンク先B」などと誤操作しないように充分な間隔を設け、リンクの間に縦線などを入れる。
上肢障害者は微妙なマウス操作が困難である。テキストリンクが縦に並んでいる場合は、行間を適宜広く設定する。
リンクテキストは長すぎないようにする。リンクテキストは短くても1行に1項目とし、1行ずつ縦に並べる。音声ブラウザではリンク箇所のみを読みあげることもできる。 リンク途中で改行すると混乱を招く。
下のように行の途中で改行すると、音声ブラウザでは「お申し込み」で一旦停止するので「問い合わせフォーム」は別リンクであるとの誤解を与える。
内容について納得いただけましたら、お申し込み・
問い合わせフォームからお願いします。
リンク切れなどのエラーメッセージには、状況を説明し、解決策を提示する。また「トップページへもどる」などのリンクを設ける。
リンク集があれば、必要な情報にすばやくアクセスできる蓋然性が高い。リンク集にはリンク数が充分にあり、項目の選定が適切である必要がある。
データのダウンロードを指示する場合は、「○○製品カタログ（zip形式: 250KB）」などとファイル形式やファイルサイズを明記する。ファイル形式やファイルサイズの明示がないと、ユーザーはデータが自分のインターネット環境に応じたものかどうか判断できない。また所要時間の予測もつかない。ファイルサイズは100キロ以下なら明記しなくてもよい。
アプレットやプラグインが必要なページでは入手方法を明記する。ダウンロードページへのロゴは広告と間違えられやすく、またクリックできることに気付かない場合があるので、テキストでの説明文をそえる。アプレットやプラグインのダウンロードにはひとつ前のバージョンを推薦する方が無難である。
表の上部に<caption>要素で表題を指定する。指定がないと、読みあげ中のテキストが表であることが認識できないことがある。<th>要素で項目の見出しであることを明示する。複雑な表には<summary>要素で要約や「列は商品、行は売り上げ」といった表の構成を記述する。
音声では、表の内容を理解することが困難である。表の代わりにリストを使うことをまず検討する。
音声ブラウザは表を左上から右下に1セルずつ読みあげるので、行や列の関係がわかりにくくなる場合がある。次の点に注意する。
表組みの要素をレイアウトのために使わない。（実は表をレイアウトに使うことが蔓延している。レイアウトテーブルには<th>要素がない。データテーブルには基本的に必要である）。
レイアウトはXHTMLとスタイルシートでおこなうことが望ましい。表の要素や属性を使用する場合は、読みあげ順序を考慮する。とくに、表をフォームに使用する場合は、ラベルとコントロールが対で順番に読みあげられるようにする。ラベルとはコントロールに対応するテキスト名称である。コントロールとラベルはできるだけ近づける。8倍などの画面拡大ソフトではごくわずかな部分しか表示されないので、離れていると内容を理解しにくい。
フレームの使用は、次の理由でバリアになりやすく最小限にする。
フレームを使用するメリットはほとんどない。一度印刷してみると、ページの一部のみ印刷されたりして、フレームの不便さがわかる。フレームはまた更新手続きが複雑である。外見はフレームに見えるが、フレームでないページも可能である。フレームがどうしても必要な場合には、<noframes>要素内に代替コンテンツを用意しておく。
フレームに表示される各ページに、タイトルを指定する。<title>要素には、フレーム内でのページの役割（ヘッダー、メニュー、本文など）と内容を示す。
文字サイズを大きくすると、文字がフレーム内に収まらない場合があるので、<frame>要素の<scrolling>属性は表示にしておく。<frame>要素の<frameborder>、<border>属性は消去せず、ユーザーが枠を任意に設定できるようにする。
選択肢が多いと、情報が一覧できない音声ブラウザでは、記憶にたよるためユーザーに高い負荷がかかる。ラジオボタンとチェックボックスは、音声ブラウザでは選択肢の数を読みあげないので、選択肢の数をあらかじめ表示しておく。これにより読み飛ばし操作が可能になる。ラジオボタン、チェックボックスでの選択肢の表示順序は、50音順などのユーザーが推測できる一定のルールを元に決定する。47都道府県から選択する場合は、キー入力の方が速い。年月日など、数字を選択するコントロールには、「1980年」など「年」などの単位も記述する。選択項目によっては、「不明」といったDK選択肢も用意する。
ラベル（名称）とチェックボックスなどのコントロールを関連づけ、ラベルをクリックすればコントロールが選択されるようにする。Tabキーによる移動順序を設定する。また、コントロールが7件を超える場合は、<fieldset>要素を使って選択肢のコントロールをグルーピングし、<legend>要素でグループのタイトルをつける。ラベルをクリックしやすい適当な長さにする。
エラーが生じたとき、[戻る]ボタンなどで、前に表示した画面に戻れるように設定し、入力済みのデータを消去せずにそのまま表示する。
送信前に入力内容の確認画面を表示するなどして送信者が確認できるようにする。入力エラー箇所を明確に示す。フォームの送信後に、「申し込みを確認しました」などの適切なフィードバックをおこなう。また受付確認のメールを送付する。電子メールや電話などの別の手段でも情報のやりとりができることが望ましい。
初心者、高齢者、障害者に配慮し、フォームの入力には時間制限は設けない。やむを得ない場合は、「30分以上アクセスしなかった場合自動的にログアウトします」などと時間制限があることを表示する。またセッションに経過時間や残り時間をページ内で表示し、ユーザー側で設定時間を延長できることが望ましい。
音声ブラウザに配慮し、[実行]ボタンや[送信]ボタンは、音声ではわかりづらいのでフォームの最後に表示するなど、入力操作の流れに沿った場所に表示する。
フォームでエラーが発生したときは、赤字だけの表示では色覚障害者にはわからない。サイズを大きくしたり太字にしたりして、目立つようにする。元のページに戻らずにエラー項目のみ再入力すればよいように設計する。見た目のレイアウトとタブ順序が一致するように、<tabindex>要素でタブ順序を設定する。
フォームへの入力操作は、障害者にはとくに負担が多く時間がかかるので最小限にする。コントロールは、適切な初期値をあらかじめ設定しておく。同じ情報は1回入力で可能なようにする。入力頻度が高い住所、郵便番号、名前、電話番号などは、形式を統一する。ハイフンの混乱がないように郵便番号は2つの入力フィールド、電話番号は3つの入力フィールドを用意する。フォームを使わずにメールでも通信が可能なようにしておく。 不必要な情報の収集は個人情報保護の観点からも避ける。年齢、生年月日、職業などの個人情報をもとめられると、敏感なユーザーは不安を覚える。これらの情報をとりたい場合は、フォーム入力後希望者だけにアンケート形式でたずねる。また、これらの個人情報は外部に漏らさないこと、他の目的に使わないことを明記する。
4－1 ビジュアル化
初心者、外国人、認知症の人などにわかりにくいコンテンツは、図・動画・音声などを併設して、直感的具体的に内容を正しく把握できるようにする。
4－2 音声
音声データの内容を、テキストで記述、要約する。聴覚障害者、音の聞こえない環境のユーザーまたはスピーカーのないユーザーは、音声だけで提供された情報を把握できない。警告音の場合、警告をあらわすテキスト情報をあわせて表示する。
音で情報を提示するときは、HTMLファイル内に同等の内容を表示する。ダイアログボックスのメッセージは読みあげやキーボード操作を可能にすることが望ましい。
音声情報が含まれるページでは、自動的に音が再生されないようにする。聴覚障害者は、音の再生を認識できない。音をださないでページを参照しているユーザーもいる。とくにトップページのBGMは使用しない。下位ページにその旨明記して流すのは許される。<bgsound>要素は使用しない。<embed>要素は、使用しないことが望ましい。音声ブラウザでは再生音と、音声ブラウザ音がまざってしまうからである。
音声の重要情報には、再生、停止、早送り、巻き戻しなどの調整をユーザー側に提供する。ただバナー広告や、ワンポイント的なGIFアニメーションには不要である。
4－3 画像
円グラフ、折れ線グラフなどで、色だけで領域を表現すると、障害者、高齢者さらにグレースケールのディスプレイのユーザーには色の違いが識別しにくい場合がある。また、白黒印刷した場合には健常者にも色の違いの把握が困難な場合がある。このような場合には引き出し線をつけ、領域の違いを表現する。また「下の赤ボタンをクリックしてください」など色名だけの表現は避け、「下の赤の中止ボタンをクリックしてください」と色名以外の表現を加える。 グラフやフローチャートを画像で表示すると、内容がわからない。グラフ元の表へのリンクやテキストでの詳細な説明が必要である。これは新たな作業を制作者に強いることになる。
弱視者、高齢者は、明度差が小さいほど読みにくくなるので、文字色と背景色の輝度などのコントラストを確保する。高齢者は白と黄、青と黒の組み合わせの識別に困難な場合がある。緑の背景に赤の文字、黄色の背景に青い文字を読むのが困難な色覚障害者がいる。色覚障害には、赤の視感度が弱い第1色弱、緑の視感度が弱い第2色弱、青の視感度が弱い第3色弱がある。
全日本人男性の20人に1人は色覚障害をもつ。色の違いのみで表現されていないか、モノクロ印刷で鮮明かどうか。ブラウザのスタイルシートをはずして問題ないか確認する。
形や位置のみでの表現は避ける。音声ブラウザや画面拡大ツールのユーザーは「右下のボタンをクリックしてください」だけでは、どのボタンか把握しにくい。この場合には「右下の印刷ボタン」などとし、ボタンにも「印刷」の名称をテキスト文で付記する。
ボタンやラジオボタンなどを独自に挿入する場合は、操作方法が見ただけでわかるように「検索」などの画像文字（画像化した文字）を組み込む。
イメージマップはクリッカブルマップともよばれ、都道府県地図のように画像の複数の箇所にリンクを設定したものである。サーバーサイドではなくクライアントサイドとする。
画像全体に代替情報を示すと共に、ホットスポット（リンク領域）にもalt属性を指定する。さらに地図の脇に別途ハイパリンクテキストを設ける。
便利ではあるが次のような欠点がある。
視覚障害者は、画像の代替情報がない場合、画像の内容を把握することができない。音声ブラウザは、画像（<img>要素）の代わりに、alt属性の内容を読みあげるので、画像にはalt属性で画像の内容を記述する。alt=”image13”といった意味不明の代替テキストは不適切である。検索エンジンではページインデックスを表示するとき、代替テキスト、画像キャプション、隣接のテキストを利用するので、代替テキストは重要である。画像には<img>要素、<area>要素、type="button"である<input>要素がある。
内容理解に関係のない箇条書きのポインタなどの装飾画像や、テキストが併記されているボタン画像には、alt=""と空文字をいれる。重要でない画像の説明をわずらわしいと感じる者もいる。
画像の代替情報にはalt属性、画像近くのテキスト情報、<img>要素の<longdesc>属性の3種ある。longdesc属性をサポートする音声ブラウザは、指定された画像URLの説明文書を「イメージの説明」という文字列から読みあげる。
画像にリンクをつけた場合は、alt属性によりリンク先の内容がわかるような説明を付加する。画像の説明は副次的なものである。画像の内容を説明する必要がある場合は、「この画像は川越からの富士山です。2005年11月」などとテキストで記述する。リンクのある画像の場合、alt属性が指定されていないと、音声ブラウザは、リンク先のURLを読みあげてしまう。
図表やグラフなどの画像の重要情報には、テキストで解説をおこなう。音声ブラウザのユーザーは、図表やグラフなどの画像の内容を詳細に把握することが困難であり、テキストの解説があれば理解しやすい。
画像サイズは50キロ以下を目安とする。
重い画像を複数用いる場合は、縦のいくつかの表にばらばらに入れる。こうすると、最初の画像は速く表示される。重い画像はあらかじめ、【サイズ：210キロ】などと表示しておく。
ウェブページで画像を縮小表示してもファイルサイズは縮小されない。アルバムのように写真を一覧表示する場合には、サムネイルが有効である。サムネイルのリンク先はHTMLファイルにする。リンク先が画像では代替テキストをつけることができない。
弱視者など画面を白黒反転させて表示している者には、画像内の文字や絵を把握することができない場合がある。画像文字の周囲は、透過色にせず、文字が見やすい背景色を使用する。背景色に透過色を指定する場合は、文字情報を縁取るなどする。
無意味に文字を画像にすることは避け、スタイルシートで表現するようにする。画像文字は、ブラウザでサイズや色のコントラストを変更できず、コピーもできない。画像表示オフでは、何の情報も得られない。
やむを得ず、画像文字を使用するときは、文字のサイズは、13ピクセル以上とする。文字の斜体などの装飾は少なくする。文字の背景に画像や写真などを使用する時は、文字のまわりを縁取るなどし、文字を見やすくする。
明滅、点滅や自動スクロールなどの変化を把握しにくい高齢者、認知症者もいる。画面を拡大している弱視者は、動くコンテンツを把握するのは困難であり、明滅領域が画面全体に及ぶこともある。画面変化をおこなうにあたっては、次のことに留意する。
動画には、内容を説明する音声、テキストを提供する。SMIL（synchronized Multimedia integration language:スマイル）をもちいて音声は動画に同期することが望ましい。SMILはW3C策定の言語でオーディオ、ビデオ、テキストなどを同期して統合することができる。テキストは必ずしも動画と同期させる必要はない。動画には、字幕をつけることが望ましい。あるいは代替HTMLを用意することも検討する。
動画の重要情報には、再生、停止、早送り、巻き戻しなどのコントロールをユーザー側に提供する。ただバナー広告や、ワンポイント的なGIFアニメーションには不要である。
PDF（Portable Document Format）は音声ブラウザでは、順番が不同であったり、制限がかけられていたり、テキストが画像であったりするため読めないケースが多い。次の点に注意する。
なお欧文のPDFファイルがウェブ上にある場合、Adobeサイトで即座にHTMLに変換でき、また電子メールでも変換されて返信されるサービスがある。
PDFは次の理由で電子文書のデファクトフォーマットになりつつある。
Flash、PDF、Javaアプレットなどのプラグイン、特定の技術には、次のような配慮が必要である。
「スキップ」リンクがあると、ブロードバンドのユーザーでもスキップすることが多い。Flash版とHTML版を設けておくとユーザーはHTML版を選択しがちである。マルチメディアを乱用するのは考えものである。かといって、専用の代替テキストページを設けることは、更新をなおざりにしがちなので、最後の手段とする。
プラグイン、特定の技術には代替手段を提供する。JavaScriptの場合は、<noscript>要素に代替情報を記述する。プラグインは、<object>要素区間に代替情報を記述する。プラグインを<embed>要素で指定する場合は<noembed>要素に代替情報を記述する。Javaアプレットでは、<applet>要素は使用しないことが望ましい。
ポップアップメニューやポップアップウィンドウは極力避ける。ポップアップメニューはマウス操作が困難なユーザーには非常に使いづらい。また、広告などのポップアップをきらってJavaScriptをオフにしているユーザーも多い。HTML以外のスクリプトの使用は最低限にする。
JavaScriptで前のページに戻る設定にしている場合がある。しかし検索エンジンから入った場合、[戻る]ボタンを押すと検索結果のページに戻ってしまう。JavaScriptでは戻る機能は使用しない。
【追】
ユーザーがウェブに求めるのは、「必要としている情報があって、さがしやすい」ことである。本稿では、次のことを制作者側に強調したい。
以上、総じてウェブコンテンツはアクセシブルになりつつあるとはいえ、なお制作者のウェブサイト側の努力と音声ブラウザ側の技術の進歩がさらに必要である。ウェブアクセシビリティの確保は社会の活性化につながるものである故、さらに一層の発展を望みたい。なお、2005年10月20日付けでJIS X8341-4が制定された。携帯電話、固定電話、FAXなどの電気通信機器に関して配慮すべき要件を規定したもので、ウェブアクセシビリティ確保への要請は一段と高まってきているといえよう。（注10：JIS X8341-4）