Accessibility chạm vào mọi lớp của sản phẩm web—nghiên cứu, UX, UI, nội dung, kỹ thuật, QA, hạ tầng, vận hành và cả mua sắm giải pháp. Playbook này dịch WCAG 2.1/2.2 AA thành hướng dẫn thực chiến để đội ngũ xây trải nghiệm bao gồm mà không phải làm lại nhiều. Dùng nó như tài liệu end-to-end: discovery, design system, pattern component, tiêu chuẩn nội dung, xử lý media, hỗ trợ bàn phím và screen reader, kiểm thử, triển khai và giám sát liên tục.
1. Nền Tảng Và Tư Duy
Accessibility là chất lượng. Bốn trụ WCAG—Perceivable, Operable, Understandable, Robust—phản chiếu rủi ro sản phẩm: người dùng không nhìn thấy, không thao tác, không hiểu thì chuyển đổi và uy tín sụt giảm. Đưa accessibility vào Definition of Ready/Done, không đợi audit sau launch. Hỏi: người khiếm thị chỉ với bàn phím + screen reader có thanh toán được? Người nhìn kém đọc được ngoài nắng? Người nhạy cảm nhận thức có xử lý bố cục mà không quá tải?
Ưu tiên HTML gốc. Button, input, select, textarea, details/summary, heading ngữ nghĩa đã có role và hành vi bàn phím. Dùng ARIA chỉ khi cần và không ghi đè ngữ nghĩa gốc. Giữ thứ tự DOM khớp trình tự hiển thị; tránh reorder bằng CSS làm rối focus.
2. Discovery Và Yêu Cầu
Phỏng vấn người dùng khuyết tật. Vẽ hành trình trọng yếu—tìm kiếm, điều hướng, đăng nhập, thanh toán, quản lý tài khoản—và ghi rào cản (carousel tự chạy, thiếu focus, thông báo lỗi mơ hồ). Đặt KPI: tỷ lệ hoàn tất với NVDA/VoiceOver, thời gian sửa lỗi form, tỷ lệ dùng phụ đề, tỉ lệ tương phản đậu/trượt, drop-off của phiên dùng trợ năng, ticket hỗ trợ về accessibility.
Thu thập yêu cầu phi chức năng: mục tiêu WCAG 2.1 AA/2.2, vận hành bàn phím, hỗ trợ screen reader (NVDA, JAWS, VoiceOver), chế độ high-contrast, reduced motion, dark mode, song ngữ, bối cảnh pháp lý. Đưa vào user story và tiêu chí chấp nhận.
3. Token Màu, Chữ, Bố Cục
Định nghĩa token màu đảm bảo tương phản: 4.5:1 cho chữ thường, 3:1 cho chữ lớn và control. Tách token nền, surface, viền, trạng thái tương tác (hover/active/focus/disabled) và cảnh báo (info/success/warning/error). Không dùng màu đơn lẻ—kết hợp icon hoặc text.
Typography: phân cấp rõ ràng, độ dài dòng 45–75 ký tự, line-height ~1.5, khoảng cách thoáng, hỗ trợ đầy đủ ký tự tiếng Việt. Có font fallback và chọn weight không bị mờ ở kích thước nhỏ.
Khoảng cách: token spacing giúp touch target tối thiểu 44x44px, tránh chen chúc, không vỡ bố cục khi phóng to chữ 200%.
4. Component Có Sẵn Accessibility
Nút và link: nút cho hành động, link cho điều hướng. Cần nhãn rõ, focus hiển thị, trạng thái disabled đúng; tránh ghost button tương phản thấp.
Form: mọi control có label gắn for/id; placeholder không thay label. Dùng fieldset/legend cho nhóm radio/checkbox. Cung cấp trợ giúp và lỗi rõ ràng, hiển thị cạnh trường và tóm tắt trên cùng với anchor quay lại. Giữ dữ liệu khi lỗi. Ghi rõ bắt buộc/không bắt buộc; tránh dấu * không giải thích.
Dialog/overlay: trap focus, aria-modal="true", trả focus về nút gọi, vô hiệu nền. Hỗ trợ Esc và nút đóng.
Điều hướng: có skip link, landmark chuẩn (header/nav/main/aside/footer), một H1 thể hiện mục đích, nhãn nhất quán. Breadcrumb thân thiện bàn phím và screen reader. Mega menu phải hỗ trợ phím mũi tên và thoát bằng Esc.
Tab/accordion: theo WAI-ARIA APG—phím mũi tên để di chuyển, Home/End để nhảy, Space/Enter để kích hoạt. Expose aria-selected/aria-controls, quản lý tabIndex đúng, giữ panel trong DOM trừ khi dùng aria-live.
Tooltip/toast: không chỉ hover; hỗ trợ focus và chạm. Cho phép đóng bằng Esc, thời gian đủ đọc. Toast không chiếm focus.
Carousel: có nút tạm dừng/dừng, không auto-rotate quá nhanh, control to và có nhãn, giữ nội dung sẵn sàng ở ngoài carousel nếu có thể. Ưu tiên grid tĩnh cho thông tin quan trọng.
Bảng dữ liệu: dùng th+scope, caption, mô tả cho bảng phức tạp, aria-sort cho cột sắp xếp. Đảm bảo responsive không làm mất header với trợ năng.
Trình phát media: điều khiển bàn phím, focus rõ, phụ đề, transcript, chỉnh âm lượng/tốc độ, không tự phát có âm thanh.
5. Chuẩn Nội Dung Và Media
Alt text: mô tả mục đích. Hình trang trí để alt="". Icon truyền trạng thái cần tên truy cập. Biểu đồ phức tạp cần mô tả dài hoặc bảng dữ liệu.
Video/audio: phụ đề (kèm tên người nói), transcript, thuyết minh audio khi hình ảnh chứa ý chính. Cung cấp bản tải hoặc bitrate thấp cho đường truyền yếu.
Copy: ngôn từ giản dị, câu ngắn, link có ý nghĩa (tránh “nhấn vào đây”). Dùng heading, danh sách để phân mảnh. Bản dịch tiếng Việt phải giữ rõ nghĩa—dịch cả alt, phụ đề, label, lỗi chứ không chỉ thân bài.
6. Chuyển Động, Dark Mode, Theming
Tôn trọng prefers-reduced-motion: tắt parallax, auto-scroll, nhấp nháy; dùng chuyển cảnh nhẹ. Tránh nội dung nhấp nháy >3 lần/giây. Với dark mode, dùng token, chỉnh đổ bóng/viền và kiểm lại tương phản; không đảo màu thô. Focus phải rõ ở mọi theme.
7. Hiệu Năng Và Độ Tin Cậy
Hiệu năng là accessibility. Tối ưu Core Web Vitals để giảm tải nhận thức. Tránh layout shift làm lệch focus. Ưu tiên HTML quan trọng trước JS; nâng cấp dần. Xử lý mạng kém bằng thông báo rõ. Form phải chịu lỗi mạng nhẹ mà không mất dữ liệu.
8. Chương Trình Kiểm Thử
Tự động: lint ARIA, chạy axe/Lighthouse/Pa11y trên template chính trong CI, chặn merge khi lỗi nghiêm trọng. Unit test widget tùy chỉnh cho focus và bàn phím.
Thủ công: duyệt bàn phím (không chuột), screen reader (NVDA+Chrome, VoiceOver+Safari), kiểm tra tương phản, zoom 200%, chế độ giảm chuyển động, dark mode, kiểm tra TalkBack/VoiceOver trên mobile. Dùng kịch bản thực tế (tìm kiếm, lọc, thêm giỏ, thanh toán) để phát hiện lỗi chặn.
Người dùng thật: định kỳ test với người dùng trợ năng (screen reader, switch, nhìn kém). 5–8 phiên đã lộ vấn đề hệ thống.
9. Quy Trình Và Quản Trị
Definition of Ready: tiêu chí chấp nhận gồm cấu trúc ngữ nghĩa, focus, label, hành vi lỗi, tương phản. Definition of Done: bài kiểm tra tự động qua; kiểm tra bàn phím và screen reader mức khói cho story đó.
Handoff: kèm focus state, kiểm chứng tương phản, ghi chú ARIA và hướng dẫn nội dung. Code review siết HTML ngữ nghĩa và quản lý focus. QA coi lỗi a11y chặn luồng chính là P1.
Design system: tài liệu pattern với ví dụ Đúng/Sai, snippet mã, yêu cầu bàn phím/ARIA. Phiên bản hóa component và chạy regression a11y khi phát hành.
Ownership: chỉ định accessibility lead để phân loại issue, theo dõi metric, điều phối audit. Đào tạo designer, engineer, PM, writer, QA hàng quý.
10. Giám Sát, Số Liệu
Theo dõi: điểm audit tự động, số lỗi tương phản, trap focus, lỗi aria, tỷ lệ dùng phụ đề/transcript, hoàn tất tác vụ với trợ năng, thời gian khắc phục lỗi, ticket hỗ trợ. Giám sát log cho lỗi focus và JS phá điều hướng. Lên lịch audit hàng quý và kiểm tra nhanh sau thay đổi UI lớn.
11. Pháp Lý, Rủi Ro, Vendor
Công bố tuyên bố accessibility và kênh phản hồi. Với widget bên thứ ba (chat, thanh toán, analytics), yêu cầu VPAT/ACR và tự test. Đưa SLA khắc phục vào hợp đồng. Ưu tiên sửa theo mức ảnh hưởng người dùng và rủi ro pháp lý.
12. Chiến Lược Di Trú UI Cũ
Bắt đầu bằng sửa ngữ nghĩa: heading, landmark, label, thứ tự focus. Thay custom control bằng phần tử gốc. Thêm phụ đề/transcript cho media quan trọng. Cập nhật token màu dần dần để đạt tương phản. Thay widget phức tạp (date picker, dropdown) bằng pattern chuẩn.
13. Mobile Và Đa Phương Thức
Touch target tối thiểu 44x44px, có khoảng cách. Cử chỉ có phím tương đương. Hỗ trợ xoay màn hình và dynamic type mà không vỡ layout. Kiểm tra thứ tự focus và thông báo trên screen reader mobile. Cung cấp trạng thái offline/lỗi dễ đọc và thao tác.
14. SEO Và Content Ops
HTML ngữ nghĩa, heading rõ, alt text, hiệu năng, structured data giúp cả accessibility và SEO. Đào tạo biên tập viên: bắt buộc alt, kỷ luật heading, link có nghĩa, chính sách phụ đề. Thêm guardrail trong CMS (bắt buộc alt, kiểm tương phản WYSIWYG, nhắc phụ đề khi upload).
15. Quản Lý Thay Đổi Và Văn Hóa
Kỷ niệm thành quả (tỷ lệ hoàn tất của người dùng screen reader tăng). Chia sẻ ví dụ trước/sau. Tổ chức workshop, duy trì thư viện pattern, đưa accessibility vào onboarding. Tạo kênh leo thang cho lỗi a11y và ghi nhận người đóng góp.
Kết luận: accessibility là cải tiến liên tục. Hãy đối xử nó như hiệu năng hoặc bảo mật—được đo lường, sở hữu và cải tiến—để mỗi lần release tiến gần hơn tới trải nghiệm “mọi người đều dùng được”.
16. Checklist Thực Tế Cho Đội Ngũ
Thiết kế: một H1 mỗi trang; trình tự heading hợp lý; cặp màu đạt tương phản; focus state cho mọi trạng thái tương tác; icon có văn bản tương đương; mock motion có phiên bản reduced-motion; token dark mode sẵn có; annotation component ghi keyboard/ARIA.
Nội dung: mọi hình có alt (hoặc alt trống nếu trang trí); link mô tả đích; phụ đề/transcript cho media; form có hướng dẫn và thông báo lỗi rõ; văn phong ngắn gọn; bản song ngữ giữ nghĩa; bảng dữ liệu có tóm tắt.
Kỹ thuật: ưu tiên phần tử ngữ nghĩa; không dùng tabindex>0; skip link đầu DOM; landmark đầy đủ; control tùy chỉnh theo APG; dialog trap focus, aria-modal="true", trả focus khi đóng; thông báo trạng thái qua aria-live; form giữ dữ liệu khi lỗi; không chiếm quyền scroll.
Kiểm thử: duyệt hoàn toàn bằng bàn phím; smoke test screen reader cho luồng chính; kiểm tra tương phản; zoom 200% vẫn dùng được; kiểm tra reduced-motion; dark mode; TalkBack/VoiceOver trên mobile; axe/Lighthouse/Pa11y không có lỗi nghiêm trọng.
17. Mẫu Cần Tránh
- Dùng placeholder làm label.
- Thẻ a không href (hãy dùng button).
- Div/span có click nhưng không role/bàn phím.
- Carousel tự chạy không nút dừng.
- Modal lồng nhau làm mất focus.
- Lạm dụng aria-hidden che nội dung tương tác.
- Chỉ dùng màu để báo lỗi/thành công.
- Infinite scroll không landmark/pagination/“load more”.
- Dropdown tự viết kém thay vì dùng select hoặc pattern chuẩn.
18. Ví Dụ Luồng Có Chú Thích
Đăng ký + xác thực email: label đầy đủ, nút hiển thị mật khẩu với aria-pressed, nêu quy tắc mật khẩu trước khi nhập, báo lỗi cạnh trường và ở tóm tắt, tránh timeout, trạng thái xác thực dùng aria-live polite.
Tìm kiếm và lọc: ô tìm có label và nút submit; bộ lọc là checkbox/radio kèm fieldset/legend; thông báo số kết quả; nút reset rõ ràng. Nếu kết quả động, cập nhật aria-live nhưng không cướp focus; giữ focus khi bật/tắt lọc.
Checkout: breadcrumb từng bước, chỉ báo tiến độ bằng chữ, form giao hàng/thanh toán có label, địa chỉ lưu trữ chọn bằng radio, iframe thanh toán được test focus/label, màn hình xác nhận đọc được với thông tin đơn hàng dạng text. Hạn chế CAPTCHA; nếu bắt buộc, cung cấp lựa chọn thân thiện trợ năng.
Chat hỗ trợ: chọn vendor đạt trợ năng; nút mở chat focus được, có nhãn, không cướp focus khi bật. Trong chat, lịch sử đọc được với screen reader, input có label, thông báo dùng aria-live nhưng không spam.
19. Đa Ngôn Ngữ Và Ngữ Cảnh Địa Phương
Chọn font bao phủ đầy đủ dấu tiếng Việt; test hiển thị weight trên Windows và Android. Điều chỉnh ví dụ, tiền tệ, địa chỉ, định dạng ngày/giờ theo ngữ cảnh. Cung cấp nút đổi ngôn ngữ với thuộc tính lang và nhãn rõ. Nếu mở rộng RTL, chuẩn bị hỗ trợ chiều đọc.
20. Xây A11y Backlog
Audit ban đầu, gắn mức độ nghiêm trọng và luồng bị ảnh hưởng. Ưu tiên P1 cho sprint gần nhất: thiếu label, trap bàn phím, lỗi tương phản, focus hỏng, thiếu phụ đề. P2 cho ma sát (hướng dẫn mập mờ, target nhỏ). P3 cho tinh chỉnh (aria-label chi tiết, tối ưu live-region). Theo dõi owner, deadline, ghi chú regression.
21. Đồng Thuận Lãnh Đạo
Diễn giải accessibility dưới góc kinh doanh: giảm rủi ro pháp lý, cải thiện chuyển đổi, giảm chi phí hỗ trợ, mở rộng thị trường (1/5 dân số), tăng SEO, nâng uy tín thương hiệu. So sánh với đối thủ về mức độ trợ năng. Đề xuất ngân sách cho audit, công cụ, đào tạo, sửa lỗi.
22. Công Cụ Đề Xuất
- Thiết kế: plugin Figma đo tương phản, bộ token chuẩn.
- Mã: eslint-plugin-jsx-a11y, stylelint a11y, Storybook + addon a11y, testing-library với truy vấn accessible.
- Tự động: axe-core trong unit/integration, Lighthouse CI, Pa11y regression.
- Thủ công hỗ trợ: Colour Contrast Analyser, NVDA/VoiceOver, tiện ích Focus Indicator, Responsively cho kiểm tra zoom.
- Nội dung: kiểm tra alt/heading trong CMS, nhắc phụ đề khi upload media.
23. Triển Khai Theo Giai Đoạn
Giai đoạn 1: sửa blocker ở luồng chính (điều hướng, tìm kiếm, tài khoản, thanh toán) và cập nhật token màu. Giai đoạn 2: refactor component trong design system và rollout. Giai đoạn 3: audit sâu template đuôi dài (blog, help center, dashboard). Giai đoạn 4: thiết lập monitoring và test người dùng định kỳ. Công bố mốc, ghi patch note, mời phản hồi từ người dùng trợ năng.
24. Đo Lường Kết Quả
Không chỉ điểm audit: đo chuyển đổi của người dùng bàn phím/screen reader (tín hiệu tổng hợp), thời gian hoàn tất, bỏ dở ở bước form, tỷ lệ ticket a11y đóng mỗi release. Chia sẻ câu chuyện cải thiện—ví dụ “tỷ lệ hoàn tất checkout của người dùng screen reader từ 62% lên 88%.”
Khi pattern tốt, quản trị rõ và kiểm thử liên tục, accessibility trở thành năng lực lặp lại—không còn là cuộc chữa cháy trước ngày go-live.
25. Khung Nghiên Cứu Tình Huống Và Nhịp Bảo Trì
Khung: chọn một luồng chính (đăng ký khóa học, vay vốn…). Audit hiện trạng, lập kế hoạch sửa với owner và deadline, refactor component trong design system trước rồi áp vào template. Mỗi thay đổi đều có test: Storybook a11y, walkthrough bàn phím, kịch bản screen reader. Công bố tóm tắt trước/sau với số liệu để lan tỏa.
Nhịp: audit toàn diện hàng quý, kiểm tra nhanh hàng tháng cho bản phát hành mới, báo cáo CI hàng tuần lên Slack, và grooming backlog định kỳ với design/engineering/product. Duy trì tài liệu “known issues” với giải pháp tạm và ngày sửa dự kiến.
26. Nghi Thức Phối Hợp
Trong refinement, gắn cờ story có UI tương tác cao để pair a11y. Ở design critique, dành thời gian cho tương phản, focus, chuyển động, độ rõ của copy. Khi kickoff kỹ thuật, rà soát ghi chú bàn phím/ARIA và script test. Khi QA ký duyệt, yêu cầu bằng chứng a11y (ảnh focus, log audit).
Khuyến khích QA và designer pair test trên staging với screen reader; đặt lịch 30 phút cho mỗi epic. Luân phiên “a11y champion of the sprint” để lan tỏa chuyên môn.
27. Giải Pháp Khẩn
Nếu sát ngày go-live phát hiện blocker—thiếu label, mất focus, tương phản không đọc được—áp dụng biện pháp nhanh: thêm nhãn văn bản tạm, chèn skip link, tắt auto-play, tăng tương phản bằng CSS override, hoặc cung cấp nội dung tĩnh thay thế. Ghi nhận bản vá và lên lịch sửa triệt để để tránh nợ ẩn.
Các chỉnh nhỏ kịp thời giúp sản phẩm dùng được cho mọi người, nhưng cần theo dõi để không kéo dài mãi.
