Bài 58 — A11y Anti-patterns & Dark Patterns

Mở đầu — vì sao bài này quan trọng

Suốt gần 60 bài của khóa học này, chúng ta đã cùng nhau xây dựng nền tảng để làm sản phẩm accessible: từ semantic HTML, ARIA, color contrast cho tới keyboard navigation và screen reader. Nhưng có một sự thật phũ phàng mà một mentor thật lòng phải nói với bạn: đôi khi thứ nguy hiểm nhất không phải là "không làm gì cả", mà là "làm sai một cách trông có vẻ đúng".

Bài học hôm nay nói về anti-patterns (những mô hình phản tác dụng) trong accessibility, và về dark patterns — những thiết kế cố tình đánh lừa người dùng. Đây là mảng kiến thức mà rất nhiều người làm design/dev bỏ qua, vì họ nghĩ chỉ cần "thêm accessibility vào là tốt". Nhưng thực tế, có những giải pháp được marketing rầm rộ là "giúp website accessible ngay lập tức" lại gây hại nhiều hơn lợi — thậm chí khiến doanh nghiệp bị kiện. Đồng thời, có những dark pattern tưởng như chỉ là chiêu trò kinh doanh nhưng lại gây tổn thương nặng nề nhất đúng vào nhóm người dùng khuyết tật.

Hiểu được các anti-pattern này giúp bạn trở thành người bảo vệ (advocate) thực thụ, biết nói "không" đúng lúc với sếp hoặc khách hàng, và tránh những cái bẫy tốn kém. Đây là bài học về sự trung thực nghề nghiệp.

Khái niệm cốt lõi

Anti-pattern là gì trong bối cảnh a11y?

Anti-pattern là một giải pháp trông hợp lý, phổ biến, được nhiều người áp dụng, nhưng thực chất tạo ra vấn đề lớn hơn vấn đề nó định giải quyết. Trong accessibility, anti-pattern thường xuất hiện khi ai đó muốn "đi tắt" — đạt được vẻ ngoài của sự tuân thủ (compliance) mà không thực sự bỏ công làm đúng.

Dark pattern thì khác về bản chất: đó là thiết kế cố ý thao túng người dùng để họ làm điều có lợi cho doanh nghiệp mà bất lợi cho chính họ — ví dụ vô tình đăng ký gói trả phí, khó hủy dịch vụ, bị lừa bấm nút sai. Khi dark pattern gặp người dùng khuyết tật, tác hại nhân lên nhiều lần vì họ có ít "đường thoát" hơn.

Anti-pattern số một: "Accessibility overlay" widget

Đây là loại anti-pattern nguy hiểm và gây tranh cãi nhất hiện nay, nên ta dành nhiều thời gian cho nó. Bạn hẳn từng thấy một nút tròn nhỏ (thường là biểu tượng người dang tay) nổi ở góc màn hình, bấm vào hiện ra một thanh công cụ hứa hẹn "làm website này accessible": chỉnh cỡ chữ, đảo màu, tắt animation, đọc to nội dung.

Các sản phẩm nổi tiếng trong nhóm này gồm accessiBe, AudioEye, UserWay, EqualWeb. Chúng được bán theo mô hình đăng ký (subscription) với lời hứa: chỉ cần dán một dòng JavaScript, website của bạn "tự động tuân thủ WCAG và ADA". Nghe quá hấp dẫn với một doanh nghiệp bận rộn, đúng không?

Vấn đề là ở chỗ:

Thứ nhất — chúng không sửa vấn đề gốc. Một overlay chạy JavaScript ở runtime để "vá" DOM và CSS. Nó có thể tự đoán và gắn alt cho ảnh bằng AI, tự thêm ARIA, tự chỉnh contrast. Nhưng những phỏng đoán này thường sai. Ảnh sản phẩm mỹ phẩm được AI mô tả thành "chai màu trắng" thay vì "Serum dưỡng ẩm Vitamin C 30ml" — vô nghĩa với người khiếm thị đang muốn mua hàng.

Thứ hai — chúng xung đột với assistive technology thật. Nhiều người dùng screen reader thực tế báo cáo rằng overlay khiến trải nghiệm tệ hơn: focus nhảy loạn, nội dung bị đọc hai lần, hoặc thanh công cụ của overlay chặn mất luồng đọc tự nhiên. Người dùng khiếm thị vốn đã có screen reader riêng (JAWS, NVDA, VoiceOver) được tùy chỉnh theo nhu cầu của họ — overlay chồng lên đó chỉ gây nhiễu.

Thứ ba — chúng tạo cảm giác an toàn giả tạo về mặt pháp lý. Đây là điểm chết người. Doanh nghiệp trả tiền cho overlay tin rằng mình đã "an toàn khỏi bị kiện". Thực tế tại Mỹ, số vụ kiện ADA nhắm vào chính các website có cài overlay ngày càng tăng. Năm 2023, hơn 900 vụ kiện accessibility đã nhắm vào website đang dùng overlay widget. Cộng đồng chuyên gia đã ra một tuyên bố chung tên "Overlay Fact Sheet" (overlayfactsheet.com) với hàng trăm chuyên gia a11y ký tên, khuyến cáo không dùng loại sản phẩm này.

Các anti-pattern phổ biến khác

Ngoài overlay, còn nhiều anti-pattern nhỏ hơn nhưng rất hay gặp:

• "Skip to content" ẩn nhưng không hoạt động: gắn link skip cho có, nhưng nó không thực sự chuyển focus tới đâu.
• ARIA lạm dụng: thêm role="button" vào thẻ <div> rồi quên xử lý bàn phím — trong khi chỉ cần dùng <button> là xong (ta đã học kỹ ở Bài 20). Có câu châm ngôn: "No ARIA is better than bad ARIA" (không dùng ARIA còn hơn dùng ARIA sai).
• Placeholder thay cho label: dùng placeholder xám nhạt làm nhãn cho ô input — khi người dùng gõ vào là nhãn biến mất, và contrast placeholder thường không đạt chuẩn.
• tabindex dương (như tabindex="5"): phá vỡ thứ tự tab tự nhiên, gây rối loạn điều hướng bàn phím.
• "Accessibility statement" sao chép: dán một tuyên bố accessibility hoành tráng lên website nhưng nội dung bên trong không hề accessible.

Dark patterns tác động lên người khuyết tật

Dark pattern là góc tối của UX. Một số loại đặc biệt tàn nhẫn với người khuyết tật:

• Confirmshaming: nút từ chối được viết theo kiểu miệt thị ("Không, tôi không quan tâm đến việc tiết kiệm tiền"). Với người có khó khăn về nhận thức (cognitive), đây là áp lực tâm lý không công bằng.
• Nút giả / bẫy focus: nút "Đóng" của quảng cáo bị làm cực nhỏ hoặc contrast thấp cố ý — người thị lực kém gần như không thấy.
• Đăng ký dễ, hủy khó (roach motel): đăng ký chỉ một cú click, nhưng hủy phải gọi điện thoại — một rào cản với người khiếm thính hoặc người khó giao tiếp bằng lời.
• Đếm ngược giả tạo tạo áp lực thời gian: gây khó khăn cực lớn cho người cần nhiều thời gian đọc và thao tác (ta đã nói về time limit ở Bài 32).

Tình huống thực tế

Ví dụ 1 — Chuỗi bán lẻ mỹ phẩm và cái bẫy overlay

Một chuỗi cửa hàng mỹ phẩm giả định tên "Bloom Cosmetics" tại TP.HCM có website bán hàng online, doanh thu khoảng 8 tỷ đồng/năm. Đầu 2024, họ nhận được email từ một đối tác nước ngoài yêu cầu website phải "đạt chuẩn accessibility" để hợp tác. Đội marketing tìm nhanh trên Google, thấy một widget quảng cáo "tuân thủ WCAG trong 48 giờ chỉ với một dòng code, giá 490 USD/năm". Quá rẻ và nhanh so với việc thuê team dev, họ cài ngay.

Ba tháng sau, họ nhận phản hồi từ chính khách hàng: một người dùng khiếm thị dùng screen reader NVDA phàn nàn rằng sau khi có widget, anh không thể hoàn tất bước thanh toán — focus cứ nhảy về đầu trang mỗi khi overlay tự "quét" lại DOM. Đối tác nước ngoài cũng thuê chuyên gia audit và kết luận: website không đạt WCAG, ảnh sản phẩm có alt text do AI tạo sai lệch, và form thanh toán vẫn thiếu label thật.

Bài học rút ra: Bloom Cosmetics mất 490 USD, mất uy tín với đối tác, và mất luôn khách hàng khiếm thị. Điều họ tiết kiệm bằng cách "đi tắt" nhỏ hơn nhiều so với cái giá phải trả. Overlay không thay thế được việc sửa mã nguồn đúng cách.

Ví dụ 2 — Ứng dụng giao đồ ăn và dark pattern hủy gói

Một app giao đồ ăn giả định tên "NhanhFood" ở Đông Nam Á triển khai gói thành viên "NhanhPlus" (miễn phí ship). Đăng ký chỉ một chạm. Nhưng để hủy, người dùng phải: vào Cài đặt → cuộn xuống cuối → bấm một link chữ xám nhạt cỡ 11px "Quản lý gói" → qua ba màn hình confirmshaming ("Bạn chắc chứ? Bạn sẽ mất ưu đãi!") → cuối cùng nút "Xác nhận hủy" lại có contrast rất thấp.

Một người dùng lớn tuổi bị thị lực kém không tìm thấy link hủy, tiếp tục bị trừ tiền 4 tháng liền. Khi báo chí địa phương đưa tin về "hàng loạt người già không hủy được gói", NhanhFood đối mặt với khủng hoảng truyền thông và bị cơ quan bảo vệ người tiêu dùng để mắt tới.

Bài học rút ra: Dark pattern "roach motel" kết hợp contrast kém và confirmshaming không chỉ là vấn đề đạo đức — nó nhắm trúng và gây tổn thương nặng nhất cho nhóm dễ tổn thương. Một luồng hủy accessible và trung thực đáng ra đã tránh được toàn bộ khủng hoảng.

Ví dụ 3 — Ngân hàng số và ARIA "làm cho có"

Một ngân hàng số giả định "TechBank" muốn nâng điểm accessibility trước một đợt audit nội bộ. Thay vì refactor các component, đội dev quyết định "rắc ARIA" khắp nơi: gắn role="button" vào đủ loại <div>, thêm aria-label cho mọi thứ, kể cả những phần tử trang trí. Kết quả điểm số trên một công cụ tự động (như axe) tăng lên vì bớt cảnh báo "thiếu label".

Nhưng khi một chuyên gia test thủ công bằng bàn phím và VoiceOver, thảm họa lộ ra: các <div role="button"> không nhận được focus bằng phím Tab, không kích hoạt bằng Enter/Space, và VoiceOver đọc ra một mớ aria-label dư thừa lặp đi lặp lại khiến người dùng không hiểu mình đang ở đâu.

Bài học rút ra: Điểm số công cụ tự động cao không đồng nghĩa với accessible. ARIA sai còn tệ hơn không có ARIA. Quy tắc vàng vẫn là: dùng đúng phần tử HTML gốc (<button>, <a>, <nav>) trước, chỉ dùng ARIA khi HTML không đủ.

Hướng dẫn từng bước

Dưới đây là quy trình để bạn phát hiện và xử lý anti-pattern trong một dự án:

• Kiểm tra sự tồn tại của overlay: Mở mã nguồn hoặc DevTools, tìm script từ các domain như accessibe.com, userway.org, audioeye.com. Nếu có, đây là dấu hiệu đỏ đầu tiên cần đưa lên bàn thảo luận.

• Test thật thay vì tin điểm số: Đừng dừng ở việc chạy axe hay Lighthouse. Rút phích chuột ra, chỉ dùng bàn phím đi hết luồng quan trọng (đăng nhập, thanh toán, hủy dịch vụ). Sau đó bật screen reader thật nghe xem có nghĩa không.

• Rà soát ARIA lạm dụng: Tìm mọi role="button", role="link" trên thẻ <div>/<span>. Hỏi: có thể thay bằng phần tử HTML gốc không? Nếu có, hãy thay.

• Soi các luồng "thoát": Kiểm tra luồng hủy đăng ký, đóng popup, từ chối cookie. Đảm bảo nút từ chối/hủy có contrast, kích thước, và ngôn từ ngang bằng với nút đồng ý — không confirmshaming, không nút giả.

• Viết lại accessibility statement trung thực: Nếu website có tuyên bố accessibility, đảm bảo nó phản ánh đúng thực trạng và có kênh liên hệ để người dùng báo lỗi.

• Đề xuất giải pháp gốc thay cho overlay: Khi tư vấn khách hàng bỏ overlay, hãy chuẩn bị lộ trình sửa mã nguồn thực sự — nếu không họ sẽ hoảng vì "mất lá chắn".

Lỗi thường gặp & mẹo

• Lỗi: Tin rằng "có accessibility còn hơn không". Sai — overlay sai lệch và ARIA hỏng có thể khiến trải nghiệm tệ hơn so với một trang HTML mộc mạc nhưng semantic. Đôi khi ít mà đúng thắng nhiều mà sai.

• Lỗi: Dùng công cụ tự động làm thước đo duy nhất. Công cụ chỉ bắt được khoảng 30–40% vấn đề WCAG. Phần còn lại — như alt text có ý nghĩa hay không, luồng logic có hợp lý không — cần con người kiểm tra.

• Mẹo: Học thuộc câu "No ARIA is better than bad ARIA" để bảo vệ quan điểm khi bị sếp thúc "cứ thêm ARIA cho nhanh".

• Mẹo: Khi phản đối overlay, dùng bằng chứng khách quan — dẫn Overlay Fact Sheet và số liệu vụ kiện thay vì chỉ nói "tôi thấy không ổn". Người ra quyết định cần dữ liệu.

• Mẹo: Phân biệt rõ dark pattern do cố ý với lỗi do vô tình. Cách xử lý khác nhau: lỗi vô tình thì sửa mã; dark pattern cố ý thì cần thuyết phục về đạo đức và rủi ro pháp lý/thương hiệu.

• Lỗi: Đánh đồng "compliance" với "accessible". Có thể pass checklist mà người thật vẫn không dùng được. Mục tiêu cuối là con người dùng được, không phải qua audit.

Bài tập thực hành

• Săn overlay: Tìm 3 website (trong nước hoặc quốc tế) có cài accessibility overlay widget. Với mỗi website, bật screen reader hoặc chỉ dùng bàn phím, ghi lại ít nhất một điểm mà overlay không giúp được hoặc gây cản trở.

• Audit ARIA: Chọn một component bạn từng code (hoặc một trang bất kỳ), mở DevTools và liệt kê mọi thuộc tính ARIA. Đánh dấu cái nào dư thừa hoặc có thể thay bằng HTML gốc. Viết lại một component theo hướng "ít ARIA hơn, đúng hơn".

• Phát hiện dark pattern: Đi qua luồng hủy đăng ký của 2 dịch vụ bạn đang dùng (app nhạc, app giao hàng, tạp chí online...). Ghi lại các dark pattern gặp phải (confirmshaming, nút contrast thấp, roach motel) và đề xuất phiên bản accessible, trung thực hơn cho từng cái.

• Viết luận điểm thuyết phục: Giả sử sếp bạn muốn mua overlay để "an toàn pháp lý". Viết một đoạn 150–200 từ thuyết phục họ đầu tư vào sửa mã nguồn thay vì overlay, có dẫn chứng cụ thể.

Tóm tắt

Bài học hôm nay là lời cảnh tỉnh: không phải mọi thứ gắn mác "accessibility" đều tốt. Accessibility overlay widget là anti-pattern nguy hiểm nhất — chúng hứa hẹn tuân thủ tức thì nhưng thường không sửa vấn đề gốc, xung đột với assistive technology thật, và tạo cảm giác an toàn pháp lý giả tạo. Bên cạnh đó là các anti-pattern nhỏ hơn như lạm dụng ARIA, placeholder thay label, hay tabindex dương.

Dark patterns — confirmshaming, nút giả, roach motel, đếm ngược giả — gây tổn thương nặng nhất đúng vào nhóm người dùng khuyết tật, và có thể kéo theo khủng hoảng thương hiệu lẫn rủi ro pháp lý.

Ba nguyên tắc để nhớ suốt đời: (1) Điểm số công cụ tự động cao không đồng nghĩa với accessible — luôn test thủ công bằng bàn phím và screen reader thật; (2) "No ARIA is better than bad ARIA" — ưu tiên HTML gốc; (3) Compliance không phải là accessible — mục tiêu cuối cùng luôn là con người thật sự dùng được sản phẩm. Là người làm design/dev tử tế, nhiệm vụ của bạn là biết nói "không" với những cái bẫy trông có vẻ đúng này.