Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa thiết kế xong một trang thanh toán tuyệt đẹp cho một sàn thương mại điện tử. Trên màn hình, mọi thứ hoàn hảo: nút "Đặt hàng" nổi bật, form nhập địa chỉ gọn gàng, dropdown chọn tỉnh thành mượt mà khi rê chuột. Bạn tự tin bàn giao. Rồi một tuần sau, bộ phận chăm sóc khách hàng nhận được phàn nàn: một người dùng khiếm thị, và một người dùng bị chấn thương cổ tay không dùng được chuột, cả hai đều không thể hoàn tất đơn hàng. Họ dùng bàn phím, và cái dropdown "mượt mà" kia của bạn — hóa ra chỉ mở được bằng chuột.
Đây chính là lý do kiểm thử bằng bàn phím thủ công (manual keyboard testing) là kỹ năng nền tảng, quan trọng bậc nhất mà bất kỳ ai làm về accessibility đều phải thành thạo. Nó là bài test rẻ nhất, nhanh nhất, và bắt được nhiều lỗi nghiêm trọng nhất. Bạn không cần cài phần mềm đắt tiền, không cần biết code sâu, không cần thiết bị đặc biệt. Bạn chỉ cần một bàn phím và khoảng 10 phút.
Vì sao bàn phím lại là "thước đo vàng"? Bởi vì rất nhiều nhóm người dùng phụ thuộc hoàn toàn vào nó: người khiếm thị dùng screen reader (screen reader điều hướng bằng bàn phím), người bị rối loạn vận động không điều khiển được chuột chính xác, người dùng chuyển mạch (switch device), và cả những người dùng power-user bình thường thích tốc độ của phím tắt. Nếu một tính năng hoạt động tốt bằng bàn phím, khả năng rất cao nó cũng ổn với nhiều công nghệ hỗ trợ khác. Ngược lại, nếu nó "chết" khi không có chuột, bạn đã dựng một bức tường vô hình chặn cả một nhóm người dùng ra khỏi sản phẩm của mình.
Ở các bài trước bạn đã học về Keyboard Navigation Patterns (Bài 11) và Focus Indicators (Bài 12) — đó là phần thiết kế cho bàn phím. Bài này tập trung vào phần kiểm chứng: làm sao để đích thân bạn ngồi xuống, dùng bàn phím, và phát hiện lỗi trước khi người dùng thật gặp phải.
Khái niệm cốt lõi
Kiểm thử bàn phím là gì và không phải là gì
Manual keyboard testing là quy trình bạn tự điều hướng qua toàn bộ giao diện chỉ bằng bàn phím, không chạm vào chuột hay trackpad, để kiểm tra xem mọi thứ có thể thao tác được không. Đây là kiểm thử thủ công (manual) — khác với công cụ tự động (automated) như axe hay Lighthouse ở Bài 37. Công cụ tự động rất giỏi bắt lỗi tĩnh (thiếu alt text, contrast kém), nhưng chúng không thể biết được liệu bạn có "mắc kẹt" trong một cái modal hay không, hay thứ tự tab có logic không. Những lỗi tương tác đó chỉ con người kiểm bằng tay mới thấy.
Bộ phím bạn cần biết
Toàn bộ việc kiểm thử xoay quanh một nhóm phím rất nhỏ:
- Tab — di chuyển tiêu điểm (focus) tới phần tử tương tác tiếp theo (link, nút, ô input...).
- Shift + Tab — di chuyển lùi về phần tử trước đó.
- Enter — kích hoạt link và thường là nút (button); gửi form.
- Space (dấu cách) — kích hoạt nút (button), tick checkbox, mở dropdown.
- Phím mũi tên (↑ ↓ ← →) — di chuyển bên trong một nhóm (radio buttons, tabs, menu, slider).
- Esc — đóng modal, dropdown, tooltip.
- Home / End — nhảy tới đầu/cuối trong một số component (danh sách, slider).
Ba khái niệm phải nắm chắc
Focus (tiêu điểm): là phần tử đang được "chọn" bởi bàn phím tại một thời điểm. Bạn phải luôn nhìn thấy nó đang ở đâu — đó là vai trò của focus indicator (viền sáng, đổi màu). Nếu bạn nhấn Tab mà không biết focus đang ở đâu, người dùng bàn phím cũng vậy — họ bị lạc.
Focus order (thứ tự tiêu điểm): thứ tự mà Tab di chuyển qua các phần tử. Nó phải theo trình tự logic, thường là từ trên xuống dưới, trái sang phải, giống như cách mắt đọc. Thứ tự nhảy lung tung (ví dụ nhảy từ header xuống footer rồi ngược lên giữa trang) khiến người dùng mất phương hướng hoàn toàn.
Keyboard trap (bẫy bàn phím): tình trạng focus bị "mắc kẹt" trong một khu vực và không thể Tab ra ngoài. Đây là lỗi cực kỳ nghiêm trọng — nó vi phạm trực tiếp WCAG 2.1.2 (No Keyboard Trap) và có thể khiến người dùng phải đóng cả trình duyệt để thoát. Bẫy bàn phím thường xuất hiện ở các widget nhúng như trình phát video, quảng cáo iframe, hoặc modal viết ẩu.
Tiêu chí WCAG liên quan trực tiếp
Kiểm thử bàn phím chính là cách bạn kiểm chứng ba tiêu chí WCAG cấp A quan trọng: 2.1.1 Keyboard (mọi chức năng phải thao tác được bằng bàn phím), 2.1.2 No Keyboard Trap (không được có bẫy), và 2.4.7 Focus Visible (tiêu điểm phải luôn nhìn thấy). Ba con số này bạn nên ghi nhớ vì khi báo cáo lỗi, việc trích dẫn đúng tiêu chí giúp đội dev hiểu mức độ nghiêm trọng.
Tình huống thực tế
Ví dụ 1 — Cái dropdown "chết" của sàn TMĐT
Một công ty thương mại điện tử tại TP.HCM (gọi là ShopViet) làm lại trang checkout. Đội thiết kế dùng một thư viện dropdown tùy chỉnh (custom <div> thay vì <select> gốc) để chọn Tỉnh/Thành. Trên demo, nó đẹp và mượt.
Khi QA ngồi xuống test bằng bàn phím, họ Tab tới ô "Tỉnh/Thành" — nhưng không có gì xảy ra. Nhấn Enter, Space, phím mũi tên: dropdown không mở. Hóa ra thư viện chỉ gắn sự kiện onClick (chuột) mà quên onKeyDown. Kết quả: 100% người dùng bàn phím không thể chọn địa chỉ, đồng nghĩa không thể đặt hàng. Đây là một lỗi chặn dòng doanh thu (revenue-blocking), không chỉ là lỗi accessibility.
Bài học: các component "custom" trông đẹp thường là ổ lỗi bàn phím lớn nhất, vì lập trình viên hay chỉ nghĩ tới chuột. Phần tử HTML gốc như <select>, <button> đã có hỗ trợ bàn phím sẵn — thay thế chúng bằng <div> là bạn tự nhận trách nhiệm dựng lại toàn bộ hành vi bàn phím, và rất dễ quên.
Ví dụ 2 — Cái bẫy trong modal đăng ký của ngân hàng số
Một ngân hàng số (giả định là TechBank) tung ra popup mời mở tài khoản. Modal hiện lên khi bạn vào trang chủ. Người dùng bàn phím Tab vào các ô trong modal bình thường, nhưng khi Tab tới nút cuối cùng rồi Tab tiếp — thay vì quay lại nút đầu modal, focus lại "chui" ra sau lưng modal, xuống các link ở trang nền phía dưới. Người dùng screen reader nghe trình đọc màn hình đọc nội dung đằng sau lớp phủ mờ, hoàn toàn rối loạn, và không có cách nào đóng modal bằng Esc vì nút đóng cũng không được lập trình cho phím.
Đây là hai lỗi kết hợp: thiếu focus trap (đúng ra focus phải bị giữ trong modal khi nó mở) và thiếu phím Esc để thoát. Người dùng bị kẹt trong một mê cung.
Bài học: Modal là trường hợp đặc biệt — đây là nơi duy nhất bạn muốn focus bị giữ lại (trong khi modal mở), nhưng phải luôn có lối thoát rõ ràng (Esc hoặc nút Đóng có thể focus). Kiểm thử modal luôn phải gồm: mở được bằng phím, Tab xoay vòng bên trong modal, Esc đóng được, và sau khi đóng focus quay về đúng nút đã mở nó. (Chi tiết pattern modal ở Bài 21.)
Ví dụ 3 — Focus vô hình trên trang tin tức
Một tòa soạn báo điện tử Việt Nam thiết kế lại giao diện với phong cách "tối giản". Nhà thiết kế thấy viền xanh mặc định của trình duyệt khi focus vào link "xấu", nên yêu cầu dev thêm dòng CSS outline: none cho toàn bộ trang. Kết quả: trang trông rất sạch, nhưng khi Tab qua các bài viết, hoàn toàn không có dấu hiệu nào cho biết focus đang ở đâu. Người dùng bàn phím như đi trong bóng tối, không biết mình đang chọn link nào.
Khi test thủ công, QA nhấn Tab liên tục và nhận ra mình mất dấu con trỏ ngay lập tức — một lỗi vi phạm WCAG 2.4.7.
Bài học: Đừng bao giờ xóa focus indicator mà không thay thế bằng một chỉ báo khác đẹp hơn (viền tùy chỉnh, đổi nền, gạch chân). "Xấu" không phải lý do để xóa — hãy thiết kế lại nó cho đẹp. Kiểm thử bàn phím phát hiện lỗi này trong vài giây.
Hướng dẫn từng bước
Dưới đây là quy trình chuẩn bạn có thể áp dụng cho bất kỳ trang nào.
Bước 1 — Chuẩn bị. Bỏ chuột ra khỏi tầm tay hoặc đặt tay ra sau lưng — nghe hơi kịch nhưng đây là mẹo tâm lý cực hiệu quả để bạn không "gian lận" bằng cách vô thức chạm chuột. Mở trang cần test, và đặt con trỏ chuột vào một góc màn hình để dễ theo dõi rằng bạn không dùng nó.
Bước 2 — Đặt focus vào đầu trang. Nhấp một lần vào thanh địa chỉ trình duyệt rồi nhấn Tab để nhảy vào trang (hoặc nhấn Tab từ đầu). Nếu trang có link "Skip to main content" (bỏ qua tới nội dung chính), phần tử đầu tiên bạn Tab tới thường chính là nó — đây là dấu hiệu tốt.
Bước 3 — Tab qua toàn bộ trang, quan sát bốn điều một lúc:
- Có nhìn thấy focus không? Mỗi lần nhấn Tab, bạn phải thấy rõ phần tử nào đang được chọn.
- Thứ tự có logic không? Focus di chuyển theo trình tự đọc tự nhiên chứ không nhảy cóc.
- Có phần tử nào bị bỏ sót không? Mọi thứ bấm được bằng chuột (link, nút, icon có chức năng) đều phải Tab tới được.
- Có phần tử "thừa" nào không? Những thứ không tương tác (đoạn văn, ảnh trang trí) không nên nhận focus.
Bước 5 — Test các component động. Mở mọi dropdown, modal, accordion, menu bằng bàn phím. Với mỗi cái, kiểm tra: mở được không, điều hướng bên trong được không, đóng bằng Esc được không, và sau khi đóng focus quay về đúng chỗ không.
Bước 6 — Săn keyboard trap. Cố tình Tab thật nhiều lần qua các khu vực nghi ngờ (video player, iframe quảng cáo, widget nhúng). Nếu bạn không thể Tab hoặc Shift+Tab ra khỏi một vùng nào đó, bạn đã tìm thấy một cái bẫy.
Bước 7 — Test cả chiều ngược. Nhấn Shift+Tab để đi lùi toàn trang. Thứ tự lùi phải là ảnh ngược của thứ tự tiến. Nhiều lỗi thứ tự chỉ lộ ra khi đi ngược.
Bước 8 — Ghi lại lỗi. Với mỗi lỗi, ghi rõ: trang/URL, phần tử nào, thao tác gì gây lỗi, kết quả mong đợi so với thực tế, và tiêu chí WCAG bị vi phạm (2.1.1, 2.1.2 hay 2.4.7). Kèm ảnh chụp màn hình nếu được.
Một checklist rút gọn để bạn dán lên màn hình:
- [ ] Mọi thứ bấm được bằng chuột đều Tab tới được.
- [ ] Focus luôn nhìn thấy rõ.
- [ ] Thứ tự Tab logic (cả tiến lẫn lùi).
- [ ] Enter/Space kích hoạt đúng phần tử.
- [ ] Không có keyboard trap.
- [ ] Modal/dropdown mở, điều hướng và đóng (Esc) được.
- [ ] Sau khi đóng overlay, focus quay về nút đã mở nó.
- [ ] Không có phần tử "ma" (không tương tác nhưng vẫn nhận focus).
Lỗi thường gặp & mẹo
Lỗi 1: Vô thức dùng chuột. Đây là cái bẫy lớn nhất với người mới. Bạn quen tay tới mức tự click mà không nhận ra. Mẹo: thật sự rút phích chuột hoặc để tay ra sau. Với trackpad laptop, có thể tạm tắt trackpad trong cài đặt hệ thống.
Lỗi 2: Nhầm giữa "trông có focus" và "thật sự có focus". Một số component tô sáng khi hover (rê chuột) chứ không phải khi focus (bàn phím). Vì bạn quen nhìn hiệu ứng hover, bạn tưởng nó ổn. Mẹo: chỉ tin vào những gì thay đổi khi bạn nhấn Tab, tuyệt đối không rê chuột trong lúc test.
Lỗi 3: Bỏ qua trạng thái ẩn. Menu con, tooltip, nội dung accordion khi đóng lại vẫn có thể chứa các phần tử focus được "ẩn" nhưng không thật sự bị loại khỏi luồng tab. Bạn sẽ Tab vào một khoảng "vô hình" — focus biến mất vào chỗ không nhìn thấy. Mẹo: nếu Tab một cái mà focus indicator biến mất nhưng số lần Tab vẫn tăng, khả năng cao có phần tử ẩn chưa được xử lý đúng (thường cần display: none hoặc thuộc tính phù hợp).
Lỗi 4: Chỉ test trên một trình duyệt. Hành vi bàn phím có khác biệt nhỏ giữa Chrome, Firefox, Safari (đặc biệt Safari trên macOS mặc định không Tab tới link — cần bật trong cài đặt hệ thống). Mẹo: test ít nhất trên hai trình duyệt, và biết rõ cấu hình Safari để không nhầm lẫn.
Lỗi 5: Test xong quên test lại sau khi sửa. Dev sửa một chỗ có thể vô tình làm hỏng thứ tự tab chỗ khác. Mẹo: kiểm thử bàn phím nên là một bước cố định trong quy trình, làm lại mỗi lần có thay đổi UI đáng kể — không phải chỉ làm một lần rồi thôi.
Mẹo vàng: hãy tập thói quen dùng bàn phím để duyệt web hàng ngày, kể cả trên các trang không phải của bạn. Sau vài tuần, mắt bạn sẽ tự động phát hiện lỗi focus ngay khi vừa Tab — kỹ năng này trở thành phản xạ chứ không còn là công việc.
Bài tập thực hành
Bài tập 1 — Test trang thật. Chọn một trang web bạn hay dùng (ví dụ trang chủ một tờ báo, một shop online Việt Nam). Rút chuột ra, Tab qua toàn bộ trang. Ghi lại theo checklist ở trên: có bao nhiêu phần tử bị mất focus indicator? Thứ tự tab có logic không? Có keyboard trap không? Viết một báo cáo ngắn 5-7 dòng.
Bài tập 2 — Săn modal. Tìm một trang có popup/modal (thường là popup mời đăng ký nhận tin). Kiểm tra bốn điều: (a) modal có được đóng bằng Esc không, (b) focus có bị giữ trong modal khi mở không, (c) khi đóng focus quay về đâu, (d) bạn có thể Tab ra trang nền phía sau khi modal đang mở không (nếu có thì đó là lỗi). Ghi lại kết quả.
Bài tập 3 — Viết báo cáo lỗi chuẩn. Chọn một lỗi bàn phím bạn tìm được ở bài 1 hoặc 2, viết thành một bug report hoàn chỉnh gồm: tiêu đề, URL, các bước tái hiện, kết quả mong đợi, kết quả thực tế, tiêu chí WCAG bị vi phạm, và mức độ nghiêm trọng. Đây chính là định dạng bạn sẽ dùng khi làm việc thật với đội phát triển.
Tóm tắt
Kiểm thử bàn phím thủ công là bài test accessibility rẻ nhất, nhanh nhất và giá trị nhất mà bạn có thể tự làm ngay hôm nay — chỉ cần bỏ chuột ra và nhấn Tab. Nó kiểm chứng ba tiêu chí WCAG cốt lõi: mọi thứ phải thao tác được bằng bàn phím (2.1.1), không có bẫy bàn phím (2.1.2), và focus luôn nhìn thấy được (2.4.7).
Quy trình gồm: chuẩn bị (bỏ chuột), Tab qua toàn trang quan sát bốn điều (thấy focus, thứ tự logic, không bỏ sót, không thừa), kích hoạt từng phần tử bằng Enter/Space, test các component động (modal, dropdown) với chu trình mở-điều hướng-đóng bằng Esc, săn keyboard trap, và test cả chiều ngược bằng Shift+Tab. Ba câu chuyện thực tế — dropdown chết của sàn TMĐT, bẫy modal của ngân hàng số, và focus vô hình của tòa soạn báo — cho thấy những lỗi này không phải lý thuyết mà đang chặn người dùng thật ra khỏi sản phẩm mỗi ngày.
Điều quan trọng nhất cần nhớ: nếu sản phẩm của bạn hoạt động tốt bằng bàn phím, bạn đã vượt qua rào cản lớn nhất của accessibility. Hãy biến việc nhấn Tab thành phản xạ hàng ngày, và bạn sẽ thấy lỗi trước khi người dùng của bạn phải chịu đựng chúng.