Mở đầu — vì sao bài này quan trọng
Hãy bắt đầu bằng một con số khiến nhiều người giật mình: theo Tổ chức Y tế Thế giới (WHO), khoảng 16% dân số toàn cầu — tức hơn một tỷ người — đang sống với một dạng khuyết tật nào đó. Ở Việt Nam, Tổng cục Thống kê ước tính có hơn 6,2 triệu người khuyết tật từ 2 tuổi trở lên. Nhưng accessibility (khả năng tiếp cận, viết tắt là a11y — số 11 là số ký tự giữa chữ "a" và "y") không chỉ phục vụ người khuyết tật vĩnh viễn. Nó phục vụ cả người bị gãy tay tạm thời, người mẹ bế con chỉ thao tác được một tay, người lớn tuổi mắt mờ, người đang đi xe buýt dưới nắng chói nhìn không rõ màn hình, hay đơn giản là người dùng kết nối 3G chập chờn ở vùng quê. Khi bạn thiết kế cho những "trường hợp khó", bạn vô tình nâng chất lượng trải nghiệm cho tất cả mọi người.
Vấn đề lớn nhất của a11y không phải là kỹ thuật, mà là thời điểm. Đa số đội ngũ chỉ nghĩ đến accessibility ở phút chót — khi sản phẩm sắp ra mắt, hoặc tệ hơn, khi đã bị khiếu nại. Lúc đó việc "vá" a11y vừa đắt vừa chắp vá. Bài học hôm nay sẽ thuyết phục bạn làm điều ngược lại: đưa accessibility vào ngay từ nét vẽ đầu tiên, từ khi bạn còn đang sketch trên giấy. Đó chính là tinh thần "Accessibility-First". Đây là một tư duy thiết kế, không phải một checklist cuối quy trình.
Khái niệm cốt lõi
Accessibility-First nghĩa là gì?
Accessibility-First là cách tiếp cận trong đó bạn coi khả năng tiếp cận là một ràng buộc thiết kế ngay từ đầu, ngang hàng với thẩm mỹ và chức năng — chứ không phải một tính năng bổ sung. Nó giống như tư duy "mobile-first" mà bạn đã quen: thay vì thiết kế cho màn hình lớn rồi cố nhồi xuống màn hình nhỏ, bạn thiết kế cho điều kiện hạn chế nhất trước, rồi mở rộng dần.
Tương tự, với a11y-first, bạn tự hỏi ngay từ đầu: "Người dùng bàn phím sẽ điều hướng màn hình này thế nào? Người dùng trình đọc màn hình (screen reader) sẽ nghe thấy gì? Người mù màu có phân biệt được trạng thái lỗi không?" Những câu hỏi này định hình thiết kế của bạn, chứ không phải đến sau.
Vì sao "vá" sau lại đắt?
Có một quy luật trong ngành phần mềm: chi phí sửa một vấn đề tăng theo cấp số nhân qua từng giai đoạn. Một vấn đề a11y phát hiện lúc sketch chỉ tốn vài phút vẽ lại. Cũng vấn đề đó, nếu phát hiện sau khi đã code và lên production, có thể đòi hỏi tái cấu trúc cả component, viết lại HTML semantic, kiểm thử lại toàn bộ — gấp hàng chục lần công sức.
Ví dụ kinh điển: bạn thiết kế một bộ tab điều hướng chỉ bằng các div được tô màu. Trên Figma nó đẹp hoàn hảo. Nhưng khi build, lập trình viên nhận ra trình đọc màn hình không hiểu đó là tab, không biết tab nào đang active, không cho điều hướng bằng phím mũi tên. Sửa lúc này nghĩa là đập đi xây lại cả cấu trúc tương tác. Nếu ngay từ khâu thiết kế bạn đã ghi chú "đây là tablist theo chuẩn ARIA, có trạng thái selected, điều hướng bằng arrow keys", vấn đề đã không bao giờ phát sinh.
Bốn trụ cột POUR
Tiêu chuẩn quốc tế về a11y là WCAG (Web Content Accessibility Guidelines). Bạn không cần thuộc lòng hàng trăm tiêu chí, nhưng nên nhớ bốn nguyên tắc gốc, viết tắt là POUR:
- Perceivable (Cảm nhận được): Người dùng phải nhận biết được thông tin. Ví dụ: ảnh có văn bản thay thế (alt text), video có phụ đề, độ tương phản màu đủ cao.
- Operable (Thao tác được): Mọi chức năng phải dùng được, kể cả chỉ bằng bàn phím. Không có bẫy nào khiến người dùng bị kẹt.
- Understandable (Hiểu được): Giao diện dễ hiểu, dễ đoán, thông báo lỗi rõ ràng, hành vi nhất quán.
- Robust (Bền vững): Nội dung hoạt động tốt với nhiều công nghệ hỗ trợ khác nhau (screen reader, phần mềm phóng đại...).
Mục tiêu thực tế: WCAG 2.1 mức AA
Trong nghề, "đạt chuẩn AA" là mục tiêu phổ biến và hợp lý cho hầu hết sản phẩm thương mại. Hai con số bạn nên khắc cốt ghi tâm:
- Tỷ lệ tương phản tối thiểu 4.5:1 cho văn bản thường, 3:1 cho văn bản lớn (từ 18px đậm hoặc 24px thường trở lên).
- Vùng chạm (touch target) tối thiểu 44×44 pixel (chuẩn Apple) hoặc 48×48dp (chuẩn Android/Material).
Tình huống thực tế
Ví dụ 1 — Ứng dụng ngân hàng số và cú "vá" tốn kém
Một ngân hàng số tại Việt Nam (gọi là "MBank" cho tiện) ra mắt app chuyển tiền với thiết kế rất "trendy": chữ xám nhạt #A0A0A0 trên nền trắng, nút bấm chỉ phân biệt trạng thái bằng màu (xanh = sẵn sàng, xám = vô hiệu), và mã OTP hiển thị bằng font mảnh. App đẹp, lên báo công nghệ.
Ba tháng sau, bộ phận chăm sóc khách hàng nhận hàng loạt phản ánh: người dùng lớn tuổi không đọc nổi chữ xám, người mù màu (khoảng 8% nam giới) không phân biệt được nút nào bấm được. Đặc biệt, một khách hàng khiếm thị dùng screen reader phản ánh rằng nút "Xác nhận chuyển tiền" được đọc thành "button button" vì không có nhãn rõ ràng — một lỗi nghiêm trọng với giao dịch tài chính.
Đội thiết kế phải dừng lại, audit toàn bộ, nâng độ tương phản, thêm icon kèm màu cho trạng thái, gắn aria-label cho mọi nút. Chi phí: gần hai sprint (4 tuần) và một bản cập nhật khẩn cấp. Bài học: nếu ngay từ wireframe họ đã kiểm tra tương phản và không dùng "chỉ màu" để truyền tải trạng thái, toàn bộ thảm họa này đã được ngăn chặn ở khâu thiết kế với chi phí gần như bằng không.
Ví dụ 2 — Grab và touch target trên đường phố
Hãy hình dung một tài xế công nghệ kiểu Grab đang dừng đèn đỏ, đeo găng tay, tay đẫm mồ hôi, cần bấm "Nhận chuyến" trong vài giây trước khi đèn xanh. Nếu nút đó nhỏ và sát các nút khác, anh ta dễ bấm nhầm "Từ chối" — mất thu nhập, mà khách cũng mất xe.
Các nền tảng gọi xe lớn ở Đông Nam Á hiểu rõ điều này nên thiết kế nút hành động chính rất lớn (thường vượt 56px chiều cao), đặt cách xa các nút phá hoại, và dùng cả màu lẫn vị trí để phân biệt. Đây chính là accessibility-first phục vụ người dùng không khuyết tật nhưng trong hoàn cảnh khó — điều mà giới chuyên môn gọi là "situational disability" (khuyết tật tình huống). Bài học: vùng chạm rộng rãi và khoảng cách an toàn giữa các nút không phải để "chiều" người khuyết tật, mà nâng tỷ lệ thao tác thành công cho tất cả, kéo theo số liệu kinh doanh đi lên.
Ví dụ 3 — Trang thương mại điện tử và form thanh toán
Một sàn TMĐT giả định "ShopVN" có form thanh toán mà nhãn (label) của ô nhập chỉ là placeholder mờ bên trong ô. Khi người dùng bắt đầu gõ, placeholder biến mất, họ quên mất ô này là gì. Người dùng screen reader thì hoàn toàn không nghe được nhãn vì placeholder không phải nhãn thực sự. Lỗi validation thì hiển thị bằng viền đỏ — vô nghĩa với người mù màu, và không có chữ giải thích "lỗi gì".
Sau khi đo lường, đội phát hiện form này có tỷ lệ bỏ giỏ hàng cao bất thường ở bước cuối. Họ thiết kế lại theo hướng a11y-first: nhãn luôn hiển thị phía trên ô nhập, lỗi báo bằng cả icon + màu + dòng chữ cụ thể ("Số thẻ phải có 16 chữ số"), và mỗi thông báo lỗi được liên kết với ô tương ứng để screen reader đọc đúng. Tỷ lệ hoàn tất thanh toán tăng rõ rệt. Bài học: a11y tốt và conversion tốt thường đi cùng nhau — vì cả hai đều xuất phát từ sự rõ ràng.
Hướng dẫn từng bước
Dưới đây là cách lồng accessibility vào từng giai đoạn thiết kế, theo đúng tinh thần "first" — làm từ đầu chứ không vá sau.
Bước 1 — Ở khâu sketch và wireframe: Trước khi chọn màu hay font, hãy nghĩ về thứ tự nội dung và luồng điều hướng bàn phím. Đánh số thứ tự tab (tab order) hợp lý: từ trên xuống, trái sang phải, đúng thứ tự logic. Đảm bảo mọi hành động quan trọng đều có thể đạt tới chỉ bằng phím Tab và Enter. Ở giai đoạn này, hãy phác họa cả heading hierarchy (H1, H2, H3) — vì đây vừa là cấu trúc thị giác vừa là cấu trúc mà screen reader dựa vào để điều hướng.
Bước 2 — Khi chọn màu và độ tương phản: Dùng công cụ kiểm tra tương phản (Stark plugin trong Figma, hoặc WebAIM Contrast Checker). Mọi cặp chữ–nền phải đạt tối thiểu 4.5:1. Quan trọng: không bao giờ dùng màu làm phương tiện duy nhất để truyền tải thông tin. Trạng thái lỗi phải có icon + chữ, không chỉ viền đỏ. Link trong đoạn văn nên có gạch chân, không chỉ đổi màu.
Bước 3 — Khi thiết kế component và trạng thái: Định nghĩa đầy đủ các trạng thái tương tác — đặc biệt là focus state (trạng thái khi component được chọn bằng bàn phím). Đây là phần hay bị bỏ quên nhất. Mỗi nút, ô nhập, link phải có một viền focus rõ ràng, tương phản tốt. Đồng thời thiết kế vùng chạm tối thiểu 44×44px, kể cả khi icon nhìn nhỏ.
Bước 4 — Khi viết nội dung trong giao diện: Mọi hình ảnh truyền tải thông tin cần ghi chú alt text. Mọi nút cần nhãn rõ nghĩa (tránh "Bấm vào đây", "Xem thêm" trơ trọi). Mọi ô form cần nhãn hiển thị, không dựa vào placeholder.
Bước 5 — Khi handoff cho lập trình viên: Ghi chú rõ vai trò ngữ nghĩa của từng phần: "đây là <nav>", "đây là tablist", "nút này cần aria-label là...". Bạn không cần viết code, nhưng chú thích semantic giúp dev build đúng ngay lần đầu.
Bước 6 — Kiểm thử nhanh: Thử điều hướng prototype chỉ bằng bàn phím. Bật trình đọc màn hình có sẵn (VoiceOver trên Mac, TalkBack trên Android) lướt qua màn hình. Bạn sẽ "nghe" ra ngay những chỗ thiếu sót.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi a11y là việc của lập trình viên. Nhiều designer nghĩ "đó là phần code". Sai. Tương phản màu, kích thước chạm, nhãn nút, thứ tự nội dung, focus state — tất cả đều do designer quyết định. Dev chỉ hiện thực hóa thứ bạn đã (hoặc chưa) thiết kế.
Lỗi 2 — Dùng chỉ màu để phân biệt. Đây là lỗi phổ biến nhất. Biểu đồ chỉ phân biệt bằng màu, trạng thái lỗi chỉ đổi màu viền. Mẹo: chụp màn hình thiết kế rồi chuyển sang grayscale (đen trắng). Nếu vẫn hiểu được, bạn ổn.
Lỗi 3 — Quên focus state. Designer trau chuốt hover state nhưng bỏ trống focus state. Người dùng bàn phím lạc lối vì không biết mình đang ở đâu. Mẹo: mỗi khi thiết kế hover, thiết kế luôn focus.
Lỗi 4 — Lạm dụng placeholder thay nhãn. Placeholder biến mất khi gõ và không được screen reader đọc như nhãn. Luôn dùng nhãn hiển thị riêng.
Lỗi 5 — Văn bản trên ảnh nền. Chữ đặt trên ảnh có vùng sáng vùng tối khiến tương phản không ổn định. Mẹo: thêm lớp overlay tối/sáng phía sau chữ để đảm bảo tương phản.
Mẹo vàng: Hãy tạo một "accessibility checklist" ngắn dán cạnh màn hình: tương phản ≥ 4.5:1, vùng chạm ≥ 44px, không-chỉ-màu, có focus state, nhãn rõ ràng, alt text đầy đủ. Chạy qua checklist này trước mỗi lần handoff. Năm phút kiểm tra tiết kiệm hàng tuần sửa chữa.
Bài tập thực hành
Bài tập 1 — Audit grayscale: Lấy một màn hình bạn đang thiết kế (hoặc một app bạn hay dùng), chụp lại và chuyển sang đen trắng. Liệt kê tất cả những chỗ trở nên khó hiểu khi mất màu: trạng thái lỗi, nút active/inactive, biểu đồ, link. Với mỗi chỗ, đề xuất một cách bổ sung tín hiệu (icon, chữ, gạch chân, hình dạng).
Bài tập 2 — Kiểm tra tương phản: Mở thiết kế của bạn, dùng plugin Stark hoặc WebAIM Contrast Checker đo 5 cặp chữ–nền bất kỳ. Ghi lại tỷ lệ. Cặp nào dưới 4.5:1, hãy điều chỉnh màu cho đạt chuẩn và ghi lại giá trị màu mới.
Bài tập 3 — Điều hướng bàn phím: Mở một prototype (của bạn hoặc một website bất kỳ). Cất chuột đi, chỉ dùng phím Tab, Shift+Tab, Enter để hoàn thành một tác vụ (ví dụ: đăng nhập). Ghi lại: bạn có nhìn thấy focus rõ ràng ở mỗi bước không? Có chỗ nào bị kẹt không? Có hoàn thành được tác vụ không?
Bài tập 4 — Thiết kế lại một form: Lấy một form thanh toán hoặc đăng ký bất kỳ. Thiết kế lại phiên bản a11y-first: nhãn hiển thị riêng, focus state rõ ràng, thông báo lỗi bằng icon + màu + chữ cụ thể, vùng chạm đủ lớn. So sánh hai phiên bản và viết 3 câu lý giải vì sao bản mới dễ tiếp cận hơn.
Tóm tắt
Accessibility-First không phải là gánh nặng kỹ thuật cuối quy trình, mà là một tư duy thiết kế bạn áp dụng ngay từ nét vẽ đầu tiên. Cốt lõi nằm ở thời điểm: vá a11y sau khi build vừa đắt vừa chắp vá, còn lồng nó vào từ đầu gần như miễn phí. Hãy ghi nhớ bốn trụ cột POUR (Perceivable, Operable, Understandable, Robust) và hai con số neo giữ: tương phản tối thiểu 4.5:1 và vùng chạm tối thiểu 44×44px.
Qua ba tình huống — ngân hàng số phải vá tốn kém, nền tảng gọi xe tối ưu nút bấm cho tài xế, và sàn TMĐT cải thiện conversion nhờ form rõ ràng — bạn thấy một điều xuyên suốt: thiết kế tiếp cận tốt phục vụ tất cả mọi người, kể cả người không khuyết tật nhưng trong hoàn cảnh khó. Là designer, bạn nắm quyền quyết định những yếu tố a11y quan trọng nhất: màu sắc, tương phản, kích thước chạm, focus state, nhãn và thứ tự nội dung. Hãy biến accessibility thành phản xạ, không phải bước kiểm tra cuối cùng. Một checklist năm phút trước mỗi lần handoff chính là khoản đầu tư sinh lời cao nhất bạn có thể thực hiện cho cả người dùng lẫn doanh nghiệp.