並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 276件

新着順 人気順

a11yの検索結果1 - 40 件 / 276件

  • LCHは、UIにベストなカラースペース|hirotoarakawa

    Linearのリニューアル記事がすごく良かった。 A design reset (part I) How we redesigned the Linear UI (part Ⅱ) その記事の中で「LCHカラースペース」について書かれていた。知らなかったので調べてみると、以下の記事を見つけた。 この記事の内容を抜粋しながら、自分用に簡易なメモとしてまとめる。 LCHとは?LCHは簡単に言うと、異なる色相でも同じコントラストに見えるように構成されたカラースペース。 1976年に国際照明委員会 (International Commission on Illumination, CIE) によって最初に定義された色空間であるため、CIELAB とも呼ばれている。 LCH は、Lightness(明度)、Chroma(彩度)、Hue(色相)の略。 HSL と LCH の違いLightness(明度

      LCHは、UIにベストなカラースペース|hirotoarakawa
    • 西本卓也さん──人命を左右するアクセシビリティの分野で、自分の役割を果たしたい - Findy Engineer Lab

      コンピュータの画面に表示されている情報を合成音声で読み上げるスクリーンリーダー。視覚障害者がコンピュータを操作するために欠かせないソフトウェアだ。西本卓也さんは、オープンソースのスクリーンリーダー「NVDA」の日本語対応を最初に始め、10年以上に渡って開発をリードしてきた。 アクセシビリティに関わるきっかけは、視覚障害のある方がパソコンを練習する教室と接点ができ、その流れで、視覚障害者のためのタイピング練習ソフトウェアの開発に携わったこと。 「プロダクトを作って、視覚障害のある方に使ってもらうというのは、私の中ではとても貴重な経験でした。そういう方々のお役に立てたのが嬉しかった」 その後、スクリーンリーダーを取り巻く状況が、世界と日本とで大きく異なることを知り、自ら手を動かすことになる。 「オープンソースのスクリーンリーダーに、日本語の読み上げを組み込んでみようとして、いろいろ頑張ってみた

        西本卓也さん──人命を左右するアクセシビリティの分野で、自分の役割を果たしたい - Findy Engineer Lab
      • ウェブアクセシビリティハンドブック|ましじめ株式会社

        本ハンドブックは、WCAG 2.0(JIS X 8341-3:2016)の達成基準をもとに すべての利用者がウェブサイト利用できるようにするためのアクセシビリティ向上の具体的な指針と実践的なアドバイスを提供します。 はじめに ウェブアクセシビリティとは 運用時のウェブアクセシビリティの取り組み 開発時のウェブアクセシビリティの取り組み ウェブアクセシビリティ試験 ウェブアクセシビリティ試験の流れ ウェブアクセシビリティ方針(サンプル) ウェブアクセシビリティ検証結果(サンプル) ウェブアクセシビリティ検証試験実施ページリスト(サンプル) 参考 実装の参考 ツールの参考 達成基準(適合レベルA,AAを解説) 1. 知覚可能の原則 代替テキストのガイドライン 【A】非テキストコンテンツの達成基準 時間依存メディアのガイドライン 【A】音声だけまたは映像だけ(収録済み)の達成基準 【A】キャプシ

          ウェブアクセシビリティハンドブック|ましじめ株式会社
        • 全盲の人が点字ブロック上を歩いていたら「何か」に道を塞がれる→視覚障害者サポート用アプリのAIで画像解析で壊れた傘だったと判明

          暗闇の世界 @LW_darkness この前点字ブロック上を歩いていたら、何かがあって苦労しながら避けて通ったんだけど、何か分からなかったから写真撮ってビーマイAIで解析したら壊れた傘だったらしい。 転んだり怪我しなくてよかった。 もしこういうのを見たら、そっと脇に避けてもらえるとめちゃくちゃ助かります。 pic.twitter.com/dsIEHsZufN 2024-04-12 06:58:55

            全盲の人が点字ブロック上を歩いていたら「何か」に道を塞がれる→視覚障害者サポート用アプリのAIで画像解析で壊れた傘だったと判明
          • 【HTML】dl, dt, ddで組みたくなる表、tableにするのがいいかもね(スクリーンリーダーと検索エンジンのために)

            dl や ul で組むべきでないという主張ではありませんので誤解のなきよう! dl で書くんだ!と思える人はそれがいいと思います😉👍 私自身は dl と table が HTML の使い方としてはどちらも正解で差がないように感じられて、どちらを使うべきか判断がつかず悩んだ末、具体的なメリットの部分を見て table にしたという話です。 同じように迷った人の参考になれば幸いです。 詳しくは以降で説明します。 想定する表の内容 この記事の議論では、名前と値の組が複数並んでいる、メタデータの表を想定します。 プログラミング言語でいうところの、連想配列 (Map, Dictionary, JS では Object) の構造に相当します。 具体的には以下のようなものです。 会社概要(「会社名:〇〇、所在地:〇〇、資本金:〇〇、…」) 商品の仕様表(「商品名:〇〇、価格:〇〇、サイズ:〇〇、…」

              【HTML】dl, dt, ddで組みたくなる表、tableにするのがいいかもね(スクリーンリーダーと検索エンジンのために)
            • アクセシビリティチェックってどうやってるの?ということで、実際にやってみた。(その3) - 水底の血

              アクセシビリティチェックってどうやってるの?ということで、実際にやってみた。(その1)、(その2)の続きです。 おさらい 対象ページ:「アトリエ金工やまぐち」 Basic認証があるので、アクセシビリティ向上日誌1【各種ツール評価編】からたどってください @HeldaForStudy氏に了承を得てアクセシビリティチェックを行っています チェック基準:WCAG 2.1レベルA 文中のSCはSuccess Criteriaの略で達成基準のこと 目的はどうやってアクセシビリティチェックしているのか、チェックしながら何を考えているのかを書き記すことです 制作ページやチェック内容にネガティブなことをいいたいわけではありません チェックに抜け漏れ、誤りがあるかもしれません 仕様等は基本的に日本語訳を当たります では続きに入っていきましょう。 「ABOUT」セクション アクセシビリティチェックの経験がある

                アクセシビリティチェックってどうやってるの?ということで、実際にやってみた。(その3) - 水底の血
              • パスワードの入力文字列を任意で表示する | Accessible & Usable

                公開日 : 2024年3月23日 カテゴリー : ユーザビリティ / アクセシビリティ フォームのパスワード入力欄 (<input type="password">) は基本的に、入力された文字列がマスキングされ、代わりに文字数の分だけ「黒い点」が提示されるようになっています。他人によるパスワードの盗み見を防ぐためですが、ユーザーは、大半のケースでは背後から覗く人が誰もいない状況でパスワードを入力するでしょうし、入力した文字列が視認できないと正しくタイプできているか不安になったり、タイプミスしたときの修正がしづらい (どの箇所でミスしたか確信が持てず、はじめから入力し直さざるを得なくなる) といった問題もあるでしょう。こうしたことを考慮に入れると、パスワードのマスキングはユーザーの任意で解除できる (入力した文字列を表示させる) ようにしたほうが、ユーザビリティの観点では望ましいと考えるこ

                  パスワードの入力文字列を任意で表示する | Accessible & Usable
                • ymrl on X: "画像の代替テキスト(alt属性)の話をしていると、いろんな人が「AIでやればいいのに」という話をするのだけど、実際にそういう試みはけっこう存在しているのは知られていないんだな、と思う。 ちょっとスレッドに有名な例を書いておきます。" / Twitter

                  • 見えない人はWebをどう閲覧? 本紙サイトの課題にがくぜん、求められる「不十分と認める勇気」【動画も】:東京新聞 TOKYO Web

                    見えない人はWebをどう閲覧? 本紙サイトの課題にがくぜん、求められる「不十分と認める勇気」【動画も】

                      見えない人はWebをどう閲覧? 本紙サイトの課題にがくぜん、求められる「不十分と認める勇気」【動画も】:東京新聞 TOKYO Web
                    • アクセシビリティチェックってどうやってるの?ということで、実際にやってみた。(その1) - 水底の血

                      ツイッターでアクセシビリティ向上日誌2【目視試験編】‐Akira Tsuda Portfolio and Blogというのを見かけて、そういえばアクセシビリティチェックって何をどうしているのかという話をウェブ上でほとんど見かけない(というか自分は知らない)ので、思い切ってチェックの過程や考え方を書いてみようかなと。 チェック対象のサイトを作った@HeldaForStudy氏に尋ねたところ、題材として使ってよいという返事をいただいたので、「アトリエ金工やまぐち」のサイト1ページをチェックしてみることにします。 対象ページはBasic認証がかかっているので、アクセシビリティ向上日誌1【各種ツール評価編】からたどってください。 @HeldaForStudy氏はレベルはA*1でチェックしたとのことなので、チェック基準はWCAG 2.1レベルAでチェックすることにしましょう。 わたしは普段はCOB-

                        アクセシビリティチェックってどうやってるの?ということで、実際にやってみた。(その1) - 水底の血
                      • 東京ニトロ 🍉𝙏𝙤𝙠𝙮𝙤𝙉𝙞𝙩𝙧𝙤 on X: "おれはイオンシネマに怒っている。というのも今回の件で、イオンシネマのバリアフリー対応を調べようとしたら、ウェブサイトの時点でバリアと不平等があるからだ。 https://t.co/v4Z5yMV1zp" / Twitter

                        • axe-core/playwrightとmarkuplintを導入しアクセシビリティの自動テストをできるようにした

                          Web アクセシビリティに興味があったので、まず機械的なチェックツールから学んで知識を増やそうということでこのサイトに @axe-core/playwright と markuplint を導入してみました。 @axe-core/playwright のセットアップ 既に Playwright が導入されている状況を想定し進めます。まず@axe-core/playwright をインストールします。 pnpm add -D @axe-core/playwright このサイトの場合 VRT として Playwright を動かしているテストがあるので(過去資料)、そのプロセスに同居する形で axe を実行することにしました。 e2e.test.tsimport AxeBuilder from "@axe-core/playwright"; import type { Page, TestI

                            axe-core/playwrightとmarkuplintを導入しアクセシビリティの自動テストをできるようにした
                          • 車いすを押してきた人間として、いま複雑な気持ちでいる

                            俺は、爺さんと親父と2人の車いすを押してきた人間として、映画館の対応で炎上している今の騒動を複雑な気持ちで見ている。 少し愚痴を書き込みたい。 単純な話として、もし自分の働いているところにああいう車いすユーザーが来たら、表面的な対応は別としても内心では腹が立つ。これはもうしょうがない。 クソみたいなクレーマーは多いし、ちょっとこっちが仏心を出すとそこにつけこむクソ客も多い。 とりあえず言ってみて通ればめっけもん、一度通ればそっからはソコを最低ラインとしてさらに言う、対応できなきゃ文句を言う。対応する側としてはクソ客以外の何物でもない。 ただ、そういう対応する側からすると速やかにおかえり願えないかなと思うようなゴリゴリ押してくる車いすユーザーが先陣を切ってくれなければ、変わらなかっただろうな、とも思う自分が居る。 爺さんの時は、俺も車いすを押したが、主に調べたのは親父やおふくろだった。 何を

                              車いすを押してきた人間として、いま複雑な気持ちでいる
                            • 単体テストでスクリーンリーダーをシミュレートする Virtual Screen Reader

                              単体テストでスクリーンリーダーをシミュレートする Virtual Screen Reader 2024.03.16 Virtual Screen Reader は単体テストのためにスクリーンリーダをシミュレートするライブラリです。このライブラリを使うことでマウスやキボードの操作をテストするように、スクリーンリーダーにより期待する読み上げが行われるかどうかをテストできます。なお、Virtual Screen Reader はあくまでスクリーンリーダーの挙動を模倣したものであり、現実で使われているスクリーンリーダーによるテストを代替するものではないことに注意してください。

                                単体テストでスクリーンリーダーをシミュレートする Virtual Screen Reader
                              • プレースホルダーのアクセシビリティ上の課題と解決策 - SmartHR Tech Blog

                                こんにちは!SmartHRプロダクトエンジニアのhimiです。 この記事ではプレースホルダーのアクセシビリティとユーザビリティについての課題と、その解決手段についての話を書きます。 プレースホルダーって何? Webアプリでよく見る、フォームコントロールに値が無いときに表示するテキストのことです。 主な用途としては、フォームの入力例や入力内容の説明テキストが設定されることが多いです。 HTML Standardでは The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief de

                                  プレースホルダーのアクセシビリティ上の課題と解決策 - SmartHR Tech Blog
                                • フォームのアクセシビリティを考える

                                  フォームのアクセシビリティを考える 2024.03.10 今日の Web におけるフォームはユーザーが情報を入力して対話するための重要な要素です。支援技術を利用しているユーザーがフォームの入力を妨げられることは当然避けるべきでしょう。また障害の有無に関わらず、ユーザーに迷いを与えたり、入力ミスを誘発するようなフォームはユーザーがタスクを完了せずに途中で離脱してしまう可能性が高まり、ビジネスの観点からも望ましくありません。この記事ではフォームのアクセシビリティについて考え、実際のフォームの実装においてどのような点に注意すべきかを紹介します。 今日の Web におけるフォームはユーザーが情報を入力して対話するための重要な要素です。スクリーンリーダーといった支援技術を利用しているユーザーがフォームの入力を妨げられることは当然避けるべきでしょう。また障害の有無に関わらず、ユーザーに迷いを与えたり、

                                    フォームのアクセシビリティを考える
                                  • チームラボ、成田国際空港公式WEBサイトのリニューアルにおいて、企画、UI/UX設計、デザイン、開発を担当。2024年2月21日公開。

                                    チームラボは、成田国際空港公式WEBサイトのリニューアルにおいて、企画、UI/UX設計、デザイン、開発を担当しました。全ての人の快適な空港体験をサポートするサイトに。2024年2月21日公開。 「ハブ・アンド・スポーク」をコンセプトに、これまでサイト内に、バラバラに点在していたコンテンツを、再整理しました。ページ間のつながりに一貫したルールを設け、かつ、カテゴリ横断で情報を集約し、連携するいくつかのハブを設ける情報設計によって、さまざまな目的を持ったユーザーが、求める情報へストレスなくたどりつけるサイト構造を実現すべく、再構築しました。 「チームラボCMS」の導入によって、サイト内のコンテンツの一元的管理と動的なページ生成を可能にし、有機的なコンテンツの集約と連携を実現しています。 また、すべてのユーザーへの使いやすさを確保することを目的にウェブアクセシビリティの改善を徹底し、日本工業規格

                                      チームラボ、成田国際空港公式WEBサイトのリニューアルにおいて、企画、UI/UX設計、デザイン、開発を担当。2024年2月21日公開。
                                    • Webアクセシビリティと合理的配慮|ymrl

                                      2024年(令和6年)4月1日に日本では「障害者差別解消法」という法律の改正が施行され、民間の事業者にとっては「合理的配慮」が義務化されます。義務化するのはあくまで「合理的配慮」であって、法律の条文にはどこにも「Webアクセシビリティ」とは書かれていません。 ここについての誤解が数多く出回ってしまっていて、先日「2024年4月や6月の時点では、まだ日本でWebアクセシビリティが義務化されません」という記事を書きました。 この記事について、以下のような声をもらいました 「専門用語が多くてわかりにくい」 「アクセシビリティは『合理的配慮』ではなかったの?」 「なぜアクセシビリティを推進したい人たちが急に『義務ではない』と言い出したの?」 そこで、もう少し的を絞って、「合理的配慮」「環境の整備」「Webアクセシビリティ」などの言葉の意味や関係について、説明しようと思います。 (筆者は法律に関して

                                        Webアクセシビリティと合理的配慮|ymrl
                                      • ノーマルスターとグリーンスターが色弱に優しくなさすぎるからどうにかしてくれ。今更色は変えられないだろうから縁をつけるとかアクセントで縞模様にするとか。たまにもらってても誰がくれてるんかよくわからん - murlock のブックマーク / はてなブックマーク

                                        ノーマルスターとグリーンスターが色弱に優しくなさすぎるからどうにかしてくれ。今更色は変えられないだろうから縁をつけるとかアクセントで縞模様にするとか。たまにもらってても誰がくれてるんかよくわからん

                                          ノーマルスターとグリーンスターが色弱に優しくなさすぎるからどうにかしてくれ。今更色は変えられないだろうから縁をつけるとかアクセントで縞模様にするとか。たまにもらってても誰がくれてるんかよくわからん - murlock のブックマーク / はてなブックマーク
                                        • 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入5000社に行くまでの振り返り - ヴェルク - IT起業の記録

                                          2024年1月9日にboardの有料登録社数が5000社を突破したので振り返りです。 boardの正式リリースは2014年8月20日なので、約9年半ほどで、推移はこんな感じでした。 *「社数は累計ですか?」と聞かれることがよくあるのですが、累計ではなくその時点のアクティブな数です。 1000社刻みで定点観測的に書いているので、過去の記事も貼っておきます。 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス(BPStudy発表時の補足) 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入2000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入3000社に行くまでの振り返り 受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入4000社に行くまでの振り返り boardとは 見積書・請求書

                                            受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入5000社に行くまでの振り返り - ヴェルク - IT起業の記録
                                          • Designing better target sizes

                                            Intro As a user, you need to interact with clickable UI elements like buttons, links, cards, and more. If an action has a small target size, it will be harder for the user to click, or they might click an adjacent action element by mistake. Let’s take a look at the following example.

                                              Designing better target sizes
                                            • @storybook/cli - Storybook

                                              • QAが率先してアクセシビリティチェック品質をリードしたらいいことづくしだった - freee Developers Hub

                                                こんにちは。freee人事労務でQAエンジニアをしているshihoです。 freee QA Advent Calendar2023 15日目です。 自己紹介 元カスタマーサポートで、2016年8月にfreeeに入社しました。3年前にQAエンジニアに異動してから、品質保証の重要性とユーザーのニーズに焦点を当てた仕事に取り組んでいます。お客様との関わりがあった経験を活かし、使いやすく信頼性の高いプロダクトを提供することに情熱を燃やしています。 アクセシビリティとは アクセシビリティに関しては、さまざまな定義が存在しますが、freeeとしては特定の個人を対象とするのではなく、すべての人に使いやすいものを提供することを目指しています。また、特定の条件での使いやすさではなく、あらゆる条件下でも使用できることを重視しています。 アクセシビリティチェックに取り組むきっかけ 元々freeeに入る前は、アク

                                                  QAが率先してアクセシビリティチェック品質をリードしたらいいことづくしだった - freee Developers Hub
                                                • ユーザーが迷わないトグルスイッチの使い方 | ベイジのUIラボ

                                                  トグルスイッチとは状態のON/OFFを切り替えるためのUIパーツです。選択肢が明確にわかり直感的に操作できるトグルスイッチは、ユーザビリティを高めるための重要な要素です。しかしそのシンプルさゆえに、不適切な使われ方をしているケースを見かけます。トグルスイッチの機能と適切な使用方法を理解し、ポイントをおさえて設計することが大切です。 トグルスイッチの定義 トグルスイッチはウェブページやアプリケーションのコンポーネントです。同時に選択できない2つのオプションからいずれかを選択し、現在の状態を視覚的に表します。ユーザーがトグルスイッチのON/OFFを切り替えれば、ボタンの操作結果やオプションの変更設定がすぐにシステムに反映されます。 一般的に「トグルボタン」や「トグルスイッチ」と呼ばれることが多く、Material Design(※1)では「スイッチ」、Human Interface Guide

                                                    ユーザーが迷わないトグルスイッチの使い方 | ベイジのUIラボ
                                                  • アイコンボタンのアクセシブルな名前はボタンが持つべきかアイコンが持つべきか

                                                    本記事は<svg>要素のみを持つ<button>要素(アイコンボタン)にアクセシブルな名前(accessible name)を持たせる方法について調査した結果と、WCAG 2.2のSuccess Criterion 1.1.1 Non-text Contentに関する私見をまとめたものです。 結論 アイコンボタンの非テキストコンテンツは装飾ではなく意味を持つ画像なので、ボタンではなくアイコン画像自体にアクセシブルな名前を持たせるべきだと考えます 一方で、非テキストコンテンツの範囲をアイコンのみではなくアイコンボタン全体と捉えると、ボタンにアクセシブルな名前を持たせることも妥当に思えますが、<img>要素や<svg>要素など様々な種類のアイコン画像の実装を想定した場合、やはりボタンにアクセシブルな名前を持たせない方針に倒す方がシンプルだと思います <svg>要素のみを持つ<button>要素

                                                      アイコンボタンのアクセシブルな名前はボタンが持つべきかアイコンが持つべきか
                                                    • アクセシビリティの謬説

                                                      覆す アクセシビリティは一部のユーザーにしか影響を与えない 影響が小さいわけではない。世界の人口の約15%、推定10億人が障害を持って暮らしています。 障害者は世界最大のマイノリティです。 障害者の数は劇的に増加しています。 アクセシビリティは一部のユーザーにしか影響を与えないについて 詳細を見る 障害者はウェブサイトを利用していない どうしてそのようなことが言えるのでしょうか。 色覚異常や運動障害などの障害を持つ多くの人が、他のユーザーと同じようにウェブサイトを利用しています。 また、どのような手段をもってしても多くの支援技術では検出できません。 障害者はウェブサイトを利用していないことについて 詳細を見る ウェブサイトをアクセシブルにするには、コストと時間がかかる プロジェクトの初期段階からアクセシビリティを考慮し、開発チームが適切なスキルを持っていれば、そのようなことはないかもしれま

                                                        アクセシビリティの謬説
                                                      • aria-labelで始める、アクセシビリティ改善活動

                                                        そもそもアクセシブルなサービスとは、どのようなサービス、実装を指すのでしょうか。 端的に表現するならば、「伝えたい情報が正しい文書構造によって実装されているサービス」だと考えます。 例えば以下のようなボタンの実装があったとします。 こちらがレンダリングされた結果です。 こちらがスクリーンリーダーの結果です。 (Macの場合command+F5でVoiceOverを使用することができます。) この例の場合、視覚的な情報と、支援技術を介して得られる情報とで差異が産まれてしまっています。これはアクセシブルではありません。(例外[1]もあります。) この例の場合、ボタンの働きが編集であれば、スクリーンリーダーにより取得した削除という情報は誤りになります。 スクリーンリーダーのような支援技術は、アクセシビリティツリーを元に情報の処理・出力を行います。 このアクセシビリティツリーは、DOMツリーという

                                                          aria-labelで始める、アクセシビリティ改善活動
                                                        • ウェブコンテンツアクセシビリティガイドライン(WCAG)は何が難しいのか、あるいは難しさに立ち向かう方法 - 水底の血

                                                          LINEヤフーにおけるこれからのアクセシビリティというスライドで「WCAGはハードルが高い」という文言を見かけました。どうしてハードルが高い、言いかえるならば難しいとされるのか、その難しさはどこから来るのかをちょっと深掘りしてみようと思います。 WCAGという言葉について、改めて見ておきましょう。WCAGはもっぱら、Web Content Accessibility Guidelines(ウェブコンテンツアクセシビリティガイドライン)というW3Cの発行する技術文書を指すわけですけども、現時点でよく参照されるのがウェブアクセシビリティ基盤委員会(WAIC)が公開している日本語訳のWCAG 2.1でしょう。ちなみに本家のW3Cは、WAICが現時点で公開しているWCAG 2.1の改訂版を今年9月に公開し、さらにバージョンの進んだWCAG 2.2を先月に発行したばかりだったりします。 WCAG 2

                                                            ウェブコンテンツアクセシビリティガイドライン(WCAG)は何が難しいのか、あるいは難しさに立ち向かう方法 - 水底の血
                                                          • Don't disable buttons

                                                            One of the most common accessibility issues I find (and fix) on client projects is dynamically disabled form buttons when a form is being submitted. Today I want to talk about why developers do it, why it’s bad, and what you can do instead. Let’s dig in! Why developers disable buttons Typically, I see the pattern used to prevent a form from being submitted a second time while waiting for the form

                                                              Don't disable buttons
                                                            • とってもやさしいウェブアクセシビリティチェックリスト|i3DESIGN Designers

                                                              こんにちは!i3DESIGNデザイナーチームです。 今回は、先日発刊させて頂きましたホワイトペーパー”とってもやさしいウェブアクセシビリティチェックリスト”の一部を記事にまとめたいと思います。 ホワイトペーパーには、ウェブアクセシビリティチェックリストというシートがあります。 このシートは、JIS X 8341-3:2016(アクセシビリティについてのJIS規格)に基づき、私たちの解釈で分類・文章を再構成しました。 エンジニアやデザイナーでない方でも理解しやすいよう、一部内容を簡略化したり、複数の達成基準をひとつにまとめたりしている箇所があります。 このチェックリストを「現在提供しているウェブサービスが、どこまで達成できているのか」を図る指標として、ご活用ください。 👇ウェブアクセシビリティチェックリストがついているホワイトペーパー”とってもやさしいウェ

                                                                とってもやさしいウェブアクセシビリティチェックリスト|i3DESIGN Designers
                                                              • ウェブアクセシビリティは合理的配慮ですか?(追記あり) - 水底の血

                                                                一般にウェブアクセシビリティは、合理的配慮の事前的改善措置となる、環境の整備に分類されます。総務省のみんなの公共サイト運用ガイドライン(2016年版)によれば、 障害者差別解消法(平成 28 年 4 月 1 日施行)において、ウェブアクセシビリティを含む情報アクセシビリティは、合理的配慮を的確に行うための環境の整備と位置づけられており、事前的改善措置として計画的に推進することが求められています。 とあり…などと自信満々に答えられてたのですが、政府広報オンラインのウェブアクセシビリティとは?分かりやすくゼロから解説!という記事(下記スクリーンショット中の下線は筆者によります。*1)によると、 障害者のある人への合理的配慮とは、(中略)ウェブサイトの場合ではJIS X 8341-3:2016に準拠したウェブサイトを作り、ウェブアクセシビリティを確保することがこれに当たります。 とあるわけで、J

                                                                  ウェブアクセシビリティは合理的配慮ですか?(追記あり) - 水底の血
                                                                • 第3回 APCAを活用して文字の視認性を確保したデザインを実践する | gihyo.jp

                                                                  しかし、実際のデザインではこの表にないフォントサイズやウェイトを使いたい場合もあるでしょう。その場合には、シミュレータやルックアップテーブルを参照することで、より精度の高い確認が可能になります。 ルックアップテーブルでフォントサイズとウェイトから必要なコントラストを確認する シミュレーションの説明の前に、より細かい基準がどのように定められているか見るために、APCAのルックアップテーブルを見てみましょう。 このルックアップテーブルは、WCAG3のシルバーレベルを満たすための基準を示しています。ブロンズレベルに追加して、この基準に準拠することでより精度の高いコントラストの確保が可能になります。 以下は、公式のシミュレーションサイトAPCA Contrast Calculatorにあるルックアップテーブルのスナップショットです。ページの下部、APCA Font Table: Silver Le

                                                                    第3回 APCAを活用して文字の視認性を確保したデザインを実践する | gihyo.jp
                                                                  • 第3回支援技術利用状況調査報告書 | 日本視覚障害者ICTネットワーク

                                                                    掲載:2023年9月30日 はじめに この報告書は、日本視覚障害者ICTネットワーク (JBICT.Net) が2023年5月から6月にかけて実施した第3回支援技術利用状況調査の結果をまとめたものです。 各設問(報告書末尾の「参考:設問一覧」を参照)への回答状況と、これらに基づいた集計結果の一部を示します。また、参考情報として、2022年に実施した前回調査の結果との比較を示している項目もあります。 参考:過去の調査結果 第2回支援技術利用状況調査報告書(2022年実施) 第1回支援技術利用状況調査報告書(2021年実施) 本報告書の著作権等 第3回支援技術利用状況調査報告書は、日本視覚障害者ICTネットワーク (JBICT.Net)が著作権を有し、CC BY-NC-ND 4.0 で公開しています。 Copyright © 2023 日本視覚障害者ICTネットワーク (JBICT.Net)

                                                                    • 第2回 WCAG3のコントラスト基準APCAの考え方と実例 | gihyo.jp

                                                                      デジタルコンテンツにおけるアクセシビリティ、特にコントラストの基準について解説する連載の第2回目です。前回の記事では、現在のWCAG2のコントラスト基準と課題について解説しました。今回はWCAG3で採用が検討されている新しいコントラスト基準、APCAについて解説します。 APCAとは WCAG 2.0でコントラストの基準が策定されて以降、ディスプレイやWebコンテンツ、CSSの機能、および視覚科学の進歩など様々な状況が変化しました。WCAGの基準についても、コントラストや視認性についてより知覚を正しくモデル化するガイドラインが求められるようになりました。 APCA(Advanced Perceptual Contrast Algorithm)はWCAG3にて現行のコントラストに代わる基準として開発・検討されている、新しいコントラスト基準です。前回紹介したようなWCAG2の基準の課題に応える

                                                                        第2回 WCAG3のコントラスト基準APCAの考え方と実例 | gihyo.jp
                                                                      • 第1回 デジタルコンテンツの視認性とWCAG2のコントラスト比の課題 | gihyo.jp

                                                                        はじめに サイオステクノロジーの伊藤と申します。今回から数回にわたりデジタルコンテンツのコントラストというテーマで、WCAG2のコントラスト基準とWCAG3で検討が進められている新しい基準APCAについて解説していきます。 対象読者としては、ウェブサイトやアプリケーションなどデジタルコンテンツの制作に携わるデザイナーやエンジニア、アクセシビリティに関心のある方を想定しています。 現在勧告されているWCAG2の達成基準では、テキストや視覚要素のコントラストが一定の基準を満たす必要があります。たとえば、レベルAAでは文字色と背景色のコントラスト比が4.5:1以上であることが要求されます。 図1 テキストとの視認性を確保するために、背景色とのコントラスト比を考える必要がある しかし、人間の目は明るい色と暗い色のコントラストを認識する際に、明るい色の相対輝度が高いほど視認性が高くなるという特性があ

                                                                          第1回 デジタルコンテンツの視認性とWCAG2のコントラスト比の課題 | gihyo.jp
                                                                        • WCAG 2.2の勧告とWCAG 2.1の更新 | アクセシビリティBlog | ミツエーリンクス

                                                                          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の話

                                                                            WCAG 2.2の勧告とWCAG 2.1の更新 | アクセシビリティBlog | ミツエーリンクス
                                                                          • VUEVO(ビューボ) | みんなの会話を視覚化し、聞こえの違いをつなぐサービス

                                                                            VUEVO(ビューボ)は、聴覚障害や聞こえにくさがある人と聴者のコミュニケーションをスムーズにしたい、それにより互いに余計なストレスや気遣い無くもっと向き合える機会を増やしたい、という想いからスタートしたサービスです。聴覚障害者と聴者の間には、職場での聞こえの違いによって会議など複数人の会話の場でコミュニケーションが難しいという課題があります。ピクシーダストテクノロジーズの先端技術を用いて開発したVUEVOは、「誰が」「何を」話しているかをリアルタイムに直感的に表示することでこの課題を解決します。

                                                                              VUEVO(ビューボ) | みんなの会話を視覚化し、聞こえの違いをつなぐサービス
                                                                            • アクセシビリティカンファレンス福岡

                                                                              ここにいる。 アクセシビリティにかぎった話ではありませんが、あらゆる活動は多くのエネルギーを必要とします。 小さな地域での取り組みは、ときどき「仲間は近くにいるのだろうか」と不安が頭をよぎることがあります。 しかし、確かに仲間は存在し、その取り組みは組織を超え、地域を超えて広がっています。 本来は場所に縛られない活動ではあるのですが、その実感を得るために、今回あえて福岡での開催を選びました。 「わたしたちは、ここにいて、そして安心して取り組めるんだ」と、このイベントを通して証明します。

                                                                                アクセシビリティカンファレンス福岡
                                                                              • アクセシビリティーに考慮するHTMLコーディング - WAI-ARIAでスクリーンリーダーの読み上げがこう変わる - ICS MEDIA

                                                                                ナビゲーションリスト ナビゲーションリストは、主にメニューやリンクの一覧を整理して表示するためのUI要素です。自分が今どのページを訪れているのかを示すことによって、ユーザーはウェブサイトの構造や階層を理解しやすくなります。 ▼ 実装例(一部抜粋) <li><a href="#">CSS</a></li> <li><a href="#" aria-current="page">JavaScript</a></li> <li><a href="#">その他</a></li> ▼ スクリーンリーダー(VoiceOver) aria-current="page"を指定した要素は「現在のページ、リンク、JavaScript」と読み上げられます。また、リンクが一度でもクリックされていたら、「閲覧済み」という音声が追加されます。 ▼ スクリーンリーダー(ナレーター) 「リンク、JavaScript」と読

                                                                                  アクセシビリティーに考慮するHTMLコーディング - WAI-ARIAでスクリーンリーダーの読み上げがこう変わる - ICS MEDIA
                                                                                • Webアクセシビリティ入門

                                                                                  2023年度リクルート エンジニアコース新人研修の講義資料です

                                                                                    Webアクセシビリティ入門