Vol.277

You’ve only added two lines - why did that take two days! ~ Matt Lacey: Creating Better Apps Jump to heading #

たった 2 行のコードを追加するのに時間がかかる理由 Jump to heading #

2 行のコードを追加するのに 2 日かかったとして、これは開発者が全くの努力をしていないということになるのか。コードの行数が努力の量、価値を示すわけではなく、またすべての行が等しい労力で作られる訳ではない。この記事では、変更が少ないにも関わらず時間がかかる理由を挙げながら、バグ自体を修正すること自体よりも、何度も同じようなバグを起こさないようにするためにはどうしたらよいか、という部分について注力することが重要であるということを指摘している。

Accessible to some - Manuel Matuzović Jump to heading #

機械的なアクセシビリティ判定と実際のアクセシビリティ Jump to heading #

Manuel 氏は、ほとんどのサイトがアクセシビリティの対応が十分にされていないことにを例に挙げ、実験的な Web サイトを制作した。この Web サイトでは Lighthouse ではエラーを出さず、機械的にはアクセシブルと判定されるが、実際のところ、ユーザーがすべての情報アクセスするのは難しくなっているという状態を極端に再現している。この記事では、この実験的な Web サイトを改善していく過程を紹介しながら、機械的なテストだけを頼りにした、一部の人のみがアクセスできる Web サイトではなく、手動テストなどを組み合わせながら本当のアクセシビリティを考慮した Web サイト制作を行って欲しいと話す。

A Reason to Exist: The Product Thesis | Toptal Jump to heading #

プロダクトの存在価値を明確にする Jump to heading #

Alex 氏はすべてのプロダクトには中核となる、存在する理由、または人々から愛されるわけ、があるはずで、それが市場のユーザーのニーズと一致するかどうかがそのプロダクトを成功に導くかどうかを決めるという。この記事では、4 つの有名なプロダクトを分析して、それらの存在意義は何なのか、市場になぜ受け入れられたのかを研究する。

Everything You Have to Know About Core Web Vitals - Calibre Jump to heading #

Google は Core Web Vitals と呼ばれる、UX を図る指標を発表した。Core Web Vitals では 3 つの側面（読み込み時間、インタラクティブ、視覚的安定性）を重要な指標として定め、これらの指標がより良い UX を提供するために必要であるとしている。この記事では、この指標について詳しく解説する。

Inclusively Hiding & Styling Checkboxes and Radio Buttons — Sara Soueidan – Freelance-Front-End UI/UX Developer Jump to heading #

ラジオボタンやチェックボックスの見た目を完全に制御することは難しい。そこで、それらの要素を非表示にし SVG などの画像を用いて見た目を変更する方法がある。この記事では、要素を非表示にするための様々な手法、また非表示にしたことでそれらがコンテンツのアクセシビリティにどのように影響するか、アクセシビリティとユーザビリティを考慮したチェックボックスとラジオボタンの適切な非表示方法について解説をする。

In Brief Jump to heading #

• Styling Layout Wrappers In CSS: コンテンツのサイズを制限したり、間隔をとるために wrapper を定義することはよくある、この記事ではその wrapper について、様々な実装方法を紹介していく

• Learn Z-Index Using a Visualization Tool: z-index の仕様と挙動について紐解いていく

• What is Developer Experience (DX)? | CSS-Tricks: 開発者体験という言葉は曖昧な言葉である。この記事ではその言葉から人々が具体的にどのようなものを連想するか紹介していく。

• Border rounding in CSS | Words: ボーダーの実際の太さがブラウザによって異なることがあることについて詳しく解説する

• When I follow TDD: テストの実装は、構築したものが長期的にメンテナンスの対象になる場合に有効な投資であり、探索的な実装を行っている場合には必ずしも TDD を行う必要はないと指摘する