Mở đầu — vì sao bài này quan trọng
Bạn đã học rất nhiều kỹ thuật a11y: từ semantic HTML, ARIA, color contrast, keyboard navigation cho tới cách kiểm thử bằng screen reader. Nhưng có một sự thật phũ phàng mà mình muốn nói thẳng với bạn ngay từ đầu: phần lớn dự án thất bại về accessibility không phải vì thiếu kỹ năng kỹ thuật, mà vì thiếu quy trình.
Mình đã chứng kiến điều này quá nhiều lần. Một team có đủ người giỏi, biết cách viết alt text, biết cách làm focus indicator, nhưng khi sản phẩm ra mắt vẫn đầy lỗi accessibility. Lý do? A11y bị đẩy xuống cuối dự án như một khâu "kiểm tra cho có", hoặc tệ hơn, chỉ được nhớ đến khi có khách hàng phàn nàn hoặc khi bị luật sư gửi thư cảnh báo.
Trong khi đó, gần như mọi team phần mềm hiện đại ở Việt Nam và Đông Nam Á đều đang chạy theo mô hình Agile/Scrum: sprint 2 tuần, daily standup, backlog, story point, retrospective. Câu hỏi cốt lõi của bài này là: làm sao để nhét accessibility vào đúng những "khe" của quy trình Agile mà bạn đang có sẵn, để nó trở thành một phần tự nhiên của cách team làm việc chứ không phải một gánh nặng bị bơ vơ ở cuối chặng?
Đây là bài học về tổ chức và quy trình, không phải về code. Nếu bạn làm đúng, a11y sẽ được "nướng sẵn" (baked in) vào từng miếng bánh nhỏ mà team giao ra, thay vì bị "phết lên" (bolted on) khi mọi thứ đã quá muộn và quá đắt để sửa.
Khái niệm cốt lõi
"Shift left" — dịch accessibility về phía bên trái
Có một khái niệm bạn cần nắm đầu tiên: shift left. Hãy tưởng tượng vòng đời một tính năng chạy từ trái sang phải: ý tưởng → thiết kế → code → test → release. Càng về bên phải, chi phí để sửa một lỗi càng đắt.
Một nghiên cứu kinh điển của Deloitte và nhiều báo cáo ngành cho thấy: sửa một lỗi accessibility ở giai đoạn thiết kế có thể rẻ hơn 30–100 lần so với sửa cùng lỗi đó sau khi đã release. Ví dụ dễ hình dung: nếu designer chọn một cặp màu chữ/nền không đủ contrast từ đầu, sửa nó trong Figma mất 2 phút. Nhưng nếu cặp màu đó đã đi vào design system, đã được code vào 40 màn hình, đã lên production — thì việc sửa có thể tốn hàng tuần và kéo theo cả một đợt regression test.
Shift left nghĩa là: đẩy trách nhiệm a11y về càng sớm càng tốt trong sprint.
Accessibility không phải một "cột mốc", nó là một "sợi chỉ"
Sai lầm phổ biến nhất mình thấy là các team coi accessibility như một task riêng: "Sprint 8 chúng ta sẽ làm accessibility". Cách nghĩ này sai về bản chất. A11y không phải một task, nó là một thuộc tính chất lượng xuyên suốt — giống như performance hay security. Bạn không có một sprint riêng để "làm security", đúng không? Security phải nằm trong mọi story. A11y cũng vậy.
Vì thế, thay vì hỏi "khi nào chúng ta làm accessibility?", câu hỏi đúng là "a11y được nhúng vào từng nghi thức (ceremony) của Scrum như thế nào?"
Bốn điểm chạm trong vòng đời sprint
Đây là phần xương sống của bài. Có bốn nghi thức Scrum mà bạn cần cắm a11y vào:
1. Backlog refinement (làm mịn backlog). Đây là nơi user story được viết và làm rõ trước khi đưa vào sprint. Mỗi story cần có acceptance criteria (tiêu chí nghiệm thu) về accessibility ngay trong phần mô tả. Ví dụ, một story "Người dùng có thể lọc sản phẩm theo giá" thì phần acceptance criteria phải bao gồm: "Bộ lọc thao tác được hoàn toàn bằng bàn phím", "Trạng thái đang chọn được screen reader thông báo", "Focus indicator rõ ràng". Nếu những dòng này không có trong story, thì developer sẽ không làm, đơn giản vậy thôi.
2. Sprint planning (lập kế hoạch sprint). Khi team estimate (ước lượng) story point, phần công sức làm a11y phải được tính vào con số đó. Nếu bạn estimate một story là 5 điểm mà quên mất phần keyboard navigation và ARIA, thì bạn đã ước lượng thiếu, và cuối sprint sẽ vỡ kế hoạch — rồi a11y lại là thứ đầu tiên bị cắt để kịp deadline.
3. Development & code review. Trong lúc code, a11y phải nằm trong Definition of Done (DoD) — định nghĩa "thế nào là xong" của team. Và trong code review, reviewer phải kiểm tra a11y như kiểm tra logic nghiệp vụ.
4. Sprint review & retrospective. Khi demo cho stakeholder, hãy demo cả phần a11y (ví dụ: điều hướng tính năng bằng bàn phím trước mặt mọi người). Trong retrospective, nếu có lỗi a11y lọt lưới, hãy đưa ra bàn để cải tiến quy trình.
Definition of Done vs Acceptance Criteria
Hai khái niệm này hay bị lẫn lộn, mình phân biệt rõ:
- Acceptance Criteria là riêng cho từng story — điều kiện cụ thể để story đó được coi là hoàn thành đúng yêu cầu. Ví dụ: "Modal đặt hàng bẫy focus bên trong nó và đóng được bằng phím Esc."
- Definition of Done là chung cho mọi story — checklist bất di bất dịch áp dụng cho tất cả. Ví dụ: "Mọi tính năng mới phải pass qua axe DevTools không có lỗi critical; mọi ảnh có alt text; mọi form input có label liên kết."
Tình huống thực tế
Ví dụ 1 — Tiki và cái bẫy "để cuối sprint"
Hãy hình dung một team làm trang danh mục sản phẩm ở một sàn thương mại điện tử lớn tại Việt Nam (bối cảnh giả định dựa trên mô hình một công ty như Tiki). Team gồm 6 người, chạy sprint 2 tuần. Ban đầu, họ có một quy ước ngầm: "code xong tính năng rồi cuối sprint QA sẽ chạy một lượt kiểm tra accessibility."
Kết quả sau 3 sprint: backlog lỗi a11y phình lên hơn 40 vé (ticket), vì mỗi sprint QA lại tìm ra một đống lỗi mà không còn thời gian sửa, đành đẩy sang sprint sau. Các lỗi cứ dồn lại như tuyết lăn. Đến sprint thứ 4, Product Owner phải dừng hẳn một sprint chỉ để "trả nợ a11y" — mất trắng 2 tuần velocity của cả team.
Bài học rút ra: khi a11y bị dồn về cuối, nó biến thành technical debt (nợ kỹ thuật) tích lũy với lãi kép. Team này sau đó chuyển sang mô hình: mỗi story có acceptance criteria a11y riêng, và không story nào được đánh dấu "done" nếu chưa pass keyboard + axe check. Sau 2 sprint áp dụng, số vé lỗi a11y mới phát sinh giảm còn dưới 5 mỗi sprint.
Ví dụ 2 — Fintech Singapore và "a11y champion"
Một startup fintech ở Singapore (bối cảnh giả định) có 4 squad phát triển song song. Họ gặp vấn đề: kiến thức a11y không đồng đều, squad này làm tốt, squad kia gần như không quan tâm. Thuê một chuyên gia a11y toàn thời gian cho mỗi squad thì quá tốn kém với một startup 30 người.
Giải pháp họ chọn là mô hình "a11y champion": mỗi squad cử ra một developer hoặc designer làm "người vô địch accessibility" — không phải chuyên gia, chỉ là người được đào tạo thêm và chịu trách nhiệm nhắc nhở, review, và là đầu mối khi có câu hỏi a11y. Các champion họp với nhau 30 phút mỗi 2 tuần để chia sẻ kinh nghiệm (một dạng "guild" hay "community of practice").
Sau 6 tháng, tỷ lệ story có acceptance criteria a11y đầy đủ tăng từ khoảng 20% lên hơn 85%. Điều quan trọng: chi phí gần như bằng không, vì họ tận dụng người có sẵn thay vì thuê ngoài. Bài học: bạn không cần biến cả team thành chuyên gia; bạn cần một người ở mỗi nhóm đủ quan tâm để giữ nhịp.
Ví dụ 3 — Ngân hàng và áp lực compliance
Một team làm ứng dụng cho một ngân hàng số ở Đông Nam Á (bối cảnh giả định) bị đối tác quốc tế yêu cầu tuân thủ WCAG 2.1 mức AA như điều kiện hợp đồng. Vấn đề: họ nhận yêu cầu này khi sản phẩm đã code được 70%.
Thay vì hoảng loạn, Scrum Master của họ làm một việc thông minh: đưa a11y vào backlog như những "user story ngược" — mỗi màn hình đã làm được biến thành một story audit ("Là người dùng screen reader, tôi cần dùng được màn hình chuyển khoản"), estimate riêng, và đưa vào sprint theo thứ tự ưu tiên rủi ro. Màn hình quan trọng nhất (đăng nhập, chuyển tiền) được xử lý trước.
Họ mất khoảng 3 sprint để đưa các luồng cốt lõi lên chuẩn AA. Bài học: ngay cả khi bạn bắt đầu muộn, việc cấu trúc hóa a11y thành story có thể estimate và ưu tiên được giúp nó trở nên khả thi và minh bạch với stakeholder, thay vì là một "hố đen" không ai biết bao giờ xong.
Hướng dẫn từng bước
Đây là cách bạn có thể triển khai ngay cho team của mình, theo trình tự vòng đời sprint:
Bước 1 — Viết acceptance criteria a11y trong backlog refinement. Với mỗi story có giao diện, thêm một mục "Accessibility" vào phần acceptance criteria. Dùng một mẫu ngắn gọn, ví dụ: thao tác được bằng bàn phím; có label/alt phù hợp; contrast đạt chuẩn; trạng thái được screen reader thông báo. Product Owner và người viết story chịu trách nhiệm việc này.
Bước 2 — Tính a11y vào estimate ở sprint planning. Khi bổ story point, hỏi thẳng: "Story này cần làm gì cho accessibility?" Nếu câu trả lời là "cũng kha khá", thì con số điểm phải phản ánh điều đó. Đừng để a11y là phần vô hình trong ước lượng.
Bước 3 — Cập nhật Definition of Done. Ngồi lại với team và thêm các dòng a11y vào DoD chung. Giữ nó ngắn và kiểm tra được, ví dụ: "Pass axe DevTools không có lỗi critical/serious", "Điều hướng được hoàn toàn bằng bàn phím", "Mọi ảnh và icon có ý nghĩa đều có text thay thế".
Bước 4 — Tích hợp kiểm tra tự động vào CI. Cắm một công cụ như axe-core, Pa11y hoặc Lighthouse CI vào pipeline. Automation không bắt được hết (chỉ khoảng 30–40% lỗi WCAG), nhưng nó chặn những lỗi "ngớ ngẩn" ngay ở pull request, giải phóng người để tập trung kiểm thử thủ công phần khó.
Bước 5 — Đưa a11y vào code review. Thêm mục a11y vào checklist review PR. Reviewer kiểm tra semantic HTML, ARIA, focus. Đây là "chốt chặn con người" bù cho phần automation bỏ sót.
Bước 6 — Demo a11y trong sprint review. Khi demo tính năng, hãy điều hướng bằng bàn phím hoặc bật screen reader trước mặt stakeholder. Việc này khiến a11y trở nên "hữu hình" và được coi trọng.
Bước 7 — Nuôi văn hóa qua retrospective. Nếu lỗi a11y lọt lưới, đưa vào retro như một điểm cải tiến quy trình, không phải để đổ lỗi cá nhân. Hỏi: "Tại sao lỗi này lọt qua? Ta cần thêm gì vào DoD hay CI?"
Lỗi thường gặp & mẹo
Lỗi 1: Tạo một "sprint accessibility" riêng. Nghe thì có vẻ tận tâm, nhưng đây là dấu hiệu a11y chưa được tích hợp. Sau sprint đó, mọi thứ lại quay về như cũ. A11y phải nằm trong mọi sprint, không phải một sprint đặc biệt.
Lỗi 2: Ném a11y hết cho QA ở cuối. Như ví dụ Tiki cho thấy, cách này tạo nợ kỹ thuật lãi kép. Developer phải chịu một phần trách nhiệm ngay khi code, không đợi QA.
Lỗi 3: Chỉ dựa vào automation. Rất nhiều team cài axe rồi tưởng đã "xong accessibility". Nhớ con số: automation chỉ bắt được 30–40% lỗi. Những thứ quan trọng nhất — thứ tự đọc hợp lý, alt text có ý nghĩa, trải nghiệm screen reader thực tế — cần con người kiểm tra.
Lỗi 4: Acceptance criteria chung chung. Viết "phải accessible" là vô nghĩa vì không ai kiểm được. Hãy viết cụ thể và đo được: "đóng modal bằng phím Esc", "focus quay lại nút đã mở modal khi đóng".
Mẹo 1: Tạo sẵn một thư viện acceptance criteria a11y tái sử dụng cho các component phổ biến (modal, form, dropdown, tabs). Khi viết story mới, chỉ việc copy đoạn tương ứng. Tiết kiệm thời gian và đảm bảo tính nhất quán.
Mẹo 2: Gắn a11y vào template pull request. Mỗi PR có sẵn một checkbox "Tôi đã kiểm tra bằng bàn phím" để nhắc developer.
Mẹo 3: Đừng cố hoàn hảo ngay. Nếu team đang từ số 0, hãy bắt đầu bằng đúng một dòng trong DoD (ví dụ "keyboard accessible") và thực thi nghiêm túc. Thêm dần theo thời gian sẽ bền hơn là áp một checklist 20 mục rồi ai cũng phớt lờ.
Bài tập thực hành
- Viết lại một user story. Lấy một story bất kỳ từ dự án của bạn (hoặc tự nghĩ ra, ví dụ "Người dùng có thể thêm sản phẩm vào giỏ hàng"). Viết đầy đủ 3–5 acceptance criteria về accessibility cho nó, thật cụ thể và kiểm tra được.
- Soạn Definition of Done a11y. Viết một DoD gồm đúng 5 mục a11y mà bạn nghĩ là quan trọng nhất và khả thi nhất để một team Việt Nam áp dụng ngay từ tuần đầu. Giải thích vì sao chọn 5 mục đó.
- Phân tích tình huống. Team bạn nhận yêu cầu WCAG AA khi dự án đã hoàn thành 60%. Hãy phác thảo một kế hoạch 3 sprint để đưa các luồng quan trọng lên chuẩn, nêu rõ bạn ưu tiên màn hình nào trước và vì sao.
- Thiết kế vai trò champion. Viết một mô tả ngắn (khoảng 150 từ) về vai trò "a11y champion" cho squad của bạn: người này làm gì hằng tuần, không làm gì, và họp guild bàn chuyện gì.
Tóm tắt
Điều quan trọng nhất bạn cần mang theo từ bài này: accessibility không phải một task, nó là một sợi chỉ dệt xuyên suốt mọi nghi thức của Scrum. Đừng bao giờ để nó lủng lẳng ở cuối sprint như một khâu kiểm tra cho có.
Bốn điểm chạm cần nhớ: (1) viết acceptance criteria a11y trong backlog refinement; (2) tính công sức a11y vào estimate khi sprint planning; (3) đưa a11y vào Definition of Done và code review khi phát triển; (4) demo và cải tiến a11y trong sprint review và retrospective.
Áp dụng nguyên tắc shift left để bắt lỗi khi còn rẻ. Dùng automation trong CI để chặn lỗi cơ bản, nhưng luôn nhớ nó chỉ bắt được 30–40% — phần còn lại cần con người. Nuôi một hoặc vài a11y champion để giữ nhịp kiến thức trong team mà không tốn chi phí thuê ngoài. Và trên hết, phân biệt rõ Definition of Done (sàn chung cho mọi story) với acceptance criteria (yêu cầu đặc thù từng story).
Nếu làm đúng những điều này, accessibility sẽ được "nướng sẵn" vào từng miếng bánh mà team giao ra — tự nhiên, bền vững, và rẻ hơn rất nhiều so với việc chữa cháy về sau. Đó chính là sự khác biệt giữa một team nói về accessibility và một team thực sự sống cùng nó.