Accessibility cho website doanh nghiệp: vì sao 83,9% trang chủ vẫn trượt tiêu chí dễ nhất
Báo cáo WebAIM Million 2026 cho thấy 83,9% trang chủ có chữ không đủ tương phản — tiêu chí máy kiểm được dễ nhất trong WCAG — và sáu loại lỗi phổ biến nhất không đổi suốt bảy năm. Đây không phải vấn đề thiếu kiến thức, mà là vấn đề đo sai.
Tháng 3 hằng năm, WebAIM quét trang chủ của một triệu website phổ biến nhất và công bố kết quả. Báo cáo 2026 ghi nhận 56.114.377 lỗi trên một triệu trang, trung bình 56,1 lỗi mỗi trang — tăng 10,1% so với mức 51 lỗi của năm 2025. Riêng lỗi chữ không đủ tương phản xuất hiện ở 83,9% số trang, tăng từ 79,1% năm trước, với trung bình 34 vị trí riêng biệt trên mỗi trang mắc lỗi.
Con số đáng suy nghĩ hơn nằm ở chỗ khác: **sáu loại lỗi phổ biến nhất không thay đổi suốt bảy năm** và chiếm tới 96% tổng số lỗi phát hiện được. Đây đều là những lỗi có cách sửa rõ ràng, không cần nghiên cứu gì mới. Nếu vấn đề chỉ là thiếu kiến thức thì bảy năm là quá đủ để tỉ lệ giảm. Nó không giảm, mà tăng. Điều đó gợi ý nguyên nhân nằm ở chỗ khác: phần lớn đội ngũ không thực sự **đo** khả năng tiếp cận của sản phẩm mình, họ chỉ chạy một công cụ quét và tin vào kết quả.
Vì sao doanh nghiệp Việt Nam không thể xếp việc này vào "làm sau"
Với thị trường trong nước, khung pháp lý hiện tại chủ yếu ràng buộc khối công. Thông tư 26/2020/TT-BTTTT quy định việc áp dụng tiêu chuẩn hỗ trợ người khuyết tật tiếp cận sản phẩm, dịch vụ thông tin và truyền thông, tham chiếu WCAG 2.0 cho cổng thông tin điện tử của cơ quan nhà nước, đơn vị sự nghiệp công lập và cơ quan báo chí. Doanh nghiệp tư nhân thuần nội địa hiện chưa bị ràng buộc tương đương — và cần nói thẳng như vậy thay vì thổi phồng.
Nhưng bức tranh đổi hẳn ngay khi có khách hàng ở nước ngoài:
- **Đạo luật Tiếp cận châu Âu (EAA)** có hiệu lực thi hành từ 28/6/2025 trên toàn bộ 27 nước thành viên. Điểm quan trọng với doanh nghiệp Việt: nghĩa vụ áp dụng cho **mọi nhà cung cấp dịch vụ thương mại điện tử tới người tiêu dùng trong EU, bất kể nhà cung cấp đó đặt ở đâu**. Ngưỡng loại trừ là doanh nghiệp dưới 10 nhân sự và doanh thu hoặc tổng tài sản dưới 2 triệu EUR. Ngoài việc đạt WCAG mức AA, doanh nghiệp còn phải công bố một bản tuyên bố về khả năng tiếp cận. Chi tiết phạm vi áp dụng được Bird & Bird tổng hợp.
- **Thị trường Mỹ** đi bằng con đường kiện tụng thay vì thanh tra. Theo báo cáo tổng kết 2025 của EcomBack, có 3.948 vụ kiện liên bang về khả năng tiếp cận website trong năm 2025, tăng 23,84% so với 3.188 vụ của năm 2024; tính cả toà tiểu bang thì vượt 5.000 vụ. Khoảng 70% nhắm vào thương mại điện tử, và 35,8% trong nhóm 500 nhà bán lẻ trực tuyến lớn nhất đã nhận ít nhất một đơn kiện.
Một chi tiết dễ bị bỏ qua: 1.427 trong số hơn 5.000 vụ kiện năm 2025 nhắm vào những công ty **đã từng bị kiện trước đó**. Sửa một lần rồi để đấy không giải quyết được gì — vì mỗi lần thêm tính năng là một lần có thể tái phát lỗi.
Còn một lý do không nằm ở pháp lý: phần lớn việc cần làm cho khả năng tiếp cận trùng với việc cần làm cho SEO và cho trải nghiệm người dùng nói chung. Cấu trúc heading đúng thứ bậc, thẻ `alt` mô tả đúng nội dung ảnh, tên khả truy cập rõ ràng cho nút và liên kết, HTML ngữ nghĩa thay vì `div` lồng nhau — đây đồng thời là những tín hiệu mà công cụ tìm kiếm và mô hình AI dùng để hiểu trang.
Sáu loại lỗi chiếm 96% tổng số
Theo báo cáo 2026, tỉ lệ trang chủ mắc từng loại như sau:
- **Chữ không đủ tương phản** — 83,9%
- **Ảnh thiếu văn bản thay thế** — 53,1%
- **Trường nhập liệu thiếu nhãn** — 51,0%
- **Liên kết rỗng** (thẻ `a` không có nội dung khả truy cập) — 46,3%
- **Nút rỗng** (thường là nút chỉ chứa icon, không có tên khả truy cập)
- **Thiếu khai báo ngôn ngữ tài liệu** (`<html lang>`)
Không có lỗi nào trong danh sách này cần kiến trúc mới hay thư viện mới. Hai lỗi cuối sửa xong trong vài phút. Việc chúng vẫn tồn tại ở quy mô hàng trăm nghìn website nói lên rằng chúng **không được nhìn thấy**, chứ không phải không sửa được.
Cạm bẫy thứ nhất: overlay widget không phải là tuân thủ
Thị trường có một nhóm sản phẩm hứa hẹn rất hấp dẫn: nhúng một dòng script, website tự động đạt chuẩn. Dữ liệu thực tế không ủng hộ lời hứa đó. Trong năm 2025, 456 vụ kiện — chiếm 22,6% tổng số — nhắm vào chính những website đang dùng overlay hoặc widget loại này. Tháng 4/2025, Uỷ ban Thương mại Liên bang Mỹ (FTC) ra quyết định buộc một nhà cung cấp overlay lớn nộp phạt 1 triệu USD vì quảng cáo sai rằng công cụ AI của họ có thể làm bất kỳ website nào đạt chuẩn WCAG. Tổng hợp các vụ việc cho thấy một số vụ kết thúc bằng phán quyết buộc gỡ bỏ overlay và cam kết khắc phục ở tầng mã nguồn.
Lý do kỹ thuật khá dễ hiểu. Overlay chạy sau khi trang đã tải, cố đoán ý nghĩa của các phần tử từ bên ngoài. Nó không biết bức ảnh này mô tả cái gì, không biết nút icon này dùng để làm gì, và trong nhiều trường hợp nó còn can thiệp vào chính phần mềm hỗ trợ mà người dùng đang chạy — biến một rào cản tiềm ẩn thành một rào cản có thật, ghi hình lại được và đưa vào hồ sơ khởi kiện.
Cạm bẫy thứ hai: tin rằng công cụ quét nhìn thấy hết
Đây là cạm bẫy tinh vi hơn, vì công cụ quét là thứ hữu ích thật. Vấn đề là giới hạn của chúng ít khi được nói rõ: **không công cụ tự động nào phát hiện được quá khoảng 40% số lỗi WCAG**. Phần còn lại đòi hỏi phán đoán về ngữ nghĩa — thẻ `alt` có mô tả đúng ý nghĩa của ảnh trong ngữ cảnh đó không, thứ tự focus có khớp với thứ tự đọc không, thông báo lỗi có được truyền đến trình đọc màn hình không.
Nghiêm trọng hơn, ngay trong nhóm 40% "máy kiểm được" ấy vẫn có những điểm mù có hệ thống. Bốn điểm dưới đây là những chỗ chúng tôi thấy công cụ phổ thông bỏ sót nhiều nhất khi kiểm tra tương phản:
Bốn điểm mù khi đo tương phản
- **Nền hiệu dụng, không phải nền thiết kế.** Một token màu chữ thường được chỉnh cho nền trang. Nhưng cùng chữ đó khi đặt trên mặt thẻ, trên dải nền phụ, hay trên một lớp phủ bán trong suốt sẽ có tỉ lệ tương phản khác hẳn. Phép đo đúng phải chồng toàn bộ chuỗi nền của các phần tử cha lại rồi mới so — một màu đạt 4,7:1 trên nền trang có thể chỉ còn 3,9:1 trên mặt thẻ trong chế độ tối.
- **Chữ trong SVG.** Công cụ quét đọc thuộc tính `color` của CSS. Chữ trong SVG tô bằng `fill`. Kết quả là toàn bộ nhãn trong sơ đồ, biểu đồ và infographic — thường là chữ nhỏ nhất trên trang, 7–11px — nằm ngoài tầm nhìn của công cụ. Với website kỹ thuật hoặc trang sản phẩm nhiều biểu đồ, đây có thể là nhóm lỗi lớn nhất mà không ai biết.
- **Nền vẽ bên trong đồ hoạ.** Khi nhãn nằm trên một mảng tô có sắc độ riêng bên trong sơ đồ, không thể tính nền bằng cách đọc DOM: bạn phải tính cả `opacity`, `fill-opacity` và opacity của mọi nhóm cha. Cách chắc chắn hơn là ẩn lớp chữ đi, chụp ảnh trang, rồi lấy mẫu pixel thật ngay dưới vị trí chữ. Mô hình hoá bằng DOM rất dễ cho kết quả sai theo cả hai chiều.
- **Nhóm phi văn bản (SC 1.4.11).** Đây là một tiêu chí riêng với ngưỡng 3:1, áp dụng cho viền và nền phân định thành phần giao diện, chỉ báo focus, và các phần đồ hoạ cần thiết để hiểu nội dung. Rất nhiều hệ thống thiết kế dùng chung một token đường kẻ mảnh cho cả đường phân cách trang trí lẫn viền nút — hợp lý về thẩm mỹ, nhưng khiến viền nút chỉ đạt hơn 1:1 và người thị lực kém không xác định được vùng bấm ở đâu.
Biết điều gì *không* phải lỗi cũng quan trọng ngang biết điều gì là lỗi
Đây là phần hiếm khi được nói tới, nhưng quyết định việc bản sửa của bạn có phá thiết kế hay không. WCAG có những miễn trừ rõ ràng, và áp dụng tiêu chí một cách máy móc sẽ làm hỏng sản phẩm mà không giúp thêm cho ai:
- Thành phần giao diện **chỉ nhận diện bằng chữ** — ví dụ một nút accordion không viền, không nền, chỉ có nhãn chữ — thuộc phạm vi tiêu chí tương phản chữ, và được miễn trừ khỏi tiêu chí phi văn bản. Thêm viền cho nó không giúp ích gì.
- Đường kẻ **trang trí** — đường phân cách giữa hai khối, lưới nền mờ — không phải thành phần giao diện. Làm đậm chúng lên cho "đạt 3:1" chỉ khiến trang nặng nề hơn.
- Một nét vẽ **chồng lên hình đã tô đặc** trong sơ đồ: nếu bản thân mảng tô đã đủ phân định hình khối, nét chồng lên không gây mất khả năng hiểu nội dung.
Nguyên tắc thực dụng: với mỗi lỗi công cụ báo, hỏi "nếu phần tử này biến mất hoàn toàn, người dùng có mất thông tin hay mất khả năng thao tác không?". Nếu không, nó là trang trí. Đây là câu hỏi tách được lỗi thật khỏi nhiễu, và tiết kiệm phần lớn công sức.
Lộ trình cho một website doanh nghiệp đang chạy
Không cần làm lại từ đầu. Thứ tự dưới đây cho kết quả sớm nhất trên mỗi giờ công bỏ ra:
- **Tuần 1 — đo và phân loại.** Quét tự động để lấy nhóm dễ, rồi bổ sung phép đo thủ công cho bốn điểm mù ở trên. Kết quả cần là một danh sách phân loại theo *nguyên nhân gốc*, không phải theo từng vị trí lỗi: 400 lỗi thường quy về 5–6 token màu.
- **Tuần 2 — sửa ở tầng hệ thống thiết kế.** Chỉnh token, thêm biến thể màu dành riêng cho chữ nếu màu thương hiệu không thể vừa làm chữ vừa giữ nhận diện, và ghi lại lý do ngay trong mã nguồn để người sau không vô tình quay lại giá trị cũ.
- **Tuần 3 — bàn phím và ngữ nghĩa.** Duyệt các luồng chính chỉ bằng bàn phím, sửa thứ tự focus, đặt tên khả truy cập cho nút icon, gắn nhãn cho mọi trường nhập liệu, và bảo đảm thông báo lỗi của form được trình đọc màn hình đọc lên.
- **Liên tục — chốt lại trong quy trình.** Thêm một bước kiểm tra tương phản vào CI để lần thêm tính năng sau không tái phát lỗi cũ. Đây chính là điểm khác biệt giữa "đã sửa một lần" và "đang tuân thủ" — và cũng là lý do 1.427 công ty bị kiện lại trong năm 2025.
Với các thành phần giao diện phức tạp, chọn thư viện có sẵn hỗ trợ đầy đủ sẽ rẻ hơn nhiều so với tự xử lý ARIA và điều hướng bàn phím. Đó là một trong những lý do chúng tôi xây Forge Select với ARIA và điều hướng bàn phím đầy đủ ngay từ đầu, và phát hành theo giấy phép MIT trên trang Cộng đồng.
Kết luận
Sáu loại lỗi giữ nguyên vị trí suốt bảy năm không phải vì chúng khó sửa — chúng nằm trong nhóm dễ sửa nhất. Chúng tồn tại vì phần lớn đội ngũ chưa từng nhìn thấy chúng: một lần quét tự động cho ra bảng kết quả xanh, và không ai kiểm tra xem công cụ đã bỏ sót những gì. Với doanh nghiệp có khách hàng ở EU hoặc Mỹ, khoảng cách giữa "trông có vẻ ổn" và "đo được là ổn" giờ đã có giá bằng tiền. Với mọi doanh nghiệp còn lại, nó vẫn là khoảng cách giữa một website mọi người dùng được và một website chỉ phần lớn người dùng được. Xem năng lực Development của KonexForge, hoặc liên hệ nếu bạn muốn một bản đánh giá khả năng tiếp cận đo trên bản build thật thay vì trên một bảng điểm tự động.
Bài viết liên quan
Giải pháp công nghệ cho phòng mạch và bác sĩ: từ hóa đơn điện tử đến bệnh án điện tử
Trong vòng 18 tháng, phòng mạch và bác sĩ tư nhân phải xử lý cùng lúc ba nghĩa vụ mới: hóa đơn điện tử theo Nghị định 70/2025, bỏ thuế khoán từ 1/1/2026, và hạn chót bệnh án điện tử 31/12/2026 theo Thông tư 13/2025/TT-BYT — trong khi phần lớn vẫn vận hành bằng sổ giấy, Excel và Zalo. Kiến trúc giải pháp tối giản chúng tôi đề xuất, và vì sao phần mềm bệnh viện thu nhỏ không phải câu trả lời.
Vì sao chuyển đổi số dẫn đến 5-6 hệ thống rời rạc và dữ liệu trùng lặp khắp nơi
Nhiều công ty và cơ quan không thiếu công nghệ — họ thừa hệ thống. Sau vài năm chuyển đổi số từng phần, một tổ chức thường vận hành 5-6 hệ thống không nói chuyện được với nhau, và cùng một khách hàng hay nhân sự tồn tại dưới nhiều phiên bản dữ liệu khác nhau. Bài viết phân tích vì sao điều này xảy ra và kiến trúc hợp nhất KonexForge áp dụng để giải quyết — không phải bằng cách mua thêm một hệ thống thứ bảy.
Forge Select: bản thay thế Select2 zero-dependency, framework-agnostic mã nguồn mở
Select2 đã phục vụ cộng đồng web nhiều năm, nhưng dựa trên jQuery — một ràng buộc ngày càng khó chấp nhận với stack hiện đại. Forge Select là component select/combobox chúng tôi tự xây: toàn bộ core chỉ 5 file, zero runtime dependency, nhưng đủ tính năng cho sản phẩm thật — virtual scroll, tree select, tags, và accessibility đầy đủ.