個人的に必要なアクセシビリティ

この記事は個人的に必要だと思ったアクセシビリティに関する内容を書いていきます。断りとして私個人が専門家であるわけではありません。その上で内容をご覧ください。

## アクセシビリティで大事なこと


アクセシビリティで最も大事なことは次の2つです。

1つ目は知ることです。

アクセシビリティに関することを全て知るのは難しいですが、アクセシビリティを知らない人が作った場合、アニメーションや配色が障害を持つ、人にとって使いづらいことや下手をしたら障害を持っていない人でも使いづらいことがあります。

知らないと対策の使用がないのです。

2つ目は最悪を避けることです。

アクセシビリティに取り組むことで、最も回避しなければいけないことはアクセシビリティ災害です。不適切なラベルをつけると混乱を招くことや情報収集を諦める可能性があります。特に ARIA-LABEL は絶大な力を持つため間違ったラベルを貼ると意味を誤認しかねません。
それを避けるだけでも重要です。

## 個人的に不要だと思うアクセシビリティ内容

### 文字を大きくする機能(大中小から選ばせる)、音声読み上げなどのプラグインなど

文字を大きくする機能は高齢者/老眼の方にとって必要と思うかもしれません。

ただ、私が見る限り「文字が大きくなる機能」で、大きな文字を選択しても大して、文字の大きさが変わらないのを目にします。
その機能はほぼ役に立っていません。

私は近視なので小さな字が見にくいです。文字を大きくするときは思いっきり大きくしたいです。

アクセシビリティ全体に言えますが、全てのユーザーの希望を満たすことはできません。が、文字大きくする機能で弱視者が役に立つほどの機能を提供しているのは見たことがないので不要です。

そのような人はOSのデフォルトフォントサイズを115%や200%に設定しているのでフォントサイズを固定ではなく相対化すること、文字を拡大してもオーバーフローしてレイアウトが崩れないかどうかなどを検証したほうか有意義だと思います。

より良い方法は、任意の大きさまで上げられるようにすることです。

音声読み上げプラグインに関して言えば、そもそもスクリーンリーダーを使用してウェブページを閲覧している人にとって、この機能は二重に提供されることとなるので全くいりません。

全てのプラグインの機能が不必要であるかというとそうでもないと思っています。

例えば配色を変更できる機能やアニメーションを無効化する機能、ハイコントラストモードは役に立つ可能性が高いと思います。

理由としては、まず一般ユーザーでもダークモードを利用したい人はいるでしょうし、暗いテーマを好む人、明るいテーマを好む人、それぞれにカスタマイズできることは良いことです。

アニメーションの無効化は、アニメーションが目障りに感じる人やスペックの低いコンピューターを利用している人にとって恩恵を受けるかもしれません。

最後にプラグインが不必要な、最大の理由はモバイル端末においてプラグインのボタンが画面の上部を占領してしまうことです。

今は多くの人がスマートフォンを利用するので、モバイル環境で実際に見えるスペースが減少するのは不便だと言えます。
障害を持つ人に配慮しても大多数の人に取って不便を強いるならそれはアクセシビリティとは言えません。アクセシビリティ≒ユニバーサルデザインの信念のだれでも使いやすいの考えに反するからです。その最たる例だと思うのは、Googleマップの配色変更でしょう。非常に多くの方が見にくいとの意見を出しています。変更直後はそのような意見が出やすいですが、配色を複数用意することも一つの解決作のように感じますがそうなっていません。

---

ここからは、必要だと思うことです。


## リダイレクトやポップアップ、新しいページを何度も作らない

日本国の行政システムでは、よくリダイレクトやポップアップをやたら使うし増やし続けますがやめていただきい。

ログインのためのリダイレクトは、理解しえるがポップアップ形式でフォームを起動させることやFAQを新しいタブでするのは、ITリテラシーの低い人にとって非常に混乱を招くと私は考えています。(JSの仕様で仕方ないのかもだけど…)

理由として、まずIT苦手な親のスマホのブラウザを見ると95個タブが大量にあるということが日常。
新しいタブで開いたことに気づかず戻るボタンが使えないと思い込むといったこともある。

以上の点から ポップアップの乱用は ITリテラシーの低い人にとって混乱を招く可能性が高くなるので避けてほしい。

## hover だけでなく focus 時にもアウトラインなどの選択の装飾を

キーボードで操作していると どのボタンにフォーカスがあたっているのかわからないデザインがあります。CSSでは、:focus も指定しましょう。キーボードだけで操作する人にとっても利用しやすくなります。

特に 繰り返し入力、送信をするフォームなどではキーボードだけで操作すると早くなりますからそのようにする人がいるので実装しておくと無難です。

私が見たひどい例は 広告で広告を閉じるボタンにはfocusの装飾がなく変化しないものの広告のリンクボタンは装飾がある例です。

## 一貫したデザインの重要性

国のフォーム(私の例は、確定申告のフォーム)を見ると いかにも古い感じのフォームと現代的なマテリアルデザインに近いフォームが混ざっている。

正直同じ機能でもデザインが違うと 間違えたのかと思ってしまう。
増して、ITリテラシーの低い人やUIの利用経験や訓練の低い、推測能力が低い年配の方々には間違いなく混乱を起こす。

なので、 デザインは全ページで統一してください。特設ページでもヘッダーは共通にしましょう。
ランディングページまで、統一しろとまでは言いません。

## パスワードの文字の制限をつけないでください！

パスワードを複雑にすることを要求する割に15文字程度しか入力できないや記号不可のパスワードフォームがたくさんたある。これは、パスワードマネージャーで作ったパスワードを受け入れてもらえないということが起きる。
また、記号なしでアルファベットと数字で12文字までの組み合わせは、総当たりでは将来的には不安が残る強さにしかならない。パスワード強度診断では弱いと出る。直ちに危険が生じるとは言えないが、AIを使った総当たりパスワード解析(辞書攻撃の効率化をAIが行う)などすると容易なること、パスワードが短いかつ記号必須だと組み合わせが大幅に減り攻撃者が優位になるので誤った安心感でしか無い。

パスワードハッシュ化 の考え方からして文字数制限は不要です。(バッファーオーバーフロー攻撃などを考えると256文字上限が望ましい。少なくとも64文字は入れられなければだめだ。)

## スクリーンリーダで広告とコンテンツが区別可能

ブログ記事には、本文の途中に広告を掲載することがあります。

明示的に広告の始まりと終わりがわかると飛ばしたりしやすいですが、広告と本文が似通っている場合 SEOの記事で SEOの広告など 混同する可能性があります。

ただし、広告をスクリーンリーグに読ませない(アクセシビリティツリーから削除する)はやりすぎです。広告にもセールの情報など有益な情報もあります。スクリーンリーグでブラウジングする人にこれらの情報が入手できなくなるのは差別的とも捉えかねません。

## 自動的に切り替わる写真スライドショーは停止できるようにしてください

これは、単純に見たいと思った情報を見たいときに戻れなかったりすると困るからです。

あと読む速度は、人それぞれです。自動的に切り替わるということはそれを妨げることになります。

## フォーカスの順序を意識して下さい/スキップリンクを採用して下さい

Cookieポリシーの同意の欄、無人チャット、広告などすぐに消したいことがあります。
そういったHTML 要素はDOM後半に追加される関係上メインコンテンツの終了後にしかフォーカスが当たらなかったりします。WCAGではキーボードトラップ無しを要求していますがそれに加えてキーボードで到達するのにとてつもなく時間のかかる要素はスキップリンクで行きたい場所へ行けるように作ってもらいたいです。

## 追記: 取り消し不能かつ操作ミスが致命的な処理の二重確認

例えば次のような、処理は 二重確認(削除ボタン+ポップアップ型モーダルウィンドウ)が必要でしょう。

 - アカウントの削除
 - メッセージの削除
 - セキュリティを低下させる処理(ファイヤーウォール無効化など)
 - 金銭的損失が発生する可能性のある処理

とりわけ、不可逆的な処理は 二重確認で削除警告を行います。特に Github などはパスワード確認+削除ボタン+削除するプロジェクト名などを入力させます。

Google chrome や firefox は ブラウザのデベロッパーツールのコンソールでクリップの貼り付けを明示的に許可する操作("Allow pasting"/"貼り付けを許可"と打たせる)しないとソースコード実行をブロックします。セルフXSS対策として導入された模様です。

一方で、ゴミ箱へ移動するなど誤操作が致命的にならない処理は そこまで求めません。

削除する対象の名前を入力させることは非常に有効だと思います。人間は、愚かなので間違えます。
具体的には、 [GitLab の従業員はセカンダリデータベース不具合修正のために初期化して同期させる比較的侵襲性の高い、不具合修正を試みたときプライマリデータベースの初期化を間違って行いました。](https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/)これは、トラブル解決の際に視野が狭まったために単純ともとれるミスを犯したと分析しています。

---

今後追加するかもしれません。
気軽に書いたものなので、いやこの部分は違うよ、私はこう思うなどかわあれば気軽にコメントしてください。
多くの人意見を取り入れて、より多くの人にとって使いやすくすることがアクセシビリティ改善の近道です。