CSSの単位px、em、remはどれをどこで使用するのがよいか、ピクセルとアクセシビリティにおける意外な真相
CSSの単位px、em、remは、どれをどこで使用するのがよいか。 font-sizeの値にはどの単位を使用していますか？ ほかにもメディアクエリを定義する時、マージンを定義する時、widthやheightを定義する時、使用する単位はアクセシビリティに配慮する必要があります。 The Surprising Truth About Pixels and Accessibility by Josh W. Comeau 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに CSSでpxとemとemの各単位がどのように機能するか アクセシビリティに関する考慮事項 どの単位をどこで使用すればよいのか どの単位がベストなのかが明らかでない場合 簡単にできる小技とメンタルモデル ボーナス: remを使用すると便利なテクニック はじめに C
お前らはまだ img タグの alt 属性の付け方を間違っている - Qiita
1行で alt属性は、「全ての 画像をそのalt属性のテキストに置き換えたときにページの意味が変わらない 」ようにつける。 （HTMLの標準規格書より） マジでこれに尽きる。 具体例 例１：ロゴ ❌ 間違ったマークアップ
「Firefox 99」正式版リリース、読み上げ機能の使い勝手が向上
ウェブブラウザ「Firefox 99」の正式版が公開されました。リーダービューの読み上げ機能にショートカットキーが設定されたことにより使い勝手が向上しています。 Firefox 99.0, See All New Features, Updates and Fixes https://www.mozilla.org/en-US/firefox/99.0/releasenotes/ ◆リーダービューでの読み上げ機能のオン／オフ切り替えに、キーボードショートカット「n」を割り当て Firefoxには、ブログや記事などにおいて本文のみを表示する「リーダービュー」という機能が搭載されています。リーダービューに対応したページではアドレスバーに文章のアイコンが表示されており、これをクリックすることでリーダービューに移行します。 このとき画面左部に表示されるメニューから、ヘッドホンのアイコンをクリックす
label で input[type="file"] を装飾するな
input[type="file"] な要素を装飾する方法を検索したときに、次のような間違った label 要素の使い方を紹介する記事ばかりヒットするのが気になったので書きました。label 要素を使っても問題ない場合もありますが、間違った使い方をしている（しようとしている）人に届きやすいようにこのような表題にしています。 何が問題か 上記の方法は input 要素を display: none で非表示にし、label 要素を使ってヒット領域を拡大させて「ファイルを選択」ボタンを表現するという方法ですが、この方法ではフォーカスが当たりません。また、tabindex 属性に非負の値を設定しフォーカスを当てられるようにしても label は clickable な要素ではないので Space / Enter キーで click イベントを発火することができません。 どうするべきか butto
![label で input[type="file"] を装飾するな](https://cdn-ak-scissors.b.st-hatena.com/image/square/abcddc7bb77ffd423240f83b7922f8b6d66776fc/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--fjF5h3Vm--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3Alabel%252520%2525E3%252581%2525A7%252520input%25255Btype%25253D%252522file%252522%25255D%252520%2525E3%252582%252592%2525E8%2525A3%252585%2525E9%2525A3%2525BE%2525E3%252581%252599%2525E3%252582%25258B%2525E3%252581%2525AA%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Adqn%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzYxMjZlNDcxNWEuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
Webのルビ仕様にはアクセシビリティを阻害している面がある。「日本DAISYコンソーシアム」が改善を求めてブラウザベンダ、WHATWG、W3Cらに公開書簡
Webのルビ仕様にはアクセシビリティを阻害している面がある。「日本DAISYコンソーシアム」が改善を求めてブラウザベンダ、WHATWG、W3Cらに公開書簡 すべての人が等しく情報にアクセスできることを目指し、国際規格であるDAISY（Digital Accessible Information System：アクセシブルな情報システム）規格の開発・維持・普及のために設立された国際団体「DAISYコンソーシアム」の正会員である「日本DAISYコンソーシアム」は、Web上の文書の文字や熟語にルビを振るためのWeb標準仕様が、弱視や失読症などを含むさまざまなハンディキャップを持つ人々にとってのアクセシビリティを阻害している面があるとして、改善を求める公開書簡をWebブラウザベンダ、WHATWG、W3C宛てに送付しました。 その一部を引用します。 The historical purpose of
アクセシブルなフロントエンドコンポーネントの完全ガイド - 前編 | POSTD
クイックサマリー ‐ 私たちは一連の短い記事で開発者とデザイナーにとって有用なツールやテクニックを紹介しており、直近の記事ではCSS監査ツールとCSSジェネレータを取り上げました。この記事ではタブやテーブルからトグルやツールチップまで、信頼性の高いアクセシブルなコンポーネントを見ていきます。 目次 以下にすべてのアクセシブルなコンポーネントをアルファベット順に記載しました。目次をスキップするか、スクロールして1つずつお読みください。 :focus styles autocomplete buttons carousels "close" buttons content sliders checkboxes color systems color palettes comics component libraries cookie consent prompts dark mode data
WAI-ARIAを学ぶときに整理しておきたいこと
結論 ロールについて知る HTMLの暗黙のロールを知る ロールを知った上でロールに対して使用できるプロパティ/ステートを使う (おまけ) markuplintを使おう aria属性を使う前に まず、いきなりaria-labelやaria-selectedとかに手を出さない。 aria-selectedとかを発見してしまうと「option要素以外にもselectedみたいな意味を付加できるんだ！すげえ！使ってみよう！」みたいな気持ちが沸き上がってしまう。わかる。とってもよくわかるよ。当時ぼくもそうだったから。 ただ、そこはぐっと我慢してほしい。 なぜかと言うと、aria属性は、使っていいときと悪いときがある。きちんとWAI-ARIAという仕様と、ARIA in HTMLやCore Accessibility API Mapping (Core-AAM)という仕様で決められていっている[1]の
Micromodal - Tiny javascript library for creating accessible modal dialogs
Introduction Micromodal.js is a lightweight, configurable and a11y-enabled modal library written in pure JavaScript It enables you to create WAI-ARIA guidelines compliant modal dialogs, with confidence and with minimal configuration. At just 1.9kb minified and gzipped, its a tiny library for big change. Following are some of the interactions handled by the library:- Closing modal on overlay click
HTML: アクセシビリティの基礎 - ウェブ開発を学ぶ | MDN
完全な初心者はこちらから!ウェブ入門ウェブ入門基本的なソフトウェアのインストールウェブサイトをどんな外見にするかファイルの扱いHTML の基本CSS の基本JavaScript の基本ウェブサイトの公開ウェブのしくみHTML — Structuring the webHTML概論HTML 入門HTML を始めようヘッド部には何が入る? HTML のメタデータHTML テキストの基礎ハイパーリンクの作成高度なテキスト整形文書とウェブサイトの構造HTML のデバッグ手紙のマークアップコンテンツのページの構造化Multimedia and embeddingマルチメディアとその埋め込みHTML の画像動画と音声のコンテンツobject から iframe まで — その他の埋め込み技術ウェブへのベクターグラフィックの追加レスポンシブ画像Mozilla のスプラッシュページHTML tablesH
今からでも遅くない！誰も教えてくれなかった React とアクセシビリティーの世界
この記事は Front-End Study #3 で発表されたライブコーディングの内容を記事にしたものです。記事中のソースコードは GitHub でご覧いただけます。 この記事は、これまで一般的なフロントエンドエンジニアだった私が一年ほどアクセシビリティーについて勉強する上で 「最初に教えてくれればよかったのに〜！」と思った内容 を React と Next.js を用いて紹介するものとなっています。 読み終わった後に次にコードを書く際にふと意識できるようなアクセシビリティーの普遍的な事実を紹介し、最後に今後の React の動きについて軽く触れるものになっています。目次は次のとおりです： 基本事項 SPA のルーティングによる問題 リッチなコンポーネントでの例 Jest + React Testing Library でのテスト Reactとアクセシビリティーの今後の動き 役に立つweb
アクセシビリティ_株式会社ニジボックス Katsuhito Karube
リクルートグループ主催！『大規模メディアにおけるWeb開発の最前線』 https://business-and-creative.connpass.com/event/188628/
キーボード操作を意識したHTML/CSSコーディング
この記事は 「Webアクセシビリティ Advent Calendar 2020」 5日目の記事です。 アクセシビリティ Advent Calenderの記事を寄稿するにあたり、少しの工夫であらゆるユーザーに対して優しいWebサイトを作れるようなHTML/CSSコーディングの方法についてまとめました。より多くの人にとって優しい・使いやすいWebサイトを作ることは訪れてくださるユーザーの方々だけでなく、クライアントにとってもユーザーの機会損失を防ぐことができるので多大なるメリットがあります。（よくコードが適当でもデザインが見えていれば良いって意見を聞くけれどそんなことはない） ただ、アクセシビリティを意識したHTML/CSSコーディングについてのまとめだと内容量が非常に多くなりZennなら記事より本で出したほうがベターになってしまうので、今回は数あるアクセシビリティの視点から「キーボード操作で
マークアップを進化させる WAI-ARIA の基本
マークアップを進化させる WAI-ARIA の基本 私 @masuP9 WAI-ARIAとは何か WAI Web Accessibility Initiative ARIA Accessible Rich Internet Applications WAI-ARIAは、ウェブコンテンツおよび アプリケーションのアクセシビリティと相互運用性を改良するためのフレームワークを提供する技術仕様である。 Accessible Rich Internet Applications (WAI-ARIA) 1.2 日本語訳 WAI-ARIAは ウェブのアクセシビリティを 高めるための技術仕様 WAI-ARIAはなぜ必要か アプリケーション化するウェブ Notion Figma G Suite 3D CAD etc... 意味も振る舞いも 既存のHTMLでは表現できなくなってきた 例えば タブUI 開いてい
Webアクセシビリティ難しすぎる問題
はじめに 私はデザイナー兼フロントエンドエンジニアというような立ち位置で、勤務するfreee株式会社のアクセシビリティガイドラインの作成に関わったり、アクセシビリティまわりの仕組みの整備や社内エバンジェリストみたいなことをしています。 もともと私はWebアクセシビリティという分野が、重要なものである以上に技術や考え方として面白いと思ってやっているうちに気付いたら仕事で大きなウェイトを占めるようになってしまったタイプの人です。しかし、そうではない人たちにその重要さを説明したり、対応をお願いしたり、そのための資料を作ったりしているうちに、「やっぱWebアクセシビリティって難しいんだなぁ」と思うようになってきたので、それについて書いてみようと思います。 なお、背景を説明するうえで必要なので社名を出しましたが、あくまでこの文章は個人の見解であり、所属組織とは関係がありません。 誰のためにやるのかが
Accessible Rich Internet Applications (WAI-ARIA) 1.0 (W3C Recommendation 20 March 2014)
Accessible Rich Internet Applications (WAI-ARIA) 1.1 W3C Recommendation 14 December 2017 This version: https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/ Latest published version: https://www.w3.org/TR/wai-aria-1.1/ Latest editor's draft: https://w3c.github.io/aria/ Implementation report: https://w3c.github.io/test-results/wai-aria/ Previous version: https://www.w3.org/TR/2017/PR-wai-aria-1.1-2
これは確かに有効そう…医療現場であることを実践したら「左右の取り違えミス」がほぼ０件になった
いちは @Willway_ER 左右の取り違えについて。 注射部位を指示するときに、「右肩」「左肩」ではなく「みぎ肩」「ひだり肩」と書くようにしただけで、取り違え報告はほぼゼロになった。 2017-05-10 08:42:53
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Patterns
WAI-ARIA 準拠には CSS Modules が最適という話