このブログのCSSライブラリをVanillaExtractからLinariaに置き換えました。
Linariaに置き換えるにあたり全体のCSSを移行する必要がありデザイン崩れが心配だったので、Playwrightでビジュアルリグレッションテストを実施してデザイン崩れがないことを自動テストしました。
Playwrightの導入とLinariaへの移行は次のPRで確認できます。
<ul>
<li><a href="https://github.com/t-yng/blog/pull/543" target="_blank">Playwrightでのビジュアルリグレッションテストを導入 #543</a></li>
<li><a href="https://github.com/t-yng/blog/pull/544" target="_blank">vanilla-extractをlinariaに移行 #544</a></li>
</ul>
<h2 id="Playwrightのインストールと環境構築">Playwrightのインストールと環境構築</h2>
パッケージ単体としてインストールもできますが<code>create</code>コマンドを利用すれば、設定ファイルの自動生成など環境構築を自動で行ってくれます。
<pre class="language-sh"><code class="language-sh">$ yarn create playwright
</code></pre>
<h2 id="設定ファイルの修正">設定ファイルの修正</h2>
自動生成された設定ファイルを自分の好みに合わせて修正します。
<ul>
<li>VRTのスクリーンショットを管理しやすくするためにファイルパスを設定</li>
<li>テスト対象の端末を設定
<ul>
<li>Desktop ChromeとMobile Safari iPhoneSE の2つを対象とする</li>
</ul>
</li>
<li>webServerでテスト実行前にローカルサーバーを起動する設定を追加</li>
</ul>
<pre class="language-ts"><code class="language-ts">// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

/**
 * See https://playwright.dev/docs/test-configuration.
 */
export default defineConfig({
 testDir: './e2e',
 // スナップショットのファイルパスを設定
 snapshotPathTemplate:
 '{testDir}/__snapshots__/{testFilePath}/{projectName}{ext}',
 /* Run tests in files in parallel */
 fullyParallel: true,
 /* Reporter to use. See https://playwright.dev/docs/test-reporters */
 reporter: 'html',
 /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
 use: {
 /* Base URL to use in actions like `await page.goto('/')`. */
 baseURL: 'http://127.0.0.1:3000',

 /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
 trace: 'on-first-retry',
 },

 // テスト対象のブラウザを設定
 projects: [
 {
 name: 'Desktop Chrome',
 use: { ...devices['Desktop Chrome'] },
 },
 {
 name: 'Mobile Safari iPhoneSE',
 use: { ...devices['iPhone SE'] },
 },
 ],

 /* Run your local dev server before starting the tests */
 webServer: {
 command: 'yarn dev',
 url: 'http://127.0.0.1:3000',
 reuseExistingServer: !process.env.CI,
 },
});
</code></pre>
<h2 id="ビジュアルリグレッションテストの作成">ビジュアルリグレッションテストの作成</h2>
Playwrightでは内部的に画像差分比較の仕組みが導入されているので、ページを表示して<code>toHaveScreenshot</code>を実行するだけでビジュアルリグレッションテストを実現できます。
ページごとにテストファイルを作成していビジュアルリグレッションテストだけを実行するテストケースを実装していきます。
<pre class="language-ts"><code class="language-ts">// e2e/top.spec.ts
import { test, expect } from '@playwright/test';

test('visual regression', async ({ page }) => {
 await page.goto('/');
 await expect(page).toHaveScreenshot({
 fullPage: true,
 animations: 'disabled',
 });
});
</code></pre>
<pre class="language-ts"><code class="language-ts">// e2e/post.spec.ts
import { test, expect } from '@playwright/test';

test('visual regression', async ({ page }) => {
 await page.goto('/post/improve-a11y');
 await expect(page).toHaveScreenshot({
 fullPage: true,
 animations: 'disabled',
 });
});
</code></pre>
<h2 id="スクリーンショットの作成">スクリーンショットの作成</h2>
初回実行時は差分となるスクリーンショットが存在しない状態なので、まずはベースとなるスクリーンショットを作成します。
<pre class="language-sh"><code class="language-sh"># 最初にスクリーンショットを作成
$ yarn playwright test --update-snapshots
</code></pre>
<h2 id="テストを実行">テストを実行</h2>
ビジュアルリグレッションの準備ができたので、実際にテストを実行してみます。
<pre class="language-sh"><code class="language-sh"># テスト実行
$ yarn playwright test

 4 failed
 [chromium] › post.spec.ts:3:5 › visual regression ──────────────────────────────────
 # 省略
</code></pre>
テストを実行したら画像の差分が発生して、テストに失敗しました。
<img src="/images/posts/playwright-vrt/failed.png" alt="ビジュアルリグレッションテストの結果" loading="lazy" width="2116" height="816">
コードを確認してみるとLinariaに移行するためにCSSの記述をJS ObjectからCSSスタイルに書き換えるにあたり、フォント指定の値が誤って文字列のままとなっていました。
ビジュアルリグレッションテストをしていなかったら、気づかずにそのままになっていました。
<pre class="language-css"><code class="language-css">/* 文字列で囲っているのでCSSの構文として正しくない */
font-family: "'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif";

/* 正しくはこう */
font-family: 'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif;
</code></pre>
<h2 id="まとめ">まとめ</h2>
ビジュアルリグレッションテストを導入することで、マージ前に事前にバグに気づけて非常に良かったです。 
プライベートで個人開発をしていると第3者のコードレビューは基本無いので、自動テストで可能な限りバグを出さない仕組みを自動化するのはとても有益だなーと改めて実感しました。😊

今回は自分のプルリクエストを自分でレビューをするメリットについて話をしたいと思います。

Playwrightでビジュアルリグレッションテストを導入して安全にCSSライブラリを置き換える

Reactでフォーカス中にのみ表示されるポップアップをデバッグする時にハマったので解決法をまとめました。
<h2 id="直面した問題">直面した問題</h2>
次のようなinput要素にフォーカスが当たっている時だけ表示される、ポップアップのCSSをデバッグする状況を考えます。
<iframe width="100%" height="400px" src="https://stackblitz.com/edit/react-ts-gnwa6a?embed=1&file=App.tsx&view=preview"></iframe>
ポップアップが表示された状態でdevtoolsで対象のDOM要素をクリックすると、フォーカスが外れるためポップアップが消えてしまいます。
Reactでは状態に応じてDOM要素を描画しないことが多く、今回のケースでもポップアップのDOM要素がDOMツリーから消えてしまうためCSSを確認できなくなります。
<h2 id="Enable a focused page を有効にする">Enable a focused page を有効にする</h2>
More tools &gt; Rendering &gt; Enable a focused page を有効にすることで、この問題を解消できます。
この設定を有効にすることでページ全体がフォーカスされた状態を維持できるので、devtoolsをクリックしてもポップアップが消えずに残り続けてデバッグすることできます。
<img src="/images/posts/devtools-debug-only-focus-element/emulate-focus-page.png" alt="devtoolsでDOMをクリックしてもポップアップが非表示ならない様子" loading="lazy" width="1089" height="542">

フォーカス中にのみ表示されるDOM要素をChromeのdevtoolsでデバッグする方法について解説します

Reactでフォーカス中にのみ表示される要素をChromeのdevtoolsでデバッグする

GoogleのProfessional Cloud Developer認定試験の勉強で残したメモ書きです

Professional Cloud Developer認定試験の学習メモ書き

先日、Googleが実施しているProfessional Cloud Developerの認定資格に合格しました。🎉 
自分が認定試験に合格するまでに行った学習の振り返りです。
<h2 id="Professional Cloud Developer(PCD)とは？">Professional Cloud Developer(PCD)とは？</h2>
<a href="https://cloud.google.com/certification/cloud-developer?hl=ja" target="_blank">Professional Cloud Developer</a>はGoogleが推奨するツール（主にGCP）とベストプラクティスを使用して、スケーラブルで可用性の高いアプリケーションを構築する知識に基づいた認定資格です。
出題内容としては次のスキルについて評価がされます。
<ul>
<li>スケーラビリティ、可用性、信頼性に優れたクラウドネイティブ アプリケーションの設計</li>
<li>アプリケーションのビルドとテスト</li>
<li>アプリケーションのデプロイ</li>
<li>Google Cloud サービスの統合</li>
<li>デプロイされたアプリケーションの統合</li>
</ul>
<h2 id="受験の経緯">受験の経緯</h2>
会社でG.I.GプログラムというGoogle Cloudの技術スキルを習得するためのエンジニア向けのプログラムに参加させて頂けることになりました。このプログラムの修了過程の一環としてGoogle Cloud認定資格の取得があります。
前からCGPをちゃんと勉強してみたいと思っていたので、折角の機会に認定試験を資格を受験してみようとなりました。
<h2 id="筆者の開発経験">筆者の開発経験</h2>
<h3 id="実装・設計の経験">実装・設計の経験</h3>
<ul>
<li>サーバーサイドの開発経験: 2.5年</li>
<li>フロントエンドの開発経験: 3年</li>
</ul>
<h3 id="インフラ経験">インフラ経験</h3>
<ul>
<li>Next.jsを本番運用するためにTerraform + AWS Fargate でインフラ構築及び運用の経験あり
<ul>
<li>既に土台があったので、それを真似して知っている人に相談しながら構築</li>
</ul>
</li>
<li>Node.js + Lambda でAPIの構築経験あり</li>
<li>AWSの基本的なサービスは知っている状態</li>
<li>GCPはコンソールの見方も分からず苦手意識がありGCP怖い状態</li>
</ul>
<h2 id="学習方法">学習方法</h2>
<h3 id="学習時間と期間">学習時間と期間</h3>
学習時間: 約60時間 
学習期間: 2ヶ月
合計の学習時間は約60時間でしたが、Courseraのコースを修了するにあたりハンズオンを完了させる必要があり1/4はその時間に費やしていた気がするので、単純な座学の時間だけだと約45時間でした。
<h3 id="Coursera">Coursera</h3>
G.I.Gプログラム参加者に提供されているCouseraのPCD受験者向けの学習コースを5つ受講・修了しました。実施内容は動画視聴によるGCPに関する学習とQwiklabsでのハンズオンです。
動画を視聴しているだけど頭に入ってこなかったので、学習動画を視聴しながら重要だなと思った点をメモ帳にメモ書きしながら、分からない単語やサービス名をドキュメントや他の人のブログ記事などを読んで理解するようにしていました。このやり方は動画視聴しているだけの時と比較して学習の質が上がったと実感できました。
<a href="/post/gcp-memo">Professional Cloud Developer認定試験の学習メモ書き</a>でメモ書きの内容を書いているので、興味ある方は確認してみてください。
具体的には次のコースを受講しました。一般向けにも公開もされているので、G.I.Gプログラム参加者以外でも受講は可能だと思います。
<ul>
<li><a href="https://www.coursera.org/learn/gcp-fundamentals-jp" target="_blank">Google Cloud Fundamentals: Core Infrastructure 日本語版</a></li>
<li><a href="https://www.coursera.org/learn/app-deployment-debugging-performance-jp" target="_blank">Application Deployment, Debug, Performance 日本語版</a></li>
<li><a href="https://www.coursera.org/learn/securing-integrating-components-app-jp" target="_blank">Securing and Integrating Components of your Application 日本語版 
</a></li>
<li><a href="https://www.coursera.org/learn/getting-started-app-development-jp" target="_blank">Getting Started with Application Development 日本語版</a></li>
<li><a href="https://www.coursera.org/learn/google-kubernetes-engine-jp" target="_blank">Getting Started with Google Kubernetes Engine 日本語版</a></li>
</ul>
<h3 id="模擬試験">模擬試験</h3>
Courseraコースを一通り受講し終えた後に<a href="https://docs.google.com/forms/d/e/1FAIpQLSc_67KaPnNwQrLZ7kuhw-aubz7gMAwY6DQwRJYcW0qlG-iajA/viewform?hl=ja" target="_blank">公式の模擬試験</a>を解いてから、知らないサービス名などの単語を全て調べて理解することをしていました。その後、何も見ずに解答の説明ができるように繰り返し解いていました。
<h2 id="難易度と雑感">難易度と雑感</h2>
選択式の試験だったのでGCPのサービスだけ把握すれば、システム構築に関する問題は経験則の勘で答えられるだろうと思っていましたが、実際にそんな感じで解答できました。
設計を含めたサーバーサイドの開発経験がある程度あれば、比較的難しくないのかな？という印象でした。特に業務でGCPを利用している方であれば、模擬試験を受けて試験の傾向と雰囲気だけ把握して少し勉強するだけでも合格できると思います。

GoogleのProfessional Cloud Developer認定試験に合格するためにやったことの振り返りです

GoogleのProfessional Cloud Developer認定試験に合格するまでの学習の振り返り

Electronアプリのリポジトリ構成をMonorepo構成に変更したので、その時の内容をまとめました。

ElectronアプリをMonorepo構成で構築

HTMLを仕様に基づいて正しく書くには思ったよりも必要な専門知識が必要です。 
例えば以下のコードは<code>p</code>要素で許可されている内容は記述コンテンツのみなので、HTMLの仕様としては誤ったコードになります。
<pre class="language-html"><code class="language-html">&lt;p>
 &lt;h1>見出し&lt;/h1>
&lt;/p>
</code></pre>
<h2 id="HTMLの仕様に基づいてコーディングする目的">HTMLの仕様に基づいてコーディングする目的</h2>
先ほどのコードはHTMLとしては構文エラーとなりますが、ブラウザ上では問題なく表示されます。見た目上問題ないのであれば、些細な問題なので別に良いのでは？と思うかもしれません。
ページを閲覧する対象は人だけでなくスクリーンリーダーや検索BOTなどの機械も含まれます。これらの機械が正確にページを解釈するには、HTMLの仕様に基づいて正しく記述されている事が重要になってきます。
<h2 id="markuplintの導入">markuplintの導入</h2>
最初にも書いたように仕様に基づいてHTMLを記述するのは一定の専門知識が必要です。知識を持つ人がプルリクのタイミングでコードをチェックする事も可能ですが、それをするには全てコードをレビューする必要があり負担が膨大になります。
<a href="https://markuplint.dev/" target="_blank">markuplint</a>を利用することで、HTMLの構文チェックを自動化でき全員が実装の段階で構文エラーに気づく事ができるようになります。また、構文エラーを通してHTMLの仕様を学ぶことも出来るので一石二鳥です。
<h3 id="インストール">インストール</h3>
まずは必要なパッケージをインストールします。
<code>markuplint</code>パッケージはHTML構文チェクのコア機能を提供するCLIツールです。
<code>@markuplint/jsx-parser</code>パッケージはjsxで記述されたコードをHTML文字列にパースして構文チェック可能にするためのパッケージです。
<code>@markuplint/react-spec</code>パッケージはReactで定義されている<code>key</code>属性などを仕様として認識されるためのパッケージです。Reactのコードを構文チェックすると<code>error: 属性「key」は許可されていません (invalid-attr)</code>とHTML仕様に定義されていない<code>key</code>属性が不正な属性として検知されてしまうため、それを防ぐためにこのパッケージをインストールします。
vueやsvelteなどの他のライブラリに対応したparserやspecは<a href="https://github.com/markuplint/markuplint/tree/dev/packages/@markuplint" target="_blank">公式リポジトリ</a>で探すことができます。
<pre class="language-shell"><code class="language-shell">$ yarn markuplint @markuplint/jsx-parser @markuplint/react-spec
</code></pre>
<h3 id="設定ファイルを作成">設定ファイルを作成</h3>
プロジェクトのルートに<code>.markuplintrc</code>を以下の内容で作成します。
<pre class="language-json"><code class="language-json">// .markuplintrc
{
 // テストファイルやストーリーファイルを除外
 "excludeFiles": [
 "./**/*.{test,spec,stories}.tsx"
 ],
 // ツールの推奨設定を利用
 "extends": [
 "markuplint:recommended"
 ],
 // jsxをHTMLテキストにパース
 "parser": {
 ".tsx$": "@markuplint/jsx-parser"
 },
 "specs": {
 ".tsx$": "@markuplint/react-spec"
 }

}
</code></pre>
<h3 id="構文チェックを実行する">構文チェックを実行する</h3>
実際に以下のコンポーネントファイルを対象として構文チェックを実行してみます。
<pre class="language-tsx"><code class="language-tsx">// src/
const Hello = () => {
 return (
 &lt;p>
 &lt;h1>こんにちは&lt;/h1>
 &lt;/p>
 )
}
</code></pre>
構文チェックの対象をblobパターンで指定をして実行をします。デフォルトでは対象ファイルの全て結果が表示されるので、<code>-p</code>オプションを付与することでエラーだけを出力するようにできます。
無事にHTMLの構文エラーが検出することができました。
<pre class="language-shell"><code class="language-shell">$ yarn markuplint -p src/**/*.tsx
&lt;markuplint> error: HTMLの仕様において、要素「p」の内容は妥当ではありません (permitted-contents) 
 4: ••••••••&lt;p>
 5: ••••••••••••&lt;h1>テスト&lt;/h1>
</code></pre>
VSCodeを利用している場合には<a href="https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint" target="_blank">markuplintプラグイン</a>もあるので、合わせてインストールしておくと便利です。

Reactのプロダクトにmarkuplintを導入する

freeeさんが公開しているアクセシビリティー・チェックリストを活用して個人のブログのアクセシビリティーをチェックして改善をしてみました。

個人ブログのアクセシビリティー・チェックと改善を実践してみた

この記事は<a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア アドベントカレンダー2022</a> 14日目の記事です。
業務でReactで実装されたフォームのパフォーマンス改善をしたので、その時の問題を一般化してパフォーマンス改善を体験できる練習問題を作ってみました。
<h2 id="練習問題">練習問題</h2>
Reactで<code>&lt;input&gt;</code>要素がリストで表示されており、<code>&lt;input&gt;</code>要素にテキストを入力してみると非常にレスポンスが遅い状態になっています。このレスポンス速度を改善するのが今回の問題です。
<iframe src="https://stackblitz.com/edit/react-ts-evcw6y?embed=1&file=src/App.tsx" style="width: 100%; height: 400px"></iframe>
ソースコードを眺めてみるとApp.tsxでTodoの一覧を管理しており<code>TotoList</code>コンポーネントを描画しています。 
<code>onChange</code>propsには<code>setTodos</code>を渡しておりTodoの一覧を更新します。
<pre class="language-tsx"><code class="language-tsx">// App.tsx
const initialTodos: TodoModel[] = [...Array(100)].map((_, i) => ({
 id: i,
 text: 'aaa',
}));

const App = () => {
 const [todos, setTodos] = useState(initialTodos);

 return (
 &lt;div>
 &lt;button
 onClick={() => {
 alert(todos[0].text);
 }}
 >
 保存
 &lt;/button>
 &lt;TodoList todos={todos} onChange={setTodos} />
 &lt;/div>
 );
};
</code></pre>
次に<code>TodoList</code>コンポーネントの実装を見てみます。
<code>TodoList</code>では<code>&lt;input&gt;</code>要素として<code>Todo</code>コンポーネントを描画しており、変更があったときに新しい<code>Todo</code>のオブジェクトを受け取り新しいTodoリストを引数としてpropsで渡された<code>onChange</code>コールバック関数を実行して、親要素に新しいTodoリストを渡しています。
<pre class="language-tsx"><code class="language-tsx">export const TodoList: FC&lt;TodoListProps> = ({ todos, onChange }) => {
 const handleChange = useCallback(
 (updatedTodo: TodoModel) => {
 const index = todos.findIndex((todo) => todo.id === updatedTodo.id);
 onChange?.([
 ...todos.slice(0, index),
 updatedTodo,
 ...todos.slice(index + 1),
 ]);
 },
 [onChange, todos]
 );

 return (
 &lt;ul>
 {todos.map((todo) => {
 return (
 &lt;li key={todo.id}>
 &lt;Todo todo={todo} onChange={handleChange} />
 &lt;/li>
 );
 })}
 &lt;/ul>
 );
};
</code></pre>
最後に<code>Todo</code>コンポーネントの実装を見てみます。
<code>Todo</code>コンポーネントではpropsで受け取った<code>todo</code>のテキストの内容を<code>&lt;input&gt;</code>要素のvalueとして表示しています。テキストが変更された時に新しいテキストでTodoオブジェクトを作成して<code>onChange</code>関数を実行して親要素に新しいTodoオブジェクトを渡しています。
<code>[...Array()]</code>はコンポーネントの描画速度を疑似的に遅くするために仕込んでいます。は問題を作成するための疑似コードなので、ここを削除しないでください。
<pre class="language-tsx"><code class="language-tsx">export const Todo: FC&lt;TodoProps> = memo(({ todo, onChange }) => {
 [...Array(100000)].forEach(() => 1 + 1);

 return (
 &lt;input
 type="text"
 defaultValue={todo.text}
 onChange={(evt) => {
 onChange({
 ...todo,
 text: evt.target.value,
 });
 }}
 />
 );
});
</code></pre>
このコンポーネント単体の描画速度は約10msほどになっており、実際の実装でも再現し得る問題になっています。
<img src="/images/posts/react-performance-question/profile.png" alt="プロファイルの結果" loading="lazy" width="1136" height="462">
<h2 id="解説">解説</h2>
問題の解答は別の記事で書こうと思います。 
興味があれば解いてみてください。

業務でReactのパフォーマンス改善をする機会があったので問題を一般化して練習問題を作ってみました

Reactのパフォーマンス改善を体験できる練習問題を作ってみた

<h2 id="Google検索で見つかるサンプル実装の課題">Google検索で見つかるサンプル実装の課題</h2>
Checkboxのデザインをカスタマイズするには、従来のCheckboxでは難しく自前でCheckboxを実装する必要があります。Googleで「チェックボックス デザイン 変更」と検索して上位に出てくる記事を見ると次のサンプルのように<code>input[type=&quot;checkbox&quot;]</code>を<code>display:none</code>で非表示にしている実装が多くあります。
この実装では<code>&lt;input&gt;</code>要素にフォーカルを当てることができないため、Tabキーで選択してスペースでトグルするようなキーボード操作ができない状態になっています。 
また、スクリーンリーダーがチェックボックスを認識できないので、スクリーンリーダーユーザーはチェックボックスの存在に気づくことすらできません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/BadCheckbox/style.css&initialpath=?bad" style="width: 100%; height: 400px;"></iframe>
<h2 id="アクセシビリティを考慮してチェックボックスを実装">アクセシビリティを考慮してチェックボックスを実装</h2>
<code>display:none</code>だとフォーカスができなくなってしまうので、代わりに<code>opacity:0;</code>で<code>&lt;input&gt;</code>を非表示にします。 
<code>&lt;input&gt;</code>は非表示のままのため、フォーカスが当たっている時のデザインを追加します。
この考慮を入れて上げるだけで、キーボード操作可能になり操作性が上がりスクリーンリーダーユーザーもチェックボックスの操作が可能になります。
<pre class="language-css"><code class="language-css">/* src/GoodCheckbox/style.css */

/* 元のチェックボックス（非表示） */
input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

/* フォーカスが当たっている時のデザインを追加 */
input[type='checkbox']:focus-visible + label::before {
 border-color: blue;
}
</code></pre>
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/GoodCheckbox/style.css" style="width: 100%; height: 400px;"></iframe>
<h2 id="デザイン実装をリファクタする（おまけ）">デザイン実装をリファクタする（おまけ）</h2>
ここから先は好みの問題かもですが、CSSを利用したサンプル実装は疑似要素を使った実装になっており直感できないため、少し保守がしづらく感じます。疑似要素を使わずに直感的にデザイン指定できるようにリファクタをしてみます。
疑似要素を使わずにカスタムなチェックボックスを<code>&lt;span&gt;</code>タグで実装してCSSでデザインを指定することで、宣言的になり直感的に分かりやすくなりました。
チェックアイコンを<code>&lt;svg&gt;</code>タグで直接表示するように変更しています。この時の注意点としてチェックアイコンの画像は視覚的な情報なのでスクリーンリーダーユーザーにとっては唯のノイズになってしまいます。実際に<code>aria-hidden</code>を消してスクリーンリーダーに読み上げさせると、チェック済みの場合に「イメージ」という無駄な読み上げが発生します。そのため、忘れないように<code>&lt;svg aria-hidden=&quot;true&quot;&gt;</code>と設定してあげる必要があります。<code>@mui/icons-material</code>ではデフォルトで<code>aria-hidden=&quot;true&quot;</code>となるので別途指定はしていません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/Checkbox/Checkbox.tsx&initialpath=?refactor" style="width: 100%; height: 400px;"></iframe>
<pre class="language-tsx"><code class="language-tsx">// src/Checkbox/Checkbox.tsx

import * as React from 'react';
import CheckRoundedIcon from '@mui/icons-material/CheckRounded';
import './style.css';

type CheckboxProps = {
 checked: boolean;
 onChange: (event: React.ChangeEvent&lt;HTMLInputElement>) => void;
};

export const Checkbox: React.FC&lt;CheckboxProps> = ({ checked, onChange }) => {
 return (
 &lt;label className="checkbox">
 &lt;input type="checkbox" defaultChecked={checked} onChange={onChange} />
 &lt;span className="custom-checkbox">
 {checked &amp;&amp; &lt;CheckRoundedIcon fontSize="small" />}
 &lt;/span>
 &lt;span>ラベル&lt;/span>
 &lt;/label>
 );
};
</code></pre>
<pre class="language-css"><code class="language-css">/* src/Checkbox/Checkbox.tsx */

.checkbox {
 display: inline-flex;
 cursor: pointer;
 gap: 8px;
}

.checkbox input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

.checkbox .custom-checkbox {
 display: inline-block;
 width: 24px;
 height: 24px;
 border: 2px solid lightgray;
 border-radius: 4px;
 background-color: white;
 box-sizing: border-box;
}

.checkbox input[type='checkbox']:checked + .custom-checkbox {
 background-color: lightcoral;
}

.checkbox input[type='checkbox']:focus + .custom-checkbox {
 border-color: blue;
}
</code></pre>

アクセシビリティを考慮したカスタムなCheckboxを実装する方法です。

アクセシビリティを考慮してチェックボックスのデザインを変更する

mswをラップして便利なutil関数を実装します。

mswをラップした便利関数をつくる

とあるフロントエンドエンジニアのブログ

記事一覧