いつものスキルに、
日本語の仕上げを。

公開実践（適用範囲を確認する）

書体・文字サイズ・行高・ウェイトを選ぶとき。実際に使う日本語の見出しと本文で判断する。

欧文の見本だけで採用せず、漢字・かな・数字を含む本文で確認する。フォント指定が日本語に効いているかも調べる。

たとえば

「請求書を確認する」「あいうえお」「0123456789」を同じ画面に置く。

例外・注意

ブランド指定がある場合は候補を増やす前に、その書体の日本語対応を確かめる。

確かめる

開発者ツールのRendered Fonts等で実際の書体を確認する。

出典：デジタル庁 タイポグラフィ / SmartHR 基本要素: タイポグラフィ

公開実践（適用範囲を確認する）

游ゴシックを採用する、またはWindowsで文字が細いという指摘があるとき。

同じfont-weightでも字面の濃さは一致しない。特に游ゴシックはMacの見た目だけで採用しない。

たとえば

本文400と見出し700をWindowsとmacOSで並べる。

例外・注意

資料中のOS別フォント構成は永続的な保証ではない。実際の配信先で確認する。

確かめる

漢字の細線、かなの太さ、ボタンラベルの判読性を比較する。

出典：SmartHR ウェブサイトのタイポグラフィ

編集上の仮説（実画面で比較する）

書体・文字サイズ・行高・ウェイトを選ぶとき。実際に使う日本語の見出しと本文で判断する。

初期検討では本文1rem前後から試し、文字の複雑さと読む距離に合わせる。16pxを法的な最低値や万能の答えとしない。

たとえば

記事本文と管理画面の表を同じサイズに固定せず、実文で比較する。

例外・注意

既存のアクセシビリティ基準や利用者要件があれば優先する。

確かめる

長文、補足、操作ラベルを通常表示と拡大表示で読む。

出典：デジタル庁 タイポグラフィ / SmartHR デザイントークン: タイポグラフィ

編集上の仮説（実画面で比較する）

日本語の本文、二行以上の見出し、ルビのある段落に行高を設定するとき。

本文は1.6〜1.8、複数行見出しは1.3〜1.5を試す出発点とし、ルビ・サイズ・書体で調整する。

たとえば

英語向けのline-height:1を二行の日本語見出しに流用しない。

例外・注意

短い一行ラベルや高密度の業務UIに同じ範囲を強制しない。

確かめる

上下の漢字が接触せず、見出しが一つのまとまりに見えるか確認する。

出典：デジタル庁 タイポグラフィ / SmartHR デザイントークン: タイポグラフィ

編集上の仮説（実画面で比較する）

書体・文字サイズ・行高・ウェイトを選ぶとき。実際に使う日本語の見出しと本文で判断する。

letter-spacing:normalを基点にする。英語の大文字ラベル用の広い字間や、大見出しの強いマイナス字間を和文全体へ広げない。

たとえば

「利用料金」を0と0.12emで比較し、語のまとまりを見る。

例外・注意

短い広告コピーの広い字間は表現として選べる。長文と設定を分ける。

確かめる

句読点を含む段落で、字間が語のまとまりを壊していないか読む。

出典：W3C CSS Text Level 3 / デジタル庁 タイポグラフィ

編集上の仮説（実画面で比較する）

書体・文字サイズ・行高・ウェイトを選ぶとき。実際に使う日本語の見出しと本文で判断する。

明朝体を和風の記号として一括適用せず、記事の語り口やブランドに合う箇所で選ぶ。小さなUIでは細線を確認する。

たとえば

編集記事の見出しは明朝、操作ラベルは読みやすいゴシックという案を比較する。

例外・注意

明朝の本文も成立する。業種と書体だけを一対一で固定しない。

確かめる

本文、注記、数字を各背景色と実サイズで読む。

出典：SmartHR 基本要素: タイポグラフィ / デジタル庁 タイポグラフィ

編集上の仮説（実画面で比較する）

日本語と英字・数字を同じ行に置くとき。価格、日付、製品名を重点的に見る。

同じfont-sizeだけで揃ったと判断せず、英字の高さ、数字、かなの字面、基線を確認する。数字の強調は対象を限定する。

たとえば

「月額 3,000円」と「API連携」を同じ行で見る。

例外・注意

価格や統計の数字を主役にする場合は意図した差を残す。

確かめる

丸数字、括弧、通貨記号を含む行が不自然に上下しないか見る。

出典：W3C 日本語組版処理の要件 / SmartHR デザイントークン: タイポグラフィ

公開実践（適用範囲を確認する）

書体・文字サイズ・行高・ウェイトを選ぶとき。実際に使う日本語の見出しと本文で判断する。

日本語Webフォントの転送量、必要なウェイト、表示中の代替書体を測る。swap指定だけで性能対策が完了したとしない。

たとえば

低速通信とフォント取得失敗で、本文とボタンの折り返しを見る。

例外・注意

フォントファイルを無許可で同梱しない。サブセットでは必要文字の欠落も確認する。

確かめる

初回表示、読み込み後の移動、フォント失敗時の可読性を記録する。

出典：Google web.dev Best practices for fonts / SmartHR 基本要素: タイポグラフィ

技術仕様・標準の解説

見出しや本文の改行、句読点の位置、和欧混植の間隔を調整するとき。

日本語の文書には適切なlangを宣言する。通常の改行を基点にし、必要な箇所でline-break:strictを比較する。

たとえば

「『次の一歩』を、今日から。」の句読点と括弧を見る。

例外・注意

strictは全ての見出しの意味的な改行を保証しない。多言語ページ全体をjaにしない。

確かめる

「、。）」が行頭に孤立せず、「（」が行末に残らないか対象ブラウザで確認する。

出典：W3C Declaring language in HTML / W3C CSS Text Level 3

技術仕様・標準の解説

日本語が狭いカードからはみ出す、または欧文の単語が途中で切れるとき。

word-break:normalを基点にし、keep-allを日本語本文全体に設定しない。break-allも英語の長い語を壊すため、全体への設定を避ける。

たとえば

「お問い合わせはこちらから」を狭いカードへ入れる。

例外・注意

短い固有名詞を一塊にしたい場合は局所指定と、幅不足の処理を用意する。

確かめる

320px相当と長い固有名詞で横にはみ出さないか確かめる。

出典：Mozilla word-break

編集上の仮説（実画面で比較する）

助詞や接尾辞だけが最終行に残るなど、意味のまとまりと表示幅が合わないとき。

助詞や接尾辞だけの最終行を避けたい場合は、文言・幅・サイズ・改行候補を比較する。見出し全体のnowrapで解決しない。

たとえば

「毎日の経理を、もっと軽く。」を一行、二行、三行で読む。

例外・注意

一字だけの最終行は直ちに規格違反ではない。短歌や固有のコピーは意図を守る。

確かめる

各幅で意味を追え、調整のために主張を変えていないか確認する。

出典：W3C 日本語組版処理の要件 / Mozilla word-break

編集上の仮説（実画面で比較する）

見出しや本文の改行、句読点の位置、和欧混植の間隔を調整するとき。

CMS本文へ表示幅依存のbrを埋め込まず、短いコピーに必要な場合だけ使う。wbrは改行候補であり、日本語の他の改行を禁止しない。

たとえば

PC用の「二行の見出し」をスマホでも同じ改行に固定しない。

例外・注意

詩、住所の構造、編集上の改行には意味があるため保つ。

確かめる

文字を拡大し、brの前後に一字だけの行が出ないか確認する。

出典：W3C CSS Text Level 3 / W3C WCAG 2.2 Understanding: Reflow

編集上の仮説（実画面で比較する）

見出しや本文の改行、句読点の位置、和欧混植の間隔を調整するとき。

短い説明文やカードでは左揃えを基点にし、text-align:justifyによる字間の伸びを確認する。長文の均等配置は目的がある場合に比較する。

たとえば

数字と英語を含む短い段落で、文字間の空きが大きく変わらないかを見る。

例外・注意

出版物に近い長文の組版まで一律に禁止しない。

確かめる

段落末尾、長い英語、約物の連続を含む実文で比較する。

出典：W3C CSS Text Level 3

技術仕様・標準の解説

括弧の余白や見出しの字面を詰めるためにOpenType機能を使うとき。

paltはフォントの字幅・間隔に関わる機能で、pwidとは異なる。句読点の空きを調整する目的ならtext-spacing-trimも比較し、本文全体への重ね掛けを避ける。

たとえば

短い見出しの括弧だけを検討し、表の桁揃えは保つ。

例外・注意

対応するOpenType機能がなければ同じ結果にはならない。

確かめる

有効・無効の両方で本文、括弧、価格、表の幅を比較する。

出典：Mozilla font-feature-settings / Mozilla font-variant-east-asian / Mozilla text-spacing-trim

技術仕様・標準の解説

見出しや本文の改行、句読点の位置、和欧混植の間隔を調整するとき。

text-autospace等を検討するときは対応環境を確認し、保存する文字列と見た目の間隔を区別する。原文の空白を一括挿入・削除しない。

たとえば

「AIで作るWebサイト」と「2026年11月」の空きを比較する。

例外・注意

製品名・コード・利用者入力の空白には意味があり得る。

確かめる

コピーした値を照合し、機能が無効でも文意が保たれるか確かめる。

出典：Mozilla text-autospace / W3C CSS Text Level 4

技術仕様・標準の解説

見出しや本文の改行、句読点の位置、和欧混植の間隔を調整するとき。

ルビはruby・rtを使い、縦組みはwriting-mode等で表す。一文字ずつbrを入れて縦書きを模倣しない。

たとえば

「組版」にルビを付け、縦組みの「2026」「（仮）」を見る。

例外・注意

横組みの全画面を縦組みに変える義務はない。読み上げ挙動は環境で異なる。

確かめる

数字・括弧の向き、ルビの重なり、選択・コピー、読み上げ順を実機で確認する。

出典：WHATWG HTML ruby / Mozilla writing-mode

編集上の仮説（実画面で比較する）

英語の大見出しや小さな日本語の副題からセクションの内容が分かりにくいとき。

英語の大見出しだけでセクションの内容を伝えず、日本語の見出しから用件を拾えるようにする。装飾の英語と情報の主役を区別する。

たとえば

「SERVICE」より先に「できること」を視覚的に認識できる案を比較する。

例外・注意

英語の読者や固有のブランド表現を対象とする場合は優先言語に合わせる。

確かめる

日本語の見出しだけを追ってページの流れが分かるか読む。

出典：デジタル庁 レイアウト / デジタル庁 リンクテキスト: アクセシビリティ

編集上の仮説（実画面で比較する）

LP、記事、一覧、業務画面の情報のまとまりと、狭い画面の配置を決めるとき。

英単語数を前提にした巨大見出しを置き換える際は、日本語実文の行数と隣接要素の位置からサイズを選ぶ。

たとえば

「部署をまたいだ承認作業を、ひとつに。」をヒーローへ入れる。

例外・注意

短い日本語を大きく見せる表現は選べる。見出しサイズに一律の上限は設けない。

確かめる

狭いPC幅とスマホで、主要な説明や操作が見出しだけに押し流されないか確認する。

出典：デジタル庁 タイポグラフィ / デジタル庁 レイアウト

編集上の仮説（実画面で比較する）

長文記事や説明欄の最大幅を指定するとき。chを日本語の文字数として扱わない。

chは主に欧文数字の幅に基づくため、日本語の行長へそのまま読み替えない。icや実文を使って比較する。

たとえば

長文の試作でmax-inline-size:40icを出発点にし、実際の読みやすさを見る。

例外・注意

40文字を推奨規格や絶対値としない。混植ではicの値と実文字数がずれる。

確かめる

同じ文章を複数の幅で読み、スマホでは画面幅を優先する。

出典：W3C CSS Values: ic / W3C 日本語組版処理の要件

公開実践（適用範囲を確認する）

LP、記事、一覧、業務画面の情報のまとまりと、狭い画面の配置を決めるとき。

関連要素の間隔を、別のまとまりとの間隔より小さくする。見出しと本文、価格と条件を離し過ぎない。

たとえば

価格の直下に、対象プランと課金周期を置く。

例外・注意

グリッドの数値だけでまとまりは決まらない。罫線・背景・文字階層も確認する。

確かめる

スクロール中に、どの注記がどの項目に属するか迷わないか確認する。

出典：デジタル庁 余白

編集上の仮説（実画面で比較する）

LP、記事、一覧、業務画面の情報のまとまりと、狭い画面の配置を決めるとき。

日本人は高密度を好むと一括りにせず、比較する画面か読む画面かで密度を変える。余白だけを増やして階層の問題を隠さない。

たとえば

料金比較表とブランド紹介ページを別々に評価する。

例外・注意

既存ユーザーの作業効率が重要な業務UIでは、読み物の余白量を強制しない。

確かめる

必要情報を探す課題で、文字サイズ・グループ・スクロール量を比較する。

出典：SmartHR デザイントークン: タイポグラフィ / デジタル庁 レイアウト

編集上の仮説（実画面で比較する）

LP、記事、一覧、業務画面の情報のまとまりと、狭い画面の配置を決めるとき。

短い英語のダミー文だけで高さを決めず、長い名称、複数行の説明、補足を入れる。本文の切り捨てで高さを合わせない。

たとえば

商品名が8文字と40文字のカードを並べる。

例外・注意

一覧で省略が必要なら、全文を確認できる導線と識別に必要な情報を残す。

確かめる

一件だけ長い場合と全件が長い場合の両方で確認する。

出典：デジタル庁 レイアウト / W3C WCAG 2.2 Understanding: Reflow

編集上の仮説（実画面で比較する）

LP、記事、一覧、業務画面の情報のまとまりと、狭い画面の配置を決めるとき。

固定幅・固定高で文字を押し込まず、横の余白と最小の高さから考える。長いラベルは文言と配置も見直す。

たとえば

「変更内容を確認する」と「保存する」を並べ、スマホでは縦積みも比較する。

例外・注意

折り返すラベルを全て禁止しない。重要操作は全文が見えることを優先する。

確かめる

通常・読込中・エラー時と文字拡大で、ラベルが欠けないか見る。

出典：SmartHR Button / W3C WCAG 2.2 Understanding: Reflow

編集上の仮説（実画面で比較する）

LP、記事、一覧、業務画面の情報のまとまりと、狭い画面の配置を決めるとき。

漢字を含む太字見出し、太い罫線、塗り面が重なるときは、文字サイズ・ウェイト・背景のどれで強弱を付けるか比較する。

たとえば

すべてを700にせず、見出しと本文と補足の差を実文で見る。

例外・注意

軽い字面を万能の美意識にしない。ブランドの力強さや可読性を優先する。

確かめる

白黒にしても主要な情報が分かれ、細線が読めるか確認する。

出典：デジタル庁 タイポグラフィ / SmartHR デザイントークン: タイポグラフィ

公開実践（適用範囲を確認する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

名詞やOKだけでは区別できない操作に、実行する動作と必要な対象を書く。

たとえば

「確認」だけで送信せず、「内容を確認する」と「送信する」を実際の処理に合わせて使う。

例外・注意

短い名詞で意味が確定する既存UIは、文体統一だけを理由に長くしない。

確かめる

ラベルと、押した後の画面・保存・送信の有無を照合する。

出典：SmartHR Button

編集上の仮説（実画面で比較する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

情緒的な言葉だけで内容を隠さず、本文を読まなくても何の話か分かる日本語を用意する。

たとえば

「未来を、ここから。」に加え、サービスが何をするかを具体的に示す。

例外・注意

ブランドコピー自体を説明文へ置き換える必要はない。情報の役割を分ける。

確かめる

見出しだけを抽出して、対象・便益・次の操作が追えるか読む。

出典：デジタル庁 レイアウト / SmartHR その他のUIテキスト

公開実践（適用範囲を確認する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

登録、保存、申込、購入、送信を、実行する処理に合わせて選ぶ。同じ処理を別の語で呼ばない。

たとえば

下書きを保存する操作を「申し込む」と呼ばない。

例外・注意

法的な手続名や既存の業務用語がある場合は、その定義を確認する。

確かめる

通常、確認、完了の各画面で同じ語が同じ状態を指すか確認する。

出典：SmartHR その他のUIテキスト / SmartHR Button

編集上の仮説（実画面で比較する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

操作ラベルを冗長な依頼文にせず、説明文の丁寧さと分けて検討する。敬語を全部除けば自然になるとは考えない。

たとえば

「設定をご保存いただけます」を、操作なら「設定を保存する」、説明なら「設定を保存できます」にする。

例外・注意

対人の挨拶や謝罪を、機械の操作ラベルと同じ基準で削らない。

確かめる

その文が操作、説明、依頼のどれかを確かめて読む。

出典：SmartHR その他のUIテキスト

公開実践（適用範囲を確認する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

エラーの対象を示し、利用者が次にできる操作を書く。入力した内容を残し、再入力を必要以上に求めない。

たとえば

「入力が不正です」から「郵便番号は7桁で入力してください」へ、実際の仕様に沿って直す。

例外・注意

原因を確定できない通信エラーで、入力ミスだと断定しない。

確かめる

各エラー文から対象の入力欄と次の操作へ進めるか確認する。

出典：SmartHR エラーメッセージ / デジタル庁 インプットテキスト: 使い方

公開実践（適用範囲を確認する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

同じ「詳しく見る」が並ぶ場合は、対象を含めて区別する。アクセシブルな名前にも可視ラベルの語を含める。

たとえば

「料金プランの詳細を見る」と「導入手順を見る」を区別する。

例外・注意

繰り返しの短いラベルが必要なら、周囲の構造と読み上げの両方で文脈を渡す。

確かめる

リンク一覧として聞いたときに、行き先を区別できるか確認する。

出典：デジタル庁 リンクテキスト: アクセシビリティ

編集上の仮説（実画面で比較する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

FAQ、CONTACT等を置く前に、対象者がその語から行き先を判断できるか確認する。日本語訳の併記は必要な箇所だけにする。

たとえば

問い合わせが主要操作なら「お問い合わせ」を表示する。

例外・注意

API、CSV、製品名など定着した語や固有名詞を無理に訳さない。

確かめる

初めて来た利用者の課題で、ラベルの選択ができるか確認する。

出典：SmartHR その他のUIテキスト / デジタル庁 リンクテキスト: アクセシビリティ

編集上の仮説（実画面で比較する）

見出し、操作ラベル、エラー、リンクの日本語を新しく書く・短くするとき。

行数を減らすための推敲でも、対象、条件、金額、期限、断定の強さを残す。削れない場合はレイアウトを調整する。

たとえば

「初月のみ無料」を「無料」に短縮しない。

例外・注意

引用、規約、固有名詞は編集範囲を別に確認する。

確かめる

修正前後で主張、条件、次の操作が同じか読み比べる。

出典：SmartHR その他のUIテキスト / デジタル庁 レイアウト

技術仕様・標準の解説

Enterキーに独自の検索・送信・決定処理を割り当てるとき。

独自のEnter送信ではIME変換中かを判定する。isComposingだけで対象のSafariまで保証したとしない。ボタンからの送信も残す。

たとえば

変換候補の確定をEnterで行い、その後の明示的な送信を区別する。

例外・注意

対象環境によって229判定等の補助が必要になる。固定時間の待機で全IMEを保証しない。

確かめる

実OS・IMEで変換中、確定直後、通常Enter、Shift+Enter、送信ボタンを確認する。

出典：Google Chrome IME-safe enter-to-submit

編集上の仮説（実画面で比較する）

日本語の入力欄や、氏名・住所など日本語を含むデータを扱うフォームを実装するとき。

未確定文字を毎キーで置き換えない。整形が必要なら、確定後の時点と対象フィールドを決め、元の値を損なわないようにする。

たとえば

かな変換の途中で全角数字を半角へ書き換えない。

例外・注意

検索補助と登録する氏名では許容できる変換が異なる。仕様があれば優先する。

確かめる

候補選択、カーソル移動、貼り付け、取り消しを実際に操作する。

出典：Google Chrome IME-safe enter-to-submit / Unicode UAX #15

公開実践（適用範囲を確認する）

日本語の入力欄や、氏名・住所など日本語を含むデータを扱うフォームを実装するとき。

業務で姓と名の区別が必要かを確認する。必要な場合もラベルと順序を明示し、外国籍の利用者や単名を想定する。

たとえば

「氏名」一欄と、「姓」「名」の二欄をデータ利用目的から選ぶ。

例外・注意

本人確認等で構造が指定されている場合は、例外時の案内も用意する。

確かめる

長い名前、中黒、空白、単名、漢字以外を含む名前で確認する。

出典：W3C Personal names around the world

編集上の仮説（実画面で比較する）

日本語の入力欄や、氏名・住所など日本語を含むデータを扱うフォームを実装するとき。

読み仮名を収集する理由を確認し、必要な文字種と例を入力前に示す。見た目だけで全角やカタカナを強制しない。

たとえば

「フリガナ」の説明に、受け付ける表記と必要な理由を添える。

例外・注意

外部システムの制約がある場合は、その範囲と修正方法を案内する。

確かめる

ひらがな、カタカナ、長音、中黒、空白で期待する受理・案内になるか確認する。

出典：W3C Personal names around the world / デジタル庁 インプットテキスト: 使い方

編集上の仮説（実画面で比較する）

日本語の入力欄や、氏名・住所など日本語を含むデータを扱うフォームを実装するとき。

日本の住所を扱う場合は郵便番号補助を検討し、補完失敗や新しい住所でも手動入力できる経路を残す。

たとえば

郵便番号から都道府県等を補完しても、町名や建物名を編集できるようにする。

例外・注意

日本語サイトが国内住所だけを受け付けるとは限らない。対象地域を先に決める。

確かめる

ハイフンあり・なし、補完0件、集合住宅、長い住所、対象外国住所を確認する。

出典：デジタル庁 インプットテキスト: 使い方 / WHATWG HTML autofill

技術仕様・標準の解説

日本語の入力欄や、氏名・住所など日本語を含むデータを扱うフォームを実装するとき。

郵便番号や電話番号など計算しない文字列を、先頭の0を落とす数値モデルにしない。typeとinputmodeを目的に合わせて選ぶ。

たとえば

郵便番号はtextとnumeric入力補助、電話番号はtelを候補にする。

例外・注意

国際番号、内線、記号の有無は実際の対象範囲で決める。

確かめる

先頭0、貼り付け、戻る操作、自動入力で値が変わらないか確認する。

出典：WHATWG HTML autofill / デジタル庁 インプットテキスト: 使い方

公開実践（適用範囲を確認する）

日本語の入力欄や、氏名・住所など日本語を含むデータを扱うフォームを実装するとき。

labelを置き、必要な条件と例をサポートテキストにする。placeholderだけに説明を置かず、必須・任意を文字でも示す。

たとえば

「郵便番号」の下に入力例を表示し、エラーと区別する。

例外・注意

デジタル庁の記号の使い方は、そのデザインシステムのルールであり全製品への義務ではない。

確かめる

入力済み、エラー、読み上げの各状態で、条件と対象を特定できるか確認する。

出典：デジタル庁 インプットテキスト: 使い方 / デジタル庁 インプットテキスト: アクセシビリティ

公開実践（適用範囲を確認する）

文字数上限のある入力欄で、変換途中や貼り付けを制限するとき。

maxlengthで変換前のかなや貼り付けを切り捨てないか確認する。長さの単位と検証時点を定め、超過時には上限と修正方法を示す。

たとえば

「が」、結合濁点、絵文字を、仕様で定めた文字数として数える。

例外・注意

UTF-16長、書記素数、バイト数のどれが正しいかは保存先の契約で異なる。

確かめる

上限前後、長いかなからの漢字変換、貼り付け、送信後の入力保持を確認する。

出典：デジタル庁 インプットテキスト: アクセシビリティ / Mozilla Intl.Segmenter

技術仕様・標準の解説

入力した氏名・引用・製品名へ、全半角変換やUnicode正規化を加えるとき。

NFKCは互換文字をまとめるため、保存する氏名や引用へ表示調整の都合だけで適用しない。比較用の値と原文を区別する。

たとえば

「①」「Ⅳ」「Ａ」と元の文字列を保存・検索の両方で比較する。

例外・注意

検索キー等へ正規化する場合は、対象と変換規則を仕様にする。

確かめる

入力から保存・再表示までの往復で、原文が意図せず変わらないか確認する。

出典：Unicode UAX #15 / W3C Personal names around the world

技術仕様・標準の解説

入力した文字列を保存・整形・再表示するとき、金額や日時を表示するとき。

ja-JP、JPY等を明示した整形を利用し、税込・税別、課金周期、対象プランを実データから表示する。

たとえば

Intl.NumberFormatで整形した価格の近くに、月額か年額かを示す。

例外・注意

ロケールは税計算や法的な表示要件を決めない。契約の仕様を確認する。

確かめる

0、大きい値、割引前後、異なる通貨で記号と単位を確認する。

出典：Mozilla Intl.NumberFormat

編集上の仮説（実画面で比較する）

入力した文字列を保存・整形・再表示するとき、金額や日時を表示するとき。

桁区切りと万・億表記を用途で選び、丸めの位置を固定する。原数値を保持し、比較表では同じ単位を使う。

たとえば

「12,340,000円」と「1,234万円」を、同じ原数値から表示する。

例外・注意

契約金額や会計値は、省略表記より正確な値を優先する場合がある。

確かめる

9999、10000、99999999、100000000と負数・小数で換算を確認する。

出典：Mozilla Intl.NumberFormat

技術仕様・標準の解説

入力した文字列を保存・整形・再表示するとき、金額や日時を表示するとき。

表示のロケールとタイムゾーンを決める。日付だけの値をUTC時刻へ変換して日がずれないか確認する。

たとえば

締切を「2026年11月8日 18:00（日本時間）」と、実際の基準に合わせて表示する。

例外・注意

海外利用者向けには、その地域の時刻や併記が適切な場合がある。

確かめる

月末・年末、UTCと日本時間で日が異なる時点を確認する。

出典：Mozilla Intl.DateTimeFormat

技術仕様・標準の解説

入力した文字列を保存・整形・再表示するとき、金額や日時を表示するとき。

和暦が必要な場合は暦を明示した整形を使い、検索・比較や入力で必要な表記も用意する。元号を固定文字列で連結しない。

たとえば

西暦入力を受けるか、和暦の選択欄を出すかを実要件で選ぶ。

例外・注意

行政向けであることだけを理由に全画面を和暦にしない。

確かめる

元号の切替日、元年、日付不正、保存後の再表示を確認する。

出典：Mozilla Intl.DateTimeFormat

公開実践（適用範囲を確認する）

入力した文字列を保存・整形・再表示するとき、金額や日時を表示するとき。

数量や金額の列は右揃えを検討する。同じ列で単位と小数桁を揃え、識別子や文章の列と区別する。

たとえば

料金比較表で3,000円と30,000円を縦に比較できるようにする。

例外・注意

郵便番号や製品コードは数量ではない。tabular-numsも対応書体で効果を確かめる。

確かめる

大きい値、負数、桁のない値、欠損値を同じ列に入れて確認する。

出典：SmartHR デザイントークン: タイポグラフィ / Mozilla Intl.NumberFormat

編集上の仮説（実画面で比較する）

入力した文字列を保存・整形・再表示するとき、金額や日時を表示するとき。

編集する本文では表記方針を決め、UI・コード・引用・利用者入力へ同じ置換を強制しない。括弧は対応を保つ。

たとえば

本文の「2026年」とコードのバージョン文字列を別々に扱う。

例外・注意

ブランド名や引用の表記は原文を優先する。単純置換で正規化しない。

確かめる

句読点、括弧、長音、マイナス、ハイフンの役割を読み比べる。

出典：Unicode UAX #15 / W3C 日本語組版処理の要件

技術仕様・標準の解説

入力した文字列を保存・整形・再表示するとき、金額や日時を表示するとき。

UTF-8を含む入力・保存・表示の経路を確認し、見た目が似た文字や異体字を欠落させない。文字数とバイト数を混同しない。

たとえば

「髙橋」「𠮷田」「が」「ガ」を入力・保存して再表示する。

例外・注意

保存先に制約がある場合は、利用者の原文を黙って別の文字へ置換しない。

確かめる

取得・送信・保存・再読込の各値を比較し、字形と文字列の差を区別する。

出典：W3C Multilingual form encoding / Unicode UAX #15

技術仕様・標準の解説

日本語の文字や操作を、拡大表示・読み上げ・異なる入力方法で確認するとき。

WCAGを確認する場合、通常の文字は4.5:1、大きな文字は3:1という条件と例外を区別する。日本語の細線は数値だけで読めたと判断しない。

たとえば

灰色の注記と細い明朝体を実サイズで確認する。

例外・注意

ロゴや非活性UI等の例外を確認する。日本語だけの特別な緩和基準を作らない。

確かめる

背景との比を測り、実際の書体・サイズでも判読する。

出典：W3C WCAG 2.2 Understanding: Contrast Minimum

技術仕様・標準の解説

日本語の文字や操作を、拡大表示・読み上げ・異なる入力方法で確認するとき。

横書きでは320 CSS px相当の幅で、不要な横スクロールや文字の欠落を確認する。固定高の見出し・ボタン・カードを重点的に見る。

たとえば

長い日本語見出しと入力エラーを出した画面を拡大する。

例外・注意

二次元の表など例外がある。幅の検査だけで全アクセシビリティ適合とは言わない。

確かめる

画面幅と拡大条件を記録し、主要な操作まで完了する。

出典：W3C WCAG 2.2 Understanding: Reflow

技術仕様・標準の解説

固定高の部品や省略処理があり、利用者が行高・字間を変更する可能性があるとき。

利用者の行高・段落・字間変更で内容が欠けないことを確認する。WCAGの検査値をデザインの既定値にする義務と読み違えない。

たとえば

日本語本文、ボタン、補足を、字間0.12em等の変更で確認する。

例外・注意

単語間隔等を使わない言語・文字体系には適用可能な項目で確認する。

確かめる

固定高とoverflow:hiddenによる切り捨て、操作の重なりを確認する。

出典：W3C WCAG 2.2 Understanding: Text Spacing

技術仕様・標準の解説

日本語の文字や操作を、拡大表示・読み上げ・異なる入力方法で確認するとき。

技術で表せる文字はテキストを使う。日本語のコピーを画像にする場合は、必要性と代替テキストを確認する。

たとえば

料金や申込条件を画像バナー内だけに入れない。

例外・注意

ロゴなど、表現自体が情報の伝達に必要な場合には例外がある。全ての文字入り画像を一律に禁止しない。

確かめる

画像の非表示、拡大、読み上げでも必要な条件を取得できるか確認する。

出典：W3C WCAG 2.2 Understanding: Images of Text

技術仕様・標準の解説

日本語の文字や操作を、拡大表示・読み上げ・異なる入力方法で確認するとき。

ページの主言語を示し、まとまった別言語の部分は必要に応じて区別する。日本語を見せてlang=enのままにしない。

たとえば

日本語本文と英語の引用を、各内容に合うlangで扱う。

例外・注意

製品名や短い外来語の一つずつに機械的なlang切替を付けない。

確かめる

実機の読み上げで、言語と語順が意図どおりか確認する。

出典：W3C WCAG 2.2 Understanding: Language of Page / W3C Declaring language in HTML

編集上の仮説（実画面で比較する）

日本語の文字や操作を、拡大表示・読み上げ・異なる入力方法で確認するとき。

見た目を整えたルビ、縦書き、英語の飾り見出しが、本文の重複読みや順序の混乱を起こさないか確認する。

たとえば

可視の日本語見出しと飾りの英語を、意味を重ねず伝える。

例外・注意

aria-hiddenで意味のある文字まで隠さない。スクリーンリーダー間の差を残す。

確かめる

VoiceOver等の対象環境で見出し移動と連続読みを確認する。

出典：WHATWG HTML ruby / W3C WCAG 2.2 Understanding: Language of Page

技術仕様・標準の解説

日本語の文字や操作を、拡大表示・読み上げ・異なる入力方法で確認するとき。

WCAG 2.2 AAの最小ターゲットは24 CSS pxの基準と間隔等の例外を含む。44pxを全てのAA必須条件と書かない。

たとえば

小さい「変更」リンクが密集する行で、領域と間隔を確認する。

例外・注意

本文内リンク等の例外がある。推奨する余裕と適合基準を分ける。

確かめる

領域の寸法と間隔を測り、指やキーボードで操作する。

出典：W3C WCAG 2.2 Understanding: Target Size Minimum

公開実践（適用範囲を確認する）

日本語の文字や操作を、拡大表示・読み上げ・異なる入力方法で確認するとき。

日本語の変換中にエラーを毎回読み上げたり、表示が動いたりしないようにする。ラベル・説明・エラーを関連付け、送信後に到達できるようにする。

たとえば

未入力で送信した後、対象欄と修正方法へ進めるようにする。

例外・注意

aria-liveをすべてのエラーへ一律に付けない。検証時点と読み上げの重複を実測する。

確かめる

変換中、送信後、修正後、複数エラーを読み上げと画面の両方で確認する。

出典：デジタル庁 インプットテキスト: アクセシビリティ / SmartHR エラーメッセージ

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

最終評価には日本語の実文か、同じ長さ・役割の例文を使う。Lorem ipsumの画面だけで日本語の完成度を判定しない。

たとえば

漢字、かな、英語、数字、括弧を含む見出しと段落を入れる。

例外・注意

未確定コピーは未確定と記録する。架空の実績や価格を本番データのように出さない。

確かめる

コピーが変わると崩れそうな部分を、長い例文で再確認する。

出典：デジタル庁 レイアウト / デジタル庁 タイポグラフィ

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

SaaSの紹介、長文記事、業務UI等を別の課題として評価する。一つの見た目を全用途へ広げない。

たとえば

料金表と読み物と入力フォームで、密度と改行の採点を分ける。

例外・注意

今回扱わない用途へ効果を外挿しない。

確かめる

各課題の内容理解と操作に必要な情報を確認する。

出典：デジタル庁 レイアウト / SmartHR デザイントークン: タイポグラフィ

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

ベースのデザインスキル、モデル、入力文、画面幅、フォントを固定し、追加スキルの有無で比較する。

たとえば

同じ課題・同じ文章で作った二案を並べる。

例外・注意

生成のゆらぎがあるため、一つの成功例から平均の改善率を主張しない。

確かめる

条件・差分・失敗例を保存し、変更した条件を明記する。

出典：デジタル庁 レイアウト / Google web.dev Best practices for fonts

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

読めない、操作できない、入力が失われる問題を先に解消する。字間や印象の好みは別の評価軸で比較する。

たとえば

IME誤送信を直したうえで、見出しの印象を評価する。

例外・注意

見た目の評点を、全規格への適合やCVR向上の証明に読み替えない。

確かめる

障害と好みの指摘を分け、再現条件を記録する。

出典：W3C WCAG 2.2 Understanding: Reflow / Google Chrome IME-safe enter-to-submit

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

通常文だけでなく、最長の想定名称、注記、エラー、数値を狭い幅へ入れる。例外処理は内容を隠す前に見直す。

たとえば

長い会社名、40文字の見出し、複数行のエラーを同じ画面に置く。

例外・注意

長さの上限が仕様にあれば、その前後を使う。無限長への保証は主張しない。

確かめる

代表幅に加えて境界の幅で、欠落・重なり・操作不能を記録する。

出典：W3C WCAG 2.2 Understanding: Reflow / Mozilla word-break

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

auto-phrase、text-autospace、text-spacing-trim等は、CSSの受理と対象ブラウザの表示を確認し、無効でも読める基本スタイルを保つ。

たとえば

@supportsの有無と対象ブラウザで、同じ見出しを比較する。

例外・注意

@supportsが真でも望む字形・改行・フォント機能まで保証しない。

確かめる

機能を外した状態、フォントが違う状態を比較する。

出典：Mozilla text-autospace / Mozilla text-spacing-trim / Mozilla word-break

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

特定企業の数値や編集上の目安を、既存ブランド・用途へ無条件に上書きしない。適用する理由と、例外の判断を短く残す。

たとえば

高密度の管理画面で、記事本文向けの1.8の行高を採用しない理由を示す。

例外・注意

安全性や必須のアクセシビリティ要件を、好みを理由に無視しない。

確かめる

ルールIDと、適用・非適用・未確認の理由を照合する。

出典：デジタル庁 タイポグラフィ / SmartHR デザイントークン: タイポグラフィ

編集上の仮説（実画面で比較する）

日本語UIの修正案、追加スキルの効果、公開する主張を比較するとき。

「こなれた」だけで終えず、階層、改行、密度、和欧混植、文言の理解、入力の支障を別々に記録する。

たとえば

日本語話者に二案を順序を隠して見せ、理由と次の操作の理解を聞く。

例外・注意

利用者試験をしていない段階で、改善率・CVR・滞在時間の増加を創作しない。

確かめる

評価者の人数、条件、判定できなかった範囲を記録する。

出典：デジタル庁 レイアウト / デジタル庁 リンクテキスト: アクセシビリティ