2026年のWebアクセシビリティ | gihyo.jp
あけましておめでとうございます。株式会社ミツエーリンクスの中村直樹です。昨年と同じく、2025年のWebアクセシビリティに関連する出来事を振り返りつつ、2026年のWebアクセシビリティの展望について俯瞰していきたいと思います。 WCAG 2.2と関連文書 Webアクセシビリティの国際規格であるISO/IEC 40500について、WCAG 2.0であったISO/IEC 40500:2012から実に13年ぶりに、WCAG 2.2と同等の内容となるISO/IEC 40500:2025に改訂されたというのが昨年のWebアクセシビリティに関する大きなトピックでした。 WCAG 2.2のエラッタ 細かい話になるのですが、ISO/IEC 40500:2025のベースとなったのは、2023年版のWCAG 2.2であり、その後エラッタ（正誤表）の内容を反映して発行された2024年版のWCAG 2.2ではあ
駒瑠市〜アクセシビリティ上の問題の体験サイト〜
アクセシビリティ上の問題を仕込んだサイトを生成します 勉強の教材、業務の資料としてお使いいただけます 用途にかかわらず無料でお使いいただけます 障壁（バリア）の設定 プリセット版 問題をあらかじめ設定（プリセット）した駒瑠市サイトです。カスタマイズ版にのみ存在する障壁もあります。 プリセット版で使うWCAGのバージョンを選択してください WCAG 2.0以外のバリアは、徐々に増やしています。WCAG 2.2のバリアはまだありません。 WCAG 2.0 WCAG 2.1 WCAG 2.2 代替テキストの不具合の多い駒瑠市駒瑠市のロゴ、COOL CHOICEのロゴ、情報が不足したalt（「温暖化の状況」ページのグラフ）円グラフの内容を説明しない実装（「温暖化の状況」ページの円グラフ）、ツールチップを読み上げない実装（トップページ「あなたにもできる取り組み」）、altと重複したキャプションの提供
俺なりの最速[要出典]アクセシビリティチェック
最速[要出典]アクセシビリティチェック ナイスなアンサーソング！みなさんもぜひ「俺のアクセシビリティチェック」を書いていただけたら嬉しいです Rikiya Ihara / magi (@magi1125) https://twitter.com/magi1125/status/1832473908928507936 ということで、「俺なりのアクセシビリティチェック」について書いてみます。実はこの「最速アクセシビリティチェックRTA」についてはmagiさんと以前にも話をしていて、お互いの目的や手法の違いを確認していて、それをちゃんと表に出すという意味もあります。 チェックの目的や重視するもの magiさんのチェック手法がWCAGやJISの一定の基準を満たしているかを網羅的に確認してレポートすることを目的としている（ように見える）のと比較すると、私のチェックの目的は開発チームにいち早くどんな問
![俺なりの最速[要出典]アクセシビリティチェック](https://cdn-ak-scissors.b.st-hatena.com/image/square/7e30450486b89d8be788d9c2e875661ed1562fd1/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--__-75Kxk--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%2525E4%2525BF%2525BA%2525E3%252581%2525AA%2525E3%252582%25258A%2525E3%252581%2525AE%2525E6%25259C%252580%2525E9%252580%25259F%25255B%2525E8%2525A6%252581%2525E5%252587%2525BA%2525E5%252585%2525B8%25255D%2525E3%252582%2525A2%2525E3%252582%2525AF%2525E3%252582%2525BB%2525E3%252582%2525B7%2525E3%252583%252593%2525E3%252583%2525AA%2525E3%252583%252586%2525E3%252582%2525A3%2525E3%252583%252581%2525E3%252582%2525A7%2525E3%252583%252583%2525E3%252582%2525AF%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aymrl%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2cxMEtvem5ETXNrSFdYVkN4dkxvYUdhaGxLNmdOVlB4cnV5eG1YNGc9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png%3F_a%3DBACAGSGT)
ボタンをaタグで作るな高校校歌 - 弁護士ドットコム株式会社 Creators’ blog
まずはこちらをお聞きください。 技術的解説: ボタンを a 要素で作るな a 要素は URL などへのリンクをつくるためのもので、button 要素はなんらかの処理を起動するボタンをつくるためのものです。 配置されるものがリンクなら a 要素で実装し、ボタンなら button 要素で実装すべきです。 これに違反すると、意図しない動作や、アクセシビリティ上の問題が発生します。 これは MDN でも詳しく説明されています。 onclick イベント -- \<a>: アンカー要素 - HTML: ハイパーテキストマークアップ言語 | MDN よく見られる誤った使い方として、擬似的なボタンを作成するためにアンカー要素を使用し、href を # または javascript:void(0) に設定してページの再読み込みを防ぎ、click を待ち受けするようにするというものがあります。 これらの偽の
「絶対にdisabled属性を避けて、aria-disabled属性を使わなければならない」わけではありません - Qiita
上記の引用にはいくつかのコード例が出てきます。1つめのコード例では、リンク（<a> 要素）に role="menuitem" を付けることでスクリーンリーダーのような支援技術に「ただのリンク」ではなく「メニューのアイテム」であることを認識させたり、aria-label 属性を使ってリンクのテキストを上書きして伝えたりしています。2つめのコード例では、ボタン（<button> 要素）に aria-pressed 属性を付けることで、このボタンがトグルボタン（「押されている・押されていない」の状態をもつボタン）であることを伝え、さらに属性値が "false" であることから「押されていない」すなわち「音を消していない」状態であることを伝えられています。 role="menuitem" や aria-pressed はHTMLの仕様の範囲では表現できない、WAI-ARIAの属性を使わなければ表現
スクリーンリーダーの操作にはTab以外のキーも必要です - Qiita
macOSのSafariでは、ボタンやリンクにTabキーでフォーカスを移動できないのがデフォルトの設定になっている Safariでは、「設定」画面の「詳細」パネル内にある「Tabキーを押したときにWebページ上の各項目を強調表示」のチェックを入れていないと、Tabキーを押したときにボタンやリンクにフォーカスが移動しません（Optionキーを押しながらTabキーを押すと移動できます）。デフォルトではチェックが入っていない状態になっています。 また、macOS版Firefoxでは、「設定（about:preferences）」内の「タブキーでフォームコントロールおよびリンク間のフォーカスを移動する」にチェックが入ってないと、Safariと同じくボタンやリンクにはTabキーでフォーカスが移動しないようになっています。これはSafariの挙動にあわせて追加されたようで、やはりデフォルトではチェック
「働く×やさしい日本語」で外国人にとっての人事・労務手続きをわかりやすくしたい｜株式会社SmartHR
SmartHRが目指す「誰もがその人らしく働ける社会」。これを実現するには、働く人々が言葉という最も基本的な社会との接点を、自分だけの力で理解でき、さまざまな手続きを行えることが重要です。 しかし、外国人や知的障害のある方など、日本語の読解に難しさを抱える方を雇用する企業が増えているいま、言葉が原因で手続きが難しくなってしまう人が増えています。 SmartHRのアクセシビリティ本部では、「やさしい日本語」がユーザーにとっての「わかりにくさ」に対する力強い解決策になると考え、ヒアリングやアンケートなどの調査を進めてきました。 そして、この度「SmartHR」ホーム画面のやさしい日本語切り替え機能を提供開始しました。 この記事では、難しい労務手続きの代表である年末調整を主軸に、企業で働く外国人に対して行った調査の結果をまとめました。 「やさしい日本語」とはやさしい日本語とは、難しい言葉を簡単な
少しの記述でユーザビリティやアクセシビリティを向上させるHTML/CSSテクニック集 – TAKLOG
少しの記述・工夫でユーザビリティやアクセシビリティを向上させるHTML/CSSテクニックを独断と偏見で集めてみました。最近クローズドな場所で登壇を行ったのですが、そちらで話した内容を纏めたものにいくつか内容を追加したものとなります。 原則的にこのブログで取り入れられている手法だったり過去の記事で触れた手法を紹介したものです。 button要素には touch-action:manipulation を指定するiOS限定の話ではありますが、button要素をつい連続でタップすると画面が拡大表示されてしまい非常に煩わしいです。 ポストを別枠で表示するそのため、パンおよびズームのジェスチャーは有効にしつつダブルタップ時のズームなどの標準外の追加的なジェスチャーを無効にするtouch-action:manipulationを指定して誤作動を防止しておくと良いでしょう。
入力欄のプレースホルダーって結局どうなの - Qiita
書籍「Webアプリケーションアクセシビリティ1」では、「3.1 ラベルと説明」のところで、紙版にして約1.5ページの分量を割いて、フォーム入力欄のプレースホルダー（<input> 要素や<textarea> 要素の <placeholder> 属性）の問題点を指摘しています。 この本で指摘されているプレースホルダーの問題点は以下の3つです。 プレースホルダーの色が薄く視認しづらい プレースホルダーとフォームコントロールの値との区別がつかない フォームコントロールに値を入力したときにプレースホルダーの値が見えなくなってしまう Webアプリケーションアクセシビリティ さらに、Nielsen Norman Groupによる「Placeholders in Form Fields Are Harmful」（日本語訳: 入力フォームのプレースホルダーを使ってはいけない）で数々の問題点が指摘されている
アクセシビリティチェックってどうやってるの？ということで、実際にやってみた。（その1） - 水底の血
ツイッターでアクセシビリティ向上日誌２【目視試験編】‐Akira Tsuda Portfolio and Blogというのを見かけて、そういえばアクセシビリティチェックって何をどうしているのかという話をウェブ上でほとんど見かけない（というか自分は知らない）ので、思い切ってチェックの過程や考え方を書いてみようかなと。 チェック対象のサイトを作った@HeldaForStudy氏に尋ねたところ、題材として使ってよいという返事をいただいたので、「アトリエ金工やまぐち」のサイト1ページをチェックしてみることにします。 対象ページはBasic認証がかかっているので、アクセシビリティ向上日誌１【各種ツール評価編】からたどってください。 @HeldaForStudy氏はレベルはA*1でチェックしたとのことなので、チェック基準はWCAG 2.1レベルAでチェックすることにしましょう。 わたしは普段はCOB-
altディシジョンツリー
About this translation ボランティアによる本翻訳は原文（英語）の内容を正確に反映できていない可能性があります。 翻訳者 Hiroya UGA. 寄稿者 Naoki Nakamura. WAIは全ての翻訳者に感謝し、また他のtranslationsも歓迎します その画像はテキストを含んでいますか？ Yes: かつ、そのテキストが実際のテキストとして近くに記載されている場合 空のalt属性を利用します。詳細は装飾目的の画像 (英語版)を参照してください。 かつ、そのテキストが視覚効果のためだけに表示されている場合 空のalt属性を利用します。詳細は装飾目的の画像 (英語版)を参照してください。 かつ、そのテキストがアイコンなど特定の機能を持つ場合 alt属性を、画像の機能を伝えるために利用します。詳細は機能を持つ画像 (英語版)を参照してください。 かつ、画像内のテキスト
オーバーレイ ファクトシート
Webアクセシビリティ オーバーレイとは何ですか？オーバーレイは、Webサイトのアクセシビリティを向上させることを目的とした技術の総称です。サードパーティのソースコード（多くはJavaScript）を読み込み、フロントエンドコードを改善します。 アクセシビリティの向上を謳うWebサイトのアドオン製品は、1990年代後半に登場したReadspeakerやBrowsealoudに遡ります。これらは、インストールされたWebサイトにテキストの読み上げ機能を追加するものでした。 その後、そのようなソフトウェアに機能を追加した類似製品が、市場に出回るようになりました。それらは、読みやすさを向上させるために、ユーザーのニーズに基づき文字サイズや色などをコントロールするものです。 最近のオーバーレイ製品のなかには、支援技術からのアクセスのしやすさを妨げる問題を修正することを目的としているものがあります。
2024年のWebアクセシビリティ | gihyo.jp
あけましておめでとうございます。株式会社ミツエーリンクスの中村直樹です。昨年と同じく、2023年のWebアクセシビリティに関連する出来事を振り返りつつ、2024年のWebアクセシビリティの展望について俯瞰していきたいと思います。 WCAG 2.2の勧告とWCAG 2.1の更新 長らく待ちわびていたWCAG 2.2について、2023年10月5日付けでようやくW3C勧告（Recommendation）となりました（日本語訳はまだありません。詳細は後述の「臨時WGの活動状況」を参照）。また、これと連動する形でWCAG 2.1（日本語訳）の勧告も改めて発行されました。 今回のWCAG 2.1の更新では、達成基準4.1.1構文解析に注記が設けられています。これにより、WCAG 2.2で削除された達成基準4.1.1の扱いについて連続性が保たれるようになっています。WCAG 2.1からの変更点は、公
ウェブアクセシビリティ検証ツール「Stark」 | Accessible & Usable
公開日 : 2023年9月22日 カテゴリー : アクセシビリティ 「Stark」というウェブアクセシビリティ検証ツールがあります。各種ブラウザ (Chrome、Firefox、Safari、Edge) の拡張機能として、あるいは各種デザインツール (Figma、Sketch、Adobe XD) のプラグインとして、色覚シミュレーションや色のコントラスト比のチェックができるツールとして以前から知られていましたが、現在は、それ以外にもアクセシビリティに関する様々なチェックができるようになっています。 この記事では、Stark で可能なウェブアクセシビリティ検証について、Chrome 拡張機能を例に、無料プランで使える機能をご紹介します。 Chrome 拡張機能で Stark を開いたところ。 機能一覧 (Contrast、Typography、Alt-Text、Touch Targets、F
自治体サイトWebアクセシビリティ調査 | 有限会社ユニバーサルワークス
防災・災害情報とアクセシビリティ 自治体サイトと言えばユニバーサルワークス。自治体サイト調査のユニバーサルワークスが、毎年9月1日にお届けする、都道府県、政令指定都市がドキドキする、Webアクセシビリティ愛好家がニヤニヤする、「自治体サイトWebアクセシビリティ調査」です。 23回目となる今回のテーマは「防災・災害情報とアクセシビリティ」です。災害時の情報発信においては、いかなる利用者も必要な情報に確実にアクセスできることが求められます。公式サイト上に点在する防災・災害情報の探しやすさ、そこから導かれる防災コンテンツの位置づけと導線、さらに防災コンテンツ内でのアクセシビリティ上の配慮が、住民の安心と安全に直結します。本調査では、各自治体の公式サイトにおける防災・災害情報の導線や構成、防災コンテンツのアクセシビリティ実装を点検し、実際に利用者が遭遇する課題を抽出しました。特に「見つけやすさ」
アクセシビリティの指摘はなぜあんなに『めんどうくさい』のか｜平尾ゆうてん
お前がめんどうくさがっているとき、相手もまためんどうくさがっているのだ シンドーイ・ダルイ5世まあ、そんな言葉を残したダルイ5世なんて存在しないんだけど、あることの『めんどうくささ』には、こういうお互い様な部分があることは読者のみなさんも経験的に感じているのではないでしょうか。 今回の話は、アクセシビリティの専門家として日々相談を受けたりレビューをする中で感じている『めんどうくささ』を説明しつつ、相談をしている側やレビューを受ける側も私の話をめんどうくさいと思って受け取っているんだろうなぁ〜という予想をしながら、これらにまつわる問題の整理と、それでもあえて『めんどうくさい』コミュニケーションをとっている言い訳を書きたいと思います。 相談に対する返答の『いつもの3点セット』「〇〇したいんだけど、アクセシビリティ的にどう思いますか？」 こういった問いは毎日のように尋ねられます。まず断言しておく
第1回支援技術利用状況調査報告書 | 日本視覚障害者ICTネットワーク
掲載：2021年8月9日 更新：2022年4月10日 更新履歴 2022年4月10日：本調査の報告会のレポートへのリンクを追加 参考：イベント・レポート：第1回支援技術利用状況調査結果報告会 はじめに この報告書は、日本視覚障害者ICTネットワーク (JBICT.Net) が2021年4月から5月にかけて実施した第1回支援技術利用状況調査の結果をまとめたものです。 調査概要 本調査は、2021年4月21日から5月31日の期間実施し、Webとメールで回答を受け付けました。 上記期間中に344件の回答が寄せられました。このうち、Webによる回答が318件（92.44パーセント）、メールによる回答が26件（7.56パーセント）でした。 344件の回答のうち、336件（97.67パーセント）が有効回答でした。 必須の設問への回答が記入されていなかったもの、記入されたメール・アドレスが明らかに誤って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報設計からのデザインアプローチ ～ユーザーの声を聞くよりも、もっとデータの声を聞け～
Tappy | 実験的なプロダクト | LINEヤフー株式会社
ユーザーは音声だけでWebサイトをどう使うのか？ 弁護士ドットコム、アクセシビリティユーザー調査の結果を公開 | 弁護士ドットコムがアクセシビリティに本気で取り組む狙い | Web担当者Forum
