web アクセシビリティに、どうやって対応したら良いか？を 手助けするツールを作りました。 WCAG2.0 の達成基準に合わせた実装方法を確認し、試験結果を記録することができます。 ■ WCAG 2.0 達成基準・実装チェックリスト https://a11y-i-guideline.netlify.com （chrome ブラウザでしか挙動確認してません） 対象 web コンテンツで JIS X 8341-3:2016・WCAG2.0 への対応を求められた コーダー、ディレクター、デザイナー 目次 アクセシビリティ用語解説 実装チェックリストでできること 各ポジション別確認ポイント 使い方 アクセシビリティ用語解説 web アクセシビリティ 一般的に「障害者対応」と考えられるが、メガネがない・眩しい屋外など健常者にとっての 一時的な状況でも、誰でも web コンテンツを支障なく利用できる状

UXエンジニアの谷です。 「クリエイターHangout」はデザイナー数名のグループで構成される社内のコミュニティです。（Hangoutについては過去の井上の記事をご覧ください。）定期的ににテーマを設けての勉強会や活動をおこなっているのですが、その機会に今回講師として参加させてもらいました。 ▼今期のHangoutのグループ Webフロントエンドエンジニアでもある私が講師を勤めたのは「デザインとエンジニアリング」です。今回はデザイナーとエンジニアのコミュニケーションにおいて、課題となる「色」を主題に「デザインシステム」のトピックを交えておこないました。 1. デザインシステムの定義とは 2. 第1回 色の棚卸し 3. 第2回 & 第3回 色の整理 4. 第4回 コントラストチェック 5. 色と名前を決めることの難しさ 6. デザインシステムはどこまで作り込むか デザインシステムの定義とは 「

Mobile Act OSAKA #11 にて、Accessibility のはじめ方についてお話しました。

HTMLには画像に「代替テキスト」と呼ばれる値を設定する機能があります。 ユーザーがもし画像を利用できない状況にあるとき、画像の代わりにこの代替テキストが提供されます。 画像のパスが間違っていたり、ページの読み込みが途中で中断されてしまったりしてデータをうまく読み込めない場面はたまにあります。そういったとき、この代替テキストの値が画像の代わりに表示されます。 通信状況が悪いときや、画像が表示されないまま長い間更新されなくなったサイトを閲覧しているときでも、適切な代替テキストが設定されていれば最低限の情報は得られます。 支援技術を利用してサイトを閲覧しているユーザーにもこの代替テキストが提供されます。 支援技術というのは、主に障害者がパソコン利用の際に、操作の補助を行うために併用されるハードウェアとかソフトウェアです。 支援技術のひとつであるスクリーンリーダーを利用すると、画面上の情報をコン

ということなので、新規投稿で画像を入れて検証。 なお検証はVoiceOverです。 「プールで遊ぶマメヒコ」を入れてみよう 「プールで遊ぶマメヒコ.jpg」とリネームしたところ、alt属性に「プールで遊ぶマメヒコ」が入った。 ファイル名をリネームしない次はモバイルで撮影した写真。リネームせずに「59905707_2369286120013939_4824854642716311552_n.jpg」という名前でアップロード。 するとalt属性には「画像2」と入った。ここではなぜファイル名の英数字の羅列ではないのだろう。そういうメタ情報を判別しているのか？あるいはファイル名の内容で判別している？ 半角英数字なファイル名でリネーム試しに半角英数字なファイル名にリネーム。「181003mamehiko_in_the_pool.jpg」とする。 すると「画像3」とalt属性に入り、

iOSDC Japan 2019 すべての人のためのアクセシビリティ対応【省略版】

英国内務省がウェブアクセシビリティを高めるための啓蒙ポスターを発表し、日本語訳も登場した。障害者にも健常者にもやさしいウェブのために、まずは「知ること」から始めたい。 この夏の参議院選挙で、重度障害者の国会議員が誕生した。快挙に喜ぶのも束の間、「国会議員が国会に登庁する」ために、参議院のバリアフリー化が進められた。 大型の車椅子で利用できるスロープや車いす用トイレの設置、パソコンの持ち込みや、本人の代わりに挙手や投票を行う介助者の付き添い。一連の合理的配慮の実施を報じるニュースを通して、健常者が日頃は気づかない「不自由さ」の数々に気づかされた。 オンラインにおける健常者と障害者の壁 こうした「不自由さ」は、私たちが毎日のように利用しているインターネット上にも無数に存在する。障害のある人のうち、半数以上がインターネットを利用しているが、彼らが私たちと同じ体験を得られているわけではない。 例え

Public file shared from https://slack.com/

何が問題かおさらいユーザーテストでは、スクリーンリーダーでタブを読む際に問題が起こりました（ユーザーテストの詳細は、第4回をご覧ください）。問題となった動きをおさらいすると、次の通りです。 「料金表」というタブにフォーカスを合わせることはできた（「料金表」というリンクとして伝わる）リンクを選択すると、見た目の上では下部のコンテンツが切り替わり、料金表が表示されるしかし、スクリーンリーダーでは切り替わったことが通知されず、リンクを選択しても何も起きないように感じられる何かが切り替わったと予想できても、切り替わったコンテンツに移動することが困難問題はスクリーンリーダーで「タブ」がうまく扱えないことこの問題を一言でまとめると、スクリーンリーダーで「タブ」がうまく扱えていない、ということになります。なぜこのタブは、スクリーンリーダーでうまく扱えないのでしょうか。 実は、Webで使われているタブの多

こんにちは。Backlogチームの中川です。 本記事では、Backlogが最近おこなっているスクリーンリーダー向けアクセシビリティ改善の取り組みを元に、明日から、いや、今開いてる画面からでも始められるアクセシビリティ改善についてご紹介します。 ちなみに、スクリーンリーダーって何？という方のために簡単にご説明しますと、スクリーンリーダーとは、視覚障がいを持つ方がPCを操作するのに使用する音声読み上げソフトです。無料で代表的なものは、Windows では NVDA、Mac では標準搭載されている VoiceOver などがあります。Backlogの改善では主にNVDAを使用して確認作業を行っています。 すぐにでも始められる作業コストが少ない改善 見出しをちゃんとマークアップする スクリーンリーダーではコンテンツ間を移動するのに、見出しを手がかりにすることが多いので、見た目の文字サイズではなく文

主にユーザー側の視点から語られることが多いアクセシビリティですが、制作という側からはどのように捉えることができるのでしょうか。2つの切り口から考えてみます。 # アクセシビリティという文脈において、何のためにHTMLを書くかという話になると マシンリーダビリティのため スクリーンリーダーのアクセシビリティのため というように、ユーザーが利用するため、というところにフォーカスした語られ方が多いように感じています もちろんユーザーのために作るというのは正しいのですが、今回はあえて視点を変えて、制作者自身の作るというところに視点を合わせて話してみたいと思っています 僕がどういうものなのかというと、 # 参照: 全部入りHTML太郎(@_yuheiy)さん | Twitter ツイッターでは「全部入りHTML太郎」という名前でやっています # 参照: シフトブレイン／スタンダードデザインユニット

前回の「アクセシビリティを考慮したデータ・テーブルのコーディングやってますか？（基本編）」の続きで、今回はもう少し複雑なテーブルについて（の考察を）まとめてみます。具体的に言うと行と列をスパンさせる場合のコーディングのやり方です。そもそも複雑なテーブルはシンプルなものに置き換えるという考えをベースにしつつ、列をスパンさせる場合のcolgroupと、行をスパンさせる場合のrowgroup + tbodyを使ったコーディングのやり方を整理してみました。 それ、本当に役に立つの？ はじめにネタばらし的に書いてしまうと、実は今回紹介するデータ・テーブルの例では、colgroupやrowgroupを使っても使わなくてもVoiceOverでの読み上げに違いがありませんでした。ググると出てくるidとheaders属性を使うやり方も試してみましたが、こちらも読み上げに変わりはありませんでした（idとhea

岡山で「リーダブルな夜」というアクセシビリティに関する情報共有を中心に考える勉強会を澤田さん、前川さんが立ち上げ、私も運営の手伝いを少しだけさせてもらっています。 その際に少し思ったことがあってちょっとダラダラと思ったことを書いてみた。本当にダラダラとしているので悪しからず。 altを考える 先日11/5に「代替テキスト祭り」というテーマで開催し、私も進行役としてお手伝いをすることになりました。 事前に用意しておいたフォームに入力していただくワーク中。 最初に先入観のない状態で、お題の画像にそれぞれ代替テキストを入力してもらうワークを行い、そのあと澤田さんのセッション。最後に答え合わせ。 答えといっても明確で確実な正解はないので、「これはどういった理由で入れた？」「他の人はどう入れている？」などガヤガヤするといった流れで進行。 私の進行はグダグダでしたが、普段何気なく入れている“alt”に

この記事はWebアクセシビリティ Advent Calendarー2018 9日目の記事です。遅くなってしまい、本当にすみません！ 私は受託のウェブ制作会社に勤めております。2018年は念願叶ってウェブアクセシビリティ対応が要件に含まれる案件にいくつか関わることができました。そのときのことについて、ざっくり書いておきます。 内容 アクセシビリティ対応 (JIS X 8341-3:2016 適合レベルAA準拠) が要件に含まれる、規模が大きくないウェブサイト わたしは実装の一部とアクセシビリティまわり？を担当 自分がやったアクセシビリティ対応に関わる作業 アクセシビリティ方針の策定とページの作成 実装チェックリストの作成 達成基準チェックリストの作成 アクセシビリティ試験の実施と試験結果ページの作成 大変じゃなかったこと アクセシビリティ対応のコストが大きい複雑なUIがなかった 実装メンバー

公開日 : 2018年7月6日 カテゴリー : アクセシビリティ サイト共通ヘッダーに、サイト内検索機能を開閉するボタン (虫眼鏡アイコン) を配置して、ボタンが押されると検索窓を開く、というユーザーインターフェース (UI) をよく見かけます。関わっているプロジェクトで、この手のボタンに対して role="search" というランドマークを付けるべきか？という興味深い議論がありました。 サイト内検索機能を開閉するボタン (虫眼鏡アイコン) に role="search" というランドマークを付けるべきか？ ランドマークの利点 role="search" (以下、「検索」ランドマーク) とは、WAI-ARIA で定義されているランドマーク (Landmark Roles) のひとつです。HTML の要素の中に role 属性を書くことで実装できますが、role 属性値は「search」の

情報収集を効率化する自然言語処理の活用方法 〜PythonではじめるAwesomeリポジトリの作り方〜 / pycon-apac-2023

Enabled through the "Experimental Web Platform features" flag in chrome://flags