Mở đầu — vì sao bài này quan trọng
Bạn có thể đã làm rất tốt phần kỹ thuật của accessibility: contrast đạt chuẩn, keyboard chạy mượt, screen reader đọc đúng thứ tự. Nhưng có một loại rào cản mà không một dòng ARIA nào chữa được — đó là khi chính ngôn ngữ bạn viết ra quá khó hiểu. Một người đọc màn hình vẫn có thể đọc to câu "Việc gia hạn hiệu lực của gói dịch vụ được thực hiện tự động thông qua cơ chế thanh toán định kỳ trừ khi có sự chấm dứt hợp lệ", nhưng người dùng vẫn không hiểu là "tiền sẽ tự động bị trừ mỗi tháng, muốn ngừng thì bấm hủy".
Plain language (ngôn ngữ đơn giản, dễ hiểu) và reading level (mức độ đọc hiểu cần thiết) là phần "accessibility của nội dung". Đây là điểm giao giữa thiết kế, viết lách và bao trùm (inclusion). Nó đặc biệt quan trọng với: người có khó khăn về nhận thức (cognitive disabilities), người khiếm thị dùng screen reader (nghe câu dài rất mệt), người không rành công nghệ, người lớn tuổi, người đọc trong bối cảnh căng thẳng (khai báo y tế, giao dịch ngân hàng), và cả những người đọc bằng ngôn ngữ thứ hai.
Ở Việt Nam, chủ đề này càng đáng chú ý: nhiều sản phẩm số dịch nguyên văn từ tiếng Anh sang một thứ tiếng Việt "văn bản hành chính", đầy thuật ngữ và câu phức. Bài này sẽ giúp bạn hiểu tiêu chuẩn WCAG liên quan, cách đo mức độ khó của văn bản, và quan trọng nhất là cách viết lại cho dễ hiểu mà không mất chính xác.
Khái niệm cốt lõi
WCAG 3.1.5 — Reading Level (Level AAA)
Tiêu chí thành công 3.1.5 Reading Level thuộc WCAG, cấp độ AAA (cấp cao nhất). Nội dung tóm gọn: khi một đoạn văn bản đòi hỏi khả năng đọc hiểu cao hơn trình độ trung học cơ sở (lower secondary education level — tương đương học sinh khoảng 11–14 tuổi, sau 7–9 năm đi học), thì bạn cần cung cấp một trong hai:
- Một phiên bản văn bản thay thế dễ đọc hơn (không đòi hỏi trình độ cao hơn THCS), hoặc
- Một bổ trợ nội dung giúp hiểu: hình minh họa, biểu đồ, video, phiên bản tóm tắt, hoặc phần giải thích thuật ngữ.
Vì sao AAA nhưng vẫn nên quan tâm
Đa số dự án nhắm mục tiêu tuân thủ AA, nên nhiều người nghĩ 3.1.5 (AAA) "không bắt buộc, bỏ qua được". Đó là hiểu nhầm về giá trị. Trên thực tế, plain language là best practice cho mọi sản phẩm, kể cả khi bạn chỉ cam kết AA. Lý do: nội dung khó hiểu làm tăng tỷ lệ bỏ giữa chừng, tăng cuộc gọi lên tổng đài, tăng lỗi thao tác của người dùng — những chi phí kinh doanh rất thật. Vậy nên hãy coi 3.1.5 là kim chỉ nam chất lượng nội dung, không chỉ là ô checkbox tuân thủ.
Reading level được đo như thế nào
"Mức độ đọc" thường được ước lượng bằng các công thức readability dựa trên độ dài câu và độ dài/độ phức tạp của từ. Với tiếng Anh, phổ biến nhất là:
- Flesch Reading Ease: điểm 0–100, càng cao càng dễ. Trên 60 là "dễ đọc", dưới 30 là "rất khó, cỡ học thuật".
- Flesch–Kincaid Grade Level: quy đổi ra "lớp mấy" (grade). Grade 8 tương đương lớp 8 — đây thường là mốc mục tiêu tốt cho nội dung đại chúng.
- Gunning Fog, SMOG: các công thức tương tự, cũng ước lượng số năm học cần thiết.
Với tiếng Việt thì sao
Các công thức trên được thiết kế cho tiếng Anh; áp thẳng vào tiếng Việt sẽ lệch, vì tiếng Việt đơn âm tiết và cách đếm "âm tiết" khác hẳn. Đến nay chưa có một chuẩn readability tiếng Việt phổ biến như Flesch. Vì thế, với tiếng Việt bạn nên dựa nhiều hơn vào nguyên tắc định tính: câu ngắn, từ thông dụng, tránh câu bị động và mệnh đề lồng nhau, giải thích thuật ngữ. Bạn vẫn có thể dùng cảm quan "một học sinh lớp 8 có đọc hiểu ngay không?" làm thước đo tinh thần.
Plain language khác "viết ngắn"
Một hiểu lầm phổ biến: plain language nghĩa là cắt cho ngắn nhất. Không hẳn. Mục tiêu là để người đọc hiểu đúng ngay lần đầu, làm đúng việc cần làm, mà không phải đọc lại. Đôi khi thêm một câu giải thích lại làm mọi thứ dễ hơn ngắn gọn nhưng mù mờ. Plain language là về sự rõ ràng và có thể hành động, không phải về số chữ.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số Việt Nam: thông báo phí
Giả định một ngân hàng số tên VietPay Digital hiển thị thông báo khi người dùng sắp bị thu phí thường niên thẻ:
> "Kính thông báo, tài khoản của Quý khách sẽ bị áp dụng khoản phí duy trì dịch vụ thường niên theo biểu phí hiện hành. Việc không đảm bảo số dư khả dụng có thể dẫn đến phát sinh nghĩa vụ tài chính quá hạn."
Đội hỗ trợ nhận hàng trăm cuộc gọi mỗi tháng hỏi "phí gì, bao nhiêu, khi nào trừ". Đo bằng cảm quan: câu bị động, thuật ngữ "biểu phí hiện hành", "số dư khả dụng", "nghĩa vụ tài chính quá hạn" — vượt xa trình độ THCS.
Đội thiết kế nội dung viết lại:
> "Ngày 15/07, chúng tôi sẽ trừ 80.000đ phí thường niên của thẻ. Hãy đảm bảo tài khoản còn đủ tiền. Nếu không đủ, khoản phí sẽ được ghi nợ và bạn có thể bị tính lãi."
Bài học: con số cụ thể (ngày, số tiền) và động từ chủ động ("chúng tôi sẽ trừ") thay cho danh từ hóa mơ hồ. Số cuộc gọi giảm mạnh vì người dùng đã có câu trả lời ngay trên màn hình. Đây chính là tinh thần 3.1.5: không cần phiên bản "cho trẻ con", chỉ cần phiên bản mà người lớn bình thường đọc là hiểu.
Ví dụ 2 — Cổng dịch vụ công: hướng dẫn nộp hồ sơ
Một cổng dịch vụ công trực tuyến có đoạn hướng dẫn:
> "Người nộp hồ sơ có trách nhiệm đối chiếu, xác thực tính hợp lệ của các thành phần hồ sơ trước khi thực hiện thao tác đề nghị giải quyết thủ tục hành chính, tránh trường hợp bị trả lại do không đáp ứng đầy đủ điều kiện theo quy định."
Câu này dài 40+ chữ, một mệnh đề duy nhất, đầy văn phong hành chính. Người lớn tuổi — nhóm dùng dịch vụ công rất nhiều — thường phải nhờ con cháu đọc hộ.
Phiên bản plain language, tách bước:
> "Trước khi bấm 'Nộp hồ sơ', hãy kiểm tra: > - Đã điền đủ các ô bắt buộc (có dấu *). > - Ảnh chụp giấy tờ rõ nét, không bị mờ. > > Nếu thiếu giấy tờ, hồ sơ sẽ bị trả lại."
Bài học: với hướng dẫn thao tác, việc cấu trúc lại thành danh sách và câu điều kiện đơn giản còn quan trọng hơn cả việc đổi từ. Ở đây ta cũng đã áp dụng luôn tinh thần "content bổ trợ" của 3.1.5 — biến một khối văn dày đặc thành checklist dễ quét mắt. Với người khiếm thị dùng screen reader, danh sách cũng được đọc rõ ràng từng mục thay vì một câu dài nghẹt thở.
Ví dụ 3 — Ứng dụng sức khỏe: giữ thuật ngữ nhưng thêm giải thích
Một app đặt lịch khám tên CareBook cần hiển thị: "Bạn cần nhịn ăn trước xét nghiệm lipid máu." Từ "lipid" là thuật ngữ y khoa, nhưng lại chính xác và cần thiết — không nên xóa. Đây đúng là trường hợp WCAG cho phép giữ nội dung khó kèm bổ trợ.
Giải pháp:
> "Bạn cần nhịn ăn 8–12 tiếng trước khi làm xét nghiệm lipid máu (mỡ máu). Bạn vẫn có thể uống nước lọc."
Thuật ngữ được giữ, nhưng thêm chú giải ngắn "(mỡ máu)" và một hướng dẫn hành động cụ thể ("nhịn ăn 8–12 tiếng", "vẫn uống nước lọc được").
Bài học: plain language không có nghĩa là loại bỏ từ chuyên môn bằng mọi giá. Với y tế, pháp lý, tài chính, đôi khi thuật ngữ chính xác là bắt buộc. Cách đúng theo 3.1.5 là giữ thuật ngữ + cung cấp bổ trợ để hiểu: chú giải trong ngoặc, tooltip, hoặc một câu diễn giải kèm bên cạnh.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho bất kỳ đoạn văn bản nào trong sản phẩm.
Bước 1 — Xác định nội dung ưu tiên. Bạn không cần rà soát toàn bộ. Hãy tập trung vào các điểm rủi ro cao: thông báo lỗi, điều khoản, hướng dẫn thanh toán, form, email giao dịch, màn hình onboarding. Đây là nơi hiểu nhầm gây hậu quả nặng nhất.
Bước 2 — Đo mức độ hiện tại (với nội dung tiếng Anh). Dán văn bản vào công cụ như Hemingway Editor, hoặc dùng tính năng Readability Statistics của Microsoft Word, hoặc các thư viện như textstat (Python). Ghi lại grade level. Mục tiêu tham khảo: grade 8 hoặc thấp hơn cho nội dung đại chúng. Với tiếng Việt, dùng thước đo định tính ở bước sau.
Bước 3 — Rút ngắn câu. Nhắm trung bình 15–20 từ mỗi câu. Tách câu dài thành nhiều câu ngắn. Một ý — một câu. Nếu bạn thấy chữ "và", "đồng thời", "tuy nhiên", "do đó" nối nhiều mệnh đề, hãy cân nhắc ngắt thành câu riêng.
Bước 4 — Đổi từ khó sang từ thông dụng. "Thực hiện" → "làm"; "tiến hành" → bỏ luôn; "khoản phí phát sinh" → "phí"; "đối với" → "với". Ưu tiên từ mà người dùng thật sự dùng khi nói chuyện.
Bước 5 — Chuyển câu bị động và danh từ hóa sang chủ động. "Việc gia hạn được thực hiện tự động" → "Gói của bạn tự động gia hạn". Nói rõ ai làm gì.
Bước 6 — Thêm cấu trúc. Dùng danh sách, tiêu đề phụ, bôi đậm từ khóa, và đặt thông tin quan trọng nhất lên đầu. Cấu trúc tốt giúp người đọc "quét" và cũng hỗ trợ screen reader điều hướng.
Bước 7 — Xử lý thuật ngữ bắt buộc. Với từ chuyên môn không thể bỏ, thêm chú giải ngắn trong ngoặc, tooltip hoặc glossary. Đây là cách đáp ứng 3.1.5 mà không hy sinh độ chính xác.
Bước 8 — Kiểm bằng người thật. Nhờ một người không thuộc lĩnh vực đọc và giải thích lại họ hiểu gì. Nếu họ tóm tắt sai, văn bản chưa đạt — dù công cụ chấm điểm đẹp đến đâu.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi điểm readability là mục tiêu cuối. Có người viết câu cụt lủn, dùng từ sai nghĩa chỉ để "kéo grade level xuống". Công thức mù ngữ nghĩa nên bị đánh lừa, nhưng người đọc thì không. Điểm số chỉ là đèn báo; phép thử thật là người thật có hiểu không.
Lỗi 2 — Nhầm plain language với "hạ thấp" người đọc. Viết dễ hiểu không phải coi thường trí thông minh của người dùng. Ngay cả chuyên gia cũng thích đọc câu rõ ràng khi đang vội. Đừng ngại đơn giản hóa vì sợ "trông thiếu chuyên nghiệp".
Lỗi 3 — Đơn giản hóa cả những chỗ không được phép. Đừng bịa lại hay làm sai lệch thông tin pháp lý/y tế chỉ để cho dễ đọc. Khi độ chính xác là bắt buộc, hãy giữ nguyên và bổ trợ, đúng như WCAG hướng dẫn.
Lỗi 4 — Bỏ quên microcopy. Nút, nhãn form, thông báo lỗi, tooltip — những mẩu chữ nhỏ này lại là nơi người dùng ra quyết định. "Đã xảy ra lỗi" thì vô dụng; "Số điện thoại phải có 10 chữ số" thì hành động được.
Lỗi 5 — Dịch nguyên văn từ tiếng Anh. Rất nhiều nội dung tiếng Việt khó hiểu vì được dịch máy móc, giữ cấu trúc câu tiếng Anh. Hãy viết lại theo cách người Việt nói, đừng dịch từng chữ.
Mẹo hay:
- Đọc to câu lên. Nếu bạn hụt hơi giữa chừng, câu đó quá dài.
- Đặt câu hỏi "người dùng cần làm gì tiếp theo?" và đưa câu trả lời đó lên đầu.
- Ưu tiên động từ hành động thay vì danh từ hóa ("hủy" thay vì "thực hiện việc hủy").
- Xây một glossary dùng chung cho cả team, để thuật ngữ luôn được giải thích nhất quán.
- Với screen reader, câu ngắn và cấu trúc rõ giúp việc nghe đỡ mệt — plain language và a11y kỹ thuật cộng hưởng với nhau.
Bài tập thực hành
Bài 1 — Đo và cải thiện (tiếng Anh). Chọn một đoạn 2–3 câu từ trang điều khoản hoặc trang giá của một sản phẩm bất kỳ. Dán vào Hemingway Editor, ghi lại grade level. Viết lại để đạt grade 8 hoặc thấp hơn, rồi so sánh hai điểm số. Ghi chú bạn đã đổi gì (rút câu, đổi từ, chuyển chủ động).
Bài 2 — Viết lại theo tinh thần 3.1.5. Lấy đoạn văn bản hành chính này và viết lại theo plain language, tách thành các bước nếu cần: "Trong trường hợp người dùng có nhu cầu chấm dứt việc sử dụng dịch vụ, việc hủy đăng ký cần được thực hiện trước thời điểm gia hạn nhằm tránh phát sinh khoản phí cho chu kỳ tiếp theo."
Bài 3 — Giữ thuật ngữ + bổ trợ. Tìm một câu có thuật ngữ chuyên môn bắt buộc (y tế, tài chính, hoặc kỹ thuật). Viết lại sao cho giữ nguyên thuật ngữ nhưng thêm chú giải ngắn hoặc câu diễn giải, đúng theo hướng "cung cấp bổ trợ" của WCAG 3.1.5.
Bài 4 — Kiểm bằng người thật. Đưa bản viết lại ở Bài 2 cho một người không làm cùng ngành đọc, rồi hỏi họ tóm tắt lại. Ghi lại chỗ họ hiểu sai (nếu có) và chỉnh tiếp. Đây là bước quan trọng nhất, vì nó vượt qua giới hạn của mọi công thức chấm điểm.
Tóm tắt
Plain language và reading level là phần accessibility nằm ở nội dung, không phải ở code. WCAG 3.1.5 Reading Level (AAA) yêu cầu: khi văn bản khó hơn trình độ THCS, hãy cung cấp phiên bản dễ hơn hoặc nội dung bổ trợ — nhưng cho phép giữ nguyên tên riêng, tiêu đề và thuật ngữ bắt buộc.
Dù đây là tiêu chí cấp AAA, plain language là best practice cho mọi sản phẩm: nó giảm hiểu nhầm, giảm bỏ giữa chừng và giảm chi phí hỗ trợ. Các công thức readability (Flesch, Flesch–Kincaid, grade level) là đèn báo hữu ích cho tiếng Anh nhưng mù ngữ nghĩa; với tiếng Việt hãy dựa vào nguyên tắc định tính. Cách viết cốt lõi: câu ngắn, từ thông dụng, câu chủ động, cấu trúc rõ ràng, và bổ trợ cho thuật ngữ. Và phép thử cuối cùng luôn là: một người bình thường đọc xong có hiểu đúng và làm được việc cần làm ngay lần đầu hay không.