Email ai cũng đọc được (accessibility)

Danh mục: Nội dung & thiết kế · Bài nâng cao

Bạn đã biết làm email responsive một cột, nút bulletproof, ảnh có thẻ alt. Bài này đi xa hơn một bậc: làm email mà bất kỳ ai cũng đọc được — kể cả người dùng trình đọc màn hình (screen reader), người mắt kém phải phóng to chữ, người mù màu, người đang đọc dưới nắng gắt với độ sáng màn hình thấp, hay người để điện thoại ở chế độ tối. Accessibility (khả năng tiếp cận) không phải tính năng “cho có nhân văn”: nó là một phần của thiết kế tốt, và nó trực tiếp ảnh hưởng tới tỷ lệ đọc, tỷ lệ nhấp và cả khả năng vào Inbox.

Điều thú vị là gần như mọi kỹ thuật accessibility đều làm email tốt hơn cho tất cả mọi người, không chỉ nhóm khuyết tật. Tương phản cao giúp người đọc ngoài nắng. HTML thật thay vì “một tấm ảnh” vừa thân thiện với screen reader vừa nhẹ hơn, ít bị nghi spam hơn. Thứ tự nội dung mạch lạc giúp cả người vuốt nhanh bằng ngón cái. Đây là kiểu đầu tư “một công đôi ba việc”.

1. Vì sao accessibility quan trọng với email marketing

Một tỷ lệ đáng kể người nhận của bạn đọc email trong điều kiện không lý tưởng: trên màn hình nhỏ, dưới ánh nắng, khi đang di chuyển, hoặc với thị lực giảm theo tuổi. Một nhóm khác dùng trình đọc màn hình — phần mềm đọc to nội dung email thành tiếng. Nếu email của bạn chỉ “đẹp” với người mắt tinh, ngồi trong phòng, nhìn màn hình lớn, bạn đang vô tình loại bỏ một phần khách hàng tiềm năng khỏi thông điệp.

Có bốn lý do thực dụng để quan tâm:

• Doanh thu: mỗi người không đọc được email là một cơ hội bán hàng mất đi. Tương phản kém, chữ bé, CTA mơ hồ trực tiếp kéo tụt tỷ lệ nhấp.
• Khả năng vào Inbox: email accessible thường là email có chữ thật, cấu trúc rõ, ít “ảnh đè” — đúng những thứ bộ lọc spam ưa thích. Xem thêm hướng dẫn vào Inbox.
• Uy tín thương hiệu: một email gãy vỡ, chữ chìm vào nền cho thấy sự cẩu thả; một email gọn, rõ, đọc được ở mọi nơi cho thấy sự chuyên nghiệp.
• Tính bền của thiết kế: email accessible sống sót tốt hơn qua các trường hợp khắc nghiệt — ảnh bị chặn, dark mode đảo màu, font tùy biến không tải được.

2. Văn bản thay thế (alt) — vượt mức “có là được”

Bạn đã biết mọi ảnh cần thẻ alt. Ở mức nâng cao, vấn đề không còn là “có alt hay không” mà là viết alt như thế nào, và biết khi nào không nên có alt. Screen reader đọc to giá trịalt; viết ẩu sẽ biến trải nghiệm nghe thành tra tấn.

Ba loại ảnh, ba cách xử lý alt

Điểm tinh tế nhất ở đây: ảnh trang trí nên có alt rỗng alt="", chứ không phải bỏ trống thuộc tính. Khác biệt rất quan trọng: nếu bạn quên hẳn thuộc tính alt, nhiều screen reader sẽ đọc to tên file (ví dụ “banner-final-v3-copy.png”) — vô nghĩa và khó chịu. Còn alt="" báo cho screen reader biết ảnh này chỉ để trang trí và hãy bỏ qua.

Quy tắc thực chiến khi viết alt

• Viết như đang đọc cho người mù nghe: nếu xóa ảnh đi và chỉ còn dòng alt, người nhận có hiểu khối này nói gì không?
• Ngắn gọn, dưới một câu: screen reader đọc tuần tự, alt dài lê thê làm người nghe mất kiên nhẫn.
• Đừng nhồi từ khóa và đừng bắt đầu bằng “Hình ảnh của...” — screen reader đã tự báo “hình ảnh” rồi.
• Ảnh có link: alt nên mô tả điểm đến, không mô tả pixel. Một banner bấm để mua hàng nên có alt như “Mua bộ sưu tập hè ngay” chứ không phải “ảnh người mẫu mặc váy”.
• Tận dụng alt cho dự phòng: ngay cả khi ảnh bị chặn (Outlook, Gmail thường chặn mặc định), alt rõ ràng vẫn truyền được thông điệp. Đây là accessibility và dự phòng cùng lúc.

Một ví dụ “trước & sau”

Giả sử bạn có một banner khuyến mãi là ảnh chữ “FLASH SALE 50% — chỉ hôm nay”, bấm vào dẫn tới trang sản phẩm. So sánh ba cách đặt alt cho cùng một banner đó:

3. Tương phản màu — con số bạn nên thuộc lòng

Tương phản (contrast) là tỷ lệ độ sáng giữa chữ và nền phía sau nó. Chữ xám nhạt trên nền trắng, hay chữ trắng trên nền cam nhạt, nhìn “sang” trên màn hình thiết kế nhưng biến mất ngoài nắng hoặc với người thị lực kém. Chuẩn WCAG đưa ra các ngưỡng tỷ lệ tương phản rất đáng dùng làm kim chỉ nam:

Cách dùng thực tế: trước khi gửi, lấy mã màu chữ và mã màu nền rồi đưa vào một công cụ kiểm tra tỷ lệ tương phản (gõ “contrast checker” là ra nhiều công cụ miễn phí). Vài lỗi tương phản phổ biến nhất ở email Việt Nam:

• Chữ trắng trên nút màu nhạt: chữ trắng trên nền vàng/cam nhạt gần như không đọc được. Nút có nền màu đậm (như cam thương hiệu) với chữ trắng thì an toàn.
• Chữ xám “cho thanh lịch”: màu xám rất nhạt trên nền trắng có thể tụt dưới 4.5:1. Hãy làm đậm thêm một bậc.
• Chữ đặt đè lên ảnh: nền ảnh có chỗ sáng chỗ tối khiến chữ lúc đọc được lúc không. Nếu phải đặt chữ trên ảnh, thêm lớp phủ tối/sáng phía sau chữ để bảo đảm tương phản.
• Đừng chỉ dùng màu để truyền nghĩa: “mục đỏ là hết hàng, mục xanh là còn” vô hình với người mù màu. Thêm chữ hoặc ký hiệu (“Hết hàng” / “Còn hàng”) bên cạnh màu.

Để dễ hình dung, vài cặp màu thường gặp và kết quả khi đưa vào contrast checker:

• Đạt: chữ trắng (#FFFFFF) trên nút cam đậm thương hiệu — tương phản cao, đọc tốt cả ngoài nắng.
• Đạt: chữ xám than (#374151) trên nền trắng — đủ đậm cho cả đoạn văn dài.
• Trượt: chữ xám nhạt (#9CA3AF) trên nền trắng — dưới ngưỡng 4.5:1, mờ với mắt kém. Làm đậm thêm một bậc là đạt.
• Trượt: chữ trắng trên nền vàng/cam nhạt — gần như chữ chìm, đừng dùng cho nội dung quan trọng.

4. Cỡ chữ & khoảng đọc — đừng bắt người ta nheo mắt

Cỡ chữ là yếu tố accessibility dễ làm nhất nhưng hay bị xem nhẹ. Người lớn tuổi, người viễn thị, người đọc trên màn hình bé đều cần chữ đủ to. Các con số an toàn cho email:

• Chữ thân tối thiểu 14px, lý tưởng 16px. Dưới 14px, iPhone tự phóng to và làm vỡ bố cục — vừa hại thiết kế vừa hại trải nghiệm.
• Giãn dòng 1.4–1.6. Dòng quá sát nhau khiến mắt “trượt” sang dòng khác, đặc biệt với người đọc khó.
• Đừng dùng chữ in hoa cho cả đoạn. CHỮ IN HOA TOÀN BỘ khó đọc hơn và bị một số screen reader đọc từng chữ cái. Dùng in hoa tiết chế cho nhãn ngắn.
• Không nhồi chữ vào ảnh. Chữ nằm trong ảnh không phóng to được theo cài đặt của người dùng và screen reader không đọc được. Hãy để chữ là chữ thật trong HTML.
• Căn trái cho đoạn dài. Căn đều hai bên (justify) tạo khoảng trắng loang lổ khó đọc; căn giữa chỉ hợp với tiêu đề ngắn, không hợp đoạn văn.
• Vùng bấm đủ to (≥ 44×44px). Người tay run, ngón cái to, hoặc đang đi xe buýt cần nút đủ rộng để bấm trúng. Một nút cao tầm 44px với khoảng đệm hai bên là mức an toàn; đừng để hai link nằm sát nhau khiến dễ bấm nhầm.

5. HTML semantic — cấu trúc mà screen reader hiểu được

“Semantic” nghĩa là dùng đúng thẻ HTML cho đúng vai trò, để máy (screen reader, bộ lọc) hiểu được cấu trúc chứ không chỉ nhìn thấy chữ. Đây là phần nhiều người làm email bỏ qua nhất vì nó vô hình với mắt thường — nhưng nó là xương sống của accessibility.

• Dùng heading thật (<h1>, <h2>) cho tiêu đề, thay vì một dòng <p> bôi đậm cỡ to. Screen reader cho phép người dùng “nhảy” giữa các heading để nắm bố cục — chỉ khi chúng là heading thật.
• Dùng danh sách thật (<ul>, <li>) thay vì gõ tay dấu “•” đầu dòng. Screen reader sẽ thông báo “danh sách, 5 mục” giúp người nghe định hướng.
• Link mô tả được điểm đến. Tránh “bấm vào đây”: screen reader có chế độ đọc liệt kê mọi link, một loạt “bấm vào đây” thì vô dụng. Hãy viết “Xem chính sách đổi trả”.
• Khai báo ngôn ngữ: đặtlang="vi" ở thẻ gốc để screen reader đọc tiếng Việt đúng giọng, không đọc dấu thành tiếng Anh.
• Bảng bố cục cần ẩn khỏi screen reader: email thường dùng <table> để dàn trang. Với bảng chỉ để bố cục (không phải dữ liệu), thêmrole="presentation" để screen reader không đọc “bảng, 3 hàng 2 cột” gây rối.

6. Dark mode — đừng để chữ & logo biến mất

Dark mode là một bài toán accessibility: nhiều người bật chế độ tối vì nhạy cảm với ánh sáng hoặc để đỡ mỏi mắt buổi đêm. Khi đó các ứng dụng mail (Gmail, Outlook, Apple Mail) tự đảo màu email — nền trắng thành đen, chữ đen thành trắng — và hay gây tai nạn:

• Logo chữ tối tàng hình trên nền tối sau khi bị đảo.
• Chữ màu đặt thủ công (ví dụ xám đậm) có thể không được đảo và chìm vào nền đen.
• Mảng trắng chói: logo PNG nền trắng nổi lên thành ô sáng giữa email tối.

Bạn không kiểm soát hoàn toàn được cách mỗi ứng dụng đảo màu, nhưng có thể thiết kế để chịu được cả hai chế độ:

• Logo nền trong suốt với phiên bản nhìn rõ trên cả nền sáng lẫn tối; nếu cần, thêm quầng/viền mỏng để tách khỏi nền.
• Chọn cặp màu vẫn tương phản dù bị đảo: màu nhấn (như cam thương hiệu) ít bị đảo mạnh như cặp đen/trắng, nên nút màu thương hiệu thường “sống sót” tốt.
• Không trông cậy vào ranh giới mảnh: đường kẻ xám nhạt phân tách khối có thể biến mất trong dark mode. Dùng khoảng cách (padding) để phân tách thay vì chỉ một đường kẻ.
• Luôn test cả hai chế độ: bật dark mode trên điện thoại, gửi thử cho chính mình. Đây là cách nhanh nhất bắt lỗi logo/chữ biến mất.

7. Screen reader — nghe thử email của bạn

Screen reader (trình đọc màn hình) đọc to nội dung email theo thứ tự HTML cho người khiếm thị. Cách tốt nhất để hiểu trải nghiệm này là tự nghe thử. Bạn không cần cài gì lạ — mọi điện thoại đều có sẵn:

• iPhone: Cài đặt → Trợ năng → VoiceOver. Bật lên rồi mở email vừa gửi và vuốt qua từng phần.
• Android: Cài đặt → Trợ năng → TalkBack. Tương tự, nghe nó đọc email của bạn.

Khi nghe, hãy chú ý những điểm sau — đây là nơi lỗi accessibility lộ rõ nhất:

• Thứ tự đọc có hợp lý không? Nội dung được đọc theo thứ tự trong HTML, không theo vị trí mắt nhìn. Nếu bạn dùng bố cục lạ, screen reader có thể đọc lộn xộn.
• Ảnh được đọc ra sao? Nếu nghe thấy “banner-final-v3.png” nghĩa là ảnh thiếu alt. Nếu một ảnh trang trí bị đọc thành một câu dài, nó nên có alt="" rỗng.
• Link nghe có rõ không? Một loạt “bấm vào đây” là dấu hiệu cần viết lại văn bản link.
• Có phần nào bị lặp/thừa? Đôi khi một ảnh có link mà cả ảnh lẫn văn bản quanh nó cùng nói một điều, gây nghe trùng.

Preheader — câu đầu tiên screen reader đọc

Preheader (đoạn xem trước) là dòng chữ hiện cạnh tiêu đề trong hộp thư, và cũng thường là thứ đầu tiên screen reader đọc khi mở email. Một preheader rỗng hay bị bỏ trống sẽ khiến ứng dụng mail tự lấy đại dòng đầu của email — có khi là “Xem bản web” hoặc một chuỗi link — nghe rất khó hiểu. Hãy chủ động viết một preheader ngắn, nói rõ email về gì. Bạn có thể dựng nhanh bằng công cụ Viết preheader rồi đọc thêm về cặp tiêu đề–preheader trong bài Preheader & CTA.

8. Áp dụng trong Mailemdi — từ chiến dịch tới transactional

Accessibility không chỉ cho email khuyến mãi. Nó áp dụng cho mọi loại email bạn gửi qua Mailemdi:

• Mẫu email sẵn: thư viện mẫu email của Mailemdi đã dựng theo bố cục một cột, heading semantic và nút bulletproof — điểm xuất phát tốt. Việc của bạn là giữ tương phản khi đổi màu thương hiệu và viết alt tử tế khi thay ảnh. Xem thêm cách dùng mẫu tại hướng dẫn mẫu email.
• Chuỗi automation: các email chào mừng, nhắc giỏ hàng, tái kích hoạt trong Automation gửi tự động hàng loạt — một lỗi accessibility ở đây nhân lên theo từng người nhận. Đầu tư làm đúng một lần, hưởng lợi mãi.
• Email giao dịch (transactional): biên nhận, xác nhận đơn, đặt lại mật khẩu là email người ta thật sự cần đọc — accessibility ở đây tối quan trọng. Nếu bạn gửi transactional qua API, nhúng cùng nguyên tắc: chữ thật, alt rõ, tương phản đủ. Xem hướng dẫn tích hợp API (gửi qua header X-API-Key, nhận trạng thái qua webhook ký HMAC) để chuẩn hóa template transactional một chỗ.

9. Quy trình kiểm tra accessibility trước khi gửi

Gộp lại thành một quy trình ngắn để chạy trước mỗi chiến dịch:

1. Xem trước & tắt ảnh: mở bản nháp, tắt hiển thị ảnh. Email có còn hiểu được và bấm được không? Nếu không, alt hoặc cấu trúc đang yếu.
2. Kiểm tra tương phản: lấy mã màu chữ/nền chính đưa vào contrast checker, bảo đảm đạt 4.5:1 cho chữ thường.
3. Bật dark mode + hạ sáng: gửi thử cho mình, mở ở chế độ tối và độ sáng thấp. Logo, chữ còn rõ không?
4. Nghe bằng screen reader: bật VoiceOver/TalkBack, nghe một lượt. Thứ tự, alt, link có ổn không?
5. Soát link & dung lượng: rà mọi liên kết bằng công cụ Soát link trong email, và kiểm tra HTML không vượt ~102KB (kẻo Gmail cắt mất chân thư) bằng công cụ Đo dung lượng email.
6. Soát từ ngữ & vào Inbox: dùng công cụ Soát từ khóa spam để tránh cấu trúc khiến bộ lọc nghi ngờ — email accessible mà rơi vào spam thì cũng không ai đọc.

Checklist accessibility trước khi gửi

Lưu lại danh sách này; soát một lượt trước mỗi chiến dịch:

• ☐ Mọi ảnh thông tin có alt mô tả rõ; ảnh trang trí có alt="" rỗng.
• ☐ Nội dung chính là chữ thật, không phải chữ nằm trong ảnh.
• ☐ Tương phản chữ/nền đạt tối thiểu 4.5:1 (chữ lớn 3:1).
• ☐ Không chỉ dùng màu để truyền nghĩa — kèm chữ/ký hiệu.
• ☐ Cỡ chữ thân ≥ 14px (lý tưởng 16px), giãn dòng thoáng.
• ☐ Heading, danh sách là thẻ HTML thật, không phải text bôi đậm.
• ☐ Văn bản link mô tả điểm đến, tránh “bấm vào đây”.
• ☐ Logo/chữ vẫn nhìn rõ ở dark mode và độ sáng thấp.
• ☐ Đã nghe thử bằng VoiceOver/TalkBack, thứ tự đọc hợp lý.
• ☐ Đã soát link, dung lượng và từ khóa spam.