※前編がこちらにあります 目次 icon links inputs keyboard navigation navigation menu modals prefers-reduced-* “skip” links SVGs tabs tables toggle switches tools tooltips video/audio players アクセシブルなインプット 2019年、WebAIMは上位100万件のWebサイトのアクセシビリティを分析し、エラーがないページの推定割合は1%未満というショッキングな結論に到達しました。アシスティブテクノロジー（支援技術）に頼っている人にとってインクルーシブで使いやすいサイトを作成するには、セマンティックHTMLの基礎を正しく理解する必要があります。Oscar Braunertのインクルーシブなインプットに関する記事は、彼の「小さく始めて共有・

クイックサマリー ‐ 私たちは一連の短い記事で開発者とデザイナーにとって有用なツールやテクニックを紹介しており、直近の記事では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

本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを

数週間ほど前にオランダのウィンデスハイム実務専門大学校で客員の講師として講義を行いました。私自身、同学校の卒業生で、恩師たちと連絡を取り続けています。最近、恩師の1人から、多くの学生がITのセキュリティとハッキングについて深く学びたがっているという話があり、客員として講義しないかと招待がありました。喜んで！　講義を面白くするためにハッキングのデモも行うことにしました。 ハッキングのデモを始めたときに、学生に企業の名前を聞き、続いて私がその企業のセキュリティを検査したら面白そうだと考えました。次の段階で全く驚きの発見をしてしまい、その企業のセキュリティを保護するため、デモの方向性を変えざるを得ませんでした。 ユニリーバをハッキング？ ある学生がオランダでも有名な企業であるユニリーバの名を挙げ、私はこの企業を調べるのが良さそうだと思いました。もちろん法律の範囲内で、です。ユニリーバのサイトのH

以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ

文：Daniel Sim　分析：Lee Shangqian、Daniel Sim、Clarence Ng ここ数ヶ月、シンガポールのMRT環状線では列車が何度も止まるものの、その原因が分からないため、通勤客の大きな混乱や心配の種となっていました。 私も多くの同僚と同じように環状線を使ってワンノースのオフィスに通っています。そのため、11月5日に列車が止まる原因を調査する依頼がチームに来た時は、ためらうことなく業務に携わることを志願しました。 鉄道運営会社SMRTと陸上交通庁（LTA）による事前調査から、いくつかの電車の信号を消失させる信号の干渉があり、それがインシデントを引き起こすことが既に分かっていました。信号が消失すると列車の安全機能である緊急ブレーキが作動するため、不規則に電車が止まる原因となります。 しかし8月に初めて発生した今回のインシデントは、不規則に起こっているように見えるた

安全で堅牢なWebアプリケーションをクラウドで開発するのは 非常に困難 です。それを簡単だと思っているような人は、例えばとんでもない頭脳をお持ちというなら別ですが、遠からず痛い目を見ることになるでしょう。 もし MVP（Minimal Viable Product：必要最低限の機能を備えた製品） のコンセプトを鵜呑みにして、有益かつ安全な製品を1ヶ月で作成できると考えているようなら、プロトタイプを立ち上げる前に一度考え直した方がいいと思います。以下に挙げたチェックリストをご覧いただければ、セキュリティに関するクリティカルな問題の多くをスキップしていることが分かるはずです。あるいは少なくとも、潜在的なユーザに対しては 誠実 であるように心がけ、製品が完全ではないこと、そしてセキュリティが不十分な製品を提供していることを伝えるようにしてください。 このチェックリストはシンプルなもので、決して完

(訳注：2020/08/22、画像と動画が正しく表示されていなかったためリンクを修正しました。) こんにちは。このブログは12月にO’Reillyから出版予定の私の著書『 Designing Products People Love 』からの抜粋です。ぜひ本も読んでみてください。また、FacebookやTwitter、 Slackなどで活躍されている20人以上のプロダクトデザイナーにインタビューもしています。* 無味乾燥なUIを経験したことはありますか？ 何か が足りないと感じてしまうようなUIを作ってしまったことはありませんか？ もしそうであれば、使い勝手の悪いUIを経験したのだと思います。 使い勝手の悪いUIには進捗インジケータがありません。ユーザにどこで障害が起きたのか知らせてくれません。怖いエラーメッセージでも表示してくれれば、なお良いのですが。わずかなデータのみの奇妙なグラフです

前のブログ記事 を書いた時、「訓練された目ならば、不親切なソフトウェアを結構な頻度で簡単に見抜けるようになる」ということに気づきました。 それは初対面の人に第一印象を抱くのに似ています。私たちは初めて会った人の印象を判断するのに コンマ1秒もかからないそうです 。 人を判断するのとは違い、ユーザインターフェースの良しあしを判断することは、私たちが（今はまだ）本能的に行っていることではありません。しかし、たった数分で、もしくはもっと早く、ユーザインターフェースがじっくり考えられて作られたものか、ちょっとした思い付きで作られたものかどうかを判断することは可能です。 どうして判断がついたのかや、どんな警告サインが出ていたのかについては確証がなかったため、私は注意を払い、メモを取ることにしました。 以下は私が気付いたことです。 用語/ラベルの使い方があまりに総称的/一貫性していない これはユーザの

HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200