最速[要出典]アクセシビリティチェック Rikiya Ihara @magi1125
role 属性とは、aria-* 属性とは、WAI-ARIA とは、いったい何なのか、いつ使うべきなのかHTMLアクセシビリティWAI-ARIA 最近、いくつかの場面でWebアクセシビリティについて、コーディングに関する技術的な説明をする機会がありました。そのなかで、そもそもWAI-ARIAというものが、どういう立ち位置のものなのかがわかりづらい状態にあるということに気付きました。その結果として、WAI-ARIAの活用を含めたWebアクセシビリティ向上に取り組むことへのネガティブな印象が生まれてしまったり、理解が足りないままWAI-ARIAの属性を使うことでかえって問題が発生しやすくなってしまったりしている現状があるのではないかと思うようになりました。 そこでこの記事では、なるべくわかりやすい形で、WAI-ARIAそのものや、その中で登場する role 属性や、名前に aria- のプレフ
DMIウェビナー『アクセシビリティの本質を考える』(2024年6月25日開催) https://dmi.jaa.or.jp/general-event/view/3713 上記イベントの第1部にて使用したスライドを公開用に編集したものです。 作者:森田 雄 / 株式会社ツルカメ https:…
Web制作の技術は日々進化しており、会社やプロジェクトによっては昨今の環境に適さない書き方をしているケースも時折見受けられます。 そこで今回は「2024年のWeb制作ではこのようにコードを書いてほしい!」という内容をまとめました。 質より量で、まずは「こんな書き方があるんだ」をこの記事で伝えたかったので、コードの詳細はあまり解説していません。なので、具体的な仕様などを確認したい方は参考記事を読んだりご自身で調べていただけると幸いです。 1. HTML 画像周りはサイトパフォーマンスに直結するので、まずはそこだけでも取り入れていただきたいです。また、コアウェブバイタルやアクセシビリティも併せて理解しておきたい内容です。 Lazy loading <img>にloading="lazy"属性を付けると画像が遅延読み込みになり、サイトの読み込み時間が早くなります。
アコーディオン型ユーザーインターフェイス(UI)はウェブページでよくみられる表現です。巷ではさまざまな方法でアコーディオンUIを作る方法が紹介されていますが、みなさんはどのような方法で実装していますか? 見た目だけでなくアクセシビリティ対策までしっかりとできているでしょうか? <details>要素と<summary>要素は、アコーディオンUIを実装するのに最適です。過去にIE対策として<button>要素や<div>要素、<input>要素などでアコーディオンUIを作っていた方は、アクセシビリティ対策が簡単にできるので、<details>要素と<summary>要素の採用がオススメです。 この記事では、<details>要素と<summary>要素がアコーディオンUIに最適と言える理由と、HTMLのマークアップからCSSでのスタイリング、JavaScriptでのアニメーション制御まで順を
はじめに みなさんは、フォームなので必須項目が入力されてない時、Submitボタンに disabled をつけて押せないようにしていませんか? この記事では、ボタンにdisabled属性をつけない方がいい理由とdisabledをつけない方法を紹介します。 disabled属性をつけない方がいい理由 disabled 属性をつけると、ユーザーがボタンを操作することを防ぎます。 そのため、キーボード(Tabキー等)で操作している時フォーカスが当たらないため、ボタンの存在が認知できません。 disableがない時 disableがある時 ボタンの存在が認知できないため、支援技術(スクリーンリーダ等)で操作しているユーザーにとって、「送信ボタンどこだろう?」と思ってしまったり、「なんで送信ボタンが出てこないんだろう?」と思ってしまい、操作を完了させることができなくなります。 aria-disabl
どうも、nano72mknです。 アクセシビリティを意識してタブUIを作ったので、実装時に調べたことやポイントをまとめます。 タブUIについて まず、初めにタブUIと言われて思い浮かべるのは、この形だと思います。 このUIは、2つのパーツに分けることができます。 1つ目は、「タブ」と呼ばれるパーツ 2つ目は、「タブパネル」と呼ばれるパーツ この2つのパーツをがっちゃんこして、タブUIは出来ています。 タブUIをアクセシブルにする roleとaria属性を付与してアクセシビリティ対応をする。 roleを付与する 付与する必要があるものは下記の3つ tab tablist tabpanel tabとtablist タブにはtab、複数のタブを囲っている要素にはtablistのroleを付与する <div id="tab"> <div role="tablist"> <button role="
私たちが日常的に目にしているウェブサイト。色覚異常を持つ人たちには、違った見え方をします。色覚異常がある人は、色を識別したり、特定の色調を区別したりする能力が通常とは異なっているためです。 そうした人たちの見え方を理解した上で、使いやすいWebページを作ることは、ユニバーサルデザインの考え方にかなっています。 普段使用しているWebブラウザには、Webページをデザインしたり制作したりする人が、色覚異常を擬似的に体験するためのツールが組み込まれています。この記事では、その機能の使い方と、Webページの見え方を紹介します。 開発者ツールの起動 色覚異常を擬似的に体験するための機能は、Webブラウザの開発者ツール(デベロッパーツール)の一部です。Chromeブラウザ、Edgeブラウザを開いた状態で、F12キーまたはControl+Shift+Iを押すと、開発者ツールが起動します。 ただし、Web
こんにちは!株式会社Rabeeのデザイナーのakaneです🐏 今回は、Webアクセシビリティの初心者が基礎を学ぶときに助かった資料を紹介します。各資料に対する説明も掲載しているので、どうぞ最後までお楽しみください🌏 ※冒頭、Webアクセシビリティに関する前提知識の紹介が長くなっています。本編を読みたい方は「資料①|ざっくり知ろう」からご覧ください。 ※今回は、デジタル庁等の引用元にならって「障害」の表記を使用します。 ※noteの内容に誤りがございましたら、お手数ですがコメントやSNS等でご指摘いただけると幸いです。 はじめにまずは、Webアクセシビリティに関する基礎知識の整理からスタートします。最近よく耳にする「合理的配慮」のことも振り返ります。 WebアクセシビリティとはWebアクセシビリティとは、文字通りWebサービスにおけるアクセシビリティのことです。 アクセシビリティは「アク
少しの記述・工夫でユーザビリティやアクセシビリティを向上させるHTML/CSSテクニックを独断と偏見で集めてみました。最近クローズドな場所で登壇を行ったのですが、そちらで話した内容を纏めたものにいくつか内容を追加したものとなります。 原則的にこのブログで取り入れられている手法だったり過去の記事で触れた手法を紹介したものです。 button要素には touch-action:manipulation を指定するiOS限定の話ではありますが、button要素をつい連続でタップすると画面が拡大表示されてしまい非常に煩わしいです。 ポストを別枠で表示する そのため、パンおよびズームのジェスチャーは有効にしつつダブルタップ時のズームなどの標準外の追加的なジェスチャーを無効にするtouch-action:manipulationを指定して誤作動を防止しておくと良いでしょう。
こんにちは。freee人事労務でQAエンジニアをしているshihoです。 freee QA Advent Calendar2023 15日目です。 自己紹介 元カスタマーサポートで、2016年8月にfreeeに入社しました。3年前にQAエンジニアに異動してから、品質保証の重要性とユーザーのニーズに焦点を当てた仕事に取り組んでいます。お客様との関わりがあった経験を活かし、使いやすく信頼性の高いプロダクトを提供することに情熱を燃やしています。 アクセシビリティとは アクセシビリティに関しては、さまざまな定義が存在しますが、freeeとしては特定の個人を対象とするのではなく、すべての人に使いやすいものを提供することを目指しています。また、特定の条件での使いやすさではなく、あらゆる条件下でも使用できることを重視しています。 アクセシビリティチェックに取り組むきっかけ 元々freeeに入る前は、アク
はじめに この記事は YAMAP エンジニア Advent Calender 2023 8 日目の記事です。 こんにちは。今年の 9 月に YAMAP のフロントエンドエンジニアとして入社した Izumi です! 新規サービスの開発に携わっています。 入社してから、フロントエンドチームを中心に「アクセシビリティやっていき会」という勉強会が1年以上継続して行われていることを知りました。 それまで、アクセシビリティという言葉や、なぜ必要なのかはなんとなく知っていましたが、実際に何から手をつけたらいいか分からない状態でした。 そこで、アクセシビリティ初心者向けのウェビナーに出たり、「アクセシビリティやっていき会」で質問会を設けたりして、私の携わるサービスでどこから改善できそうかを探っていきました。(入社時には初期リリースに必要な画面や機能がほぼ出来上がっている状態で、私が引き継ぐ形でした。) 本
はじめに 突然アクセシビリティ筋を鍛えたくなったのが先月の話です. WCAG 2.1の日本語訳を全部読めばムキムキになれるのではと思い,先頭から読み進めて1ヶ月かかり読了しました. 中でも面白かったのは「失敗例」という項目です.ここには良くないWebページの実装例がたくさん書かれており,「あ〜初心者ならやりがちだよね〜」という例から「え…?職場のコードでやらかしてるんだが……?」みたいな例まであり,マジで死にたくなりました. 私の学習メモとして,またはアクセシビリティの入門資料として,あるいは過去の過ちへの禊みそぎとして,やらかしそうな失敗例を, WCAG 2.1のすべての達成基準に対して 思いつく限りまとめようと思います. レベル(A,AA,AAA)の低い順に記載しますので,下に行くほど発展的な内容になります. 失敗に気づいたら 「WCAG2.1 達成基準の番号 十分な達成方法」でググり
■ はじめに <div>要素にonClickを渡すべきではない、ということ聞いたことはないでしょうか? ただ、なぜ渡すべきでないのか? 理解してなかったので今回調べてみました。 サンプルコード 今回動作確認に利用したサンプルリポジトリのコードはReactで書いています。 ■ 結論:<div>にonClickを定義するのがなぜダメなのか? ユーザーにとって操作性の低いボタンになってしまうから、です! 要するに UX が悪くなってしまうから! その理由を解説していきます! ■ 操作性の低いボタンになってしまう理由 大きく3つあると考えています。 div要素は focus を持たないから returnキー, spaceキーをonClickに変換しないから スクリーンリーダーが認識しない要素だから ◎ focus を持たないから <div>要素はfocusを持ちません。 なので、tabキーで要素に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く