レスポンシブデザインサイトのWebアクセシビリティ対応 | クズリーマンのカス備忘録

レスポンシブデザインサイトのWebアクセシビリティ対応

accessibility-logo Webアクセシビリティ
スポンサーリンク

URL分けないでPCとスマホページが1つのソースに同梱されてるやつ。

画面幅が変わるとレイアウトが変わるやつ。

 

の対応。。。

 

 

目的:JIS X 8341-3の準拠

JIS X 8341-3に準拠していれば必ず現実的にアクセシブルなWebサイトになっているかといえばそうとも言い切れない。

ぶっちゃけ、解釈論みたいな部分もあったりするので。

 

 

 

もちろん現実的なアクセシブルなサイトにするのがベストであることは言うまでもないけど、

 

今回の目的はJIS X 8341-3の準拠の方。

気になるポイント

  • 画面幅を変えたときにレイアウトが変わるのはいいのか?(良いと思うけど)
  • スマホサイトはキーボードのみで操作できる必要あるのか?
    • サイトの先頭(最初にTabキー押すと出る)「本文へ」リンクは設置しても意味ないのでは?

 

 

WAIC(ウェブアクセシビリティ基盤委員会)のご意見

これから取り組むWebアクセシビリティ Vol.2 開催報告
2017年2月15日、情報通信ネットワーク産業協会(CIAJ)会議室において、「これから取り組むWebアクセシビリティ Vol.2」を開催しました。 74名の方々よりお申し込みいただき、当日は5

Q.

ワンソース・マルチデバイス対応のレスポンシブデザインで設計されたウェブサイト、ポータルに対するアクセシビリティからの課題、見解をお聞かせ願えますでしょうか?

おぉ、ざっくりな質問ですな。

これに対する回答↓

A.

Aレスポンシブデザインを採用したWebページと、そうではないWebページとで、アクセシビリティ対応に必要な考え方に相違はありません。しかし、特定の画面サイズにおいてページの一部を非表示にしたり、あるいはレイアウトを大きく(HTMLのソースにある記述と乖離する方向に)変更しているような場合には、それが特定のユーザーのアクセシビリティを妨げていないか、注意が必要です。

ざっくりですなw

でも、

 

「ワンソース・マルチデバイス対応のレスポンシブデザインで設計されたウェブサイト」

 

に対して、画面幅が変わることで勝手にレイアウトが変わることについて言及していないので(「大きく」変わるのがダメ、とは言ってるが)、WAIC的にはアリなんですねー。

 

というわけで「気になるポイント」の1個めで書いた、「画面幅を変えたときにレイアウトが変わるのはいいのか?」については、明示されてるわけではないが、よさげだなー。

 

MDN 「モバイルのウェブアクセシビリティを学ぶ」

モバイルのアクセシビリティ - ウェブ開発を学ぶ | MDN
モバイルデバイスでのウェブアクセスは非常に人気があり、iOS や Android などの一般的なプラットフォームには本格的なアクセシビリティツールが備わっているため、これらのプラットフォームでのウェブコンテンツのアクセシビリティを考慮することが重要です。この記事では、モバイル固有のアクセシビリティについて検討します。

こちらは、現実的なウェブアクセシビリティについて言及してますな。

JIS X 8341-3準拠の更に先 と言い換えても良いかもしれない。

 

iOSやAndroidでの検証方法も書かれている(スクリーンリーダーについて)

 

心からウェブアクセシビリティに対応したサイトを作りたい、と思った際には大変役に立つ情報だと思う。

 

今回の目的とは違うけど。

 

 

W3CのWCAG 更新したよーのアナウンス

W3C - Web Contents Accessibility Guidelines (WCAG)を更新
モバイルデバイス対応・弱視・コグニティブのための仕様が拡張. 国際的な認知がさらに広がる

本家本元。

例えばモバイルデバイスに対しては,  WCAG 2.1はキーボードやマウスとともにタッチ操作のサポートが強化され,  タッチインターフェイスや他デバイスセンサーの意図しない作動を回避するためのガイドラインを加えています. 

あれ、そんな実装方法あったっけなー。見た記憶がない。が、どっかに記述されてるんじゃろう。

 

 

W3CのWCAG2.0 達成基準 2.1.1

達成基準 2.1.1 を理解する | WCAG 2.0解説書

 

達成基準 2.1.1の目的が、

可能な限り、コンテンツをキーボード又は (代替キーボードが利用できるような) キーボードインタフェースで操作ができるようにすることである。

って書いてある。

 

この「可能な限り」っていうのがね、、、抜け道になっちゃうんだよね。

 

ちなみにこの2.1.1のページにはモバイルデバイス(ケータイ、スマホ)については言及されていないが、これの実装方法G202(以下参考)について触れられている。

 

G202: すべての機能に対してキーボード制御を確保する

G202: すべての機能に対してキーボード制御を確保する | WCAG 2.0 達成方法集

 

「解説」のところ見ると、

多くのモバイルデバイスはオペレーティングシステムにキーボードインタフェースか、又は外部接続のワイヤレスキーボードに接続する選択肢を持っている。

 

ほほう、スマホでも、外部キーボード接続して使えるよね、と。

同様のことは3つある事例の3番目にも書かれてますな↓

  • モバイル版ウェブサイトに、タップするとフロートオーバーレイでサイトメニューを開くメニューボタンがある。モバイルデバイスに接続する外部接続キーボードまたは特殊スイッチを利用している人々へのアクセスを提供するために、メニューボタン及びサイトメニューがいずれもモバイルデバイスのキーボードインタフェースで操作できるようにしている。

 


 

 

 

注記: 同じ機能を使用できる手段がウェブページ上で複数提供されている場合には、必ずしもそれぞれのコントロールをキーボードだけで操作可能にする必要はない。

コントロールをキーボードだけで利用できん場合、そのコントロールを利用する機能と同等の機能を用意せぇや。と。

 

 

というわけで「気になるポイント」の2個めに書いた「スマホサイトはキーボードのみで操作できる必要あるのか?」については、

 

スマホサイトでもキーボードのみで操作できる必要ある

 

という解釈が濃厚ですな。

 

コメント

タイトルとURLをコピーしました