転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
その色を直す工程で、手順書に一行足しました。
ライトモードとダークモード、両方を見る。
理由も添えてあります。
ダークモードで色が沈んでいるはずだから、というものでした。
実際に見に行ったら、手順は正解で、理由は外れていました。
しかも2つ書いた理由が、2つとも外れていました。
見えない枠は、沈んでいたのではなく無かった
ひとつ目の見立ては、入力欄やカードの枠がダークモードで背景と同化している、というものでした。
見に行ったら、枠がありません。
ダークモードで見えにくいのではなく、ライトモードでも枠が描かれていませんでした。
使っているCSSのリセットで、既定の枠線が消えていたためです。
同化しているのではなく、最初から存在していませんでした。
読みにくかったのは、想定と逆のモードでした
ふたつ目は、エラー文の赤がダークモードで読みにくいはずだ、という見立てでした。
測ってみたら、逆でした。
ダークモードのコントラスト比は4.97で、アクセシビリティの基準を満たしています。
落ちていたのはライトモードのほうで、3.81でした。
手順書に書いた理由のとおりに見に行って、書いた理由とは逆の場所で問題が出たことになります。
直したあと、ライトモードは6.22になりました。
理由が外れても、手順は効きました
面白かったのは、理由が2つとも外れているのに、手順のほうは機能したことでした。
効いたのは、両方見る、という手順が実際に画面を開かせたからです。
何が見えるかは、開くまで分かりません。
理由の正しさは、ここでは関係ありませんでした。
効いたかどうかと、当たったかどうかは別
ここで止めておくと、理由は要らない、という話になりそうですが、そうでもないと思っています。
逆のこともあるはずだからです。
理由がもっともらしくても、手順のほうが的を外していることはあります。
そう考えると、手順が効いたかどうかと、その理由が当たっていたかどうかは、別々に確かめるものでした。
今回は手順だけが当たりました。
理由を信じ込んでいたら、ライトモードのほうは見ずに帰っていたと思います。
