<a href="https://fukuoka.a11yconf.net/" target="_blank">アクセシビリティカンファレンス福岡</a> に現地参加してきました。 
カンファレンスの発表内容のメモ書きで。
<h2 id="伝わるを拡張するアクセシビリティ">伝わるを拡張するアクセシビリティ</h2>
発表者: <a href="https://fukuoka.a11yconf.net/#speaker-majima" target="_blank">間嶋沙知さん</a>
<h3 id="アクセシビリティとは？">アクセシビリティとは？</h3>
<ul>
<li>Access + ability</li>
<li>アクセシビリティは0か100ではなく高めるもの</li>
<li>使えるレベルと満たしてから、使える状況の幅を広げる</li>
<li><a href="https://www.w3.org/WAI/perspective-videos/" target="_blank">Web Accessibility Perspective Video</a>
<ul>
<li>色々な状況でのa11yのメリットを紹介したビデオ</li>
</ul>
</li>
<li>a11yは障害者のためのものではない
<ul>
<li>怪我をして一時的に片手を使えない場合などもある</li>
<li>すべての人に意味がある</li>
</ul>
</li>
<li>障害のある人は既にニーズを知っているリードユーザーと見ることができる</li>
</ul>
<h3 id="「伝わる」を阻む壁を知る">「伝わる」を阻む壁を知る</h3>
<ul>
<li>5cmの壁があっても車椅子などでは超えるのが困難</li>
<li>壁が取り除かれるとみんなが便利になる</li>
<li>なにか壁を作るのか？
<ul>
<li>**「知らなかった」**が壁をつくる</li>
</ul>
</li>
<li>デザインをする時は「だれに」「何を」「どうやって」を考えるのが大事
<ul>
<li>アクセシビリティは新しい「知る」を教えてくれる。</li>
</ul>
</li>
</ul>
<h3 id="ここから始めるアクセシビリティ">ここから始めるアクセシビリティ</h3>
<ul>
<li>a11yはコストがかかるんでしょう？
<ul>
<li>上流から考慮すればコストを抑えれる</li>
<li>後から対応はコストが高い</li>
</ul>
</li>
<li>エンジニアが頑張るもの？デザイナーやディレクターができることはある？
<ul>
<li>企画・設計、デザイン、コンテンツ制作で取り組めることはたくさんある</li>
</ul>
</li>
<li>色覚特性をシミュレーションできるモバイルアプリ
<ul>
<li><a href="https://asada.website/cvsimulator/j/" target="_blank">色のシミュレータ</a></li>
<li>実際にそう見えている色ではないことに注意（あくまでシミュレーション）</li>
</ul>
</li>
<li>コントラストが低い問題は世界のサイトの80%で見受けられる
<ul>
<li>WCAGの1.4.11でコンストラスト比のガイドラインが決められている</li>
<li>使いたい色の役割を意識して配色をすると、コンストラストを適切に保てる</li>
</ul>
</li>
<li>WCAGを噛み砕いてアクセシビリティガイドラインを作成している国内企業のドキュメントを読むのがおすすめ
<ul>
<li>Freeee, Ameba, Liful, SmartHR</li>
</ul>
</li>
<li>コンテンツ制作
<ul>
<li>見出しをつけよう</li>
<li>ノンデザイナーズ、ガイドブック</li>
<li>情報を整理して内容ごとにまとめる</li>
<li>内容を予測できる見出しをつける</li>
</ul>
</li>
<li>代替テキストをつけよう</li>
<li><a href="https://www.aaa11y.com/" target="_blank">a11yギャラリー</a>はアクセシビリティ対応されたサイトが掲載されている</li>
<li>アクセシビリティに取り組むとデザインの視点や伝わる可能性が広がる
<ul>
<li>より良いデザイン</li>
<li>これまでのデザインを拡張する</li>
</ul>
</li>
<li>今日からできること
<ul>
<li>SNSの画像に代替テキストに入れてみる</li>
<li>今日のイベントについて周りの人と話してみる</li>
<li>気づいたこと、取り組んだことを発信してみる</li>
</ul>
</li>
</ul>
<h2 id="ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜">ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜</h2>
発表者: <a href="https://fukuoka.a11yconf.net/#speaker-shibata" target="_blank">柴田宏仙さん</a> ✕ <a href="https://fukuoka.a11yconf.net/#speaker-ihara" target="_blank">伊原力也さん</a>
<h3 id="テーマについて">テーマについて</h3>
<ul>
<li>アクセシビリティに取り組む課題
<ul>
<li>知見がある人がいない/最適な人材がいない</li>
<li>何から手をつければ良いか分からない</li>
<li>リソースが足りない</li>
<li>開発予算がない</li>
<li>ビジネス上のインパクトが示しづらい</li>
<li>ユーザーからの要望がない</li>
</ul>
</li>
</ul>
<h3 id="品質について">品質について</h3>
<ul>
<li>div要素だけでHTMLが作られていたりスクリーンリーダーに対応できていない時に「もやもや」する人で溢れるチームになる</li>
<li>クリエイターは人が喜ぶサイトを作りたい</li>
<li>ステップ: 伝える =&gt; 見せる =&gt; やってもらう =&gt; 評価する</li>
<li>伝える
<ul>
<li>アクセシビリティやろうよ！と言っても共感は難しい</li>
<li>Webのすごさ（誰でも情報にアクセスできること）を伝えることで共感をしてもらう</li>
<li>耳で情報を得ている人でも自分たちのマークアップによって情報の収集をサポートできる</li>
<li>「武器になるHTML」に書いてあるよ</li>
</ul>
</li>
<li>見せる
<ul>
<li>自分たちのやっていることを他の人に見せる</li>
<li>サイトの拘りや競合サイトとの比較を見せる</li>
<li>フォント拡大への対応</li>
</ul>
</li>
<li>やってもらう
<ul>
<li>簡単にできることから</li>
<li>pxで文字サイズ指定されているモノをremに直したり</li>
</ul>
</li>
<li>評価する
<ul>
<li>やってもらった事に対して「うれしい」と感じれられるFBをする</li>
</ul>
</li>
</ul>
<h3 id="営業について">営業について</h3>
<ul>
<li>手元でひとりでやる =&gt; 仕事としてチームでやる</li>
<li>ポイント
<ul>
<li>3人以上でやろう</li>
<li>「やってみた」マインドでやってみる</li>
<li>表に出す（表に出すと中の人が見て、既成事実になる）</li>
</ul>
</li>
<li>社内でやってみる =&gt; 社内向けにまとめる =&gt; 社外向けになおす =&gt; 社外に出す =&gt; 中の人がみる</li>
<li>ステップ1 学んでみた
<ul>
<li>会社とアクセシビリティを紐付ける準備をする</li>
<li>勉強会レポートなどを社のブログ等で発信する</li>
</ul>
</li>
<li>ステップ2 調べてまとめてみた
<ul>
<li>アクセシビリティを調べて発信する</li>
<li>自治体サイトのa11y対応状況とか</li>
</ul>
</li>
<li>ステップ3 自分のところ直してみた
<ul>
<li>自分の裁量で触れるところを改善してみる</li>
</ul>
</li>
<li>ステップ4 仕事で一部やってみた
<ul>
<li>小さい、しかし意味のある単位で改善する</li>
</ul>
</li>
<li>ステップ5 仕事に組み込んでみた</li>
<li>ステップ6 仕事でまるっとやってみた
<ul>
<li>特定の機能をスクリーンリーダーでも使えるようにするとか</li>
</ul>
</li>
</ul>
<h3 id="まとめ">まとめ</h3>
ウェブにあるだけで圧倒的にアクセシブル
<h2 id="ヌーラボのウェブサイト課におけるアクセシビリティ関連の取組み">ヌーラボのウェブサイト課におけるアクセシビリティ関連の取組み</h2>
発表者: 松永知典さん
ヌーラボのミッション 
「&quot;このチームで一緒に仕事できてよかった&quot;を世界中に生み出していく。」
<h3 id="ミッションの作成">ミッションの作成</h3>
<ul>
<li>ワークショップでメンバーの相互理解をうかめてからミッションを作成
<ul>
<li>人生において大事な価値観を共有</li>
</ul>
</li>
<li>ミッション作成で実現したいこと
<ul>
<li>優先度を決める際の判断規準になる</li>
<li>自分のやっていることに誇りが持てる</li>
<li>困難にぶち当たった時にポジティブになれる</li>
</ul>
</li>
<li>気をつけたこと
<ul>
<li>会社の方向性や、ウェブサイト課、個人のwillの重なりを意識した</li>
<li>ミッションステートメントを一文で作成</li>
</ul>
</li>
</ul>
<h3 id="フロントエンドエンジニアの求人票を変更">フロントエンドエンジニアの求人票を変更</h3>
<ul>
<li>フロントエンドエンジニアからマークアップエンジニアに名称に変更</li>
<li>「セマンティックなマークアップを意識してWebサイトの開発に取り組める方」を記載
<ul>
<li>Webアプリの開発を主とした方々からの応募は減少傾向</li>
<li>マークアップからアクセシビリティの改善を意識して求職する方の応募が増えた</li>
</ul>
</li>
</ul>
<h3 id="社内へのアクセシビリティの浸透">社内へのアクセシビリティの浸透</h3>
<ul>
<li>社内の全体チャットへの投稿
<ul>
<li>「こちら」のリンクを止めましょうという話</li>
</ul>
</li>
<li>何が問題なのかハッキリしていて、分かりやすい</li>
</ul>
<h2 id="LINEヤフーにおけるこれからのアクセシビリティ">LINEヤフーにおけるこれからのアクセシビリティ</h2>
発表者: 岡崎晶彦さん・富田梓さん
<ul>
<li>a11yのタスクフォースのスタート</li>
<li>所属部署の年次の取り組みとして「アクセシビリティ」</li>
</ul>
<h3 id="TFの取り組み">TFの取り組み</h3>
<ul>
<li>障害当事者へのヒアリング
<ul>
<li>実際の理解が圧倒的に足りない</li>
<li>社内の視覚障害当事者を対象にしたヒアリング</li>
<li>視覚障害というもののグラデーションや、環境の多様性</li>
</ul>
</li>
<li>MeetUP 開催
<ul>
<li>社内イベント</li>
<li>頻度は2,3ヶ月に一回</li>
<li>当事者インタビュー、プロジェクトでの改善事情、色覚等区政</li>
<li>「アクセシビリティをやっている人間がいること」が見える</li>
</ul>
</li>
<li>ガイドラインの作成
<ul>
<li>WCAGはハードルが高い</li>
<li>他社のガイドラインをそのまま利用する？
<ul>
<li>社内向けにする場合に限界がある</li>
</ul>
</li>
<li>他社のガイドラインを参考に自社用のガイドラインを作成</li>
</ul>
</li>
<li>チェックリストと運用方法までドキュメント化</li>
</ul>
<h3 id="ドキュメントの浸透">ドキュメントの浸透</h3>
<ul>
<li>a11yブートキャンプを実施</li>
<li>完全な対応は諦める
<ul>
<li>ガイドラインを全部読んで理解する</li>
<li>読み合わせのガイドラインの項目を絞る</li>
</ul>
</li>
<li>最初の目標は、チェックを完了するところまでにした
<ul>
<li>見つかった問題はチケット作成</li>
</ul>
</li>
</ul>
<h3 id="a11yブートキャンプの実施">a11yブートキャンプの実施</h3>
<ul>
<li>全体スケジュール
<ul>
<li>2023/3~10月で全8回</li>
</ul>
</li>
</ul>
<h2 id="「違う人生を生きる人と一緒に働く」ということ">「違う人生を生きる人と一緒に働く」ということ</h2>
<h3 id="株式会社方角の設立の経緯">株式会社方角の設立の経緯</h3>
<ul>
<li>コロナ影響で就職が難しくフリーランスを初めて、そのまま仕事で会社として設立</li>
<li>エキマトペを制作</li>
<li>初期デザインへの対応
<ul>
<li>聴覚障がいの人が見慣れている横組み字幕を組むべき</li>
<li>手話をもっと大きく</li>
<li>情報の上にオノマトペを被せない方が良い</li>
</ul>
</li>
<li>世間の反応
<ul>
<li>聴覚障がいの人から色々な意見をもらえた</li>
<li>自分たちの言語が手話が大きく表示されていて嬉しい</li>
</ul>
</li>
<li>当事者が身近にいてもっと色々と知りたい
<ul>
<li>自社で雇用することにした</li>
</ul>
</li>
</ul>
<h3 id="コミュニケーションの仕方">コミュニケーションの仕方</h3>
<ul>
<li>対面では手話や筆談</li>
<li>リモートではテキストコミュニケーションを主としている</li>
<li>聴覚障がい者にも様々
<ul>
<li>手話を第一言語として日本語に苦手意識がある人とは、手話でコミュニケーション</li>
<li>唇を読み取れる人は口話で会話</li>
<li>盲ろうの人とは、テキストで会話</li>
<li>人によってコミュニケーションの手段を変えている</li>
</ul>
</li>
</ul>
<h2 id="デジタル庁でのアクセシビリティへの取り組み ―誰一人取り残されない、人にやさしいデジタル化をの実現に向けて―">デジタル庁でのアクセシビリティへの取り組み ―誰一人取り残されない、人にやさしいデジタル化をの実現に向けて―</h2>
アーカイブ禁止のためスキップ
<h2 id="今後やりたいと思ったこと">今後やりたいと思ったこと</h2>
<ul>
<li>業務で定期的に開催をしてくれているa11y勉強会で、半年・1年で達成したいことを洗い出してマイルストーンを作成
<ul>
<li>インプットが多くなっていると感じるので、プロダクトの改善という形でアウトプットを増やしていきたい</li>
</ul>
</li>
<li>業務でのa11yでの改善をブログなど何かしらの形で発信する</li>
<li><a href="https://www.digital.go.jp/policies/servicedesign/designsystem" target="_blank">デジタル庁のデザインシステム</a>を読む
<ul>
<li>コンポーネントやデザイントークンのライブラリ実装で<a href="https://www.digital.go.jp/policies/servicedesign/designsystem" target="_blank">デジタル庁のデザインシステム</a>を参考にしていく</li>
</ul>
</li>
<li><a href="https://www.digital.go.jp/" target="_blank">デジタル庁のサイト</a>のマークアップを読んでみる</li>
</ul>
<h2 id="感想">感想</h2>
<h3 id="セッションの感想">セッションの感想</h3>
アクセシビリティの社内への浸透など各社や各々の取り組みを色々と学べた。共通点として小さな改善を繰り返して共有していく事があり、継続して進めていける体制や仕組みづくりが大事なのかなと感じられ、a11yという話に限らない全てのことにおいて共通で適用される話だなと感じました。
片山さんのセッションでは、自分が想像している以上に障がい者と一緒に働くことの大変さや工夫が知れて、そこについて自分が全く考えたことがなかった事に気づけました。
デジタル庁のセッションでは、改めてデジタル庁がアクセシビリティへの対応として何をしていて、どのように進めているか聞けて非常に楽しかった。具体的な取り組みとして単に達成基準を満たせば良いということでも無いという話もあり、機械的に対応せずにちゃんと自分たちのプロダクトのことを考えていくことが大事。 
業務でのデザインシステムのライブラリ開発を進めているのに、困ったときに<a href="https://www.digital.go.jp/policies/servicedesign/designsystem" target="_blank">デジタル庁のデザインシステム</a>も参考にした方が良いな！という事に改めて気づけました。
<h3 id="参加しての感想">参加しての感想</h3>
コロナの関係もあり数年ぶりにカンファレンスに現地でオフライン参加できたが、会場独特の熱量や雰囲気はオフラインで参加しないと得られないものがあり、改めてオフラインの良さを実感できて非常に楽しかったです！

福岡で開催されたアクセシビリティカンファレンスの参加して聞いた発表内容のメモ書きです。

アクセシビリティカンファレンス福岡 参加メモ

TypeScriptの型パラメーターの変性のデフォルトの振る舞いとそれに関する変性アノテーションについてまとめました。

TypeScriptの型パラメーターの変性と変性アノテーション

この記事では、引数の配列の値をキーに持つオブジェクトを返す関数を型安全にする実装を紹介します。 
また、const-type-parametersを利用して、より型安全にする方法をまとめています。
<h2 id="配列でキーを指定する関数">配列でキーを指定する関数</h2>
次のように引数で指定した配列の値をキーにランダムな数値を持つオブジェクトを生成する関数を型安全にしていく方法を考えてみます。 
この関数では戻り値のキーの型が<code>string</code>のため、戻り値のオブジェクトで存在しないキーを指定しても型エラーになりません。
<pre class="language-typescript"><code class="language-typescript">const useIds = &lt;T extends string[]>(keys: T) => {
 return keys.reduce((acc, key: string) => {
 acc[key] = Math.floor(Math.random() * 10)
 return acc;
 } ,{} as {[key: string]: number}); 
}

const ids = useIds(['a', 'b']);

// エラーにならない
console.log(ids.hoge);
</code></pre>
<h2 id="型安全にする">型安全にする</h2>
ポイントは<code>[key in (typeof keys[number])]: number</code>の所です。MappedTypesと配列からユニオン型を生成する仕組みを組み合わせることで、配列の値だけをキーとして持つオブジェクトの型を生成できます。
また、<code>T extends readonly string[]</code>で<code>readonly</code>を指定することで、呼び出し側で値を<code>['a', 'b'] as const</code>と固定することができます。呼び出し側で<code>as const</code>を指定できないと、ユニオン型を生成できず、キーを制限することができなくなります。
<pre class="language-typescript"><code class="language-typescript">const useIds = &lt;T extends readonly string[]>(keys: T) => {
 return keys.reduce((acc, key: typeof keys[number]) => {
 acc[key] = Math.floor(Math.random() * 10)
 return acc;
 } ,{} as {[key in (typeof keys[number])]: number}); 
}

const ids = useIds(['a', 'b'] as const);

// Property 'hoge' does not exist on type '{ a: number; b: number; }'.(2339)
console.log(ids.hoge);
</code></pre>
<h2 id="const-type-parametersでリファクタ">const-type-parametersでリファクタ</h2>
先ほどのサンプルコードでは呼び出し側で<code>as const</code>を指定して値を固定する必要がありました。逆に言うとTypeScriptに慣れてない人と一緒に開発をする時に<code>as const</code>が指定されずに型安全にならない可能性があります。
人のスキルに依存せずに、できる限り仕組みで強制できるようにしたいです。
TypeScript5.0から追加された<a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#const-type-parameters" target="_blank">const-type-parameters</a>を利用することで、関数側で仕組みを強制することができます。
<code>const T extends readonly string[]</code>とジェネリクスの前に<code>const</code>を付けることで、型推論が<code>string[]</code>から<code>['a','b']</code>となります。 
関数の内部の型定義を意識せずに、文字列の配列を渡すだけで型安全に関数を利用することが可能になります。
<pre class="language-typescript"><code class="language-typescript">const useIds = &lt;const T extends readonly string[]>(keys: T) => {
 return keys.reduce((acc, key: typeof keys[number]) => {
 acc[key] = Math.floor(Math.random() * 10)
 return acc;
 } ,{} as {[key in (typeof keys[number])]: number}); 
}

const ids = useIds(['a', 'b']);

// Property 'hoge' does not exist on type '{ a: number; b: number; }'.(2339)
console.log(ids.hoge);
</code></pre>

引数の配列の値をキーに持つオブジェクトを返す関数を型安全にする実装を紹介します。また、const-type-parametersを利用して、より型安全にする方法をまとめています。

TypeScriptでジェネリクスと配列で戻り値のキーを制限する

GitHub Actionでnpmパッケージのリリース作業を自動化する方法をまとめています。

GitHub Actionでnpmパッケージのリリース作業を自動化する

このブログの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を導入する

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

記事一覧

アクセシビリティカンファレンス福岡参加メモ

TypeScriptの型パラメーターの変性と変性アノテーション

TypeScriptでジェネリクスと配列で戻り値のキーを制限する

GitHub Actionでnpmパッケージのリリース作業を自動化する

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

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

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

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

ElectronアプリをMonorepo構成で構築

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

記事一覧

アクセシビリティカンファレンス福岡 参加メモ

TypeScriptの型パラメーターの変性と変性アノテーション

TypeScriptでジェネリクスと配列で戻り値のキーを制限する

GitHub Actionでnpmパッケージのリリース作業を自動化する

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

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

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

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

ElectronアプリをMonorepo構成で構築

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

アクセシビリティカンファレンス福岡参加メモ