/* ============================================================ motion.css ── スクロールリビール ＋ ページトップ戻るボタン 2026-07-29 ============================================================ ■ なぜ style.css と分けたか モーションは「後から丸ごと外せる」ことに価値がある。 配色やレイアウトと違って、実機で見てから止める判断がありうるため、 この1ファイルを読み込まなければ完全に元へ戻る状態にしてある。 （style.css には一切手を入れていない） ■ 設計の芯：「どう動くか」を決めるのは、このCSSだけ JS（motion.js）は画面に入った要素に .is-rv-in を付けるだけで、 どんな見た目で動くかを一切知らない。 → 速さ・距離・段差を変えたいときは §1-0 の4行だけ直す。 → **対象**を変えるときだけ、JS側の RV_SEL と揃えて直すこと。 ■ 壊れない仕掛け（フェイルセーフ） 1. html.js が付いているときだけ隠す。 この class は motion.js が 内で同期実行して付ける。 JSが無効／読み込み失敗なら class が付かない ＝ 何も隠れない。 「アニメーションが動かない」ことはあっても「本文が消える」ことは無い。 2. @media screen で囲ってある ＝ 印刷時は必ず全部出る。 3. prefers-reduced-motion: reduce では丸ごと無効（WCAG 2.3.3）。 4. ファーストビュー（p-fv / p-page-kv / p-recruit-hero）と新着バーは対象外。 opacity:0 の要素は LCP 候補から外れるため、ヒーロー画像を フェードさせると LCP がフェード完了まで後ろにずれる。 ■ 「to キーフレームを書かない」ことの意味（重要） @keyframes kuroiwa-rv には from しか書いていない。 to を省くと、終了値は **その要素が本来持っている値** になる。 テーマ側が意図的に半透明にしている要素 （.c-cta__text は opacity:.9、.p-fv__lead は .85）を opacity:1 に塗り替えてしまわないための書き方。 to{opacity:1} と書くと、この2つのデザインが壊れる。 ============================================================ */ /* ============================================================ §1 スクロールリビール ============================================================ */ @media screen and (prefers-reduced-motion: no-preference) { /* ---- §1-0 調整つまみ ------------------------------------ 2026-07-30 ボス指示 「アニメーションはもっと遅く、スクロールする人の目に触れる感じがいい」 直したのは速さだけではない。**3つとも**原因だった。 ① 時間 .55s → .9s ② イージング cubic-bezier(.22,1,.36,1)（easeOutQuint） → cubic-bezier(.215,.61,.355,1)（easeOutCubic） Quint は経過25%の時点で **すでに72%動き終わっている**。 つまり時間だけ倍にしても「見えている動き」はほとんど増えず、 残りの75%はただ止まって見える尻尾だった。 Cubic は同じ25%地点で58%。動きが時間全体に散る。 ③ 距離 18px → 26px（小さすぎて動いたことに気付けない） さらに **発火位置を要素ごと**に変えた（§1-1のコメント参照）。 ここまでやって初めて「スクロールしている人の目の前で起きる」。 数字はこの4つだけ見ればいい。戻すのも1行。 */ html.js { --rv-dur: .9s; --rv-dist: 26px; --rv-step: 80ms; --rv-ease: cubic-bezier(.215, .61, .355, 1); } /* ---- §1-1 隠す ------------------------------------------ 以前は **セクション単位**（section:not(.is-inview)）だった。 セクションが1画面を超えると、下半分の中身は 「画面に入る前にアニメーションが終わっている」。 実測：TOPの p-strengths 1.35画面 / p-services 1.08 / p-cases 1.48 / p-access 1.86 ── 5つのうち4つが該当。 これが「目に触れない」の正体だったので、**要素単位**に変えた。 ■ このセレクタは motion.js の RV_SEL と1文字も違ってはいけない 片方だけ直すと「隠れたまま出てこない要素」が生まれる。 （JS側にも同じ注意書きを置いてある） */ html.js section:not(:where(.p-fv, .p-page-kv, .p-recruit-hero, .c-newsbar)) :where( .container > *:not([class*="__list"]):not([class*="__grid"]):not([class*="__plans"]), .container > :where([class*="__list"], [class*="__grid"], [class*="__plans"]) > * ):not(.is-rv-in):not(.is-rv-instant) { opacity: 0; transform: translateY(var(--rv-dist)); } /* ---- §1-2 出す（.is-rv-in は motion.js が付ける） ------- transition ではなく animation を使う。 transition だと「終了値」を明示せざるを得ず、 半透明の要素まで opacity:1 に上書きしてしまうため。 詳細度は上の「隠す」ルールより低いが問題ない。 CSSアニメーションは通常宣言より上のカスケード原点にいるので、 詳細度に関係なく勝つ。 */ html.js .is-rv-in { animation: kuroiwa-rv var(--rv-dur) var(--rv-ease) calc(var(--rv-i, 0) * var(--rv-step)) both; } @keyframes kuroiwa-rv { from { opacity: 0; transform: translateY(var(--rv-dist)); } /* to は書かない。§冒頭のコメント参照 */ } /* ---- §1-3 初期表示ですでに見えている位置の要素 ----------- 読み込み直後にフェードさせない。開いた瞬間から出ているべき ものが 0.9 秒かけて現れるのは体感速度を落とすだけ。 やり方は「隠す条件から外すだけ」。 .is-rv-in を付けないので、そもそもアニメーションが存在しない。 以前は .is-rv-instant で animation:none を当て、2フレーム後に その class を外していた。しかし class を外した瞬間に animation 指定が復活する ＝ **そこで初めてフェードが走る**。 「即表示」のつもりが、読み込み直後にワンテンポ遅れて フェードするという逆の結果になっていた。 付けたら外さない今の形なら、その事故が起きようがない。 */ /* ---- §1-4 段差（スタガー） ------------------------------ 要素単位の発火にしたので、**縦に並ぶものは段差がいらない** （それぞれが自分のタイミングで画面に入ってくる）。 以前の --rv-base（セクション内の何番目のブロックか）は廃止。 残すのは --rv-i だけ。横に並ぶカードは同時に画面へ入るので、 ここだけは人工的な段差が要る。80ms × 最大4 ＝ 320ms。 以前は最大 620ms あって、最後の1枚が出る頃には もう画面外に流れていた。 */ html.js :where([class*="__list"], [class*="__grid"], [class*="__plans"]) > *:nth-child(1) { --rv-i: 0; } html.js :where([class*="__list"], [class*="__grid"], [class*="__plans"]) > *:nth-child(2) { --rv-i: 1; } html.js :where([class*="__list"], [class*="__grid"], [class*="__plans"]) > *:nth-child(3) { --rv-i: 2; } html.js :where([class*="__list"], [class*="__grid"], [class*="__plans"]) > *:nth-child(4) { --rv-i: 3; } html.js :where([class*="__list"], [class*="__grid"], [class*="__plans"]) > *:nth-child(n+5) { --rv-i: 4; } } /* ============================================================ §2 ページトップ戻るボタン 参考3サイトのうち mmslaw.jp / maable.or.jp が実装している部品。 ただし「一番必要なのは黒岩」＝ TOPページが 11,251px と 参考サイト（5,242px / 7,731px）より長いため（_docs/13 §3 B-2）。 ・52×52px … WCAG 2.5.5（AAA）の 44×44px を満たす ・非表示中は visibility:hidden ＝ Tabキーでも到達しない ・prefers-reduced-motion では smooth スクロールを使わない（JS側） ============================================================ */ .c-totop { position: fixed; right: 20px; bottom: 20px; z-index: 60; width: 52px; height: 52px; padding: 0; border: 0; border-radius: var(--r-pill); display: grid; place-items: center; background: var(--grad-cta); color: #fff; cursor: pointer; box-shadow: 0 6px 20px rgba(11, 13, 17, .18); opacity: 0; visibility: hidden; transform: translateY(8px); transition: opacity .25s ease, transform .25s ease, visibility .25s; } .c-totop.is-visible { opacity: 1; visibility: visible; transform: none; } .c-totop:hover { box-shadow: 0 8px 24px rgba(11, 13, 17, .26); } .c-totop:focus-visible { outline: 2px solid var(--c-primary); outline-offset: 3px; } .c-totop svg { width: 22px; height: 22px; display: block; } @media (max-width: 767px) { .c-totop { right: 14px; bottom: 14px; width: 48px; height: 48px; } } @media (prefers-reduced-motion: reduce) { .c-totop { transition: none; transform: none; } } /* 印刷には出さない */ @media print { .c-totop { display: none; } } /* ============================================================ §3 eyebrow の大文字統一 ■ なぜCSSでやっているか（本来はテンプレート側で直すべき） サイト全体で20個ある英字ラベル（eyebrow）のうち、 ご相談の流れ／選考の流れ の3箇所だけが `Flow` とタイトルケースで、 他は全部大文字。本来は front-page.php / page-first.php / page-recruit.php の3ファイルを直すのが正しい。 ただし今回、WP管理画面のテーマファイルエディター経由の保存が 反映されない事象（原因未特定）に当たったため、 暫定的にCSSで統一している。 ■ 暫定とはいえ、この書き方自体は悪くない text-transform で統一しておくと、 今後どのセクションを足しても大文字/小文字が揺れなくなる。 テンプレート側を直したあとも、このルールは残してよい。 （残す場合は style.css へ移すのが筋） ============================================================ */ .eyebrow { text-transform: uppercase; } /* ============================================================ §4 駐車場案内イラストマップ 素材 : assets/img/access-parking-map.webp（1600×750 / 35.7KB） 原寸 5334×2500 から縮小。WebP は Baseline（Safari 14 / 2020〜）。 markup: mu-plugins/kuroiwa-motion.php が差し込む
■ サイズ感の判断（2026-07-29 ボス指示で改訂） ・幅はコンテンツ幅いっぱい（1080px） ・高さは **上のGoogleマップと同じ** にする → 原図は 2.13:1 と横長で、1080px幅では高さ506pxになり、 Googleマップ（518×389）より117pxも高くなって見た目が悪かった。 ■ どうやって縦を詰めたか（画像は加工していない） object-fit:cover ＋ object-position で上下をトリミング表示している。 素材ファイルは原図のまま。数値を変えれば見え方をいつでも戻せる。 表示比 1080:440 → 原図側では 1600×652px の窓（y43〜695）。 この窓に、事務所ピン／ロゴ／Pマーク／提携駐車場／Mパーク郡元8／ 徒歩約1分 複数台駐車可／純心学園駅前／郡元／鹿児島大学 が **すべて入る**（＝情報は1文字も落ちていない）。 切れるのは最下部の「唐湊線」ラベルの下端だけ。 Googleマップ側も aspect-ratio を 518/440 に変えて高さを合わせた。 どちらも aspect-ratio 指定なので、画面幅が変わっても揃ったまま。 ■ 数値の効果 駐車場マップ 506px → 440px（−66px） Googleマップ 389px → 440px（+51px、横に並ぶので揃う） キャプション帯 49px → 38px アクセスセクション全体では約26px短くなり、2つの地図の高さが一致する。 ■ SPで横スクロールにしている理由 幅343pxに収めると図中の文字が約6pxになり、 肝心の駐車場名と徒歩時間が読めなくなる。 画像幅を640px固定にして横スクロールさせ、約12pxを確保した。 SPでは上下トリミングもしない（縦に潰すと余計に読めなくなるため）。 ============================================================ */ .p-access__parking--map { width: 100%; margin: 0; padding: 0; border: 1px solid var(--c-border); border-radius: var(--r-md); background: #fff; overflow: hidden; } .p-access__parking-scroll { overflow-x: auto; overscroll-behavior-x: contain; -webkit-overflow-scrolling: touch; } .p-access__parking-scroll img { display: block; width: 100%; height: auto; } .p-access__parking-caption { padding: 10px 14px; border-top: 1px solid var(--c-border); background: var(--c-card-alt); color: var(--c-sub); font-size: 12px; line-height: 1.6; text-align: center; } /* タブレット以上：2枚の地図の高さを揃える */ @media (min-width: 768px) { .p-access__map { aspect-ratio: 518 / 440; } .p-access__map > * { height: 100%; } .p-access__parking-scroll img { aspect-ratio: 1080 / 440; object-fit: cover; object-position: center 44%; } } @media (max-width: 767px) { .p-access__parking-scroll img { width: 640px; max-width: none; aspect-ratio: auto; object-fit: fill; } .p-access__parking-caption::after { content: "（図は横にスクロールできます）"; display: block; margin-top: 4px; font-size: 11px; opacity: .8; } } /* ============================================================ §5 採用ページ ファーストビュー：SPでもパララックス ------------------------------------------------------------ 2026-07-29 ボス指示。PC/TBだけだったスティッキー背景をSPにも。 ■ 事前に伝えていた懸念（実測値） SP画像 recruit-hero-sp.jpg は 980×1689（縦横比 0.580）。 いまのヒーロー枠 375×675（0.556）にはほぼピッタリ収まる。 ところがパララックスにすると背景枠が 100svh（375×844 / 0.444）になり、 cover で入れると **横幅を約21%切る**ことになる。 ＝ 一番外側に立っている2人が画面から消える。 ■ そこでの手当て background-position を 50% ではなく 50% 18% にしている。 横は中央のまま、縦だけ上寄せ。人物の頭が切れるより 足元が切れるほうが被害が小さいため。 それでも両端は切れるので、**実機で見て許容できなければ このブロックごと削除すれば元（パララックス無し）に戻る**。 ■ スクリムを縦グラデーションに変えている理由 PCは横グラデ（左が濃い）だが、SPは文字が縦に積まれるので 上下方向で濃度を変えないと、下のボタン周りが白飛びする。 ============================================================ */ @media screen and (max-width: 767px) and (prefers-reduced-motion: no-preference) { html.js .p-recruit-hero-wrap { clip-path: inset(0); } html.js .p-recruit-hero__bg { display: block; position: sticky; top: 0; height: 100svh; margin-bottom: -100svh; z-index: 0; background: url(../img/recruit-hero-sp.jpg) 50% 18% / cover no-repeat; } html.js .p-recruit-hero__bg::after { content: ""; position: absolute; inset: 0; background: linear-gradient( 180deg, rgba(var(--c-scrim-recruit-rgb), .34) 0%, rgba(var(--c-scrim-recruit-rgb), .16) 26%, rgba(var(--c-scrim-recruit-rgb), .58) 100% ); } html.js .p-recruit-hero { position: relative; z-index: 1; background-image: none; background-color: transparent; } html.js .p-recruit-hero::before { display: none; } } /* ============================================================ §5-2 TOPのFVにも同じパララックスを入れる ------------------------------------------------------------ 2026-07-30 ボス指示 「トップについてはフォント等はそのままで、パララックスだけ反映」 ■ 採用ページで使っている仕掛けと同じもの 背景を position:sticky で画面に貼り付け、 その上を本文と次のセクションが滑っていく。 写真が止まって見えるので「奥行きがある」。 採用： .p-recruit-hero-wrap（clip-path） └ .p-recruit-hero__bg（sticky / margin-bottom マイナス） └ .p-recruit-hero TOP ： .p-fv（clip-path） └ .p-fv__bg └ （sticky / margin-bottom マイナス） TOPは .p-fv__bg が .p-fv の中にあり、しかも .p-fv が display:flex なので、__bg 自体をスティッキーにすると フレックスアイテムになって組版が動く。 そこで **1段内側の ** を留めている。 .p-fv__bg は position:absolute のままなので、 フレックスの計算には一切参加しない。 ■ overflow:hidden を clip-path:inset(0) に置き換えている理由 テーマは .p-fv に overflow:hidden を当てている。 overflow が visible 以外の祖先は**スクロールコンテナ**になるので、 その中のスティッキーは「親が動かない＝ずっと張り付き」になり、 1pxも動かない。見た目は「パララックスが効かない」。 clip-path なら同じように切り抜けて、スクロールコンテナは作らない。 （採用ページの -wrap が clip-path なのも同じ理由） ■ margin-bottom に % を使わない スティッキーの可動域は「親の内容ボックス − 自分のマージンボックス」。 高さと同じだけマイナスマージンを足してマージンボックスを潰さないと、 可動域が0になって動かない（§6でも同じ罠を踏んでいる）。 ここで margin-bottom:-100% と書くと、**%は親の幅基準**なので 1905pxが引かれる。意図と違うので svh で書く。 ■ 高さを 100% にしてある（採用は 100svh） FVのコントラストは、いまの切り抜き（高さ844px）で実測して スクリムと影を決めてある（typo.css §6）。 100svh にすると切り抜きが変わって測り直しになるので、 **見た目が1pxも変わらない 100% を選んだ**。 マイナスマージンだけ 100svh にして、可動域は必ず足りるようにしている。 ■ 効かない環境 prefers-reduced-motion: reduce では丸ごと無効。 テーマの overflow:hidden がそのまま残るので、現状の見た目に戻る。 ============================================================ */ @media screen and (prefers-reduced-motion: no-preference) { html.js .p-fv { overflow: visible; clip-path: inset(0); } html.js .p-fv__bg { overflow: visible; } html.js .p-fv__bg > :is(picture, img) { display: block; position: sticky; top: 0; height: 100%; margin-bottom: -100svh; } html.js .p-fv__bg > picture > img { width: 100%; height: 100%; object-fit: cover; } } /* ============================================================ §6 スクロール順次点灯（選考の流れ／キャリアパス） ------------------------------------------------------------ 2026-07-29 ボス指示。 「最初はグレーで、スクロールしたら色が入っていく。 全部色が変わるまでスクロールが止まって見えるように」 ■ しくみ 1. セクションに大きな padding-bottom を足してスクロール量を稼ぐ 2. 中身（.container）を position:sticky で画面に留める → 見た目は「スクロールが止まっている」 3. その間の進捗を motion.js が --seq-p（0〜1）として書き込む 4. 進捗がしきい値を越えた項目に .is-lit が付く ■ ピン留めはPC/TBのみ SPで padding-bottom に vh を使うと、ブラウザのアドレスバーの 出入りで高さが変わって位置が飛ぶ。 SPは「留めずに、スクロールに合わせて順に点く」だけにする。 点灯そのものはSPでも動く。 ■ JSが動かないとき html.js が付かない → 消灯状態のルールが効かない → 最初から全部点灯。 ピンも掛からないので、ただの通常セクションとして表示される。 ============================================================ */ /* ---- ピン留め（PC/TBのみ） ---- ■ 画面の「高さ」でも出し分けている（2026-07-29 実測して追加） ピンは「止まっている間に全部見せ切る」のが目的なので、 中身が画面に入り切らない高さの画面で掛けると逆効果になる。 実測（1366x700 の窓）：入社後の仕事は下に176pxはみ出し、 カード04が画面外のまま点灯していた。 選考の流れ … 必要な高さ ≒ 465px → min-height: 560px で許可 入社後の仕事 … 必要な高さ ≒ 865px → min-height: 870px で許可 内訳 80(ヘッダー)+257(見出し+業務リスト)+28〜64(間隔) +430(矢印とカード)+42(カードのはみ出し)+32(下余白) 条件を外れた画面ではピンが掛からず、SPと同じ 「スクロールに合わせて順に点く」に自動で落ちる。演出は消えない。 */ @media screen and (min-width: 768px) and (min-height: 560px) and (prefers-reduced-motion: no-preference) { /* ■ 余白は「sticky 要素の外」に置く（2026-07-29／ここで2回ハマった） ピンが効くには「親のコンテンツボックス」と「sticky 要素の マージンボックス」に**差**が要る。その差ぶんだけ動ける。 ✕ section に padding-bottom padding はコンテンツボックスの外側なので、親の中身は増えない。差ゼロ。 ✕ .container に margin-bottom（←ここで長くハマった） 親のコンテンツボックスは確かに伸びる。**が、同時に sticky 要素自身の マージンボックスも同じだけ伸びる**ので、差はやはりゼロ。 仕様どおりの挙動で、Chromeのバグではない。 computed が position:sticky でも1pxも動かない、という形で出る。 ○ section::after で「別の子要素」として余白を置く 親のコンテンツボックスだけが伸び、sticky 要素は元の高さのまま。 差＝::after の高さ＝そのままピンの持続距離になる。 ■ 110vh ＝ 約990pxぶん「スクロールが止まって見える」 この 990px のうち、**前半68%で全部点き終わり、後半32%（約317px）は "全部点いた状態で止まっている時間"** になる（配分は motion.js の HOLD）。 Appleのサイトでよくある「一旦止まる→見せ切る→再開」の作り。 130vh も試したが、2セクションでページが +2,437px 伸びて 「縦を短くしたい」という以前の方針と衝突したので110vhに落ち着かせた。 この数字ひとつで「止まって見える時間」を調整できる。 */ /* ■ ピン中は「画面まるごとが舞台」にする（2026-07-29 ボス指摘） 最初は container をそのままの高さで sticky させていたが、 ピン中に下側へ数百pxの空白が残って間延びして見えた。 Appleのサイトがこう見えないのは、**留める要素が画面の高さいっぱいで、 中身がその中央に来ている**から。余白は上下に均等に散るので 「空いている」ではなく「余裕がある」に見える。 ・min-height:100svh … 留める箱を画面の高さにする ・justify-content:center … 中身を縦中央に ・section の上下 padding は 0 に （箱が画面高さを持つので、外側の余白は二重になるだけ） */ /* display:flow-root … 子のマージンが親をすり抜けて外に出る（マージン相殺） のを止める保険。padding を 0 にすると相殺が起きるようになるため。 overflow:hidden でも BFC は作れるが、**それをやると親がスクロール コンテナ扱いになり sticky が即解除される**ので使わない。 */ html.js .p-flow { display: flow-root; padding-top: 0; padding-bottom: 0; } html.js .p-flow > .container { position: sticky; top: 0; /* 上 80px ＝ 固定ヘッダーの高さ。box-sizing:border-box なので 箱は画面ぴったりのまま、中身だけヘッダーの下に落ちる。 これが無いと「入社後の仕事」の見出しがヘッダーに触れる（実測 top:76px）。 下 32px は「入社後の仕事」対策。カード群が親ボックスより 42px はみ出して描かれる（階段状レイアウトのため）ので、 上下均等に置くと下端が画面外に6px落ちる。 下にも余白を入れて中心を少し上げている。 実測（管理バー込み903px時）：文字の上端100px／下端893px。 */ padding-top: 80px; padding-bottom: 32px; min-height: 100svh; display: flex; flex-direction: column; justify-content: center; } /* ピンの持続距離。この高さぶん「スクロールが止まって見える」。 ::after で持たせているのは上のコメントの理由。 */ html.js .p-flow::after { content: ""; display: block; height: 110vh; } } /* ---- ピン留め：入社後の仕事（高さ870px以上の画面のみ） ---- 中身が縦に長いので、選考の流れより条件が厳しい。 仕組みは上と同じ。理由もすべて上のコメントを参照。 */ @media screen and (min-width: 768px) and (min-height: 870px) and (prefers-reduced-motion: no-preference) { html.js .p-jobdesc { display: flow-root; padding-top: 0; padding-bottom: 0; } html.js .p-jobdesc > .container { position: sticky; top: 0; padding-top: 80px; padding-bottom: 32px; min-height: 100svh; display: flex; flex-direction: column; justify-content: center; } html.js .p-jobdesc::after { content: ""; display: block; height: 110vh; } /* 見出しブロックと矢印ブロックの間隔。 画面が低いほど詰める（＝下のカードを画面内に残す）。 841px ＝ 間隔以外に必要な高さの合計。 画面が十分高ければ元の64pxのまま。 */ html.js .p-jobdesc > .container > .p-jobdesc__top { margin-bottom: clamp(28px, 100vh - 841px, 64px); } } /* ---- 消灯／点灯：ステップ系すべて ---- `.p-flow--select`（採用の選考の流れ）だけでなく `.p-flow` 全体を対象にする。 TOP と /first/ の「ご相談の流れ」も **まったく同じ部品**（`.c-flow-step`／ `.p-flow__list::before`／同じ配色）でできているので、 セレクタを1段ゆるめるだけで3箇所そろう。 2026-07-29 ボス指示「ほかのページで同じようにできそうな部分は同じように」 */ @media screen and (prefers-reduced-motion: no-preference) { html.js .p-flow .c-flow-step__circle { background: #c9d2dc; transition: background .5s ease; } html.js .p-flow .c-flow-step.is-lit .c-flow-step__circle { background: var(--c-primary-dark); } html.js .p-flow .c-flow-step__label { color: #646e79; transition: color .5s ease; } html.js .p-flow .c-flow-step.is-lit .c-flow-step__label { color: var(--c-heading); } /* 説明文（/first/ のみ。TOPと採用ページには無いので空振りする）。 ここを消灯対象から外すと、丸とラベルだけ灰色で説明文は真っ黒、 という中途半端な見え方になる。 2026-07-30 ボス指示②で消灯色を上げた。 ラベル #9aa4b0 → #646e79（2.46:1 → 4.90:1） 説明文 #a8b0ba → #646e79（2.13:1 → 4.90:1） アイコン #b9c2cd → #858f9c（1.75:1 → 3.10:1） 「読めるが薄い」つもりで置いた数字が、実測すると **WCAGの4.5:1を大きく割っていた**。スクロールが途中で 止まった人には本当に読めない状態だった。 点灯後は var(--c-heading) / var(--c-sub) なので、 落差は十分残っている。 */ html.js .p-flow .c-flow-step__desc { color: #646e79; transition: color .5s ease; } html.js .p-flow .c-flow-step.is-lit .c-flow-step__desc { color: var(--c-sub); } /* アイコン（TOP と /first/ のみ。採用ページには無いので空振りする）。 線画なので currentColor を薄くするだけで消灯になる。 */ html.js .p-flow .c-flow-step__icon { color: #858f9c; transition: color .5s ease; } html.js .p-flow .c-flow-step.is-lit .c-flow-step__icon { color: var(--c-heading); } /* ステップをつなぐ線。灰色の上を、進捗ぶんだけ色が伸びる。 線そのものは style.css の ::before をそのまま使い、 背景をグラデーションに差し替えているだけ。 */ html.js .p-flow .p-flow__list::before { background: linear-gradient( 90deg, var(--c-primary) calc(var(--seq-p, 0) * 100%), #dfe3e9 0 ); } /* ---- 消灯／点灯：キャリアパス ---- */ html.js .p-jobdesc .c-path-step { opacity: .32; transform: translateY(8px); transition: opacity .5s ease, transform .5s cubic-bezier(.22, 1, .36, 1); } html.js .p-jobdesc .c-path-step.is-lit { opacity: 1; transform: none; } /* 矢印画像を左から右へ「描かれる」ように出す。 clip-path で右側を隠しておき、進捗ぶんだけ開く。 篠原税理士事務所の筆ストローク演出と同じ原理。 */ html.js .p-jobdesc .p-jobdesc__path-wrap img { clip-path: inset(0 calc((1 - var(--seq-p, 0)) * 100%) 0 0); } } /* ---- 丸の中の「step 01」の色（2026-07-30 ボス指示②） ---- ■ 何が問題だったか（実測） 消灯中の丸は #c9d2dc、その上の文字は白。**1.53:1**。 「step」は8px（SPは11px）太字なので WCAG は 4.5:1 を要求する。 19pxの数字も、大文字扱いの基準3:1にすら届いていない。 しかもこれは点灯の仕掛けだけの話ではない。 テーマ側も2〜4番目の丸を同じ #c9d2dc にしているので、 **モーションを切っている人にも同じ状態が出る**。 ■ 直し方：丸を濃くするのではなく、文字を濃くした 丸を白文字が乗るまで暗くする（#69747f 相当）と、 「淡いグレーがふっと青に変わる」という見え方が消えて、 消灯中の丸が重くなる。 淡いグレーのまま、文字だけ濃くすれば **8.2:1** になり、 点灯すると「濃い文字＋淡い丸」→「白文字＋青い丸」と 2つ同時に反転する。落差はむしろ増えた。 ■ :not(.is-lit) にしている理由 点灯後はテーマ既定の白文字に戻したい。 class 1つで両方の状態を面倒みられる。 モーションを切っている人（.is-lit が付かない）にも効く。 */ .l-main .p-flow .c-flow-step:not(.is-lit) :is(.c-flow-step__num, .c-flow-step__step) { color: var(--c-heading); } @media screen and (prefers-reduced-motion: no-preference) { html.js .p-flow :is(.c-flow-step__num, .c-flow-step__step) { transition: color .5s ease; } } /* モーションを切っている人には点灯の仕掛けが動かないので、 丸は全部同じ淡いグレーに揃える。 テーマ既定だと1つ目だけ青で、そこに濃い文字が乗ると 3.37:1 になり、 8pxの「step」が基準を割る。 */ @media screen and (prefers-reduced-motion: reduce) { .l-main .p-flow .c-flow-step__circle { background: #c9d2dc; } } /* ---- SPでは線を縦向きに ---- */ @media screen and (max-width: 767px) and (prefers-reduced-motion: no-preference) { html.js .p-flow .p-flow__list::before { background: linear-gradient( 180deg, var(--c-primary) calc(var(--seq-p, 0) * 100%), #dfe3e9 0 ); } } /* ---- SPの線の終点と左右位置（2026-07-30 ボス指摘） ---- ■ 終点 テーマは上下とも 35px の対称な内側寄せにしている。 PCは全ステップが同じ幅なのでそれで丸の中心に着くが、 SPはステップの高さがバラバラ（実測 114/160/114/138px）なので、 下端だけ「最後のステップの高さ − 丸の半径」でないと合わない。 138 − 35 ＝ 103px 必要なところが 35px しか無く、 **68px はみ出していた**。 値は motion.js の fitFlowLine() が --flow-tail に入れる。 JSが落ちたら既定値35pxに戻る＝いまと同じ見え方（フェイルセーフ）。 ■ 左右 丸は 70px 幅で左端0から始まるので中心は x=35。 線は left:35px / width:2px ＝ 35〜37px で、**1px右にずれていた**。 34px にして中心を揃える。 ※ prefers-reduced-motion: reduce の人にも位置のズレは見えるので、 このブロックだけモーションのメディアクエリの外に置いている。 */ @media screen and (max-width: 767px) { html.js .p-flow .p-flow__list::before { bottom: var(--flow-tail, 35px); left: 34px; } }