カルーセルUIのアクセシビリティを向上させてみよう！｜bonji810
この記事は STUDIO アクセシビリティ委員会のマガジン vol.7 です。 こんにちは！STUDIO株式会社 フロントエンドエンジニアのjimbouです。 私からはSTUDIO アクセシビリティ委員会マガジンにて、主にエンジニア/デザイナーさん向けに技術的な記事を発信しています。 STUDIOに限らずWebサイト、Webアプリに携わる全ての方々に読んでいただければと思います🌟 今回は「カルーセルUI」についての記事になります💡 Webサイト、WebアプリでカルーセルUIをデザイン/実装する方に向けて、少しでも役に立つ記事になれば幸いです☺️ 何のためにアクセシビリティを向上させるのか？では、カルーセルUIを実装する上で、アクセシビリティを向上させるとどんな良いことが起こるのでしょうか。 例として、アクセシビリティを特に意識せず、主にdivタグを用いてマークアップしたカルーセルUIを
Ubie アクセシビリティ改善の振り返り 2022
Ubie株式会社でデザインエンジニアをしているtakanoripです。 年の瀬なので今年取り組んだアクセシビリティ向上の施策について振り返りつつ来年の展望を考えようかなと思います。12月19日に公開された @3284 の記事もあわせて読んでみてください。 アクセシビリティ向上にむけた実装の改善 去年からアクセシビリティ向上のための実装改善を進めていたのですが、今年の前半で一旦完了となりました。全ての不具合を修正できてはいませんが、プロダクトを利用する上でクリティカルな問題は全て解消できました。 Lintの導入 toCプロダクトにeslint-plugin-jsx-a11yとmarkuplintを導入しました。 Ubieはフロントエンドが得意でないエンジニアがUIを実装することが多いので、Lintでエラーや警告を出すことで最低限のアクセシビリティ品質を担保するためにLintを導入しました。け
社内のみんなにアクセシビリティ｜Hiroki Tani
自分が観測している範囲でそう感じているところもあるかもしれませんが、デジタルプロダクトやサービスにおける情報アクセシビリティを高めていこう、というのが年々広がっていると感じています。 自分が設計・開発に関わるサービスではもちろん、SNS等でもなるべく画像に代替テキストをいれる等、100％ちゃんとやれている自信はないですが努力しているつもりです。 ところで、みなさんの職場で同僚との仕事上でのやりとり等ではどうでしょうか？ドキュメントの共有や、Slackなどのテキストコミュニケーション、あるいはZoomでの会議といった機会において意識できるアクセシビリティがあります。 この記事では普段ぼんやりと感じている「仕事場におけるアクセシビリティとして気をつけること」を挙げていってみます。 色だけで情報を区別しない社内で共有するドキュメントで「赤字は重要」「色だけで分けられた円グラフ」といった表現をする
Web アクセシビリティに配慮し、なおかつ式として例外のないものにしたい色設計
デザインシステムにおける色設計、ルールをひとつの式で表現できるようにしたい。でもA11y対応でルールが増えるので、どうやったらシンプルにできるかを試行錯誤するお話。 色を展開するルールをシンプルにしたい 色計算が可能なプログラミング言語でひとつの式を使いさえすれば、設計されたカラーシステムを再現できるというのはメリットが多いはずだ。(デザインシステムで定義された色をわざわざコード上で演算する必要があるのかは怪しいけれど) メリット 規則的なのでプログラミングで表現しやすい 人間も覚えやすい 式の例 上記のように$some-colorに対して明度への演算をかけるだけで赤、青、黄、緑のカラーパレットがデザインシステムに沿ったものになるのであればいくらかコードへの負担が軽減されるのではないだろうか。(と期待しているけど、聞かないとダメですねコレ) RGBではなく、H(色相)S(彩度)B(明度)と
モーダルウィンドウのコンテナ要素に aria-modal 属性を適用する | Accessible & Usable
公開日 : 2021年6月6日 (2021年6月7日 更新) カテゴリー : アクセシビリティ 先の記事「折り畳まれたナビゲーションメニューの展開 (オーバーレイではなくインレイで)」を書く過程で、オーバーレイで提示されるモーダルウィンドウのアクセシビリティについて改めて調べていたところ、aria-modal という属性が気になりました。aria-modal とは、2017年に勧告された WAI-ARIA 1.1 から追加されたプロパティで、あるコンテナ要素に aria-modal="true" という属性が適用されている場合、その要素がモーダルであることをスクリーンリーダーなどの支援技術に示し、それ以外のコンテンツの利用を排除する (インタラクション可能な範囲を、モーダルのコンテンツに限定する) というものです。(参考 : aria-modal の定義 (WAI-ARIA 1.1) /
アクセシブルなサイトリニューアルのチェック項目
検討したり、例外を適切に設けるために使うものです。 要件定義 バックエンドシステム・CMSが以下に対応している 入力フォームに時間制限はない 入力フォームの入力チェック機能は適切なエラーメッセージがでる 出力されるHTMLが仕様に準拠したHTML 画像に代替テキスト(alt属性)が入れられる 動画にクローズドキャプションを追加できる 自動的に生成されるウィジェットがアクセシブルになっている 画像のポップアップ（モーダル）機能など 3rdパーティのウィジェットやASPがアクセシブルである 動画埋め込み 地図埋め込み サイト内検索 自動翻訳機能 チャットボット 情報設計 情報設計に問題がない・情報を管理できている ナビゲーション設計が適切でどのページにもたどり着ける リンクテキストとリンク先ページタイトル・見出しに乖離がない ページタイトルとh1見出しに乖離がない サイト内でページタイトルに重
a11y由来のスタイリング考察
aria属性 や role属性 を用いたスタリング実例は、まだあまり聞くことがありません。例えば CSS Modules の場合次の様な指定が可能であり、a11yとスタイリングを両立できるため、アプローチとして良さそうと考えています。 .text { color: #000; } .text[aria-invalid=true] { color: #f00; /* エラーの表現とか */ } .menu[aria-expanded=false] { display: none; /* メニューの開閉表現とか */ } .menu[aria-expanded=true] { display: block; /* メニューの開閉表現とか */ }
アイコンフォント
安全でアクセシブルなアイコン・フォントアイコンフォントの問題点と、安全な方法で提供する方法について解説された翻訳記事。フォントが読み込まれない場合、@font-face がサポートされていない古いブラウザの場合の話や、アクセシビリティに関してアイコンフォントが適切に動作しない場合の話などが紹介されている。 アイコンフォントとアクセシビリティ： ディスレクシア（失読症）向けフォントでの表示問題についてアイコンフォントを利用していると、ディスレクシア向けの機能でフォントが置き換えられた場合にコンテンツが正しく表示されない問題が紹介されている。 アイコンフォントか？ SVG アイコンか？「ユーザーがフォント設定をカスタマイズした場合などに、アイコンフォントが表示されない (いわゆる「豆腐」になったり、文字化けしたり、空白になったりする)。」という問題に対して考察。アイコンフォントが表示されないリ
アクセシビリティを気にし出したきっかけと、2020年の振り返り
この記事はトレタ Advent Calendar 2020 の19日目の記事です。 はじめに 今年は私にとってアクセシビリティ元年と言える年だったように思います。 この記事では、今年やったことをまとめておきたいと思います。 きっかけ JSConf JP のセッション アクセシビリティへの興味が高まったきっかけは、2019年のJSConfJPで聞いたアクセシビリティのセッションでした。とても熱量のあるセッションで印象に残るものでした。 それ以前から、 "キーボード操作ができた方が良い" とか、 "labelをクリックするとフォームの要素にフォーカスが当たった方が良い" とか、よく知られていることは知っていました。しかし、アクセシビリティに関して体系的に学んだことはありませんでした。 私は、 "ユーザーにより良い体験を提供したい" という思いでフロントエンドエンジニアをやっているのですが、アク
「font-sizeの指定はpxとremどちらを使うべきか？」問題に対する回答
こんにちは。TAK(@tak_dcxi)です。 今回は SNS で頻繁に話題になる「font-size の指定はpxとremどちらを使うべきか？」問題について。 自分が観測している限りだと、 font-size の指定は px と rem どちらを使うべきか？ Web デザイナーはコーディングの知識があったほうがいいか？ jQuery はオワコンなのか？ 実装者はピクセルパーフェクトに拘らないとダメか？ h1 タグはどこに使うべきか？ あたりは四半期に一度は話題になっている感覚がありますね。 おそらくこの記事を読んでいる方や、もしくはタイムラインにこの記事の Twitter カードなんかが流れてきてウンザリしている方も多いことでしょう。僕も正直「またこの話題か…」という感想ですが、頻繁に話題になるということはそれだけ意見が割れているということなので、自分なりの見解をまとめるためにもこの記事
「この機能のアクセシビリティどうしよう」と思ったら
こんにちは、この記事は Webアクセシビリティ Advent Calendar 2020 の6日目です。 すこし前に、同僚のエンジニアに「Webアプリケーションにドラッグ＆ドロップを使う機能を作ろうとしているんだけど、アクセシビリティは何をすればいいのかわからない」という相談をされる機会がありました。そのときの回答が、実はアクセシビリティを考える上ですごく大事なことだなと思ったので、ちょっと文章化してみることにしました。 相談されたのは「新しい機能で直感的な操作を実現するためにドラッグ＆ドロップを使いたいが、アクセシビリティチェックをパスできない気がする」というような内容でした。たしかに私の会社で運用しているチェックでは、キーボードやスクリーンリーダーによる動作チェックを行っているので、それらではドラッグ＆ドロップの操作ができそうには思えません。 彼のこの相談内容からは「良いものを作ろう」
キーボード操作を意識したHTML/CSSコーディング
この記事は 「Webアクセシビリティ Advent Calendar 2020」 5日目の記事です。 アクセシビリティ Advent Calenderの記事を寄稿するにあたり、少しの工夫であらゆるユーザーに対して優しいWebサイトを作れるようなHTML/CSSコーディングの方法についてまとめました。より多くの人にとって優しい・使いやすいWebサイトを作ることは訪れてくださるユーザーの方々だけでなく、クライアントにとってもユーザーの機会損失を防ぐことができるので多大なるメリットがあります。（よくコードが適当でもデザインが見えていれば良いって意見を聞くけれどそんなことはない） ただ、アクセシビリティを意識したHTML/CSSコーディングについてのまとめだと内容量が非常に多くなりZennなら記事より本で出したほうがベターになってしまうので、今回は数あるアクセシビリティの視点から「キーボード操作で
クラウドワークスのフロントエンド活動を振り返る 2020 - クラウドワークス エンジニアブログ
この記事はクラウドワークスアドベントカレンダー１日目の記事です。 クラウドワークスでフロントエンドの可能性を模索し続けている @yamanoku です。 アドベントカレンダーを今年もやっていきます。初日の盛り上げ手としてよろしくおねがいします。 フロントエンド活動の振り返りをしてみよう クラウドワークスでは現在、フロントエンド専属のエンジニアチームというものは存在しません。 その代わりにサーバーサイド（Ruby on Rails）も併せてフロントエンド開発するのが基本体制となっています。 各チームごとでのフロントエンド開発の悩みやノウハウといったものは存在するのですが、それらを全体を通してうまく共有・把握できてないような気がしていました。 そこで今後の開発で各チームの「次」に活かすための参考として、併せて今年はどういったことを行っているのかを外部にも知ってもらうために、この記事では 202
アクセシビリティを意識したアコーディオンを作ってWAI-ARIAを学んでみたお話
この記事は 「Webアクセシビリティ Advent Calendar 2020」 10日目の記事です。（執筆が終わったのが11日目になってしまい申し訳ございません） 先日投稿したWebアクセシビリティ Advent Calendarの記事「キーボード操作を意識したHTML/CSSコーディング」は思いがけず大変な反響をいただきました。ありがとうございます。 今回はWeb制作において頻出度の高いアコーディオンをアクセシビリティを意識しながら作ってみたという「やってみた」系記事です。 今回の記事を書くにあたり、そめさんよりいくつかレビューを頂きました（ありがとうございます）。今回はそのレビューも含めて修正前と修正後も同時掲載します。 はじめに はじめに今回のアコーディオンのサンプルを掲載します。（サンプルではaria属性の付与はJSで行っています） この記事を書いた理由は WAI-ARIAの知識
Webサービスのアクセシビリティについて 考慮すべきポイントを挙げてく
WebサービスやWebサイトを開発するうえで最低限おさえておきたいアクセシビリティのポイントを雑多に挙げてく。ある程度のボリュームになったら記事にする予定。
マークアップを進化させる 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 開いてい
折り畳み UI のスクリーンリーダー対応 | Accessible & Usable
公開日 : 2015年7月1日 (2023年9月7日 更新) カテゴリー : アクセシビリティ 最近のウェブサイトでは、ユーザーの任意操作 (クリックやタップ) によって、機能やコンテンツを展開する/折り畳むユーザーインターフェース (UI) をよく見かけます。たとえば以下のようなものです。 メガメニュー ハンバーガーアイコン (押すとメニューが展開表示される) 虫眼鏡アイコン (押すと検索窓が出現する) アコーディオン これらの UI は当然アクセシビリティが担保されるべきで、キーボードによる操作 (Tab キーでフォーカスを当てて Enter キーで展開/折り畳みを実行する) が可能だったり、スクリーンリーダー (音声読み上げ) でも利用可能であることが求められます。 特にスクリーンリーダーでの利用に向けては、一連のインタラクションを完遂するうえで手掛かりとなる情報がすべて音声によって
aria-expandedのよくある間違い | masuP.net
WAI-ARIAの中で、コンテンツが展開されているかどうかの状態を表すaria-expandedは、WAI-ARIAの中でもよく使われている属性のうちの一つ[注1]ですが、誤った使い方をみかけることも少なくありません。また私自身も間違った理解のまま使用していた時期もありました。 [注1] : 出典 Usage of ARIA attributes - Analysis - Discuss - HTTP Archive そこでaria-expandedのよく見かける間違いと、仕様に基づいた正しい使い方をまとめました。 間違いその1：aria-hiddenとaria-expandedを混同する aria-expanded は要素、または要素が制御する別のグループ化要素が、現在展開されるまたは折りたたまれるかどうかを示す。ステートです。要素そのものが隠れているかどうかを示すaria-hidden
ウェブサイトの配色で気を付けたい9つのこと | knowledge / baigie
ウェブサイトやアプリケーションにおいて配色の持つ役割は大きく、その設計は使いやすさに強く影響を及ぼします。今回は基本的ではあるけれど覚えておくと役立つ、配色にまつわる9つのトピックについて解説します。 なお、本記事では、配色が与える情緒的な印象の話は出てきません。印象論的な配色理論は、数多く存在する他の書籍や記事に譲るとして、主にユーザビリティやアクセシビリティ、ビジネス上の課題解決に繋がる、基本的なポイントに絞って解説していきます。 1. メインカラーに赤を安易に採用しない 色を知覚する視細胞の中で、赤錐体（赤に反応する視細胞）は緑や青のものより数が多いという研究結果があります。 人間の目は赤に対して敏感であるという現象は、いくつかの学術的な裏付けにより証明されている事実と言えるでしょう。 色覚のしくみ – 多様な色覚に対応したデザインと社会の改善 特定非営利活動法人カラーユニバーサルデ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://codepen.io/tak-dcxi/pen/eYdVGEv