俺なりの最速[要出典]アクセシビリティチェック
最速[要出典]アクセシビリティチェック ナイスなアンサーソング！みなさんもぜひ「俺のアクセシビリティチェック」を書いていただけたら嬉しいです Rikiya Ihara / magi (@magi1125) https://twitter.com/magi1125/status/1832473908928507936 ということで、「俺なりのアクセシビリティチェック」について書いてみます。実はこの「最速アクセシビリティチェックRTA」についてはmagiさんと以前にも話をしていて、お互いの目的や手法の違いを確認していて、それをちゃんと表に出すという意味もあります。 チェックの目的や重視するもの magiさんのチェック手法がWCAGやJISの一定の基準を満たしているかを網羅的に確認してレポートすることを目的としている（ように見える）のと比較すると、私のチェックの目的は開発チームにいち早くどんな問
![俺なりの最速[要出典]アクセシビリティチェック](https://cdn-ak-scissors.b.st-hatena.com/image/square/057a8ecb61ee27ff8ff331de75755aa899b6cda3/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--__-75Kxk--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%2525E4%2525BF%2525BA%2525E3%252581%2525AA%2525E3%252582%25258A%2525E3%252581%2525AE%2525E6%25259C%252580%2525E9%252580%25259F%25255B%2525E8%2525A6%252581%2525E5%252587%2525BA%2525E5%252585%2525B8%25255D%2525E3%252582%2525A2%2525E3%252582%2525AF%2525E3%252582%2525BB%2525E3%252582%2525B7%2525E3%252583%252593%2525E3%252583%2525AA%2525E3%252583%252586%2525E3%252582%2525A3%2525E3%252583%252581%2525E3%252582%2525A7%2525E3%252583%252583%2525E3%252582%2525AF%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aymrl%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2cxMEtvem5ETXNrSFdYVkN4dkxvYUdhaGxLNmdOVlB4cnV5eG1YNGc9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
共通化すれば良いとは限らない - Object.create(null)
ここのところ偶然なのか「共通化」という言葉を多く聞いているのですが, その言葉を聞くたびに身構えていることに気がついたので, この気持ちの出どころを共有しておきます. なぜ身構えているかというと, 共通化が必ずしもコードを良い状態にするとは限らないにも関わらず, それ自体が目的になってしまっている (ように見える) ことが多いからです. この手のリファクタリングの目的はあくまでコードの改善のはずで, そのことを忘れて共通化するだけで満足してしまうと, 良くてリファクタリングの効果が半減, 悪ければ逆効果になってしまいます. 個人的にコードを共通化する上で注意してほしいと思っているのは以下の二つです. コードを共通化すべきでない場合もある 共通化されたコードは一般的な原則にしたがって設計されなければならない 似たようなことは歴史の中で何度も繰り返し言われていることだろうと思いますが, 改めて
Parse, don’t validate
Historically, I’ve struggled to find a concise, simple way to explain what it means to practice type-driven design. Too often, when someone asks me “How did you come up with this approach?” I find I can’t give them a satisfying answer. I know it didn’t just come to me in a vision—I have an iterative design process that doesn’t require plucking the “right” approach out of thin air—yet I haven’t bee
バッドUIを改善する方法 ― UIの「5つの状態」を考える | POSTD
(訳注：2020/08/22、画像と動画が正しく表示されていなかったためリンクを修正しました。) こんにちは。このブログは12月にO’Reillyから出版予定の私の著書『 Designing Products People Love 』からの抜粋です。ぜひ本も読んでみてください。また、FacebookやTwitter、 Slackなどで活躍されている20人以上のプロダクトデザイナーにインタビューもしています。* 無味乾燥なUIを経験したことはありますか？ 何か が足りないと感じてしまうようなUIを作ってしまったことはありませんか？ もしそうであれば、使い勝手の悪いUIを経験したのだと思います。 使い勝手の悪いUIには進捗インジケータがありません。ユーザにどこで障害が起きたのか知らせてくれません。怖いエラーメッセージでも表示してくれれば、なお良いのですが。わずかなデータのみの奇妙なグラフです
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
High-Level Programming Languages in AI Era -Human Thought and Mind-
今からでも遅くない！誰も教えてくれなかった React とアクセシビリティーの世界
この記事は Front-End Study #3 で発表されたライブコーディングの内容を記事にしたものです。記事中のソースコードは GitHub でご覧いただけます。 この記事は、これまで一般的なフロントエンドエンジニアだった私が一年ほどアクセシビリティーについて勉強する上で 「最初に教えてくれればよかったのに〜！」と思った内容 を React と Next.js を用いて紹介するものとなっています。 読み終わった後に次にコードを書く際にふと意識できるようなアクセシビリティーの普遍的な事実を紹介し、最後に今後の React の動きについて軽く触れるものになっています。目次は次のとおりです： 基本事項 SPA のルーティングによる問題 リッチなコンポーネントでの例 Jest + React Testing Library でのテスト Reactとアクセシビリティーの今後の動き 役に立つweb
著名なオープンソースRailsアプリのapp/以下を見る
Railsにおける app/ とは app/はRailsのアプリケーション用ディレクトリで、普通のRailsアプリケーションでは、この下にmodels,controllers,viewsを含めた様々なディレクトリが作られます。 基本的には新しいディレクトリを追加する必要はないのですが、アプリケーションが複雑になると、Railsを拡張するべくここにアプリケーション固有のディレクトリを作って、その下に関連するファイルを置くことがあります。 中には、servicesやserializersのように、多くのRailsアプリケーションで見られるものもあれば、完全にアプリケーション独自のものが作られることもあります。また、アプリケーションによっては独自のディレクトリは一切作らないものもあれば、大量に作るものもあります。それぞれアプリケーションの開発方針によるものです。 本記事では、比較的有名なOSSの
契約による設計事始め
Object-Oriented Conferenceの発表資料です。 https://fortee.jp/object-oriented-conference-2020/proposal/1224f293-8624-4448-866f-5d1b991d377f カンファレンスの感想はこちら。 …
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
finalを付けるのをやめてみた - 日々常々
2024-06-12 追記: 書いた内容自体はそうなんだけど、なんだかんだで `final` 書くほうがいいやってなってます😜 ほら、「やめてみた」なんで。ほら。 Javaの話ね。バージョンは8以降の実質的final（effectively final）があるものとします。7以前は匿名クラス（この呼び方は 匿名クラスとかローカルクラスとか参照）でローカル変数を使うにはfinalが必要なので文脈変わります。 前提の整理 final は色々なところにつけられます。 例えばこんな感じ。 final class FooClass { final Object barField = new Object(); final void bazMethod(final Object quxParameter) { final Object corgeLocalVariable; } } このエントリで対
デザインの「悪い方がよい」原則 The Rise of "Worse is Better"
デザインの「悪い方がよい」原則 The Rise of "Worse is Better" rpg@lucid.com 日本語訳: daiti-m@is.aist-nara.ac.jp 私や Common Lisp と CLOS のデザイナーのほとんどは、MIT/Stanford 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
『NieR:Automata』のUIデザイン | NieR:Automata 開発ブログ
こんにちは。『NieR:Automata』で UI (ユーザーインターフェイス) とメカデザインを担当した木嶋です。開発ブログを書くのは『ベヨネッタ2』以来になります。(以前書いた記事) 普段あまり注目されないUIですが、ありがたいことにユーザーの方々からの要望があり、当記事を執筆することになりました。UIにもヨコオさんのこだわりがたくさん詰まっているので、その一部も併せて紹介していこうと思います。 ■はじめに：UIアーティストの仕事 UIアーティストは、体力ゲージや会話ウインドウ、各種メニュー画面などゲーム内表示物を作っています。 大まかな仕事の流れはこんな感じです。 1：UIのコンセプトデザイン策定 2：仕様に合わせて各メニュー画面や表示物のデザインを量産 3：UIのゲームデータを作成してプログラマーに実装してもらう 4：動くUIを触ってみてアニメーションなどの調整、クオリティアップ
Headless Chromeでデザイン変更履歴を追える魚拓を作ってみた - pixiv inside
はじめに こんにちは、普段はPawooの開発を担当している新卒エンジニアのabcangです。 最近話題のHeadless Chromeを使って魚拓を作ってみましたので、その話をします。 結論から言うと、こういうものができました。 以下、詳しくお話していきます。 日々行われるデザイン変更をどう把握するか pixivには毎日新機能やUIの変更がデプロイされており、どんどんページが変わっていきます。 ある日、ディレクターから「デザインの変更履歴を追うための魚拓ツールがほしい」と相談されました。魚拓ツールがあると、なにか数値の変動があったときにデザインの崩れを確認したり、過去のデザインを振り返ったりするときに便利とのことです。 ちょうどそのタイミングでHeadless Chromeが利用できるGoogle Chrome 59がリリースされていたので、試すいい機会だと思い引き受けました。 Headl
Clojureの世界観 - 紙箱
ブログを書くのは久々です。 京都で小さな会社をやっていて、自社開発でClojureとClojureScriptを使用し続けて、概ね３年くらい使い続けています。その過程で、Clojure自体にも小さいながらソースレベルの貢献ができたりして、オープンソースプロジェクトとしても面白かったのですが、もともとオブジェクト指向言語ばかりやってきたところから、Clojureという、まったくオブジェクト指向言語ではない言語に飛び込んだ経験や考えたことなんかを、ブログにストックすると、何か他の人にも役立つこともあるかと思って、ブログに書くことにしました。 このところずっと、自社の仕事とは別に、恵比寿にある 株式会社ユーザベース さんのお仕事に参加しています（私が法人を作る前からなので、もう５、６年くらいになります）。そちらの方でもClojureやシステム設計の話（プレゼンなど）などを何度かさせてもらったり、
ロード時のスピナーとプログレスバー、どう使い分ける？
お店で誰かに商品の場所を尋ねたとして、その相手がただそこに立ったままだったとしたらどう思うでしょうか。きっとイライラして、その場を立ち去りますよね。同じように、ユーザーは長い間スクリーン上のスピナー（通信やローディング時にくるくる回るアニメーション表示の）を見ていると、このような心理状況に陥ります。 スピナーは時間のかかる処理には適さない スピナーは、その処理が終わるまでどのくらいの時間を要するのかをユーザーに伝えません。長時間の処理にスピナーを使うと、最終的にユーザーはアプリに何か問題が起こったのではないかと疑問に思うでしょう。フィードバック無しでは不確実性が生じ、ユーザーは最悪の場合を想定することになります。 ユーザーは読み込みに時間がかかるだろうと考え、待つ気をなくすのです。そしてしびれを切らして、戻るボタンを押したり、またはアプリを終了したりするでしょう。 ４秒ルール ユーザーをア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
桜井政博氏が“試しに作った”ゲームに「さすがプロ」「天才」の声、続出！射撃と加速が同一になったSTGを『はじめてゲームプログラミング』で制作 | インサイド
SimpleとEasyは違う / Simple is not Easy
似非サービスクラスの殺し方 / #ginzarb
複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ
