2024年度リクルート エンジニアコース新人研修の講義資料です
「ディアブロ IV」では50以上のアクセシビリティ機能が利用可能。障害を持つプレイヤーにとって役立つ機能を多数追加 編集部:やわらぎ Activision Blizzard Japanは本日(2023年5月23日),「ディアブロ IV」(PC / PS5 / PS4 / Xbox Series X|S / Xbox One)にて50以上のアクセシビリティ機能が利用可能であることを発表した。 利用可能になる機能は,ボタン割り当て機能や,片手操作が可能になるアナログスティックの割り当て,フォントの色やサイズなどを変えられる字幕設定や,音声のテキスト化などだ。 本作のリード・アクセシビリティデザイナーである,ドリュー・マクロリー氏は,「開発チームは障害を持つプレイヤーにとって役に立つ機能を追加しながら、それ以外のプレイヤーのゲームプレイを損なうことがないように、慎重にバランスを取りながら、アクセ
About 5 years ago Mozilla shipped Firefox Quantum, an upgrade that included significant performance improvements for most Firefox users. Unfortunately, Firefox Quantum didn’t improve performance for people who use screen readers and other assistive technology. In some ways, our screen reader performance actually regressed with the architecture changes that Quantum delivered. The Firefox accessibil
Web Content Accessibility Guidelines (WCAG) 2.1 W3C Recommendation 21 September 2023 More details about this document This version: https://www.w3.org/TR/2023/REC-WCAG21-20230921/ Latest published version: https://www.w3.org/TR/WCAG21/ Latest editor's draft:https://w3c.github.io/wcag/guidelines/22/ History: https://www.w3.org/standards/history/WCAG21/ Commit history Implementation report: https://
An examination of design for readabilityAnd before we continue, let’s make it absolutely clear that we have no control of the color of the text in this very article, as it is hosted through Medium.com, which features poor visual accessibility of their site design. Further, Medium prevents their users from selecting black text as a choice. While Medium’s “Fischer-Price-simple” content creation is e
少数色覚者にとって黄緑とオレンジは見分けづらい組み合わせの一つです。この記事のタイトル画像とかなかなか最悪です。 WEB、アプリや印刷物などのメディアではだいぶカラーユニバーサルデザインの考え方が浸透してきており、デザイナーも多様な色覚でも読み違えないように配慮してデザインすることが当たり前になってきていると思います。 Photoshopなどのグラフィックツールには簡単に少数色覚の見え方を確認できるプレビューモードがありますし、AdobeColorを使えば無料で少数色覚の人が混同しやすい色かどうかをすぐに確かめられます。https://color.adobe.com/ja/create/color-accessibility 少数色覚が見分けづらい色の組み合わせだと「-」が表示されるしかし、工業製品の世界では少数色覚にとって見分けづらい緑とオレンジの組み合わせのLEDインジケータ(表示)を
あけましておめでとうございます。株式会社ミツエーリンクスの中村直樹です。昨年に引き続き、技術仕様と国内法整備に関して、2022年のWebアクセシビリティの短期的な予測をしてみます。 WCAG 2.2とWCAG 3.0 WCAG 2.2に関しては、2020年末では2021年2月にCandidate Recommendation(勧告候補)になる予定だったものが、ずるずるとスケジュールが後ろ倒しになっており、執筆時点の2021年12月初頭になっても未だに勧告候補のステータスにはない状況です。一方で、執筆時点でのWhat’s New in WCAG 2.2 Working Draftによれば、2022年6月にRecommendation(勧告)を発行するスケジュールとのことです。 このスケジュールに間に合わせるのであれば、逆算すると4月までに勧告候補を発行する必要があります。よって、4月に勧告候
Ameba事業部の谷(@hiloki)です。Amebaのデザインシステム Spindleのマネージャーをしつつ、UIの設計・開発をしています。 2021年は多くのガイドラインやUIコンポーネント設計・開発に取り組んできました。この記事ではCyberAgent Developers Advent Calendar 2021の3日目の記事として1年を振り返り、特に考えることの多かったカルーセルUI について、その設計視点やアクセシビリティを考えてみました。 カルーセルUI とは あらためてこの記事におけるカルーセルUI(以下「カルーセル」と呼称します)を定義します。 『デザイニング・インターフェイス(第2版)』におけるカルーセルの定義を引用すると下記のように説明されています。 視覚的に興味を引くことができる項目のリストを、横一列またはアーチ状に配置し、画像のサムネイルを左右にスクロールまたはス
TRILL開発部のiOSエンジニアの石田です。 今年もdelyではアドベントカレンダーを行っており、本記事はその2日目の記事となっています。 昨日の1日目の記事は奥原さん (@okutaku0507) の「プロダクトマネージャー3年目の教科書」という記事でした。delyのエースPdMである奥原さんによる大作となっていますので是非ご覧ください。 本記事では、機械学習を使ってUIを補完するAppleの研究について紹介します。 AppleはMachine Learning Researchで機械学習に関する様々な研究を発表しています。 その多くはコンピュータビジョンや音声・テキスト認識のような研究なのですが、機械学習xUIという研究も行っております。 本記事ではその中でも、アプリのスクリーンショット(画像)から機械学習を使ってUIコンポーネントを認識し、アクセシビリティ機能を補完するMaking
はじめに 私はGoが好きなので、disられている場面に遭遇すると心が痛みます。残念ながらプログラミング言語について深く語れるほどの知識や経験は持ち合わせていないため、世界が平和になることを祈るくらいしかできません。 (元ネタ)Go言語を嫌う6個の理由 - さめたコーヒー それはそれとして、Goが好きな理由を語る人はあまり見かけない気がします。この記事ではGoが好きな理由を視覚に障害のあるユーザーの視点から語ります。読み終えたところで得るものは何もありませんし、長いので覚悟して読んでください。 あなたは誰? 4年ほど業務でサーバーサイドのGoを書いています。また、業務で使いはじめる前から趣味でGoに触れていました。そのため無意識の内にひいきしているかもしれません。ただし、流行っているからといって理由もなくGoを勧めたりはしません。 視覚障害ならではのコーディング事情 Goが好きな理由と深く関
Explanation Enter a foreground and background color in RGB hexadecimal format or choose a color using the Color Picker. Enter an Alpha value to adjust the transparency of the foreground color. Use the Lightness slider to adjust the perceived lightness of the color. WCAG 2.0 level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG 2.1 requires a contrast rat
この記事は Front-End Study #3 で発表されたライブコーディングの内容を記事にしたものです。記事中のソースコードは GitHub でご覧いただけます。 この記事は、これまで一般的なフロントエンドエンジニアだった私が一年ほどアクセシビリティーについて勉強する上で 「最初に教えてくれればよかったのに〜!」と思った内容 を React と Next.js を用いて紹介するものとなっています。 読み終わった後に次にコードを書く際にふと意識できるようなアクセシビリティーの普遍的な事実を紹介し、最後に今後の React の動きについて軽く触れるものになっています。目次は次のとおりです: 基本事項 SPA のルーティングによる問題 リッチなコンポーネントでの例 Jest + React Testing Library でのテスト Reactとアクセシビリティーの今後の動き 役に立つweb
2019年10月12日(土曜)に PyCon mini Hiroshima 2019 を開催しました。 イベント自体については別の場で報告を書こうと思っていますが、チームから「ウェブサイト構築の話を共有してほしい」という意見があったので、忘れないうちに、まずここに書いておきます。 hiroshima.pycon.jp は2015から2016にかけては GitHub Pages で私が自分で作りました。 2018 からは参加費をいただくイベントとして開催することに決めて、専門家に制作をお願いして、WordPress で構築されました。 (現在は静的サイトに変換して残しています) 2019 では、もっと自分たちでコントロールしながら制作したいと考えて、Next.js を使いました。 さいわいチームにはコーディングもデザインもやっていただける Nyoho さんがおられて、私は作業をチェックして本
こんにちは、この 4 月にメルカリに新卒入社したフロントエンドエンジニアの @karszawa です。 この頃は Google I/O 2019 のキーノートでアクセシビリティが大きく取り上げられたり、Safari に Audit タブが追加されアクセシビリティに関する様々なテストできるようになったりと、フロントエンド界隈におけるアクセシビリティへの関心の高まりを感じます。 本記事では React アプリケーションのアクセシビリティをチェックするためのライブラリである React-axe と、その中心技術である axe-core を応用した様々なツールをご紹介します。 React-axe とは React-axe は React アプリケーションのアクセシビリティをチェックするためのツールです。チェックの結果は Chrome DevTools に表示され、開発中にアクセシビリティの問題に気
2019年5月16日、Global Accessibility Awareness Day に合わせて神戸で開催された「アクセシビリティの祭典」にて、今年もセッション登壇と NVDA の紹介ブース出展をさせていただきました。 リンクなど アクセシビリティの祭典2019 公式サイト Togetterまとめ 西本のセッション「スクリーンリーダーで使いやすいサービスやアプリを作りたい技術者の声」スライド おことわり:動画と一部画像を削除しています。 セッション登壇のふりかえり どうしてこういうタイトルになったのか、疑問ですよね。その疑問に答える時間すらなかったですね。。 最初に打診をうけたときから「若い人と一緒に登壇してもらう予定」と聞いていたのですが、まったく打ち合わせや準備が進まないまま3月になり4月になり、事前告知や情報保障のためにタイトルや内容を出すタイミングがやってきました。 私は「質
はじめに スマホアプリやWebアプリで、ボタンなどのUIを作る場合を考えます。例えばボタンの色と、その上の"OK"などのテキストの色を決める際に注意すべき点を紹介します。UIだけでなく、ドキュメントの図やプレゼン資料など、色を使う全ての場面に使えます。 例えば、スマホアプリに次のようなボタンがあるとします。 こういう配色のボタン、よく見ますよね。ところが、このボタンは背景の黄緑色と「今すぐ購入」のフォントの白の「コントラスト比」が低い、つまり「色の明るさの差」が少ないので、「文字が薄くて読めない」と感じるユーザーが存在します。 人間の色の感じ方はみな同じではなく、遺伝子の状況や疾患などによって異なります。例えば、正常とされる人とは異なった色に見えたり感じたりする「先天性色覚異常」は、日本人男性の20人に1人(5%)、日本人女性の500人に1人(0.2%)といわれており、男性ではAB型の血液
主にユーザー側の視点から語られることが多いアクセシビリティですが、制作という側からはどのように捉えることができるのでしょうか。2つの切り口から考えてみます。 # アクセシビリティという文脈において、何のためにHTMLを書くかという話になると マシンリーダビリティのため スクリーンリーダーのアクセシビリティのため というように、ユーザーが利用するため、というところにフォーカスした語られ方が多いように感じています もちろんユーザーのために作るというのは正しいのですが、今回はあえて視点を変えて、制作者自身の作るというところに視点を合わせて話してみたいと思っています 僕がどういうものなのかというと、 # 参照: 全部入りHTML太郎(@_yuheiy)さん | Twitter ツイッターでは「全部入りHTML太郎」という名前でやっています # 参照: シフトブレイン/スタンダードデザインユニット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く