W3Cからアナウンスされたように、WCAG 2.2が2023年10月5日付けで勧告（Recommendation）となりました。 WCAG 2.1の最初の勧告が2018年ですから、そこから5年が経って達成基準（Success Criterion）が追加されたことになります。 WCAG 2.1の勧告について「最初の」とわざわざ言っているのは、WCAG 2.1が先月に更新されたことによります（W3Cのアナウンス）。 WCAG 2.1の更新の内容はもっぱらエラッタの適用ですが（WCAG 2.1のChange Logも参照）、その中でも達成基準4.1.1について注記が追加されたのが目立った変更点と言えます。 この追記は、端的にはWCAG 2.2では達成基準 4.1.1が削除されているように、達成基準 4.1.1についての評価は別の達成基準で行うようにするという内容です。 さて、WCAG 2.2の話
入力フォームがあるページの設計をする際はフロントエンドでもバリデーションを実装することが多くあります。代表的なバリデーションは例えば以下のようなものです。 必須の入力欄に値が入力されていなければエラーとする メールアドレス入力欄に入力された値がメールアドレス形式でなければエラーとする パスワードとして使用できない文字が入力されればエラーとする 入力内容が不適切な場合は、入力欄に装飾を施すために:validと:invalidの2つの擬似クラスを利用してきました。 :validと:invalidは、主にフォームコントロール要素に関連する擬似クラスで、以下のような基準にしたがって各要素の状態がマッチするかどうかを判定します。 required属性付きの入力欄が空でなければ:valid、空であれば:invalid type属性がemailである入力欄に入力された値がメールアドレス形式であれば:va
以前のBlog記事で、Twitterで投稿された画像に設定された代替テキストが表示できるようになり、より広く代替テキストという言葉が認知されるようになるのではないかとお伝えしました。その後、私の観測する範囲とはなってしまいますが、特に企業の公式アカウントなどが代替テキストを追加したり、Web制作に携わっていない方が代替テキストについて話題にするなど、想像していた以上の広がりがあり驚いています。 一方、ボタンを押すことで表示できる隠しテキストとしてユーモアを持たせるような長文のテキストが記載されるなど、おそらくTwitter社が意図しない目的で使用される例も見られました。こうした代替テキストの使用方法については、アクセシビリティの専門家やスクリーンリーダーユーザーの間でも一部話題となりました。 私は画像と代替テキストの内容は一致させるべきで、冒頭の記事にも書いた通り、可能な限り簡潔な代替テキ
2021年1月22日 W3C Accessibility Guidelines (WCAG) 3.0の初期公開作業草案が発行されました アクセシビリティ・エンジニア 中村（直） Web Content Accessibility Guidelines (WCAG) 2.0とそのマイナーバージョンの後続として開発されている、W3C Accessibility Guidelines (WCAG) 3.0がFirst Public Working Draft（初期公開作業草案）として発行されました。 元の言葉はWeb ContentからW3Cに変更されているものの、略称は同じWCAGになっているのは、WCAGという語がWebアクセシビリティを取り巻く世界ではよく知られている証左と捉えることもできそうです。 そんなWCAG 3.0ですが、Abstract（概要）には以下の1文が記載されています。
以前に同僚と少し絵文字に関する話をしていたこともあり、ふと、絵文字はスクリーンリーダーでどう読み上げられるのかということが気になって、ごく簡単に読み上げさせてみましたという話です。 筆者の自宅の環境がWindowsとAndroidであることから、読み上げのテストにあたっては、NVDA、Windowsのナレーター、TalkBackで試してみました。以下にテスト環境を記しておきます。ブラウザーによる違いは見られなかったので、これについては省いています。 Windows バージョン 1909（OS ビルド 18363.836） NVDA 2020.1jp Android 10 TalkBack バージョン 8.2.0.303936097 以下が4つの絵文字について読み上げテストを実施した結果になります。言語については、lang属性を付与して読み上げさせました。 笑顔を表す絵文字と各スクリーンリー
この記事は、ミツエーリンクスアドベントカレンダー2019 - Qiitaの9日目の記事です。 2019年10月、国土交通省は公共交通機関の移動等円滑化整備ガイドライン（通称：バリアフリー整備ガイドライン）の改訂を行いました（報道発表資料）。 このガイドラインは、公共交通機関（鉄道、バス、旅客船、航空機）について、旅客施設と車両などに対して、主にハード面からどのように交通アクセシビリティを確保すればよいのかについて、重点的に取り扱ってきたものでした。今回の改訂では、第5部「情報提供のアクセシビリティ確保に向けたガイドライン」が新設され、その中の「１．ウェブアクセシビリティについて」「①ウェブサイト等による情報提供」には「考え方」と「ガイドライン」がそれぞれ次のように記載されています。 考え方 障害者等にとって、円滑に旅客施設を利用するためにエレベーターやトイレ等の設備の設置状況や設置位置、受
2019年9月11日 Firefox Nightlyで色覚シミュレーションが可能に アクセシビリティ・エンジニア 中村（直） @FirefoxDevToolsの2019年9月6日のツイートによれば、Firefox Nightlyで特別なアドオンをインストールすることなしに、開発ツールで色覚のシミュレーションができるようになったようです。 開発ツールの[アクセシビリティ]タブを選択すると、画面上に「Simulate」が出現します（画像参照）。 1型2色覚（P型）、2型2色覚（D型）、3型2色覚（T型）について、それぞれの強弱の6種類と、視界が暗く見えるContrast lossの7種類が現在シミュレーションできるようです。また、「ドキュメント...」はMDNへのリンクになっていますが、今のところ該当URLについては記事の中身は何もない状態のようです。 実際に1型2色覚のシミュレーションとなる
WAI-ARIAを使ってアクセシブルなコンテンツを作成したいと考えていても、WAI-ARIAの指定方法に問題がないかどうか不安、という方も多いと思います。そのような場合には、まずはWAI-ARIAの仕様に従っているかどうかを確認すると良いと、私は考えています。というのも、明白なミスを防ぐことができる制約がWAI-ARIAの仕様にはいくつか定められているためです。この記事では、ARIA Validatorを使った検証方法とWAI-ARIAの仕様で定められている制約のいくつかを紹介します。 ARIA ValidatorはページがWAI-ARIAの仕様に従っているかどうかをチェックするGoogle Chromeの拡張機能です。記事執筆段階での最新版は0.10です。 現時点ではまだベータ段階とのことですが、閲覧中のページに対して様々な検証を行うことができます。ただし、ARIA Validatorは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
