- 日本語
- English
- 한국어
- 简体中文
- 繁體中文
- Español
- Português (Brasil)
- Bahasa Indonesia
- ไทย
- Tiếng Việt
- Français
- Deutsch
見やすい記事の作り方：文字サイズ・行間・見出し・配色・12言語・アクセシビリティまで「読者を迷子にしない」設計
結論から言うと、見やすい記事は「オシャレなフォントを当てた記事」ではない。開いた瞬間に何の記事か分かり、途中で注意が飛んでも戻れて、文字を大きくしても壊れず、言語が変わっても自然に読める記事だ。読者は記事を攻略しに来ていない。記事側が道案内をしろ、という話である。
先に3行でまとめると：
- 本文は17〜18px前後、行間1.7〜1.9、長すぎない1行幅を実務上の開始点にすると扱いやすい。これは万能な法律ではない。
- WCAG 2.2では、コントラスト、200%文字拡大、320 CSS pxでのリフロー、Text Spacing上書き、キーボード操作などを壊さないことが重要だ。[R1-R8]
- 12言語は「同じCSSを12回コピペ」ではなく、共通アクセシビリティ基盤＋文字体系ごとの調整にする。[R10-R13]
1. 読みやすさはセンスではなく、3層の設計
読みやすさには少なくとも3層ある。文字が見えること、文章を追えること、ページを操作できることだ。18pxでも文章が壁ならつらい。文章が簡単でもボタンが小さすぎればつらい。つまり「フォントサイズだけ直して完成」は、家の表札だけ磨いて階段を撤去するようなものだ。
2. 読者は最初から全文を読まない。だから4段階で読めるようにする
Webでは拾い読みが普通に起きる。そこで記事を、5秒＝タイトルと冒頭、30秒＝H2と太字、3分＝要点、深掘り＝全文の4段階で読めるようにする。これは短文しか書くなという意味ではない。長文でも途中駅を大量に作れ、という意味だ。
H2だけ並べても話が通り、各節の最初に小さな結論があり、表や箇条書きで比較が拾える。こうすると「全部読む人」と「答えだけ欲しい人」を同じページで共存させられる。
3. 本文の文字サイズは17〜18px前後から始める
Web本文に絶対の最適値はない。ただし、小さすぎる文字は視認性を落とし、実ページを使った視線研究でもフォントサイズの増加は固定時間の短縮と関連した。[R14] 実務では本文17〜18px前後を開始点にし、remなど拡大しやすい単位で組むと扱いやすい。
重要なのは「18pxにしたからアクセシブル」ではないこと。WCAG 2.2 AAのResize Textは、200%まで拡大しても内容や機能を失わないことを求める。[R3] 読者が大きくした瞬間にメニューが消えるなら、18pxの美しい初期画面はただの記念写真である。
4. 行間・段落間・1行幅は「文字の交通量」を減らす
本文の開始値として行間1.7〜1.9程度は、長文Web記事で余裕を作りやすい。段落間にも明確な空白を置く。1段落1テーマを基本にし、改行ゼロの巨大ブロックを避ける。[R9]
欧文では55文字程度の中程度の行長が有効だった研究があり、実務では55〜70文字前後を開始点にしやすい。[R15] WCAG AAAのVisual Presentationは、変更可能な表示として80文字以下、CJKは40字以下を示す。[R8] ここでも「55が宇宙の真理」ではない。画面、言語、文字サイズで調整する。
本文の両端揃えは、単語間の空白が暴れやすい。特にWebでは基本的に片側揃えでよい。[R8]
5. フォントは魔法の杖ではない。普通に読めるものを速く出せ
セリフ体かサンセリフ体かに万能の勝者はいない。制御実験では読書速度に大きなセリフ効果が見られなかった。[R16] さらに2026年のメタ分析では、OpenDyslexicなどの「ディスレクシア向け特殊フォント」が標準フォントより一貫して読書成績を改善する証拠は確認されなかった。[R17]
つまり、障害対応＝特殊フォント強制、ではない。十分なサイズ、余白、自然な文字形、正しい文字収録、ユーザーが拡大できることのほうが土台になる。本文は端末のシステムフォントや各言語向けの一般的なフォントを優先すると、巨大なWebフォントを読み込まずに済む。
6. 背景色とコントラスト：薄いグレー文字は「オシャレ税」が高い
WCAG 2.2 AAでは通常文字4.5:1、大きな文字3:1以上のコントラストが基準になる。[R2] 「なんとなく高級そう」な薄灰色を白背景に置き、読者の目にデバフをかける必要はない。
研究では、暗い文字を明るい背景に置く正極性表示が、校正や小さい文字の視認で有利になる結果が複数ある。[R18] したがって一般向けの初期値はライトテーマが無難。ただしダークモードを好む人もいるので選択肢は残す。「真っ白より必ずオフホワイトが健康に良い」まで断言できる強い根拠はない。
7. H1・H2・H3は飾りではなく、記事の道路標識
H1はページの主題。H2は大きな論点。H3はその内訳。見た目だけ太字にして見出しのふりをするのではなく、HTMLの見出し構造として意味を持たせる。スクリーンリーダー利用者は見出しを使ってページ内を移動するため、見出しは視覚デザインとナビゲーションを兼ねる。[R7][R9]
良いテストは簡単だ。H2だけ抜き出しても記事の筋が分かるか。 分からなければ、見出しが「第2章」「続き」「もっと詳しく」みたいな迷子製造機になっている可能性が高い。
8. 太字・箇条書き・表・結論ボックスは「情報標識」として使う
太字は重要語。箇条書きは並列情報。表は比較。結論ボックスは判断の着地点。全部に役割を与える。全文を太字にしたら、警告灯を100個同時に点灯させるのと同じで、結局どれも目立たない。
リンクは色だけで区別せず、下線など別の手掛かりを持たせる。重要情報も「赤だから危険です」で終わらせず、文字やアイコンでも意味を示す。
9. 「ドパガキ」モードを前提にする。ただし人類の注意力8秒説には乗らない
ここでいう「ドパガキ」は医学用語ではない。通知→ショート動画→別タブ→戻る→『どこ読んでた？』という現代Webの散漫状態をネタ化した呼び名である。世代や障害をまとめて罵る言葉として使う話ではない。
対策は記事を全部ショート動画化することではない。短い段落、具体的な見出し、節ごとの小結論、必要なら目次、戻ってきても文脈を復元できる固有名詞を書くこと。自動再生、無関係なカルーセル、読んでいる途中に画面を占領するポップアップは、読者の集中に椅子を投げる行為なので減らす。[R9]
10. 障害アクセシビリティは「特別モード」ではなく標準装備にする
基礎はWCAG 2.2 AAを狙う。代表的には、200%文字拡大、320 CSS px相当で横往復しないリフロー、4.5:1コントラスト、24×24 CSS px以上のポインタ対象または十分な間隔、キーボード操作、見えるフォーカス、繰り返し部分を飛ばす仕組みなどだ。[R1-R7]
Text Spacingの「行間1.5、段落後2、字間0.12em、単語間0.16em」は初期CSSをその値にしろという命令ではない。利用者がその値へ上書きしても、文字が重なったり消えたり機能が壊れたりしないことがAA要件である。[R5]
実務上は主要ボタンを44px前後まで大きくすると押しやすいが、WCAG 2.2 AAの最低基準そのものは例外条件を含む24×24 CSS pxだ。[R6]
11. 12言語は同じデザインシステムを共有し、同じ組版を強制しない
共通化するのは、コントラスト、見出し階層、拡大、リフロー、余白、操作性、アクセシブルネームなどの土台。言語ごとに変えるのは、フォント、改行、ハイフネーション、句読点、行高などの文字体系依存部分だ。[R10-R13]
lang属性も重要。zh-Hans、zh-Hant、pt-BRのような情報を勝手にzhやptへ丸めない。ブラウザ、読み上げ、ハイフネーション、フォント選択の手掛かりになる。
12. 言語別の実務開始値
| グループ | 開始値の考え方 |
|---|---|
| 日本語 | 17〜18px、行間1.8前後、1行30〜40字程度から。不要な字間拡張を強制しない。日本語組版を尊重。[R10] |
| 簡体字・繁体字中国語 | CJK向けフォントを分け、禁則や句読点を壊さない。zh-Hansとzh-Hantを分離。[R11] |
| 韓国語 | Hangul向けフォントを使い、不自然な字間を入れない。韓国語組版の行分割を確認。[R12] |
| タイ語 | 正しいシェーピングと語境界・改行を壊さない。行高はやや広めが安全。word-break: break-allを雑に使わない。[R13] |
| ベトナム語 | ダイアクリティカルマークを完全収録するフォントを使い、固定高さで上下面を切らない。 |
| en/es/pt-BR/id/fr/de | 55〜70字程度を開始点にし、正しいlangとhyphens:autoを検討。ドイツ語の長い複合語などでオーバーフローを確認。 |
13. スマホでは「読める」だけでなく「すぐ出る」が重要
12言語全部に巨大なWebフォントを積むと、文字が出る前に読者が帰る。web.devはWebフォントがFCP/LCPを遅らせ、フォント入れ替えがCLSを起こしうると説明している。[R19] 本文はシステムフォント優先、ブランドフォントは必要箇所だけ、が堅い。
Core Web Vitalsの良好目標は現在、p75でLCP 2.5秒以下、INP 200ms以下、CLS 0.1以下。[R20] 読んでいる途中で広告やフォントのせいで段落がズドンと下へ落ちるサイトは、内容以前に「指で本を押さえていたら店員が机を動かした」状態になる。
14. 継続利用される記事は、毎回同じ場所に同じものがある
再訪を増やす土台は、派手な演出より予測可能性だ。見出しの見た目、リンクの見た目、目次、記事幅、言語切替、検索結果、関連記事の位置が毎回ほぼ同じなら、読者は操作を学習できる。
文字サイズ・行間・テーマを変える「Aa」設定を用意するなら、その選択を保存するのもよい。アクセシビリティは毎回「障害者モードをONにしてください」ではなく、初期状態から壊れにくく、必要な人だけ調整できる形が扱いやすい。
15. やってはいけない「読者耐久テスト」
避けたい代表例は、12px級の本文、薄い灰色、100文字超の長い行、両端揃え、1画面を埋める段落、見出し階層の飛び、全部太字、色だけで意味を表すUI、自動再生、閉じにくいポップアップ、本文を画像にする、拡大すると横スクロール地獄、巨大Webフォント、意味のないアニメーションである。
読者は「このサイトを読み切れる知能と動体視力があるか」を受験しに来たわけではない。
16. 迷ったらこの基準値から始める
| 項目 | 実務上の開始値 | 備考 |
|---|---|---|
| 本文 | 17〜18px | 絶対値ではない。拡大可能にする |
| 本文行間 | 1.7〜1.9 | 言語・フォントで調整 |
| 欧文1行 | 約55〜70文字 | 研究と実務の開始点。長すぎを避ける[R15] |
| CJK1行 | 約30〜40字 | 40はWCAG AAA Visual Presentationの目安にも対応[R8] |
| H1 | 約32〜40px | 本文との差を明確に |
| H2 | 約25〜30px | H2だけでも流れを理解可能に |
| H3 | 約21〜24px | H2との差を残す |
| 通常文字コントラスト | 4.5:1以上 | WCAG 2.2 AA[R2] |
| 大きな文字 | 3:1以上 | WCAG 2.2 AA[R2] |
| ポインタ対象 | 24×24 CSS px以上が基準 | 例外あり。実務では44px前後も検討[R6] |
| 文字拡大 | 200% | 内容・機能を失わない[R3] |
| リフロー | 320 CSS px | 原則2方向スクロール不要[R4] |
17. 品質ゲートを作る。「気をつけます」は品質保証ではない
記事工場やCMSなら、可読性を人間の記憶だけに任せない。静的検査でlang、H1、見出し順、画像alt、アクセシブルネーム、禁止CSSを見て、実ブラウザ検査で320px、200%拡大、Text Spacing上書き、キーボード、フォーカス、横スクロールを確認する。
安全に直せるものは自動修正してよい。たとえば欠けたlangや共通CSSの適用。ただし文章の意味、翻訳、altの内容など意味を変える修正は勝手に捏造しない。直せないならFAILにして人へ回す。品質ゲートは「怒る先生」ではなく「壊れた商品を出荷しない改札」である。
18. まとめ：良い記事は読者を試験しない
見やすい記事の本質は、文字を巨大化することでも、余白をオシャレにすることでもない。どこを読めばいいか分かる、途中で戻れる、拡大できる、押せる、読み上げられる、言語ごとに自然、そして速い。 これらを同じ設計システムにすることだ。
普通の成人には自然で、注意が散りやすい人、視力が弱い人、読字が苦手な人、キーボードや支援技術を使う人にも壊れにくい。それが一番強い。「アクセシブル版」を別室に作るより、最初から玄関を広くしておけばいい。
How to Make Articles Easy to Read: Typography, Spacing, Headings, Color, 12-Language Layout, and Accessibility Without Losing the Reader
An easy-to-read article is not simply an article wearing a fashionable font. It is a page whose purpose is obvious immediately, whose structure is easy to recover after an interruption, whose text survives zooming, and whose layout still feels natural when the language changes. Readers did not come to beat your article on hard mode. The article should provide the map.
Three-point summary:
- A practical starting point for long-form body text is roughly 17–18px with 1.7–1.9 line height and a controlled line measure. These are starting values, not universal laws.
- WCAG 2.2 makes contrast, 200% text resize, 320 CSS-pixel reflow, text-spacing overrides, keyboard access, and other behaviors testable requirements.[R1-R8]
- For 12 languages, share the accessibility system, not every typography rule. Script-specific layout still matters.[R10-R13]
1. Readability is a three-layer system, not a matter of taste
At minimum, a page must make text visible, make ideas easy to follow, and make controls usable. Large type cannot rescue a wall of confusing prose. Clear prose cannot rescue tiny controls. Fixing only font size is like polishing the street sign after removing the road.
2. People do not begin by reading every word, so design four reading depths
A strong article supports 5 seconds for title and summary, 30 seconds for headings and highlights, 3 minutes for the core answer, and a deep-read path for the full explanation. This does not mean every article must be short. It means long articles need many useful entry points.
If the H2 headings alone tell a coherent story, each section opens with its local conclusion, and comparisons are available in bullets or tables, scanners and deep readers can use the same page.
3. Start body text around 17–18px, then make enlargement safe
There is no single scientifically perfect body size. However, tiny text increases visual demand, and an eye-tracking study using real webpages found larger font sizes associated with shorter fixation duration.[R14] Around 17–18px is a reasonable production starting point for many long-form pages.
The important requirement is not “use exactly 18px.” WCAG 2.2 Resize Text requires text to reach 200% without losing content or functionality.[R3] If zooming makes navigation disappear, the attractive default screenshot does not count as success.
4. Line height, paragraph spacing, and line length control visual traffic
A body line height around 1.7–1.9 often gives long-form text comfortable breathing room. Separate paragraphs clearly and keep one main idea per paragraph.[R9]
A classic screen-reading experiment found a medium line length of about 55 characters supported effective reading; in production, roughly 55–70 characters is a useful starting band for Latin scripts.[R15] WCAG AAA Visual Presentation uses a configurable limit of 80 characters, or 40 for CJK.[R8] None of these numbers is a universal magic constant.
Avoid fully justified body text by default. Variable word spacing can make tracking harder.[R8]
5. Fonts are not magic; choose ordinary readable fonts and deliver them fast
Research does not identify a universal serif-versus-sans winner. A controlled 2005 study found no reading-speed benefit attributable to serifs.[R16] A 2026 meta-analysis also found no consistent reading-performance advantage for special dyslexia-oriented fonts over standard fonts.[R17]
Accessibility therefore should not mean forcing everyone into a “special disability font.” Size, spacing, familiar letterforms, complete character coverage, and user control matter more as a baseline. System fonts are especially useful when they avoid large downloads.
6. Background and contrast: faint gray text charges an expensive style tax
WCAG 2.2 AA requires at least 4.5:1 contrast for normal text and 3:1 for large text.[R2] Pale gray on white may look refined on a designer’s monitor while becoming free eye strain elsewhere.
Several studies report an advantage for dark text on a light background in proofreading and small-character legibility.[R18] A light default is therefore defensible for general reading, while dark mode can remain an option. There is not strong evidence that a particular off-white shade is universally healthier than white.
7. H1, H2, and H3 are road signs, not decorations
H1 names the page topic, H2 marks major arguments, and H3 breaks those arguments down. Use semantic heading elements, not merely bold text. Headings are also navigation landmarks for screen-reader users.[R7][R9]
A simple test: remove the paragraphs and read only the H2s. If the article no longer makes sense, headings such as “More,” “Next,” and “Chapter 2” may be manufacturing lost readers.
8. Bold, bullets, tables, and conclusion boxes should act as information signs
Bold marks key terms. Bullets express parallel items. Tables compare. A conclusion box marks a decision point. If everything is bold, nothing is emphasized; it is the visual equivalent of turning on every warning light at once.
Do not communicate meaning with color alone. Links should have another cue such as underlining, and critical states should also be expressed in text or icons.
9. Design for “dopagaki mode” without believing the eight-second attention myth
Here “dopagaki” is a joking label, not a medical term: notification → short video → another tab → return → “where was I?”. It should not be used to insult a generation or disability group.
The solution is not turning every article into a short video. Use short paragraphs, descriptive headings, local conclusions, optional contents navigation, and explicit nouns that restore context. Autoplay, irrelevant carousels, and popups that seize the screen are basically chairs thrown at the reader’s concentration.[R9]
10. Disability accessibility should be standard equipment, not a separate room
A solid baseline targets WCAG 2.2 AA: 200% text resize, reflow at 320 CSS pixels, 4.5:1 normal-text contrast, minimum pointer targets of 24×24 CSS pixels or qualifying spacing/exceptions, keyboard operability, visible focus, and mechanisms to bypass repeated blocks.[R1-R7]
The Text Spacing values—1.5 line height, 2em paragraph spacing after paragraphs, 0.12em letter spacing, and 0.16em word spacing—are not required default styles. The AA requirement is that user overrides to those values do not destroy content or functionality.[R5]
For comfort, major controls around 44px can be a useful design choice, but WCAG 2.2 AA itself uses 24×24 CSS pixels with exceptions.[R6]
11. Share one design system across 12 languages, not one forced typesetting system
Share contrast, hierarchy, reflow, spacing logic, accessible names, focus behavior, and control patterns. Adjust fonts, line breaking, hyphenation, punctuation behavior, and line height where the writing system requires it.[R10-R13]
Preserve precise language tags such as zh-Hans, zh-Hant, and pt-BR. They help browsers, speech systems, font selection, and hyphenation.
12. Practical script-by-script starting points
| Group | Starting approach |
|---|---|
| Japanese | 17–18px, roughly 1.8 line height, about 30–40 full-width characters per line; avoid forced extra tracking.[R10] |
| Simplified / Traditional Chinese | Separate CJK font stacks and preserve punctuation and line-start/end rules; keep zh-Hans and zh-Hant distinct.[R11] |
| Korean | Use Hangul-capable fonts and avoid unnatural character spacing; test Korean line breaking.[R12] |
| Thai | Preserve shaping, segmentation, and valid line breaking; slightly larger line height is often safer; avoid blunt word-break: break-all.[R13] |
| Vietnamese | Use fonts with complete diacritic support and avoid fixed-height boxes that clip marks. |
| en/es/pt-BR/id/fr/de | Start around 55–70 characters per line; use correct lang, consider hyphens:auto, and test long words such as German compounds. |
13. On mobile, readable also means fast
Loading huge web-font payloads for every script can make readers leave before the typography arrives. web.dev notes that web fonts can delay text rendering and LCP and can create layout shifts when fallback fonts are swapped.[R19] System fonts for body copy and selective brand fonts are a robust default.
Current good Core Web Vitals targets are LCP ≤2.5s, INP ≤200ms, and CLS ≤0.1 at the 75th percentile.[R20] A paragraph that jumps downward while somebody is reading it is the digital equivalent of moving the table while they are writing.
14. Repeat use grows when the interface behaves predictably
Consistency beats spectacle. Keep heading styles, article width, language switching, search results, related content, and link behavior predictable. Once readers learn the page, do not make them relearn it every visit.
If you offer an “Aa” control for size, spacing, width, or theme, remember the preference. Accessibility works better when the default is already sturdy and customization is optional, rather than hiding basic usability behind an “accessible mode.”
15. Avoid the reader endurance test
Common failures include 12px body copy, weak gray contrast, very long lines, full justification, giant paragraph walls, skipped heading levels, everything bold, color-only meaning, autoplay, hard-to-close popups, text embedded in images, horizontal-scroll hell at zoom, giant font downloads, and decorative motion with no purpose.
The reader did not come to prove they possess enough intelligence, vision, and motor precision to survive your website.
16. A practical baseline table
| Item | Starting value | Note |
|---|---|---|
| Body | 17–18px | Not a law; preserve zoom |
| Body line height | 1.7–1.9 | Tune by script/font |
| Latin line measure | ~55–70 chars | Practical starting band[R15] |
| CJK line measure | ~30–40 glyphs | Related to WCAG AAA 40-glyph configurable limit[R8] |
| H1 | ~32–40px | Clearly distinct from body |
| H2 | ~25–30px | Make the outline understandable |
| H3 | ~21–24px | Keep hierarchy visible |
| Normal text contrast | ≥4.5:1 | WCAG 2.2 AA[R2] |
| Large text contrast | ≥3:1 | WCAG 2.2 AA[R2] |
| Pointer target | 24×24 CSS px baseline | Exceptions exist; ~44px can improve comfort[R6] |
| Text resize | 200% | No lost content/function[R3] |
| Reflow | 320 CSS px | Avoid two-dimensional scrolling in normal content[R4] |
17. Build a quality gate: “we will be careful” is not quality assurance
For a CMS or article factory, automate what can be tested. Static checks can inspect lang, one H1 per public page, heading order, alt presence, accessible names, and risky CSS. Browser tests can check 320px reflow, 200% zoom, Text Spacing overrides, keyboard navigation, focus visibility, and horizontal overflow.
Safe structural fixes can be automated. Meaning-changing fixes—rewriting prose, translations, or meaningful alt text—must not be fabricated. If the system cannot fix it safely, fail the gate and route the problem for review. A quality gate is not an angry teacher; it is the turnstile that stops broken products from shipping.
18. Conclusion: a good article does not test the reader
Readable design means the reader knows where to look, can recover after interruption, can enlarge text, can operate controls, can use assistive technology, gets natural typography in their language, and does not wait forever for the page to settle.
Make the default comfortable for ordinary adults and resilient for people with low vision, reading difficulty, cognitive or attention barriers, motor limitations, or assistive-technology needs. Instead of building a separate accessibility side door, make the main entrance wide enough.
읽기 쉬운 글 만드는 법: 글자 크기·줄간격·제목·색상·12개 언어·접근성까지, 독자를 길 잃게 하지 않는 설계
읽기 쉬운 글은 멋진 폰트를 씌운 글이 아니다. 열자마자 무슨 글인지 알 수 있고, 집중이 끊겨도 다시 위치를 찾을 수 있으며, 글자를 키워도 깨지지 않고, 언어가 바뀌어도 자연스럽게 읽히는 글이다. 독자는 웹페이지 고난도 던전을 깨러 온 사람이 아니다. 길 안내는 글이 해야 한다.
먼저 세 줄 요약:
- 장문 본문은 대략 17
18px, 줄높이 1.71.9, 지나치게 길지 않은 행 길이를 실무 시작점으로 삼기 좋다. 절대 법칙은 아니다. - WCAG 2.2에서는 대비, 200% 확대, 320 CSS px 리플로우, Text Spacing 사용자 덮어쓰기, 키보드 접근 등이 실제 검사항목이다.[R1-R8]
- 12개 언어는 접근성 기반은 공유하되, 문자 체계별 조판까지 억지로 같게 만들면 안 된다.[R10-R13]
1. 가독성은 감각이 아니라 3층 구조다
최소한 문자가 보이는가, 내용을 따라갈 수 있는가, 페이지를 조작할 수 있는가를 함께 봐야 한다. 글씨가 커도 문단이 벽이면 힘들고, 문장이 쉬워도 버튼이 너무 작으면 힘들다. 폰트 크기 하나만 고치는 것은 도로를 없애고 표지판만 닦는 것과 비슷하다.
2. 사람은 처음부터 전부 읽지 않는다. 네 단계로 읽게 하자
5초: 제목과 요약, 30초: H2와 강조, 3분: 핵심 답, 깊게 읽기: 전체 본문이라는 네 깊이를 지원하면 좋다. 장문을 금지하자는 뜻이 아니다. 장문에 정거장을 많이 만들자는 뜻이다.
H2만 읽어도 흐름이 보이고, 각 절 첫머리에 작은 결론이 있으며, 비교는 목록이나 표로 찾을 수 있으면 훑어보는 사람과 정독하는 사람이 같은 페이지를 쓸 수 있다.
3. 본문은 17~18px 부근에서 시작하고 확대를 안전하게 만든다
완벽한 단일 크기는 없다. 다만 실제 웹페이지를 이용한 시선추적 연구에서는 글자 크기가 커질수록 고정 시간이 줄어드는 경향이 확인됐다.[R14] 그래서 17~18px은 장문 페이지의 합리적인 시작점이다.
더 중요한 것은 WCAG 2.2 Resize Text다. 200%까지 키워도 내용이나 기능이 사라지지 않아야 한다.[R3] 기본 화면이 예뻐도 확대 순간 메뉴가 증발하면 성공이 아니다.
4. 줄간격·문단간격·행 길이는 화면의 교통량을 줄인다
본문 줄높이 1.7~1.9 정도는 장문에 여유를 주기 쉽다. 문단 사이도 분명히 구분하고, 한 문단에 한 주제를 기본으로 한다.[R9]
라틴 문자 연구에서는 약 55자 중간 행 길이가 효과적인 읽기를 지원했다.[R15] 실무에서는 55~70자 정도부터 시험하기 좋다. WCAG AAA Visual Presentation은 조절 가능한 표시에서 최대 80자, CJK는 40자를 제시한다.[R8] 숫자를 종교처럼 믿지 말고 실제 언어와 화면에서 확인한다.
5. 폰트는 마법이 아니다. 평범하게 읽히고 빨리 뜨는 것이 먼저다
세리프와 산세리프 사이에 보편적 승자는 없다. 통제 연구에서 세리프가 읽기 속도를 올리는 뚜렷한 효과는 없었다.[R16] 2026년 메타분석에서도 OpenDyslexic 같은 특수 폰트가 일반 폰트보다 일관된 읽기 성능 향상을 보인다는 근거가 나오지 않았다.[R17]
따라서 접근성은 “장애인 전용 폰트 강제”가 아니라 충분한 크기, 간격, 익숙한 글자 형태, 완전한 글리프 지원, 사용자 확대가 기본이다.
6. 배경과 대비: 흐린 회색 글씨는 스타일 비용이 너무 비싸다
WCAG 2.2 AA는 일반 텍스트 4.5:1, 큰 텍스트 3:1 이상의 대비를 요구한다.[R2] 흰 바탕에 옅은 회색을 얹어 고급스러움을 얻고 독자에게 눈 피로를 청구할 이유는 없다.
여러 연구에서 밝은 배경의 어두운 글자가 교정과 작은 글자 식별에 유리했다.[R18] 일반 읽기의 기본은 라이트 테마가 합리적이고, 다크 모드는 선택으로 제공하면 된다.
7. H1·H2·H3는 장식이 아니라 도로표지판이다
H1은 페이지 주제, H2는 큰 논점, H3는 하위 논점이다. 단순히 굵게 보이게 하지 말고 의미 있는 HTML 제목으로 만든다. 화면낭독기 사용자는 제목 구조를 페이지 이동에 활용한다.[R7][R9]
H2만 뽑아 읽어도 전체 흐름이 이해되는지 확인하자. “더 보기”, “다음”, “2장”만 반복되면 제목이 아니라 미로 표지판이다.
8. 굵게·목록·표·결론 상자는 정보 표지로 쓴다
굵게는 핵심어, 목록은 병렬 정보, 표는 비교, 결론 상자는 판단 지점에 쓴다. 모든 문장을 굵게 하면 모든 경고등을 동시에 켜는 셈이라 아무것도 눈에 띄지 않는다.
링크와 상태는 색만으로 구분하지 말고 밑줄, 텍스트, 아이콘 등 다른 단서를 같이 둔다.
9. ‘도파가키 모드’를 전제로 하되 8초 집중력 신화는 버린다
여기서 ‘도파가키’는 의학용어가 아니라 알림→숏폼→다른 탭→복귀→“어디 읽었지?” 상태를 농담으로 부르는 표현이다. 세대나 장애를 비하하는 분류가 아니다.
해법은 모든 글을 숏폼으로 만드는 것이 아니다. 짧은 문단, 구체적인 제목, 절마다 작은 결론, 필요하면 목차, 복귀했을 때 문맥을 복원할 명확한 명사를 쓴다. 자동재생과 화면을 가로채는 팝업은 집중력에 의자를 던지는 행동이다.[R9]
10. 장애 접근성은 별도 모드가 아니라 기본 장비로 둔다
WCAG 2.2 AA를 기준으로 200% 확대, 320 CSS px 리플로우, 4.5:1 대비, 24×24 CSS px 포인터 대상 또는 허용 예외/간격, 키보드 조작, 보이는 포커스, 반복 영역 건너뛰기 등을 확인한다.[R1-R7]
Text Spacing의 1.5 줄높이, 2em 문단 뒤 간격, 0.12em 자간, 0.16em 단어 간격은 기본 CSS 권장값이 아니라 사용자 덮어쓰기 내성 시험값이다.[R5]
11. 12개 언어는 한 디자인 시스템을 공유하되 한 조판을 강제하지 않는다
대비, 계층, 리플로우, 포커스, 접근 가능한 이름 등은 공유한다. 폰트, 줄바꿈, 하이픈, 문장부호, 줄높이는 문자 체계에 맞게 바꾼다.[R10-R13] zh-Hans, zh-Hant, pt-BR 같은 정확한 lang 정보도 유지한다.
12. 문자 체계별 시작점
| 그룹 | 시작 접근법 |
|---|---|
| 일본어 | 17 |
| 중국어 간체/번체 | CJK 폰트를 분리하고 문장부호·금칙을 보존, 두 언어 태그를 구별.[R11] |
| 한국어 | Hangul 지원 폰트, 불필요한 자간 금지, 한국어 줄바꿈 확인.[R12] |
| 태국어 | 셰이핑·단어 경계·줄바꿈을 보존, 충분한 줄높이, break-all 남용 금지.[R13] |
| 베트남어 | 모든 성조 부호를 지원하고 고정 높이 박스에서 잘리지 않게 한다. |
| 라틴계 언어 | 약 55~70자, 정확한 lang, 필요 시 hyphens:auto, 긴 단어 오버플로 확인. |
13. 모바일에서는 읽을 수 있는 것만큼 빨리 뜨는 것도 중요하다
모든 언어에 거대한 웹폰트를 실으면 글자가 뜨기 전에 사용자가 떠날 수 있다. web.dev는 웹폰트가 렌더링/LCP를 늦추고 폰트 교체가 CLS를 만들 수 있다고 설명한다.[R19] 본문은 시스템 폰트 우선이 안전하다.
현재 Core Web Vitals의 좋은 목표는 p75 기준 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하이다.[R20]
14. 재방문은 화려함보다 예측 가능성에서 나온다
제목 모양, 본문 폭, 언어 전환, 검색 결과, 관련 글 위치, 링크 스타일을 일관되게 유지한다. 독자가 한 번 배운 조작을 다음 방문에도 그대로 쓸 수 있게 한다.
“Aa” 설정을 제공한다면 크기·줄간격·폭·테마 선택을 저장하는 것도 좋다. 기본값부터 튼튼하게 만들고 조정은 선택으로 둔다.
15. 독자 내구도 시험을 만들지 말자
12px 본문, 약한 회색, 너무 긴 행, 양쪽 정렬, 거대한 문단, 제목 단계 점프, 전부 굵게, 색만으로 의미 전달, 자동재생, 닫기 어려운 팝업, 이미지 속 본문, 확대 후 가로스크롤, 거대한 폰트 파일, 무의미한 애니메이션은 피한다.
독자는 사이트 생존시험을 보러 온 것이 아니다.
16. 기본값 표
| 항목 | 시작값 |
|---|---|
| 본문 | 17~18px |
| 줄높이 | 1.7~1.9 |
| 라틴 행 길이 | 약 55~70자[R15] |
| CJK 행 길이 | 약 30~40자[R8] |
| H1 | 약 32~40px |
| H2 | 약 25~30px |
| H3 | 약 21~24px |
| 일반 텍스트 대비 | ≥4.5:1[R2] |
| 큰 텍스트 대비 | ≥3:1[R2] |
| 포인터 대상 | 24×24 CSS px 기준, 예외 있음[R6] |
| 텍스트 확대 | 200%[R3] |
| 리플로우 | 320 CSS px[R4] |
17. 품질 게이트를 만든다
정적 검사로 lang, H1, 제목 순서, alt, 접근 가능한 이름, 위험 CSS를 검사하고 브라우저 검사로 320px, 200% 확대, Text Spacing, 키보드, 포커스, 가로 오버플로를 확인한다.
구조적으로 안전한 문제는 자동수정할 수 있다. 하지만 문장 의미, 번역, 의미 있는 alt처럼 내용이 바뀌는 수정은 자동으로 지어내지 않는다. 안전하게 못 고치면 실패시켜 검토로 보낸다.
18. 결론: 좋은 글은 독자를 시험하지 않는다
어디를 읽을지 알 수 있고, 끊겼다가 돌아올 수 있고, 확대해도 되고, 누를 수 있고, 읽어줄 수 있고, 언어마다 자연스럽고, 빨리 뜨는 페이지가 강하다. 별도 접근성 출입구를 만드는 대신 처음부터 정문을 넓게 만들자.
怎样做出真正好读的文章：字号、行距、标题、配色、12种语言和无障碍设计，一次把读者“别弄丢”
好读的文章，不是给正文换一个“高级字体”就结束。真正的目标是：打开就知道在讲什么，中途分心后能迅速找回来，放大文字也不坏，切换语言后仍然自然。读者不是来挑战网页困难模式的，路线应该由文章自己标清楚。
三句话先说完：
- 长文正文可从约17–18px、1.7–1.9行高和适中的行宽开始测试；这是实务起点，不是宇宙常数。
- WCAG 2.2把对比度、200%文字放大、320 CSS px重排、Text Spacing覆盖、键盘操作等变成可检查要求。[R1-R8]
- 12种语言应共享无障碍基础，但不同文字系统的字体、换行和标点规则不能强行统一。[R10-R13]
1. 可读性不是审美，而是三层系统
至少要同时考虑：文字看不看得见、内容跟不跟得上、页面操不操作得了。大字号救不了文字墙，简单句也救不了小得像灰尘的按钮。只改字体大小，就像道路拆了以后认真擦亮路牌。
2. 用户不会一上来逐字读完，所以要支持四种阅读深度
可以按5秒看标题和结论、30秒扫H2和重点、3分钟抓核心、深读时看全文来设计。不是禁止长文，而是给长文多修几个车站。
如果只读H2也能理解逻辑，每节开头有小结论，比较信息能从列表和表格里直接找到，扫读者和深读者就能共用同一篇文章。
3. 正文可从17–18px附近开始，但更重要的是允许安全放大
不存在唯一最佳字号。不过真实网页眼动研究发现，字号增大与更短的注视时长有关。[R14] 因此17–18px可作为许多长文页面的合理起点。
真正的硬要求是WCAG 2.2 Resize Text：文字放大到200%时不能丢失内容或功能。[R3] 如果一放大菜单就消失，默认页面再漂亮也只是截图好看。
4. 行距、段距和行宽是在给视觉“降车流”
正文行高约1.7–1.9通常较适合长文起步。段落之间留明显空白，一段尽量只讲一个核心主题。[R9]
拉丁文字研究中，约55字符的中等行长表现较好；实务可从55–70字符附近试起。[R15] WCAG AAA Visual Presentation给出的可调显示上限是80字符，CJK为40字形。[R8] 这些数字都要结合设备与语言验证。
5. 字体不是魔法：普通、完整、加载快更重要
衬线和无衬线没有永远的冠军。控制研究没有发现衬线带来明确阅读速度优势。[R16] 2026年的元分析也没有发现OpenDyslexic等“阅读障碍专用字体”稳定优于标准字体的证据。[R17]
所以无障碍不等于给所有人强制换“特殊字体”。字号、间距、熟悉的字形、完整字符覆盖和用户控制才是基础。
6. 背景和对比度：浅灰正文的“高级感税”很贵
WCAG 2.2 AA要求普通文字至少4.5:1，大号文字至少3:1。[R2] 白底配很浅的灰字也许在设计稿里很精致，在别人的屏幕上可能只是免费视力测试。
多项研究发现，浅色背景上的深色文字在校对和小字识别上更有优势。[R18] 因此普通阅读可以默认浅色主题，同时保留深色主题选择。
7. H1、H2、H3是路标，不是装饰
H1说明页面主题，H2划分主要问题，H3解释子问题。应使用真正的语义标题元素，因为屏幕阅读器用户会利用标题结构进行页面导航。[R7][R9]
只抽出H2读一遍，如果文章逻辑仍然成立，结构通常不错。如果全是“继续”“更多”“第二章”，那更像迷宫里的假路牌。
8. 粗体、列表、表格和结论框要承担明确职责
粗体标关键词，列表表示并列，表格做比较，结论框负责落点。整页都加粗，相当于把100个警报灯一起打开，结果一个也不醒目。
链接和状态不要只靠颜色表达，应同时使用下划线、文字或图标等线索。
9. 按“dopagaki模式”设计，但别信人类注意力只有8秒的神话
这里的“dopagaki”只是网络玩笑，不是医学词：通知→短视频→另一个标签页→回来→“我刚读到哪？”。它不是用来给某一代人或残障群体贴标签的。
解决办法不是把所有文章都做成短视频，而是短段落、具体标题、每节小结论、必要时目录，以及能帮助重新建立上下文的明确名词。自动播放和挡住正文的弹窗，基本等于往读者的注意力上扔椅子。[R9]
10. 残障无障碍应该是标准配置，而不是单独的“特殊模式”
以WCAG 2.2 AA为基础，检查200%文字放大、320 CSS px重排、4.5:1对比度、24×24 CSS px指针目标或符合例外/间距规则、键盘操作、可见焦点和跳过重复区块等。[R1-R7]
Text Spacing中的1.5行高、段后2em、字距0.12em、词距0.16em不是默认CSS推荐值。AA要求是用户覆盖到这些值时，内容和功能不能坏掉。[R5]
11. 12种语言共享设计系统，不共享一套强制排版
共享对比度、层级、重排、焦点、无障碍名称等底层规则；字体、换行、连字符、标点与行高按文字系统调整。[R10-R13] zh-Hans、zh-Hant、pt-BR等精确lang标签也应保留。
12. 不同文字系统的起步策略
| 组别 | 起步方式 |
|---|---|
| 日语 | 17–18px、约1.8行高、每行约30–40字；不要强制多余字距。[R10] |
| 简体/繁体中文 | 分开CJK字体栈，遵守标点与禁则，区分zh-Hans/zh-Hant。[R11] |
| 韩语 | 使用Hangul完整字体，避免不自然字距，测试韩文换行。[R12] |
| 泰语 | 保留塑形、词边界和合法换行；行高留足；避免粗暴break-all。[R13] |
| 越南语 | 字体必须完整支持附加符号，固定高度不能裁掉符号。 |
| 拉丁文字语言 | 可从每行55–70字符开始，正确设置lang，酌情hyphens:auto，测试长词溢出。 |
13. 手机上“能读”还不够，还要“马上出现”
为12种语言加载巨大的Web字体包，可能文字还没出来读者就走了。web.dev指出Web字体会影响文字渲染和LCP，字体切换也可能产生CLS。[R19] 正文优先系统字体通常更稳。
当前Core Web Vitals良好目标为p75下LCP≤2.5秒、INP≤200ms、CLS≤0.1。[R20]
14. 持续使用来自可预测，而不是每页都放烟花
标题样式、文章宽度、语言切换、搜索结果、相关文章和链接样式尽量一致。用户学会一次以后，下次不必重新学习。
如果提供“Aa”阅读设置，可记住字号、行距、内容宽度和主题。默认状态先做稳，再把个性化变成可选项。
15. 别把页面做成读者耐力测试
避免12px正文、低对比灰字、超长行、两端对齐、巨型段落墙、跳级标题、全页粗体、只用颜色表示含义、自动播放、难关弹窗、图片里的正文、放大后横向滚动地狱、巨型字体文件和无意义动画。
读者不是来参加网页生存考试的。
16. 可直接拿来起步的基准
| 项目 | 起步值 |
|---|---|
| 正文 | 17–18px |
| 行高 | 1.7–1.9 |
| 拉丁文字行宽 | 约55–70字符[R15] |
| CJK行宽 | 约30–40字[R8] |
| H1 | 约32–40px |
| H2 | 约25–30px |
| H3 | 约21–24px |
| 普通文字对比度 | ≥4.5:1[R2] |
| 大文字对比度 | ≥3:1[R2] |
| 指针目标 | 24×24 CSS px基准，存在例外[R6] |
| 文字放大 | 200%[R3] |
| 重排 | 320 CSS px[R4] |
17. 建立质量门：‘我们会注意’不叫质量保证
静态检查可验证lang、单个H1、标题顺序、alt、无障碍名称和危险CSS；真实浏览器检查可验证320px、200%放大、Text Spacing、键盘、焦点和横向溢出。
能安全修的结构问题可以自动修。会改变含义的正文、翻译和alt内容不能凭空编造。不能安全修复就让质量门失败并交给人工检查。
18. 总结：好文章不会考试读者
真正强的页面让人知道该看哪里，分心后能回来，能放大、能操作、能被辅助技术理解，在每种语言里自然，而且加载稳定。与其另修一扇“无障碍侧门”，不如一开始就把正门修宽。
怎樣做出真正好讀的文章：字級、行距、標題、配色、12種語言與無障礙設計，一次把讀者「別弄丟」
好讀的文章，不是把正文換成一個「高級字體」就完成。真正的目標是：打開就知道在講什麼，中途分心後能快速找回位置，放大文字也不壞，切換語言後仍然自然。讀者不是來挑戰網頁困難模式的，路線應該由文章自己標清楚。
先用三句話講完：
- 長文正文可從約17–18px、1.7–1.9行高與適中的行寬開始測試；這是實務起點，不是宇宙常數。
- WCAG 2.2把對比度、200%文字放大、320 CSS px重排、Text Spacing覆寫、鍵盤操作等變成可檢查要求。[R1-R8]
- 12種語言應共享無障礙基礎，但不同文字系統的字體、換行與標點規則不能硬做成一樣。[R10-R13]
1. 可讀性不是審美，而是三層系統
至少同時看三件事：文字看不看得見、內容跟不跟得上、頁面操不操作得了。大字救不了文字牆，簡單句也救不了小得像灰塵的按鈕。只改字級，就像把道路拆掉後認真擦亮路牌。
2. 使用者不會一開始逐字讀完，所以要支援四種閱讀深度
可以按5秒看標題與結論、30秒掃H2與重點、3分鐘抓核心、深讀再看全文來設計。不是禁止長文，而是要替長文多蓋幾個車站。
只讀H2也能理解邏輯，每節開頭有小結論，比較資訊能從列表與表格直接找到，掃讀與深讀就能共存。
3. 正文可從17–18px附近開始，但更重要的是安全放大
沒有唯一最佳字級。真實網頁眼動研究發現，字級增加與較短的注視時間相關。[R14] 因此17–18px可作為許多長文頁面的合理起點。
真正的硬要求是WCAG 2.2 Resize Text：文字放大到200%時不能失去內容或功能。[R3] 一放大選單就消失，預設畫面再漂亮也只是截圖漂亮。
4. 行距、段距與行寬是在降低視覺交通量
正文行高約1.7–1.9通常適合長文起步。段落之間留明顯空白，一段盡量只講一個核心主題。[R9]
拉丁文字研究中，約55字元的中等行長表現不錯；實務可由55–70字元附近測試。[R15] WCAG AAA Visual Presentation的可調顯示上限為80字元，CJK則為40字形。[R8]
5. 字體不是魔法：普通、完整、載入快更重要
襯線與無襯線沒有永遠的冠軍。控制研究沒有發現襯線帶來明確閱讀速度優勢。[R16] 2026年的統合分析也沒有發現OpenDyslexic等特殊字體穩定優於標準字體的證據。[R17]
因此無障礙不等於強迫所有人使用「特殊字體」。字級、間距、熟悉字形、完整字元支援與使用者控制才是基礎。
6. 背景與對比：淺灰正文的高級感稅很貴
WCAG 2.2 AA要求一般文字至少4.5:1，大字至少3:1。[R2] 白底配過淡灰字，在設計稿可能精緻，在其他螢幕可能只是免費視力測驗。
多項研究顯示亮背景上的暗文字在校對與小字辨識上較有利。[R18] 一般閱讀可預設亮色主題，深色主題則保留為選項。
7. H1、H2、H3是路標，不是裝飾
H1說明頁面主題，H2切主要問題，H3再拆子問題。要用真正有語意的標題元素，因為螢幕閱讀器使用者會依靠標題結構導覽。[R7][R9]
只讀H2若仍能理解文章主線，通常結構不錯。「更多」「下一步」「第二章」若沒有資訊量，就比較像迷宮路牌。
8. 粗體、列表、表格與結論框都要有工作
粗體標關鍵字、列表呈現並列、表格做比較、結論框標示落點。全文都粗體就像100盞警示燈一起亮，最後一盞都不醒目。
連結與狀態也不要只靠顏色，應搭配底線、文字或圖示。
9. 以「dopagaki模式」為前提，但別相信人類注意力只有8秒的神話
這裡的「dopagaki」只是網路玩笑，不是醫學術語：通知→短影音→另一個分頁→回來→「我剛看到哪？」。它不是拿來羞辱某世代或障礙群體的分類。
解法不是把所有文章變短影音，而是短段落、具體標題、每節小結論、必要時目錄，以及能重建上下文的明確名詞。自動播放與擋住正文的彈窗，本質上是在向讀者的注意力丟椅子。[R9]
10. 障礙無障礙應是標準配備，不是特殊模式
以WCAG 2.2 AA為基礎，檢查200%文字放大、320 CSS px重排、4.5:1對比、24×24 CSS px指標目標或符合例外/間距規則、鍵盤操作、可見焦點與跳過重複區塊等。[R1-R7]
Text Spacing的1.5行高、段後2em、字距0.12em、詞距0.16em不是預設CSS建議值。AA要求是使用者覆寫到這些值時，內容與功能不能壞掉。[R5]
11. 12種語言共享設計系統，不共享一套強制排版
共享對比度、層級、重排、焦點與無障礙名稱等底層規則；字體、換行、連字、標點與行高依文字系統調整。[R10-R13] zh-Hans、zh-Hant、pt-BR等精確lang資訊也應保留。
12. 不同文字系統的起步策略
| 群組 | 起步方式 |
|---|---|
| 日文 | 17–18px、約1.8行高、每行約30–40字；不要強制多餘字距。[R10] |
| 簡體/繁體中文 | 分開CJK字體堆疊，遵守標點與禁則，區分兩種語言標籤。[R11] |
| 韓文 | 使用完整Hangul字體，避免不自然字距，測試韓文換行。[R12] |
| 泰文 | 保留塑形、詞界與合法換行；行高留足；避免粗暴break-all。[R13] |
| 越南文 | 字體完整支援附加符號，固定高度不能裁切。 |
| 拉丁文字語言 | 可從每行55–70字元開始，正確lang，視需要使用hyphens:auto並測試長字。 |
13. 手機上「能讀」還不夠，還要很快出現
替12種語言載入巨大Web字體，可能文字還沒出現人就走了。web.dev指出Web字體可影響渲染與LCP，字體交換也會製造CLS。[R19] 正文優先系統字體通常更穩。
目前Core Web Vitals良好目標為p75的LCP≤2.5秒、INP≤200ms、CLS≤0.1。[R20]
14. 持續使用來自可預測，而不是每頁都放煙火
標題樣式、文章寬度、語言切換、搜尋結果、相關文章與連結樣式盡量一致。使用者學會一次後，下次不必重新學。
若提供「Aa」閱讀設定，可保存字級、行距、內容寬度與主題。預設先做穩，再提供選擇。
15. 別把頁面做成讀者耐力測驗
避免12px正文、低對比灰字、超長行、兩端對齊、巨大段落牆、標題跳級、全文粗體、只靠顏色傳意、自動播放、難關彈窗、圖片裡的正文、放大後橫向捲動地獄、巨大字體檔與無意義動畫。
讀者不是來參加網頁生存考試的。
16. 可直接拿來起步的基準
| 項目 | 起步值 |
|---|---|
| 正文 | 17–18px |
| 行高 | 1.7–1.9 |
| 拉丁文字行寬 | 約55–70字元[R15] |
| CJK行寬 | 約30–40字[R8] |
| H1 | 約32–40px |
| H2 | 約25–30px |
| H3 | 約21–24px |
| 一般文字對比 | ≥4.5:1[R2] |
| 大文字對比 | ≥3:1[R2] |
| 指標目標 | 24×24 CSS px基準，存在例外[R6] |
| 文字放大 | 200%[R3] |
| 重排 | 320 CSS px[R4] |
17. 建立品質閘門
靜態檢查驗證lang、單一H1、標題順序、alt、無障礙名稱與危險CSS；真實瀏覽器再測320px、200%放大、Text Spacing、鍵盤、焦點與水平溢出。
可以安全修的結構問題可自動修；會改變語意的正文、翻譯和alt不可憑空生成。不能安全修就失敗並送審。
18. 總結：好文章不會考讀者
真正強的頁面讓人知道該看哪裡，分心後找得回來，能放大、能操作、能被輔助技術理解，在各語言中自然，而且載入穩定。與其另修一扇無障礙側門，不如一開始就把正門修寬。
Cómo crear artículos fáciles de leer: tamaño de texto, espaciado, encabezados, color, 12 idiomas y accesibilidad sin perder al lector
Un artículo legible no es simplemente un texto vestido con una tipografía elegante. Debe dejar claro su propósito al abrirse, permitir recuperar el hilo después de una interrupción, sobrevivir al zoom y seguir pareciendo natural cuando cambia el idioma. El lector no ha venido a superar tu web en modo difícil; la página debe poner las señales.
Resumen en tres puntos:
- Para texto largo, 17–18px, una altura de línea de 1.7–1.9 y una medida de línea controlada son buenos puntos de partida, no leyes universales.
- WCAG 2.2 convierte en comprobables el contraste, el aumento al 200%, el reflow a 320 CSS px, las modificaciones de Text Spacing y el acceso por teclado.[R1-R8]
- En 12 idiomas conviene compartir la base de accesibilidad, no imponer exactamente la misma composición a todos los sistemas de escritura.[R10-R13]
1. La legibilidad es un sistema de tres capas
Hay que comprobar si el texto se ve, si las ideas se siguen y si la interfaz se puede usar. Un tamaño grande no arregla un muro de texto; una redacción sencilla no arregla botones minúsculos. Corregir solo la fuente es pulir la señal después de quitar la carretera.
2. La gente no empieza leyendo todo: diseña cuatro profundidades
Una página puede servir a 5 segundos para título y resumen, 30 segundos para H2 y destacados, 3 minutos para la respuesta central y lectura profunda para todo el desarrollo. No es una prohibición de los textos largos; es una obligación de construir paradas útiles.
Si los H2 cuentan por sí solos una historia coherente y cada sección abre con una pequeña conclusión, el lector que escanea y el que profundiza pueden compartir la misma página.
3. Empieza el cuerpo cerca de 17–18px y protege el aumento
No existe un tamaño perfecto único. Un estudio de seguimiento ocular con páginas reales encontró que el aumento del tamaño tipográfico se asociaba con fijaciones más cortas.[R14] Por eso 17–18px es un inicio razonable para muchos artículos largos.
Lo obligatorio no es usar exactamente 18px: WCAG 2.2 exige que el texto pueda aumentar hasta 200% sin pérdida de contenido ni función.[R3]
4. Interlineado, párrafos y longitud de línea reducen el tráfico visual
Una altura de línea de 1.7–1.9 suele dar aire suficiente. Separa bien los párrafos y procura una idea principal por bloque.[R9]
Un estudio clásico encontró buen rendimiento con unas 55 letras por línea; para alfabetos latinos, 55–70 es una banda práctica inicial.[R15] WCAG AAA Visual Presentation utiliza como opción configurable 80 caracteres, 40 en CJK.[R8]
Evita la justificación completa del cuerpo como valor por defecto.[R8]
5. La tipografía no es magia: normal, completa y rápida gana
No hay campeón universal entre serif y sans serif. Un estudio controlado no halló ventaja de velocidad por las serifas.[R16] Un metaanálisis de 2026 tampoco encontró una mejora consistente de fuentes especiales para dislexia frente a fuentes estándar.[R17]
La accesibilidad no consiste en forzar una “fuente para discapacidad”, sino en tamaño, espacio, formas familiares, cobertura completa y capacidad de personalización.
6. Fondo y contraste: el gris pálido cobra un impuesto de diseño caro
WCAG 2.2 AA pide al menos 4.5:1 para texto normal y 3:1 para texto grande.[R2] El gris demasiado claro sobre blanco puede parecer sofisticado en un mockup y convertirse en una prueba de vista en otro monitor.
Diversos estudios favorecen texto oscuro sobre fondo claro para corrección y caracteres pequeños.[R18] Un tema claro por defecto es defendible, con tema oscuro opcional.
7. H1, H2 y H3 son señales de carretera
H1 nombra el tema, H2 divide los grandes argumentos y H3 detalla. Usa encabezados semánticos: los lectores de pantalla los emplean para navegar.[R7][R9]
Prueba rápida: lee solo los H2. Si ya no entiendes el artículo, quizá tus encabezados dicen “Más”, “Siguiente” y “Capítulo 2” cuando deberían informar.
8. Negritas, listas, tablas y cajas de conclusión deben tener función
Negrita para conceptos clave, listas para elementos paralelos, tablas para comparar y cajas para aterrizar una decisión. Si todo está en negrita, nada destaca.
No comuniques significado solo con color. Añade subrayado, texto o iconos cuando corresponda.
9. Diseña para el “modo dopagaki”, sin comprar el mito de los ocho segundos
Aquí “dopagaki” es una broma, no un término médico: notificación → vídeo corto → otra pestaña → regreso → “¿dónde estaba?”. No es una etiqueta para insultar generaciones ni discapacidades.
La solución no es convertir todo en vídeo corto. Usa párrafos breves, encabezados concretos, conclusiones locales, índice cuando ayude y sustantivos claros que reconstruyan el contexto. El autoplay y los popups invasivos son sillas lanzadas contra la concentración.[R9]
10. La accesibilidad para personas con discapacidad debe venir de serie
Apunta a WCAG 2.2 AA: aumento del 200%, reflow a 320 CSS px, contraste 4.5:1, objetivos de puntero de 24×24 CSS px o excepciones/espaciado válidos, teclado, foco visible y salto de bloques repetidos.[R1-R7]
Los valores de Text Spacing—1.5 de altura de línea, 2em tras párrafos, 0.12em entre letras y 0.16em entre palabras—no son estilos por defecto obligatorios. La página debe resistir que el usuario los aplique.[R5]
11. Comparte un sistema de diseño entre 12 idiomas, no una composición forzada
Comparte contraste, jerarquía, reflow, foco y nombres accesibles. Ajusta fuentes, salto de línea, guionado, puntuación y altura según el sistema de escritura.[R10-R13] Conserva etiquetas precisas como zh-Hans, zh-Hant y pt-BR.
12. Puntos de partida por escritura
| Grupo | Enfoque inicial |
|---|---|
| Japonés | 17–18px, línea ~1.8, 30–40 caracteres; sin tracking extra forzado.[R10] |
| Chino simplificado/tradicional | Pilas CJK separadas y reglas de puntuación/salto correctas.[R11] |
| Coreano | Fuentes Hangul completas, sin espaciado artificial; probar saltos.[R12] |
| Tailandés | Mantener shaping, segmentación y saltos; altura generosa; evitar break-all indiscriminado.[R13] |
| Vietnamita | Fuente con todos los diacríticos y sin recorte por alturas fijas. |
| Lenguas latinas | 55–70 caracteres aprox., lang correcto, considerar hyphens:auto, probar palabras largas. |
13. En móvil, legible también significa rápido
Cargar enormes fuentes web para doce escrituras puede expulsar al lector antes de mostrar el texto. web.dev explica que las fuentes pueden retrasar render/LCP y causar CLS al cambiar.[R19] Para cuerpo, las fuentes del sistema son una base sólida.
Objetivos actuales de Core Web Vitals: LCP≤2.5s, INP≤200ms y CLS≤0.1 en p75.[R20]
14. La repetición de uso nace de la previsibilidad
Mantén consistentes encabezados, ancho, selector de idioma, resultados de búsqueda, relacionados y enlaces. Una interfaz aprendida una vez debería seguir funcionando igual la próxima visita.
Si ofreces controles “Aa”, recuerda tamaño, interlineado, ancho y tema.
15. Evita el examen de resistencia del lector
Evita cuerpo de 12px, gris débil, líneas interminables, justificación total, muros de párrafos, saltos de jerarquía, todo en negrita, significado solo por color, autoplay, popups difíciles, texto en imágenes, scroll horizontal al ampliar, fuentes gigantes y movimiento decorativo.
El lector no vino a demostrar que sobrevivirá a tu web.
16. Tabla base
| Elemento | Inicio |
|---|---|
| Cuerpo | 17–18px |
| Interlineado | 1.7–1.9 |
| Línea latina | ~55–70 caracteres[R15] |
| Línea CJK | ~30–40[R8] |
| H1 | ~32–40px |
| H2 | ~25–30px |
| H3 | ~21–24px |
| Contraste normal | ≥4.5:1[R2] |
| Contraste grande | ≥3:1[R2] |
| Objetivo de puntero | base 24×24 CSS px, con excepciones[R6] |
| Aumento | 200%[R3] |
| Reflow | 320 CSS px[R4] |
17. Crea una puerta de calidad
Los chequeos estáticos pueden verificar lang, un H1, orden de encabezados, alt, nombres accesibles y CSS de riesgo. El navegador real prueba 320px, 200%, Text Spacing, teclado, foco y desbordamiento horizontal.
Automatiza reparaciones estructurales seguras, pero no inventes texto, traducciones ni alt con significado. Si no puede arreglarse con seguridad, falla y manda a revisión.
18. Conclusión: un buen artículo no examina al lector
La página fuerte indica dónde mirar, permite volver tras una interrupción, se amplía, se opera, funciona con tecnología de apoyo, respeta cada idioma y carga de forma estable. Mejor ensanchar la entrada principal desde el principio que construir una puerta lateral llamada “modo accesible”.
Como criar artigos fáceis de ler: tamanho da fonte, espaçamento, títulos, cores, 12 idiomas e acessibilidade sem perder o leitor
Um artigo fácil de ler não é apenas um texto usando uma fonte bonita. Ele precisa deixar o assunto claro de imediato, permitir que a pessoa retome o fio depois de uma interrupção, sobreviver ao zoom e continuar natural quando o idioma muda. O leitor não abriu a página para jogar “site no modo difícil”. A própria página deve mostrar o caminho.
Resumo em três pontos:
- Para textos longos, cerca de 17–18px, line-height de 1.7–1.9 e uma linha de largura controlada são bons pontos de partida, não leis universais.
- WCAG 2.2 transforma contraste, aumento de 200%, reflow em 320 CSS px, substituições de Text Spacing e acesso por teclado em itens verificáveis.[R1-R8]
- Em 12 idiomas, compartilhe a base de acessibilidade, mas não force a mesma tipografia sobre sistemas de escrita diferentes.[R10-R13]
1. Legibilidade é um sistema de três camadas
É preciso perguntar se o texto pode ser visto, se o raciocínio pode ser seguido e se os controles podem ser usados. Fonte grande não conserta uma parede de texto; redação simples não conserta botões minúsculos. Ajustar só a fonte é polir a placa depois de remover a estrada.
2. Ninguém começa lendo tudo: ofereça quatro profundidades
Projete para 5 segundos de título/resumo, 30 segundos de H2/destaques, 3 minutos para a resposta central e leitura profunda para o texto completo. Isso não proíbe textos longos; exige que eles tenham estações úteis.
3. Comece o corpo perto de 17–18px e torne o aumento seguro
Não existe tamanho perfeito universal. Um estudo de eye tracking com páginas reais associou fontes maiores a fixações mais curtas.[R14] Por isso 17–18px é um ponto inicial razoável.
WCAG 2.2 exige que o texto possa chegar a 200% sem perder conteúdo ou função.[R3]
4. Line-height, espaço entre parágrafos e comprimento de linha reduzem tráfego visual
Line-height de 1.7–1.9 costuma dar bom espaço para leitura longa. Separe parágrafos e mantenha uma ideia principal por bloco.[R9]
Um estudo clássico encontrou bom desempenho perto de 55 caracteres por linha; para escrita latina, 55–70 é uma faixa inicial útil.[R15] WCAG AAA Visual Presentation usa 80 caracteres como opção configurável, 40 para CJK.[R8]
Evite justificação total do corpo por padrão.[R8]
5. Fonte não é magia: comum, completa e rápida vem primeiro
Não há campeão universal entre serif e sans serif. Um estudo controlado não encontrou ganho de velocidade devido às serifas.[R16] Uma meta-análise de 2026 também não encontrou vantagem consistente de fontes especiais para dislexia sobre fontes comuns.[R17]
Acessibilidade não é obrigar todo mundo a usar uma “fonte de deficiência”; tamanho, espaçamento, formas familiares, cobertura de caracteres e controle do usuário são a base.
6. Fundo e contraste: cinza claro cobra um imposto de estilo alto
WCAG 2.2 AA exige 4.5:1 para texto normal e 3:1 para texto grande.[R2] Cinza pálido no branco pode ser elegante no mockup e virar teste de visão no celular alheio.
Estudos favorecem texto escuro sobre fundo claro em tarefas de revisão e letras pequenas.[R18] Tema claro é uma boa base geral; tema escuro pode ser opcional.
7. H1, H2 e H3 são placas de trânsito
H1 define o assunto, H2 divide os grandes argumentos e H3 detalha. Use headings semânticos porque leitores de tela navegam por eles.[R7][R9]
Leia só os H2. Se o artigo deixar de fazer sentido, os títulos provavelmente não estão carregando informação suficiente.
8. Negrito, listas, tabelas e caixas de conclusão precisam ter função
Negrito marca termos-chave, listas mostram itens paralelos, tabelas comparam e caixas de conclusão dão o ponto de chegada. Se tudo estiver em negrito, nada está destacado.
Não use apenas cor para comunicar significado; combine sublinhado, texto ou ícones.
9. Projete para o “modo dopagaki” sem acreditar no mito dos oito segundos
Aqui “dopagaki” é piada, não termo médico: notificação → vídeo curto → outra aba → volta → “onde eu estava?”. Não é rótulo para insultar geração ou deficiência.
A solução não é transformar tudo em vídeo curto. Use parágrafos curtos, headings descritivos, pequenas conclusões, sumário quando ajudar e substantivos claros que reconstruam o contexto. Autoplay e popups invasivos jogam uma cadeira na concentração.[R9]
10. Acessibilidade para pessoas com deficiência deve vir de fábrica
Mire WCAG 2.2 AA: texto a 200%, reflow em 320 CSS px, contraste 4.5:1, alvos de ponteiro de 24×24 CSS px ou exceções/espaçamento válidos, teclado, foco visível e mecanismo para pular blocos repetidos.[R1-R7]
Os valores de Text Spacing—1.5 de line-height, 2em após parágrafos, 0.12em entre letras e 0.16em entre palavras—não são estilos padrão obrigatórios. A página deve continuar funcionando quando o usuário os aplica.[R5]
11. Compartilhe um design system entre 12 idiomas, não uma composição forçada
Compartilhe contraste, hierarquia, reflow, foco e nomes acessíveis. Ajuste fontes, quebra de linha, hifenização, pontuação e altura conforme a escrita.[R10-R13] Preserve zh-Hans, zh-Hant, pt-BR e outras tags precisas.
12. Pontos iniciais por escrita
| Grupo | Abordagem inicial |
|---|---|
| Japonês | 17–18px, line-height ~1.8, cerca de 30–40 caracteres; não force tracking extra.[R10] |
| Chinês simplificado/tradicional | Pilhas CJK separadas e regras de pontuação/quebra corretas.[R11] |
| Coreano | Fontes Hangul completas, sem espaçamento artificial; teste quebras.[R12] |
| Tailandês | Preserve shaping, segmentação e quebra; line-height generoso; evite break-all bruto.[R13] |
| Vietnamita | Fonte com todos os diacríticos, sem clipping em caixas de altura fixa. |
| Idiomas latinos | ~55–70 caracteres, lang correto, considerar hyphens:auto, testar palavras longas. |
13. No celular, legível também significa rápido
Fontes web enormes para doze escritas podem expulsar o leitor antes do texto aparecer. web.dev explica que fontes podem atrasar render/LCP e causar CLS na troca.[R19] Para corpo, fontes do sistema são uma base forte.
Metas atuais de Core Web Vitals: LCP≤2.5s, INP≤200ms e CLS≤0.1 no p75.[R20]
14. Uso recorrente nasce da previsibilidade
Mantenha consistentes headings, largura, seletor de idioma, busca, relacionados e links. Quem aprendeu a página uma vez não deveria reaprender em cada visita.
Se houver controle “Aa”, salve tamanho, espaçamento, largura e tema.
15. Evite o teste de resistência do leitor
Evite corpo 12px, cinza fraco, linhas enormes, justificação total, paredes de parágrafo, saltos de heading, tudo em negrito, significado só por cor, autoplay, popup difícil, texto em imagem, rolagem horizontal no zoom, fontes gigantes e movimento sem função.
O leitor não veio provar que sobrevive ao seu site.
16. Tabela base
| Item | Início |
|---|---|
| Corpo | 17–18px |
| Line-height | 1.7–1.9 |
| Linha latina | ~55–70 caracteres[R15] |
| Linha CJK | ~30–40[R8] |
| H1 | ~32–40px |
| H2 | ~25–30px |
| H3 | ~21–24px |
| Contraste normal | ≥4.5:1[R2] |
| Contraste grande | ≥3:1[R2] |
| Alvo de ponteiro | base 24×24 CSS px, com exceções[R6] |
| Aumento | 200%[R3] |
| Reflow | 320 CSS px[R4] |
17. Crie um quality gate
Checks estáticos podem validar lang, um H1, ordem dos headings, alt, nomes acessíveis e CSS de risco. Testes no navegador verificam 320px, 200%, Text Spacing, teclado, foco e overflow horizontal.
Correções estruturais seguras podem ser automáticas; texto, tradução e alt com significado não devem ser inventados. Se não der para corrigir com segurança, falhe e envie para revisão.
18. Conclusão: um bom artigo não faz prova com o leitor
Uma página forte mostra onde olhar, deixa retomar após interrupção, permite ampliar e operar, funciona com tecnologia assistiva, respeita cada idioma e estabiliza rápido. Em vez de construir uma porta lateral chamada “modo acessível”, faça a entrada principal larga desde o início.
Cara Membuat Artikel yang Mudah Dibaca: Ukuran Teks, Jarak, Heading, Warna, 12 Bahasa, dan Aksesibilitas Tanpa Membuat Pembaca Tersesat
Artikel yang mudah dibaca bukan sekadar artikel dengan font yang terlihat mahal. Halaman harus langsung menjelaskan topiknya, mudah dilanjutkan setelah perhatian terputus, tidak rusak saat teks diperbesar, dan tetap terasa alami ketika bahasa berubah. Pembaca tidak datang untuk menamatkan situs dalam mode sulit. Halamanlah yang harus memasang petunjuk jalan.
Ringkasan tiga poin:
- Untuk long-form, sekitar 17–18px, line-height 1.7–1.9, dan panjang baris yang terkendali adalah titik awal praktis, bukan hukum universal.
- WCAG 2.2 membuat kontras, pembesaran 200%, reflow 320 CSS px, override Text Spacing, keyboard, dan lainnya dapat diuji.[R1-R8]
- Untuk 12 bahasa, bagikan fondasi aksesibilitas tetapi jangan memaksakan aturan tipografi yang sama pada semua sistem tulisan.[R10-R13]
1. Keterbacaan adalah sistem tiga lapis
Periksa apakah teks terlihat, gagasan mudah diikuti, dan kontrol mudah digunakan. Teks besar tidak menyelamatkan dinding paragraf; kalimat sederhana tidak menyelamatkan tombol superkecil. Memperbaiki font saja seperti memoles rambu setelah jalannya dibongkar.
2. Orang tidak mulai dengan membaca semuanya: sediakan empat kedalaman
Rancang untuk 5 detik melihat judul/ringkasan, 30 detik memindai H2/penekanan, 3 menit mendapatkan jawaban inti, dan deep read untuk penjelasan penuh. Long-form tetap boleh; ia hanya butuh banyak halte.
3. Mulai body sekitar 17–18px dan pastikan aman saat diperbesar
Tidak ada satu ukuran sempurna. Studi eye-tracking pada halaman nyata mengaitkan ukuran font yang lebih besar dengan durasi fiksasi lebih pendek.[R14] Karena itu 17–18px adalah titik awal yang masuk akal.
WCAG 2.2 meminta teks dapat diperbesar hingga 200% tanpa kehilangan konten atau fungsi.[R3]
4. Line-height, jarak paragraf, dan panjang baris mengurangi lalu lintas visual
Line-height sekitar 1.7–1.9 memberi ruang nyaman untuk artikel panjang. Pisahkan paragraf dengan jelas dan fokuskan satu ide utama per blok.[R9]
Eksperimen klasik menemukan sekitar 55 karakter per baris efektif untuk membaca layar; 55–70 karakter menjadi rentang awal praktis untuk aksara Latin.[R15] WCAG AAA Visual Presentation memakai opsi hingga 80 karakter, 40 untuk CJK.[R8]
5. Font bukan sihir: biasa, lengkap, dan cepat lebih penting
Tidak ada pemenang universal serif vs sans serif. Studi terkontrol tidak menemukan keuntungan kecepatan membaca dari serif.[R16] Meta-analisis 2026 juga tidak menemukan keunggulan konsisten font khusus disleksia dibanding font standar.[R17]
Aksesibilitas bukan memaksa “font khusus disabilitas”; ukuran, ruang, bentuk huruf familiar, cakupan karakter, dan kontrol pengguna adalah fondasi.
6. Latar dan kontras: abu-abu pucat mengenakan pajak gaya yang mahal
WCAG 2.2 AA meminta 4.5:1 untuk teks biasa dan 3:1 untuk teks besar.[R2] Abu-abu sangat muda di atas putih bisa terlihat elegan di mockup namun berubah menjadi tes mata di perangkat lain.
Sejumlah studi menguntungkan teks gelap di latar terang untuk proofreading dan karakter kecil.[R18] Tema terang masuk akal sebagai default, tema gelap tetap bisa menjadi opsi.
7. H1, H2, H3 adalah rambu jalan
H1 menyatakan topik, H2 membagi argumen besar, H3 memecah subtopik. Gunakan heading semantik karena screen reader memakainya untuk navigasi.[R7][R9]
Baca H2 saja. Jika alurnya hilang, heading seperti “Lebih lanjut” dan “Berikutnya” mungkin tidak cukup informatif.
8. Bold, bullet, tabel, dan kotak kesimpulan harus punya pekerjaan
Bold untuk kata penting, bullet untuk daftar paralel, tabel untuk perbandingan, kotak kesimpulan untuk titik keputusan. Jika semua bold, tidak ada yang menonjol.
Jangan memakai warna sebagai satu-satunya pembawa makna; tambahkan garis bawah, teks, atau ikon.
9. Desain untuk “mode dopagaki”, tanpa mitos perhatian delapan detik
“Dopagaki” di sini hanya lelucon, bukan istilah medis: notifikasi → video pendek → tab lain → kembali → “tadi sampai mana?”. Bukan label untuk menghina generasi atau kelompok disabilitas.
Solusinya bukan mengubah semua artikel menjadi video pendek. Gunakan paragraf singkat, heading deskriptif, kesimpulan lokal, daftar isi bila berguna, dan kata benda yang jelas untuk memulihkan konteks. Autoplay dan popup invasif seperti melempar kursi ke konsentrasi pembaca.[R9]
10. Aksesibilitas disabilitas harus menjadi perlengkapan standar
Targetkan WCAG 2.2 AA: pembesaran 200%, reflow 320 CSS px, kontras 4.5:1, target pointer 24×24 CSS px atau pengecualian/spacing yang valid, keyboard, fokus terlihat, dan bypass blok berulang.[R1-R7]
Nilai Text Spacing—line-height 1.5, 2em setelah paragraf, letter spacing 0.12em, word spacing 0.16em—bukan style default wajib. Halaman harus tetap berfungsi saat pengguna menerapkannya.[R5]
11. Bagikan design system untuk 12 bahasa, bukan satu typesetting paksa
Bagikan kontras, hierarki, reflow, fokus, dan accessible name. Sesuaikan font, line breaking, hyphenation, tanda baca, dan line-height berdasarkan sistem tulisan.[R10-R13] Pertahankan tag tepat seperti zh-Hans, zh-Hant, pt-BR.
12. Titik awal menurut sistem tulisan
| Grup | Pendekatan awal |
|---|---|
| Jepang | 17–18px, line-height ~1.8, 30–40 karakter; jangan memaksa tracking ekstra.[R10] |
| Tionghoa sederhana/tradisional | Pisahkan font CJK dan hormati aturan tanda baca/line break.[R11] |
| Korea | Font Hangul lengkap, tanpa spacing buatan; uji line break.[R12] |
| Thai | Jaga shaping, segmentasi, line break; line-height cukup; jangan sembarang break-all.[R13] |
| Vietnam | Font harus memiliki semua diakritik dan tidak terpotong kotak fixed-height. |
| Bahasa Latin | ~55–70 karakter, lang benar, pertimbangkan hyphens:auto, uji kata panjang. |
13. Di ponsel, mudah dibaca juga berarti cepat
Font web besar untuk 12 sistem tulisan bisa membuat pengguna pergi sebelum huruf muncul. web.dev menjelaskan font web dapat memperlambat render/LCP dan pergantian font dapat menambah CLS.[R19] System font untuk body adalah fondasi kuat.
Target Core Web Vitals saat ini: LCP≤2.5s, INP≤200ms, CLS≤0.1 pada p75.[R20]
14. Penggunaan berulang tumbuh dari prediktabilitas
Pertahankan heading, lebar artikel, pemilih bahasa, hasil pencarian, related content, dan link secara konsisten. Interaksi yang sudah dipelajari tidak perlu dipelajari ulang.
Jika ada kontrol “Aa”, simpan ukuran, jarak, lebar, dan tema.
15. Hindari ujian ketahanan pembaca
Hindari body 12px, abu-abu lemah, baris sangat panjang, full justification, dinding paragraf, heading lompat, semua bold, makna hanya lewat warna, autoplay, popup sulit ditutup, teks dalam gambar, scroll horizontal saat zoom, font besar, dan animasi tanpa fungsi.
Pembaca tidak datang untuk membuktikan ia bisa selamat dari situs Anda.
16. Tabel baseline
| Item | Awal |
|---|---|
| Body | 17–18px |
| Line-height | 1.7–1.9 |
| Baris Latin | ~55–70 karakter[R15] |
| Baris CJK | ~30–40[R8] |
| H1 | ~32–40px |
| H2 | ~25–30px |
| H3 | ~21–24px |
| Kontras normal | ≥4.5:1[R2] |
| Kontras besar | ≥3:1[R2] |
| Target pointer | baseline 24×24 CSS px, ada pengecualian[R6] |
| Pembesaran | 200%[R3] |
| Reflow | 320 CSS px[R4] |
17. Buat quality gate
Static check dapat memeriksa lang, satu H1, urutan heading, alt, accessible name, dan CSS berisiko. Browser test menguji 320px, 200%, Text Spacing, keyboard, fokus, dan overflow horizontal.
Perbaikan struktur yang aman boleh otomatis; isi, terjemahan, dan alt bermakna tidak boleh dikarang. Bila tidak aman diperbaiki, fail dan kirim ke review.
18. Kesimpulan: artikel bagus tidak menguji pembaca
Halaman kuat menunjukkan ke mana harus melihat, mudah dilanjutkan setelah terganggu, dapat diperbesar dan dioperasikan, mendukung teknologi bantu, alami di tiap bahasa, dan stabil saat dimuat. Daripada membuat pintu samping “mode aksesibel”, lebarkan pintu utama sejak awal.
วิธีทำบทความให้อ่านง่ายจริง: ขนาดตัวอักษร ระยะห่าง หัวข้อ สี 12 ภาษา และการเข้าถึง โดยไม่ทำให้ผู้อ่านหลงทาง
บทความที่อ่านง่ายไม่ใช่แค่บทความที่ใส่ฟอนต์สวย ๆ แต่ต้อง เปิดแล้วรู้ทันทีว่าเรื่องอะไร กลับมาอ่านต่อได้หลังสมาธิหลุด ขยายตัวอักษรแล้วไม่พัง และเปลี่ยนภาษาแล้วก็ยังเป็นธรรมชาติ ผู้อ่านไม่ได้มาเล่นเว็บไซต์โหมด Hard หน้าที่บอกทางเป็นของหน้าเว็บ
สรุปสามข้อก่อน:
- สำหรับบทความยาว เริ่มทดสอบที่ประมาณ 17–18px, line-height 1.7–1.9 และความยาวบรรทัดที่ไม่ยาวเกินไปได้ ตัวเลขนี้เป็นจุดเริ่มต้น ไม่ใช่กฎสากล
- WCAG 2.2 ทำให้เรื่อง contrast, ขยายข้อความ 200%, reflow ที่ 320 CSS px, Text Spacing override และคีย์บอร์ดเป็นสิ่งที่ตรวจสอบได้จริง[R1-R8]
- 12 ภาษาควรใช้ฐาน accessibility ร่วมกัน แต่ไม่ควรบังคับกฎการจัดตัวอักษรเดียวกันทุกระบบอักษร[R10-R13]
1. ความอ่านง่ายคือระบบสามชั้น ไม่ใช่แค่รสนิยม
ต้องดูพร้อมกันว่าตัวอักษรมองเห็นไหม เนื้อหาตามทันไหม และปุ่มหรือส่วนควบคุมใช้งานได้ไหม ตัวใหญ่ช่วยกำแพงข้อความไม่ได้ และประโยคง่ายก็ช่วยปุ่มจิ๋วไม่ได้ แก้แค่ฟอนต์เหมือนขัดป้ายถนนหลังรื้อถนนทิ้ง
2. คนไม่ได้เริ่มด้วยการอ่านทุกคำ จึงควรมีสี่ระดับการอ่าน
ออกแบบให้ 5 วินาทีเห็นชื่อเรื่อง/สรุป, 30 วินาทีสแกน H2/ตัวเน้น, 3 นาทีได้คำตอบหลัก และอ่านลึกได้ทั้งบทความ ไม่ได้แปลว่าห้ามบทความยาว แต่บทความยาวต้องมีจุดพักและทางเข้าเยอะ
3. เริ่ม body แถว 17–18px แล้วทำให้การขยายปลอดภัย
ไม่มีขนาดเดียวที่ดีที่สุด งาน eye-tracking บนหน้าเว็บจริงพบว่าฟอนต์ใหญ่ขึ้นสัมพันธ์กับ fixation ที่สั้นลง[R14] ดังนั้น 17–18px เป็นจุดเริ่มต้นที่สมเหตุผลสำหรับหลายหน้า
WCAG 2.2 กำหนดให้ขยายข้อความถึง 200% ได้โดยไม่เสียเนื้อหาหรือฟังก์ชัน[R3]
4. Line-height ระยะย่อหน้า และความยาวบรรทัดช่วยลดความหนาแน่น
line-height ราว 1.7–1.9 มักให้พื้นที่สบายกับบทความยาว แยกย่อหน้าให้ชัดและให้หนึ่งย่อหน้ามีหนึ่งแนวคิดหลัก[R9]
งานคลาสสิกพบว่าประมาณ 55 ตัวอักษรต่อบรรทัดมีประสิทธิภาพกับการอ่านบนจอ สำหรับอักษรละตินจึงเริ่มที่ 55–70 ได้[R15] WCAG AAA Visual Presentation ใช้ 80 ตัวอักษรและ 40 glyph สำหรับ CJK เป็นตัวเลือกที่ผู้ใช้ปรับได้[R8]
5. ฟอนต์ไม่ใช่เวทมนตร์: อ่านธรรมดา ครบ และโหลดเร็วสำคัญกว่า
ไม่มีผู้ชนะสากลระหว่าง serif กับ sans serif งานควบคุมไม่พบประโยชน์ชัดด้านความเร็วจาก serif[R16] และ meta-analysis ปี 2026 ก็ไม่พบข้อได้เปรียบที่สม่ำเสมอของฟอนต์เฉพาะ dyslexia เหนือฟอนต์มาตรฐาน[R17]
Accessibility จึงไม่ใช่การบังคับ “ฟอนต์สำหรับคนพิการ” แต่คือขนาด ระยะห่าง รูปทรงคุ้นเคย อักขระครบ และให้ผู้ใช้ปรับได้
6. พื้นหลังและ contrast: ตัวเทาจางมีภาษีความสวยสูง
WCAG 2.2 AA ต้องการ contrast อย่างน้อย 4.5:1 สำหรับข้อความปกติ และ 3:1 สำหรับข้อความใหญ่[R2] สีเทาจางบนขาวอาจดูหรูใน mockup แต่กลายเป็นแบบทดสอบสายตาบนเครื่องคนอื่น
หลายงานพบข้อได้เปรียบของตัวอักษรมืดบนพื้นสว่างในการพิสูจน์อักษรและตัวเล็ก[R18] จึงใช้ light theme เป็นค่าเริ่มต้นได้ และให้ dark mode เป็นทางเลือก
7. H1 H2 H3 คือป้ายทาง ไม่ใช่เครื่องประดับ
H1 บอกหัวข้อหลัก H2 แบ่งประเด็นใหญ่ H3 แบ่งย่อย ใช้ heading เชิง semantic จริง เพราะผู้ใช้ screen reader ใช้โครงสร้าง heading เพื่อนำทาง[R7][R9]
ลองอ่านเฉพาะ H2 ถ้ายังเข้าใจเรื่องได้ แปลว่าโครงสร้างค่อนข้างดี
8. ตัวหนา รายการ ตาราง และกล่องสรุปต้องมีหน้าที่
ตัวหนาใช้กับคำสำคัญ รายการใช้กับข้อมูลคู่ขนาน ตารางใช้เปรียบเทียบ กล่องสรุปใช้บอกจุดตัดสินใจ ถ้าทุกอย่างหนา ก็ไม่มีอะไรเด่น
อย่าสื่อความหมายด้วยสีอย่างเดียว ให้มีเส้นใต้ ข้อความ หรือไอคอนช่วยด้วย
9. ออกแบบเผื่อ “โหมด dopagaki” แต่อย่าเชื่อตำนานสมาธิ 8 วินาที
คำว่า “dopagaki” ตรงนี้เป็นมุก ไม่ใช่ศัพท์แพทย์: แจ้งเตือน → คลิปสั้น → แท็บอื่น → กลับมา → “อ่านถึงไหนแล้ว?” ไม่ใช่ป้ายดูหมิ่นคนรุ่นใดหรือกลุ่มความพิการ
ทางแก้ไม่ใช่ทำทุกบทความเป็นคลิปสั้น แต่ใช้ย่อหน้าสั้น หัวข้อชัด สรุปย่อย สารบัญเมื่อช่วยได้ และคำนามที่ทำให้กลับมารู้บริบทได้ autoplay กับ popup ที่บังเนื้อหาเหมือนขว้างเก้าอี้ใส่สมาธิผู้อ่าน[R9]
10. Accessibility สำหรับคนพิการควรเป็นอุปกรณ์มาตรฐาน
ตั้งเป้า WCAG 2.2 AA: ขยาย 200%, reflow ที่ 320 CSS px, contrast 4.5:1, pointer target 24×24 CSS px หรือเข้าเงื่อนไขข้อยกเว้น/spacing, คีย์บอร์ด, focus ที่เห็น และการข้ามบล็อกซ้ำ[R1-R7]
ค่าของ Text Spacing—line-height 1.5, ระยะหลังย่อหน้า 2em, letter spacing 0.12em, word spacing 0.16em—ไม่ใช่ค่า CSS เริ่มต้นที่บังคับ แต่หน้าเว็บต้องไม่พังเมื่อผู้ใช้ override เป็นค่านั้น[R5]
11. ใช้ design system เดียวใน 12 ภาษา แต่อย่าบังคับ typesetting เดียว
แชร์ contrast, hierarchy, reflow, focus และ accessible name แต่ปรับฟอนต์ การตัดบรรทัด hyphenation เครื่องหมายวรรคตอน และ line-height ตามระบบอักษร[R10-R13] เก็บ lang ที่แม่น เช่น zh-Hans, zh-Hant, pt-BR
12. จุดเริ่มต้นตามระบบอักษร
| กลุ่ม | แนวทางเริ่มต้น |
|---|---|
| ญี่ปุ่น | 17–18px, line-height ~1.8, ราว 30–40 ตัว; ไม่บังคับ tracking เกินจำเป็น[R10] |
| จีนย่อ/จีนดั้งเดิม | แยกฟอนต์ CJK และรักษากฎวรรคตอน/ตัดบรรทัด[R11] |
| เกาหลี | ฟอนต์ Hangul ครบ ไม่เว้นอักษรแปลก ๆ และทดสอบการตัดบรรทัด[R12] |
| ไทย | ต้องรักษา shaping, segmentation และ line break; ให้ line-height พอ; หลีกเลี่ยง break-all แบบเหมา[R13] |
| เวียดนาม | ฟอนต์ต้องมี diacritics ครบและไม่โดนกล่องความสูงตายตัวตัด |
| ภาษาอักษรละติน | ราว 55–70 ตัว, lang ถูกต้อง, พิจารณา hyphens:auto, ทดสอบคำยาว |
13. บนมือถือ อ่านได้ต้องเร็วด้วย
Web font ขนาดใหญ่สำหรับ 12 ระบบอักษรอาจทำให้คนออกก่อนตัวหนังสือมา web.dev อธิบายว่าฟอนต์กระทบการ render/LCP และการสลับฟอนต์ทำ CLS ได้[R19] body ใช้ system font เป็นฐานจึงแข็งแรง
เป้าหมาย Core Web Vitals ปัจจุบันคือ LCP≤2.5s, INP≤200ms, CLS≤0.1 ที่ p75[R20]
14. การกลับมาใช้ซ้ำเกิดจากความคาดเดาได้
ทำ heading ความกว้างบทความ ตัวเลือกภาษา ผลค้นหา related content และลิงก์ให้สม่ำเสมอ ผู้ใช้เรียนครั้งเดียวแล้วใช้ต่อได้
ถ้ามี “Aa” ให้จำขนาด ระยะ ความกว้าง และธีมของผู้ใช้
15. อย่าทำข้อสอบความอดทนให้ผู้อ่าน
หลีกเลี่ยง body 12px, สีเทาอ่อน, บรรทัดยาวมาก, full justify, กำแพงย่อหน้า, heading กระโดด, ทุกอย่างตัวหนา, ใช้สีอย่างเดียว, autoplay, popup ปิดยาก, ข้อความอยู่ในภาพ, zoom แล้วต้องเลื่อนแนวนอน, font file ใหญ่ และ motion ที่ไม่มีประโยชน์
ผู้อ่านไม่ได้มาแข่งเอาชีวิตรอดบนเว็บคุณ
16. ตาราง baseline
| รายการ | จุดเริ่ม |
|---|---|
| Body | 17–18px |
| Line-height | 1.7–1.9 |
| บรรทัดละติน | ~55–70 ตัว[R15] |
| บรรทัด CJK | ~30–40[R8] |
| H1 | ~32–40px |
| H2 | ~25–30px |
| H3 | ~21–24px |
| Contrast ปกติ | ≥4.5:1[R2] |
| Contrast ตัวใหญ่ | ≥3:1[R2] |
| Pointer target | ฐาน 24×24 CSS px มีข้อยกเว้น[R6] |
| Text resize | 200%[R3] |
| Reflow | 320 CSS px[R4] |
17. สร้าง quality gate
Static check ตรวจ lang, H1 เดียว, ลำดับ heading, alt, accessible name และ CSS เสี่ยง ส่วน browser test ตรวจ 320px, 200%, Text Spacing, keyboard, focus และ overflow แนวนอน
แก้โครงสร้างที่ปลอดภัยอัตโนมัติได้ แต่ห้ามแต่งความหมายของเนื้อหา คำแปล หรือ alt ขึ้นมาเอง ถ้าแก้อย่างปลอดภัยไม่ได้ให้ fail แล้วส่งตรวจ
18. สรุป: บทความที่ดีไม่สอบผู้อ่าน
หน้าที่แข็งแรงทำให้รู้ว่าควรมองตรงไหน กลับมาได้หลังสมาธิหลุด ขยายและกดได้ ใช้เทคโนโลยีช่วยเหลือได้ เป็นธรรมชาติในแต่ละภาษา และโหลดนิ่ง แทนที่จะทำประตูข้างชื่อ “โหมดเข้าถึงได้” ให้ทำประตูหน้ากว้างตั้งแต่แรก
Cách làm bài viết thật sự dễ đọc: cỡ chữ, khoảng cách, tiêu đề, màu sắc, 12 ngôn ngữ và khả năng tiếp cận mà không làm người đọc lạc đường
Một bài viết dễ đọc không chỉ là bài viết mặc một bộ font “xịn”. Nó phải cho biết chủ đề ngay khi mở, giúp người đọc tìm lại mạch sau khi bị gián đoạn, không vỡ khi phóng to chữ và vẫn tự nhiên khi đổi ngôn ngữ. Người đọc không đến để phá đảo website ở chế độ khó. Bài viết phải tự đặt biển chỉ đường.
Tóm tắt ba ý:
- Với nội dung dài, khoảng 17–18px, line-height 1.7–1.9 và độ dài dòng được kiểm soát là điểm khởi đầu thực tế, không phải định luật tuyệt đối.
- WCAG 2.2 biến độ tương phản, phóng chữ 200%, reflow ở 320 CSS px, Text Spacing override và thao tác bàn phím thành các mục có thể kiểm tra.[R1-R8]
- Với 12 ngôn ngữ, hãy chia sẻ nền tảng accessibility nhưng đừng ép mọi hệ chữ dùng cùng một cách dàn trang.[R10-R13]
1. Khả năng đọc là hệ thống ba lớp
Cần hỏi: chữ có nhìn thấy không, ý có theo được không, giao diện có thao tác được không. Chữ lớn không cứu được một bức tường văn bản; câu đơn giản cũng không cứu được nút quá nhỏ. Chỉ sửa font giống như đánh bóng biển báo sau khi dỡ luôn con đường.
2. Người dùng không bắt đầu bằng việc đọc hết: hãy tạo bốn độ sâu
Thiết kế để 5 giây xem tiêu đề/tóm tắt, 30 giây quét H2/điểm nhấn, 3 phút lấy câu trả lời chính và đọc sâu khi cần toàn bộ. Không phải cấm bài dài; bài dài cần nhiều trạm dừng hữu ích.
3. Bắt đầu body quanh 17–18px và bảo vệ việc phóng to
Không có một kích thước hoàn hảo. Nghiên cứu eye tracking trên trang web thật cho thấy font lớn hơn liên quan đến thời gian fixation ngắn hơn.[R14] Vì vậy 17–18px là điểm bắt đầu hợp lý.
WCAG 2.2 yêu cầu văn bản có thể tăng đến 200% mà không mất nội dung hay chức năng.[R3]
4. Line-height, khoảng đoạn và độ dài dòng giảm “giao thông thị giác”
Line-height khoảng 1.7–1.9 thường tạo khoảng thở tốt cho bài dài. Tách đoạn rõ và giữ một ý chính mỗi đoạn.[R9]
Một nghiên cứu kinh điển cho thấy khoảng 55 ký tự mỗi dòng hỗ trợ đọc màn hình hiệu quả; với chữ Latin, 55–70 là dải khởi đầu thực tế.[R15] WCAG AAA Visual Presentation dùng 80 ký tự, 40 với CJK như một tùy chọn có thể cấu hình.[R8]
5. Font không phải phép thuật: quen thuộc, đầy đủ và nhanh quan trọng hơn
Không có người thắng tuyệt đối giữa serif và sans serif. Nghiên cứu kiểm soát không thấy lợi thế tốc độ đọc rõ từ serif.[R16] Meta-analysis năm 2026 cũng không thấy lợi thế nhất quán của font chuyên cho dyslexia so với font chuẩn.[R17]
Accessibility không có nghĩa bắt mọi người dùng “font cho người khuyết tật”; cỡ chữ, khoảng cách, hình dạng quen thuộc, đủ ký tự và quyền điều chỉnh mới là nền tảng.
6. Nền và tương phản: chữ xám nhạt có “thuế thời trang” cao
WCAG 2.2 AA yêu cầu 4.5:1 cho chữ thường và 3:1 cho chữ lớn.[R2] Xám quá nhạt trên trắng có thể đẹp trong mockup nhưng thành bài kiểm tra mắt trên điện thoại khác.
Nhiều nghiên cứu cho thấy chữ tối trên nền sáng có lợi trong proofreading và nhận dạng chữ nhỏ.[R18] Light theme là mặc định hợp lý, dark mode có thể là lựa chọn.
7. H1, H2, H3 là biển chỉ đường
H1 nêu chủ đề, H2 chia luận điểm lớn, H3 chia nhỏ. Dùng heading semantic thật vì screen reader sử dụng cấu trúc này để điều hướng.[R7][R9]
Chỉ đọc H2 mà vẫn hiểu mạch thì cấu trúc tốt. Nếu toàn “Xem thêm”, “Tiếp theo”, “Phần 2”, biển chỉ đường đang thiếu thông tin.
8. Bold, bullet, bảng và hộp kết luận phải có nhiệm vụ
Bold cho từ khóa, bullet cho thông tin song song, bảng để so sánh, hộp kết luận để chốt quyết định. Nếu mọi thứ đều bold, chẳng có gì nổi bật.
Đừng dùng màu là tín hiệu duy nhất; thêm gạch chân, chữ hoặc icon.
9. Thiết kế cho “chế độ dopagaki”, không tin huyền thoại chú ý tám giây
“Dopagaki” ở đây chỉ là câu đùa, không phải thuật ngữ y khoa: thông báo → video ngắn → tab khác → quay lại → “mình đang đọc đâu?”. Không phải nhãn để xúc phạm thế hệ hay nhóm khuyết tật.
Giải pháp không phải biến mọi bài thành short video. Hãy dùng đoạn ngắn, heading cụ thể, kết luận nhỏ, mục lục khi hữu ích và danh từ rõ để khôi phục bối cảnh. Autoplay và popup xâm lấn giống như ném ghế vào sự tập trung.[R9]
10. Khả năng tiếp cận cho người khuyết tật phải là trang bị tiêu chuẩn
Nhắm WCAG 2.2 AA: tăng chữ 200%, reflow 320 CSS px, tương phản 4.5:1, pointer target 24×24 CSS px hoặc ngoại lệ/khoảng cách hợp lệ, bàn phím, focus nhìn thấy và bỏ qua khối lặp.[R1-R7]
Các giá trị Text Spacing—line-height 1.5, 2em sau đoạn, letter spacing 0.12em, word spacing 0.16em—không phải style mặc định bắt buộc. Trang phải chịu được khi người dùng override như vậy.[R5]
11. Chia sẻ design system cho 12 ngôn ngữ, không ép một typesetting
Chia sẻ contrast, hierarchy, reflow, focus, accessible name. Điều chỉnh font, line breaking, hyphenation, dấu câu và line-height theo hệ chữ.[R10-R13] Giữ tag chính xác như zh-Hans, zh-Hant, pt-BR.
12. Điểm bắt đầu theo hệ chữ
| Nhóm | Cách bắt đầu |
|---|---|
| Nhật | 17–18px, line-height ~1.8, khoảng 30–40 ký tự; không ép tracking dư.[R10] |
| Trung giản/phồn | Font CJK riêng và giữ quy tắc dấu câu/line break.[R11] |
| Hàn | Font Hangul đầy đủ, không spacing nhân tạo; test line break.[R12] |
| Thái | Giữ shaping, segmentation, line break; line-height đủ; tránh break-all thô.[R13] |
| Việt | Font phải đủ toàn bộ dấu và không bị clip bởi fixed height. |
| Ngôn ngữ Latin | ~55–70 ký tự, lang đúng, cân nhắc hyphens:auto, test từ dài. |
13. Trên mobile, dễ đọc cũng phải nhanh
Web font khổng lồ cho 12 hệ chữ có thể khiến người dùng rời đi trước khi chữ xuất hiện. web.dev giải thích font có thể làm chậm render/LCP và font swap gây CLS.[R19] System font cho body là nền tảng mạnh.
Mục tiêu Core Web Vitals hiện tại: LCP≤2.5s, INP≤200ms, CLS≤0.1 ở p75.[R20]
14. Người dùng quay lại vì tính dự đoán được
Giữ heading, chiều rộng, đổi ngôn ngữ, kết quả tìm kiếm, nội dung liên quan và link nhất quán. Người đã học giao diện một lần không nên phải học lại.
Nếu có “Aa”, lưu cỡ chữ, khoảng cách, chiều rộng và theme.
15. Đừng tạo bài thi sức bền cho người đọc
Tránh body 12px, xám yếu, dòng quá dài, full justify, tường đoạn, nhảy heading, mọi thứ bold, chỉ dùng màu, autoplay, popup khó đóng, chữ trong ảnh, zoom rồi cuộn ngang, font khổng lồ và motion vô nghĩa.
Người đọc không đến để chứng minh họ sống sót qua website.
16. Bảng baseline
| Mục | Bắt đầu |
|---|---|
| Body | 17–18px |
| Line-height | 1.7–1.9 |
| Dòng Latin | ~55–70 ký tự[R15] |
| Dòng CJK | ~30–40[R8] |
| H1 | ~32–40px |
| H2 | ~25–30px |
| H3 | ~21–24px |
| Contrast thường | ≥4.5:1[R2] |
| Contrast chữ lớn | ≥3:1[R2] |
| Pointer target | baseline 24×24 CSS px, có ngoại lệ[R6] |
| Text resize | 200%[R3] |
| Reflow | 320 CSS px[R4] |
17. Tạo quality gate
Static check kiểm lang, một H1, thứ tự heading, alt, accessible name và CSS rủi ro. Browser test kiểm 320px, 200%, Text Spacing, bàn phím, focus và overflow ngang.
Sửa cấu trúc an toàn có thể tự động; không được bịa nội dung, bản dịch hoặc alt có ý nghĩa. Không sửa an toàn được thì fail và gửi review.
18. Kết luận: bài tốt không kiểm tra người đọc
Trang mạnh cho biết nhìn đâu, quay lại được sau gián đoạn, phóng to và thao tác được, hỗ trợ công nghệ trợ giúp, tự nhiên trong mỗi ngôn ngữ và tải ổn định. Thay vì làm cửa phụ tên “chế độ accessible”, hãy làm cửa chính rộng ngay từ đầu.
Comment créer des articles vraiment faciles à lire : taille du texte, espacement, titres, couleurs, 12 langues et accessibilité sans perdre le lecteur
Un article lisible n’est pas simplement un texte habillé d’une belle police. Son sujet doit être évident dès l’ouverture, son fil doit être facile à retrouver après une interruption, le zoom ne doit rien casser et chaque langue doit rester naturelle. Le lecteur n’est pas venu terminer votre site en mode difficile. C’est à la page de poser les panneaux.
Résumé en trois points :
- Pour un texte long, environ 17–18px, une hauteur de ligne de 1.7–1.9 et une largeur maîtrisée constituent de bons points de départ, pas des lois universelles.
- WCAG 2.2 rend vérifiables le contraste, l’agrandissement à 200%, le reflow à 320 CSS px, les overrides Text Spacing et l’accès clavier.[R1-R8]
- Pour 12 langues, partagez la base d’accessibilité, mais n’imposez pas la même composition à tous les systèmes d’écriture.[R10-R13]
1. La lisibilité est un système à trois couches
Il faut vérifier que le texte se voit, que les idées se suivent et que l’interface se manipule. Une grande police ne sauve pas un mur de texte ; une prose simple ne sauve pas des boutons minuscules. Corriger seulement la police, c’est polir le panneau après avoir supprimé la route.
2. Personne ne commence par tout lire : prévoyez quatre profondeurs
Concevez pour 5 secondes de titre/résumé, 30 secondes de H2/éléments clés, 3 minutes pour la réponse principale et une lecture profonde pour le détail. Les longs articles restent permis ; ils ont simplement besoin de nombreux arrêts utiles.
3. Commencez le corps vers 17–18px et sécurisez l’agrandissement
Il n’existe pas une taille parfaite. Une étude oculométrique sur de vraies pages a associé des polices plus grandes à des fixations plus courtes.[R14] 17–18px est donc un point de départ raisonnable.
WCAG 2.2 exige que le texte puisse atteindre 200% sans perte de contenu ni de fonctionnalité.[R3]
4. Interligne, espace entre paragraphes et longueur de ligne réduisent le trafic visuel
Un line-height de 1.7–1.9 donne souvent un bon confort aux textes longs. Séparez les paragraphes et gardez une idée principale par bloc.[R9]
Une étude classique a trouvé un bon équilibre autour de 55 caractères par ligne ; 55–70 est une bande pratique pour les écritures latines.[R15] WCAG AAA Visual Presentation utilise une option configurable à 80 caractères, 40 pour CJK.[R8]
5. La police n’est pas magique : familière, complète et rapide d’abord
Aucun vainqueur universel entre serif et sans serif. Une étude contrôlée n’a pas trouvé de gain de vitesse dû aux empattements.[R16] Une méta-analyse de 2026 n’a pas non plus trouvé d’avantage constant des polices spéciales pour dyslexie.[R17]
L’accessibilité ne consiste donc pas à imposer une « police handicap », mais à assurer taille, espace, formes familières, couverture de caractères et contrôle utilisateur.
6. Fond et contraste : le gris pâle coûte cher en style
WCAG 2.2 AA demande au moins 4.5:1 pour le texte normal et 3:1 pour le grand texte.[R2] Un gris trop faible sur blanc peut sembler raffiné dans une maquette et devenir un test de vue ailleurs.
Plusieurs études favorisent le texte sombre sur fond clair pour la relecture et les petits caractères.[R18] Un thème clair est un bon défaut général, avec thème sombre en option.
7. H1, H2 et H3 sont des panneaux de circulation
H1 nomme le sujet, H2 découpe les grands arguments et H3 détaille. Utilisez de vrais headings sémantiques : les lecteurs d’écran s’en servent pour naviguer.[R7][R9]
Lisez seulement les H2. Si le fil disparaît, les titres ne portent probablement pas assez d’information.
8. Gras, listes, tableaux et encadrés doivent avoir un rôle
Gras pour les termes clés, listes pour les éléments parallèles, tableaux pour comparer, encadrés pour la conclusion. Si tout est en gras, rien ne ressort.
Ne transmettez pas une information uniquement par couleur ; ajoutez soulignement, texte ou icône.
9. Concevez pour le « mode dopagaki » sans croire au mythe des huit secondes
Ici « dopagaki » est une blague, pas un terme médical : notification → vidéo courte → autre onglet → retour → « j’en étais où ? ». Ce n’est pas une étiquette contre une génération ou un handicap.
La solution n’est pas de transformer chaque article en vidéo courte. Utilisez petits paragraphes, titres précis, mini-conclusions, sommaire si utile et noms explicites qui rétablissent le contexte. Autoplay et popups envahissants lancent une chaise sur la concentration.[R9]
10. L’accessibilité handicap doit être un équipement standard
Visez WCAG 2.2 AA : agrandissement 200%, reflow 320 CSS px, contraste 4.5:1, cibles de pointeur 24×24 CSS px ou exceptions/espacements valides, clavier, focus visible et mécanisme de saut des blocs répétés.[R1-R7]
Les valeurs Text Spacing—1.5 de hauteur, 2em après paragraphe, 0.12em entre lettres, 0.16em entre mots—ne sont pas des styles par défaut obligatoires. La page doit résister à leur application par l’utilisateur.[R5]
11. Partagez un design system entre 12 langues, pas une composition forcée
Partagez contraste, hiérarchie, reflow, focus et noms accessibles. Ajustez polices, césure, coupures de ligne, ponctuation et hauteur selon le système d’écriture.[R10-R13] Gardez des balises exactes comme zh-Hans, zh-Hant, pt-BR.
12. Points de départ par écriture
| Groupe | Approche initiale |
|---|---|
| Japonais | 17–18px, hauteur ~1.8, ~30–40 caractères ; pas de tracking forcé.[R10] |
| Chinois simplifié/traditionnel | Piles CJK distinctes, règles de ponctuation et de coupure respectées.[R11] |
| Coréen | Polices Hangul complètes, pas d’espacement artificiel ; tester les coupures.[R12] |
| Thaï | Préserver shaping, segmentation et coupure ; hauteur généreuse ; éviter break-all brutal.[R13] |
| Vietnamien | Couverture complète des diacritiques, sans clipping par hauteur fixe. |
| Langues latines | ~55–70 caractères, lang correct, envisager hyphens:auto, tester les mots longs. |
13. Sur mobile, lisible signifie aussi rapide
Des web fonts énormes pour douze écritures peuvent faire fuir avant l’apparition du texte. web.dev explique qu’elles peuvent retarder rendu/LCP et créer du CLS lors du remplacement.[R19] Les polices système sont une base robuste pour le corps.
Objectifs Core Web Vitals actuels : LCP≤2.5s, INP≤200ms, CLS≤0.1 au p75.[R20]
14. Le retour des lecteurs vient de la prévisibilité
Gardez cohérents headings, largeur, changement de langue, recherche, contenus liés et liens. Une interface apprise une fois doit rester familière.
Si vous proposez « Aa », mémorisez taille, espacement, largeur et thème.
15. Évitez le test d’endurance
Évitez corps 12px, gris faible, lignes interminables, justification complète, murs de paragraphes, sauts de headings, tout en gras, couleur seule, autoplay, popup difficile, texte en image, scroll horizontal au zoom, polices énormes et mouvement inutile.
Le lecteur n’est pas venu prouver qu’il survivra à votre site.
16. Tableau de base
| Élément | Départ |
|---|---|
| Corps | 17–18px |
| Line-height | 1.7–1.9 |
| Ligne latine | ~55–70 caractères[R15] |
| Ligne CJK | ~30–40[R8] |
| H1 | ~32–40px |
| H2 | ~25–30px |
| H3 | ~21–24px |
| Contraste normal | ≥4.5:1[R2] |
| Contraste grand | ≥3:1[R2] |
| Cible pointeur | base 24×24 CSS px, exceptions possibles[R6] |
| Agrandissement | 200%[R3] |
| Reflow | 320 CSS px[R4] |
17. Construisez un quality gate
Les tests statiques vérifient lang, un H1, l’ordre des headings, alt, noms accessibles et CSS risqué. Le navigateur réel teste 320px, 200%, Text Spacing, clavier, focus et overflow horizontal.
Automatisez seulement les réparations structurelles sûres. N’inventez pas le sens du texte, des traductions ou des alt. Si la correction sûre est impossible, faites échouer et envoyez en revue.
18. Conclusion : un bon article ne fait pas passer un examen au lecteur
Une page forte indique où regarder, permet de reprendre après interruption, s’agrandit, se contrôle, fonctionne avec les technologies d’assistance, reste naturelle dans chaque langue et se stabilise vite. Plutôt qu’une porte latérale « mode accessible », élargissez l’entrée principale dès le départ.
So werden Artikel wirklich gut lesbar: Schriftgröße, Abstände, Überschriften, Farben, 12 Sprachen und Barrierefreiheit ohne Leser zu verlieren
Ein gut lesbarer Artikel ist nicht einfach Text in einer schicken Schrift. Das Thema muss sofort erkennbar sein, nach einer Unterbrechung muss man den Faden wiederfinden, Zoom darf nichts zerstören und jede Sprache muss natürlich gesetzt sein. Niemand öffnet eine Website, um sie im Schwierigkeitsgrad „Hard“ zu besiegen. Die Seite selbst muss die Wegweiser aufstellen.
Drei Punkte vorweg:
- Für lange Texte sind ungefähr 17–18px, eine line-height von 1.7–1.9 und eine begrenzte Zeilenlänge brauchbare Startwerte, keine universellen Gesetze.
- WCAG 2.2 macht Kontrast, 200% Textvergrößerung, Reflow bei 320 CSS px, Text-Spacing-Overrides und Tastaturzugang prüfbar.[R1-R8]
- Bei 12 Sprachen sollte die Accessibility-Basis gemeinsam sein, nicht jede typografische Regel für jedes Schriftsystem.[R10-R13]
1. Lesbarkeit ist ein System aus drei Ebenen
Prüfe, ob Text sichtbar ist, Gedanken nachvollziehbar sind und Bedienelemente funktionieren. Große Schrift rettet keine Textwand; einfache Sprache rettet keine winzigen Buttons. Nur die Schrift zu korrigieren ist, als würde man das Straßenschild polieren, nachdem die Straße entfernt wurde.
2. Menschen lesen nicht von Anfang an alles: plane vier Tiefen
Baue für 5 Sekunden Titel/Zusammenfassung, 30 Sekunden H2/Hervorhebungen, 3 Minuten Kernaussage und Deep Read für den vollständigen Text. Lange Artikel bleiben erlaubt; sie brauchen nur genügend Haltestellen.
3. Beginne beim Fließtext um 17–18px und sichere die Vergrößerung ab
Es gibt keine eine perfekte Größe. Eine Eye-Tracking-Studie mit echten Webseiten verband größere Schrift mit kürzeren Fixationen.[R14] 17–18px ist daher ein vernünftiger Startwert.
WCAG 2.2 verlangt, dass Text bis 200% vergrößert werden kann, ohne Inhalt oder Funktion zu verlieren.[R3]
4. Zeilenhöhe, Absatzabstand und Zeilenlänge senken den visuellen Verkehr
Eine line-height von etwa 1.7–1.9 schafft oft genug Luft für lange Texte. Absätze klar trennen und möglichst eine Hauptidee pro Block verwenden.[R9]
Eine klassische Studie fand etwa 55 Zeichen pro Zeile effektiv; für lateinische Schrift sind 55–70 ein brauchbarer Startbereich.[R15] WCAG AAA Visual Presentation nutzt als einstellbare Obergrenze 80 Zeichen, 40 für CJK.[R8]
Blocksatz sollte im Web-Fließtext nicht der Standard sein.[R8]
5. Schriftarten sind keine Magie: vertraut, vollständig und schnell zuerst
Es gibt keinen universellen Sieger Serif vs. Sans Serif. Eine kontrollierte Studie fand keinen Lesegeschwindigkeitsvorteil durch Serifen.[R16] Eine Meta-Analyse 2026 fand auch keinen konsistenten Vorteil spezieller Dyslexie-Schriften gegenüber Standardschriften.[R17]
Barrierefreiheit bedeutet deshalb nicht, allen eine „Behindertenschrift“ aufzuzwingen. Größe, Abstand, vertraute Zeichenformen, vollständige Glyphen und Benutzerkontrolle sind wichtiger.
6. Hintergrund und Kontrast: blasses Grau hat eine hohe Stilsteuer
WCAG 2.2 AA fordert mindestens 4.5:1 für normalen Text und 3:1 für großen Text.[R2] Sehr helles Grau auf Weiß kann im Mockup edel wirken und auf einem anderen Display zum Sehtest werden.
Mehrere Studien zeigen Vorteile von dunklem Text auf hellem Hintergrund bei Korrekturaufgaben und kleinen Zeichen.[R18] Ein helles Standardthema ist daher gut vertretbar; Dark Mode kann optional bleiben.
7. H1, H2 und H3 sind Wegweiser
H1 benennt das Thema, H2 trennt Hauptargumente, H3 Unterpunkte. Verwende semantische Heading-Elemente, denn Screenreader nutzen sie zur Navigation.[R7][R9]
Lies nur die H2. Wenn der Gedankengang verschwindet, tragen die Überschriften zu wenig Information.
8. Fett, Listen, Tabellen und Fazitboxen brauchen eine Aufgabe
Fett markiert Schlüsselbegriffe, Listen zeigen parallele Punkte, Tabellen vergleichen, Fazitboxen markieren Entscheidungen. Wenn alles fett ist, ist nichts hervorgehoben.
Bedeutung nicht nur über Farbe vermitteln; Unterstreichung, Text oder Icons ergänzen.
9. Für den „Dopagaki-Modus“ gestalten, aber nicht an den Acht-Sekunden-Mythos glauben
„Dopagaki“ ist hier ein Witz, kein medizinischer Begriff: Benachrichtigung → Kurzvideo → anderer Tab → zurück → „wo war ich?“. Es ist kein Etikett gegen Generationen oder Menschen mit Behinderung.
Die Lösung ist nicht, jeden Artikel zum Kurzvideo zu machen. Nutze kurze Absätze, konkrete Überschriften, lokale Fazits, Inhaltsverzeichnis wenn sinnvoll und klare Nomen, die Kontext wiederherstellen. Autoplay und invasive Popups werfen praktisch einen Stuhl auf die Konzentration.[R9]
10. Barrierefreiheit für Menschen mit Behinderung gehört zur Standardausstattung
Ziele auf WCAG 2.2 AA: 200% Vergrößerung, Reflow bei 320 CSS px, 4.5:1 Kontrast, Pointer-Ziele von 24×24 CSS px oder gültige Ausnahmen/Abstände, Tastatur, sichtbarer Fokus und Skip-Mechanismen für wiederholte Blöcke.[R1-R7]
Die Text-Spacing-Werte—1.5 line-height, 2em nach Absätzen, 0.12em Buchstabenabstand, 0.16em Wortabstand—sind keine verpflichtenden Default-Styles. Die Seite muss Benutzer-Overrides auf diese Werte aushalten.[R5]
11. Ein Designsystem für 12 Sprachen, aber kein erzwungener Einheitssatz
Teile Kontrast, Hierarchie, Reflow, Fokus und accessible names. Passe Schrift, Zeilenumbruch, Silbentrennung, Interpunktion und Höhe an das Schriftsystem an.[R10-R13] Präzise Tags wie zh-Hans, zh-Hant, pt-BR bleiben erhalten.
12. Startpunkte nach Schriftsystem
| Gruppe | Startansatz |
|---|---|
| Japanisch | 17–18px, line-height ~1.8, ca. 30–40 Zeichen; kein künstliches Tracking.[R10] |
| Chinesisch vereinfacht/traditionell | Getrennte CJK-Stacks, korrekte Interpunktion und Umbruchregeln.[R11] |
| Koreanisch | Vollständige Hangul-Schriften, kein künstlicher Zeichenabstand; Umbruch testen.[R12] |
| Thai | Shaping, Segmentierung und Umbruch erhalten; großzügige Höhe; kein pauschales break-all.[R13] |
| Vietnamesisch | Vollständige Diakritika und kein Clipping durch feste Höhen. |
| Lateinische Sprachen | ~55–70 Zeichen, korrektes lang, ggf. hyphens:auto, lange Wörter testen. |
13. Auf dem Smartphone bedeutet lesbar auch schnell
Riesige Webfonts für zwölf Schriftsysteme können Leser vertreiben, bevor Text erscheint. web.dev erklärt, dass Fonts Rendering/LCP verzögern und beim Austausch CLS verursachen können.[R19] Systemschriften für den Fließtext sind eine robuste Basis.
Aktuelle Core-Web-Vitals-Ziele: LCP≤2.5s, INP≤200ms, CLS≤0.1 beim p75.[R20]
14. Wiederkehrende Nutzung entsteht durch Vorhersagbarkeit
Halte Heading-Stile, Textbreite, Sprachwechsel, Suche, verwandte Inhalte und Links konsistent. Eine einmal gelernte Oberfläche sollte beim nächsten Besuch wieder funktionieren.
Wenn „Aa“-Einstellungen existieren, speichere Größe, Abstand, Breite und Theme.
15. Vermeide den Leser-Ausdauertest
Vermeide 12px-Fließtext, schwaches Grau, endlose Zeilen, Blocksatz, Absatzwände, übersprungene Heading-Ebenen, alles fett, Bedeutung nur durch Farbe, Autoplay, schwer schließbare Popups, Textbilder, horizontales Scrollen beim Zoom, riesige Fontdateien und nutzlose Bewegung.
Der Leser ist nicht gekommen, um zu beweisen, dass er deine Website überlebt.
16. Basistabelle
| Element | Start |
|---|---|
| Fließtext | 17–18px |
| Line-height | 1.7–1.9 |
| Lateinische Zeile | ~55–70 Zeichen[R15] |
| CJK-Zeile | ~30–40[R8] |
| H1 | ~32–40px |
| H2 | ~25–30px |
| H3 | ~21–24px |
| Normaler Kontrast | ≥4.5:1[R2] |
| Großer Text | ≥3:1[R2] |
| Pointer-Ziel | Basis 24×24 CSS px, Ausnahmen vorhanden[R6] |
| Textvergrößerung | 200%[R3] |
| Reflow | 320 CSS px[R4] |
17. Baue ein Quality Gate
Statische Checks prüfen lang, genau ein H1, Heading-Reihenfolge, alt, accessible names und riskantes CSS. Browser-Tests prüfen 320px, 200%, Text Spacing, Tastatur, Fokus und horizontalen Overflow.
Sichere strukturelle Reparaturen dürfen automatisch sein; Textbedeutung, Übersetzungen und bedeutungsvolle Alt-Texte dürfen nicht erfunden werden. Wenn es nicht sicher reparierbar ist, muss das Gate fehlschlagen und Review verlangen.
18. Fazit: Ein guter Artikel prüft den Leser nicht
Eine starke Seite zeigt, wo man hinschauen soll, lässt nach Unterbrechungen zurückfinden, lässt sich vergrößern und bedienen, funktioniert mit Assistenztechnik, wirkt in jeder Sprache natürlich und stabilisiert sich schnell. Statt einer Seitentür namens „barrierefreier Modus“ sollte der Haupteingang von Anfang an breit sein.
