:focus-visible 擬似クラスはユーザーの入力方法によって異なるフォーカス表示をしたい時に便利です。この擬似クラスはキーボード操作によりフォーカスされた場合に適用されますが、マウス操作によりフォーカスした場合には適用されません。 それでは、JavaScript の focus()メソッドによりフォーカスされた場合には、`:focus-visible` 擬似クラスは適用されるのでしょうか？実はこれは最後 `focus()` メソッドが呼ばれる前に要素にフォーカスがあったかどうかにより異なります。

誰でも読める愚直なコードであることの 1 つの目安として、テストコードの中に if 文や三項演算子などの条件分岐が入り込んでいていないことが上げられます。if 文が存在するコードはアンチパターンであるといえます。実際に if 文がテストコードの中に入り込んだ例を見てみましょう。

例えばフォームの項目になにか入力されるまで、送信ボタンを無効にしたい状況があるかと思います。このような場合には `<button>` に `disabled` 属性を与えることでフォームの送信を無効にできます。`disabled` 属性はデフォルトでコントロールを無効にする一般的に期待されるすべての機能を提供するため、多くの場合はこの属性を使用するべきです。しかし `disabled` 属性には 1 つ問題点が存在します。それは Tab キーによるフォーカスができなくなるという点です。

単体テストの目的は、ソフトウェア開発プロジェクトを持続可能なものにすることです。この目的を達成するための単体テストの機能の 1 つにリファクタリングに対する耐性が上げられます。これは内部のコードを変更した前後でも、外部の振る舞いから見た振る舞いが壊れていないことを保証してくれる度合いです。この耐性が高ければ、開発者は安全にコードを変更できます。 この記事では、単体テストをコード単位で書いた場合と振る舞い単位で書いた場合をそれぞれ提示して、リファクタリングに対する耐性がどのように異なるのかを見ていきます。

アクセシビリティの対応は、要件定義段階から設計したりなど大変そうなイメージはあります。実際に本格的に対応するにはどの達成基準を目標にするか決めたり、入念なテストが必要になるなど確かに一朝一夕で対応できるわけではないでしょう。 ですが、完璧な対応を目指すのではなく、少しづづ改善できるところから進めることこともできます。実際にやってみると、簡単な HTML や CSS のコードの修正でもよい改善を得られたりします。 この記事では比較的低コストで実践入門できるアクセシビリティの改善を紹介します。

データの取得・ルーティング・フォームの値の管理に至るまで JavaScript で制御するようになった結果、本来備わっていた機能を損なう形で実装されるような間違いが起きるケースも発生してしまいました。見た目上操作に不都合がないのですが、修飾キーが有効でなかったりと、とある要素が当然に持っているべき機能が失われていることがよくあります。

Satori とは Vercel が公開している OGP 画像生成ライブラリです。OGP 画像を表示したい場合、記事ごとに対応する OGP 画像が必要になるわけで、新しい記事を投稿するたびに新たな画像を生成しなければいけません。都度画像を生成する手間は取れないわけで、このOGP 画像を生成する工程を自動化する仕組みが必要となります。Satori は記事のタイトルなどをもとに動的 OGP 画像を生成するユースケースのために使用できます。

ユーザーの OS の設定や LocalStorage の値をもとにダークモードかどうか判定する場合、コンテンツが読み込まれる前にスクリプトの実行が完了している必要があります。

Pa11y とは Web Content Accessibility Guidelines (WCAG) をベースに HTML のアクセシビリティを検査するツールです。適合レベル AA を対象にテストします。Pa11y にはいくつかの種類がありますが、その中でも Pa11y CI は CI 上で実行することにフォーカスしています。

jest coverage reportは GitHuba Actions のワークフローの1つで Jest で実行したテストのコードカバレッジをプルリクエスト上にコメントしてくれます。 この記事では yarn workspaces 使用して作成したモノレポ構築のレポジトリで jest coverage report を動かしてみます。

TypeScript において `in` 演算子を `unknown` 型に対して使用した際の挙動が改善されました。

あるページの中で重要ではない付随的なデータの取得を待たずに、重要なデータの取得が完了したタイミングでページを表示させたい場合があります。例えば、ブログの記事のページを遷移する場合、ユーザーにとって記事のコンテンツは重要なデータですが、それに付随するコメントやいいねの数はそれほど重要ではないので、それらのデータの取得を待つ必要がありません。 この記事では React Router の loaderを使用して重要なデータの完了のみを待機する方法を試してみます。