Bài 49 — Case Study: Banking App A11y

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

Ở Bài 48, chúng ta đã cùng nhau đi qua một audit accessibility (khả năng tiếp cận) cho website thương mại điện tử — nơi rủi ro lớn nhất là mất doanh thu và bỏ lỡ khách hàng. Bài 49 này bước sang một địa hình khắc nghiệt hơn nhiều: ứng dụng ngân hàng số.

Vì sao ngân hàng lại là "sân chơi khó" của accessibility? Ba lý do.

Thứ nhất, rủi ro tài chính trực tiếp. Nếu một người dùng khiếm thị nhấn nhầm nút, chuyển 50 triệu thay vì 5 triệu, hoặc không nghe được screen reader (trình đọc màn hình) đọc số dư còn lại, hậu quả không phải là "trải nghiệm tệ" mà là mất tiền thật. Không có ngành nào mà một lỗi a11y lại có thể quy đổi thẳng ra tiền mặt nhanh như ngân hàng.

Thứ hai, tệp người dùng của ngân hàng Việt Nam đang già hóa và đa dạng. Khác với app gọi xe hay mua sắm vốn nghiêng về Gen Z, khách hàng cốt lõi của ngân hàng bán lẻ Việt Nam tập trung mạnh ở nhóm 40–65 tuổi — những người có tài sản, có nhu cầu tiết kiệm, vay, đầu tư. Nhóm này thường gặp suy giảm thị lực do tuổi tác (presbyopia — lão thị), run tay, phản xạ chậm, và quen với giao dịch tại quầy hơn là màn hình cảm ứng. Khi ngân hàng "ép" họ lên app trong chiến lược mobile-first, accessibility trở thành yếu tố quyết định họ ở lại hay bỏ về quầy.

Thứ ba, áp lực pháp lý và bảo mật đè nặng lên nhau. Ngân hàng vừa phải tuân thủ WCAG (chuẩn accessibility) vừa phải tuân thủ các quy định của Ngân hàng Nhà nước về xác thực, eKYC, OTP. Hai yêu cầu này thường xung đột: cái làm cho app "an toàn" (OTP hết hạn nhanh, CAPTCHA, timeout phiên) lại thường là kẻ thù của người khuyết tật.

Bài học hôm nay là một case study xuyên suốt: chúng ta sẽ đóng vai đội thiết kế/a11y của một ngân hàng top 10 Việt Nam, đi qua từng luồng nghiệp vụ đặc thù của ngành và học cách gỡ những nút thắt mà chỉ ngân hàng mới có.

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

Bối cảnh case study

Hãy gọi ngân hàng của chúng ta là NamViet Bank — một ngân hàng thương mại cổ phần thuộc top 10 Việt Nam, giả định nhưng dựng trên các đặc điểm rất thật của thị trường. Năm 2024, ban lãnh đạo NamViet đặt mục tiêu mobile-first: đến cuối 2025, 70% giao dịch bán lẻ phải diễn ra trên app thay vì tại quầy hoặc Internet Banking cũ.

Các luồng nghiệp vụ chính của app:

• eKYC — định danh điện tử khi mở tài khoản (chụp CMND/CCCD, chụp khuôn mặt, xác thực liveness).
• Chuyển tiền — trong và ngoài hệ thống, quét QR, nhập số tài khoản, OTP.
• Tiết kiệm — mở sổ online, tất toán, xem lãi suất.
• Thẻ — mở/khóa thẻ, xem sao kê, thanh toán dư nợ.

Chân dung người dùng chủ đạo: 40–65 tuổi, nhiều người là công chức về hưu, tiểu thương, giáo viên. Đây chính là nhóm mà một app "đẹp nhưng khó dùng" sẽ đẩy họ quay lại quầy — làm hỏng cả chiến lược mobile-first lẫn bài toán chi phí vận hành.

Vì sao accessibility trong ngân hàng khác các ngành khác

Có bốn đặc thù mà bạn phải nắm khi làm a11y cho fintech/banking:

1. Xung đột giữa bảo mật và khả năng tiếp cận. OTP thường hết hạn sau 60–120 giây. Với người lớn tuổi mắt kém, phải chuyển qua tin nhắn SMS đọc mã, quay lại app gõ từng số — 120 giây là không đủ. Kết quả: OTP hết hạn, họ thử lại, lại hết hạn, cuối cùng bỏ cuộc hoặc gọi tổng đài. Đây là điểm ma sát số một.

2. Dữ liệu nhạy cảm, không thể "đọc bừa". Screen reader đọc to số dư tài khoản ở nơi công cộng là vấn đề quyền riêng tư. Nhưng nếu che số dư mặc định thì người mù lại không truy cập được. Cần thiết kế "privacy-aware" có chủ đích.

3. Con số là trung tâm. Ngân hàng đầy số: số tài khoản 12–14 chữ số, số tiền, ngày giao dịch, lãi suất. Cách screen reader đọc "50000000" rất khác "năm mươi triệu". Định dạng số cho accessibility là kỹ năng riêng.

4. Không được phép sai. Trong e-commerce, đặt nhầm hàng thì đổi trả. Trong ngân hàng, chuyển nhầm tiền thì gần như không lấy lại được. Vì vậy các bước xác nhận (confirmation) phải rõ ràng, đọc được, và không gây hiểu lầm cho mọi loại người dùng.

Bốn nhóm rào cản điển hình trong app ngân hàng

Khi NamViet chạy audit, đội a11y phân loại lỗi thành bốn cụm:

• Cụm eKYC: hướng dẫn chụp ảnh chỉ bằng hình động không có mô tả text; nút chụp không có nhãn; liveness yêu cầu "quay đầu sang trái" mà người khiếm thị không thực hiện được.
• Cụm nhập liệu số: ô nhập số tài khoản không gợi ý định dạng; bàn phím không tự bật kiểu số; lỗi validation hiện màu đỏ nhưng không đọc được.
• Cụm timeout & OTP: phiên và OTP hết hạn quá nhanh, không cảnh báo trước, không cho gia hạn.
• Cụm xác nhận giao dịch: màn hình "Xác nhận chuyển tiền" hiển thị số tiền bằng font nhỏ, screen reader đọc lộn xộn, người dùng không chắc mình đang chuyển bao nhiêu cho ai.

Bốn cụm này sẽ là khung xương cho phần thực hành phía dưới.

Tình huống thực tế

Tình huống 1 — Luồng OTP giết chết giao dịch của bác Sáu

Bác Sáu, 63 tuổi, giáo viên hưu trí, dùng iPhone của con tặng. Bác muốn chuyển 3 triệu học phí cho cháu. Bác nhập số tài khoản (mất 90 giây vì gõ chậm và soi từng số), nhấn "Chuyển", app gửi OTP qua SMS. Bác thoát app sang tin nhắn, đọc mã 6 số, quay lại app — nhưng ô nhập OTP đã báo "Mã hết hạn, vui lòng thử lại". Bác thử lần hai, cũng vậy. Lần ba, bác gọi cho con: "Cái app này nó không cho ba chuyển tiền".

Đội a11y của NamViet đo được: tỷ lệ bỏ dở giao dịch tại bước OTP ở nhóm trên 55 tuổi là 34%, gấp ba lần nhóm dưới 35 tuổi (11%). Nguyên nhân không phải bác Sáu "không biết dùng công nghệ" — mà là:

• OTP hết hạn sau 60 giây, tính cả thời gian SMS đến.
• Ô OTP không hỗ trợ autofill từ SMS (trên iOS là thuộc tính textContentType="oneTimeCode", trên web là autocomplete="one-time-code").
• Không có nút "Gửi lại mã" dễ thấy; nút bị nhỏ và đặt dưới cùng.

Cách khắc phục: NamViet nâng thời gian OTP lên 180 giây, bật autofill OTP (iOS tự gợi ý mã ngay trên bàn phím, không cần thoát app), phóng to nút "Gửi lại mã" đạt kích thước chạm tối thiểu 44×44 pt, và thêm dòng đếm ngược có aria-live="polite" để screen reader thông báo "Còn 30 giây" thay vì để mã âm thầm hết hạn. Sau ba tháng, tỷ lệ bỏ dở ở nhóm trên 55 tuổi giảm từ 34% xuống 12%.

Bài học rút ra: Bảo mật và accessibility không nhất thiết đối nghịch. Autofill OTP vừa an toàn hơn (giảm gõ nhầm, giảm nguy cơ đọc mã sai) vừa dễ tiếp cận hơn. Đừng mặc định "muốn an toàn thì phải khó dùng".

Tình huống 2 — Màn hình xác nhận chuyển tiền và người dùng screen reader

Anh Tuấn, 41 tuổi, kỹ sư IT, mất thị lực sau tai nạn, dùng VoiceOver (screen reader của iOS). Anh chuyển tiền hằng ngày cho công việc. Vấn đề: màn hình "Xác nhận giao dịch" của NamViet bản cũ hiển thị như sau về mặt code — người nhận, số tài khoản, số tiền, phí nằm trong các <div> rời rạc không có nhãn liên kết. VoiceOver đọc thành: "Nguyễn Văn A. 1 9 0 3 4 5 6 7 8 9. 5 0 0 0 0 0 0 0. 0. Xác nhận".

Anh Tuấn không thể chắc "50000000" là năm mươi triệu hay năm trăm nghìn, và "0" ở giữa là cái gì. Anh phải gọi tổng đài để xác nhận từng giao dịch — bất tiện và mất an toàn (đọc số dư qua điện thoại).

Cách khắc phục: Đội thiết kế viết lại màn hình xác nhận theo nguyên tắc "đọc như con người nói". Mỗi trường có nhãn rõ ràng và giá trị được định dạng ngữ nghĩa:

• "Người nhận: Nguyễn Văn A"
• "Số tài khoản: 1903456789" (đọc từng số có chủ đích, kèm nhãn)
• "Số tiền chuyển: 50.000.000 đồng — năm mươi triệu đồng"
• "Phí giao dịch: miễn phí"

Số tiền được gắn aria-label diễn giải bằng chữ ("năm mươi triệu đồng") bên cạnh hiển thị số. Toàn màn hình dùng landmark và heading để anh Tuấn "nhảy" thẳng tới phần số tiền mà không phải nghe lại từ đầu.

Bài học rút ra: Với dữ liệu tài chính, cách screen reader đọc con số quan trọng ngang với con số hiển thị. Một chuỗi số trần trụi là vô nghĩa và nguy hiểm. Hãy định dạng ngữ nghĩa và luôn diễn giải số tiền lớn bằng chữ.

Tình huống 3 — eKYC loại trừ người khiếm thị

Chị Lan, nhân viên văn phòng, hỗ trợ mẹ mình (khiếm thị hoàn toàn) mở tài khoản NamViet online để nhận lương hưu. Đến bước eKYC, app yêu cầu: "Nhìn thẳng vào camera", "Quay mặt sang trái", "Chớp mắt" — các lệnh liveness (chống giả mạo) hiển thị bằng animation không có mô tả âm thanh, và bản thân việc "nhìn thẳng camera" là bất khả thi với người mù. Mẹ chị Lan không thể tự hoàn tất; cuối cùng phải ra quầy — đúng thứ chiến lược mobile-first muốn tránh.

Đây là bài toán khó nhất và không có lời giải hoàn hảo, nhưng NamViet đã cải thiện đáng kể:

• Chuyển toàn bộ hướng dẫn liveness thành văn bản đọc được bởi screen reader kèm hướng dẫn bằng giọng nói (audio cue), thay vì chỉ animation.
• Thêm phản hồi haptic (rung) khi camera đã bắt đúng khuôn mặt, để người khiếm thị biết "giữ nguyên".
• Quan trọng nhất: cung cấp luồng thay thế (alternative path) — đặt lịch nhân viên gọi video hỗ trợ hoặc tới nhà xác minh, ngay trong app, thay vì buộc người dùng tự bơi.

Bài học rút ra: Không phải mọi rào cản a11y đều giải được thuần bằng kỹ thuật. Khi một luồng (như eKYC dựa trên thị giác) có giới hạn cố hữu, nghĩa vụ của bạn là cung cấp luồng thay thế tương đương chứ không phải bỏ mặc. Đây cũng là tinh thần cốt lõi của WCAG: luôn có con đường khác dẫn tới cùng kết quả.

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

Đây là quy trình audit a11y cho một app ngân hàng, đúc kết từ case NamViet. Bạn có thể áp dụng gần như nguyên xi cho bất kỳ fintech nào.

Bước 1 — Lập bản đồ luồng nghiệp vụ quan trọng (critical journeys). Đừng audit "cả app". Xác định 4–5 luồng sinh tử: đăng nhập, chuyển tiền, xem số dư/sao kê, mở tiết kiệm, eKYC. Đây là nơi lỗi a11y gây thiệt hại tài chính trực tiếp, ưu tiên tuyệt đối.

Bước 2 — Xây persona người dùng thật của ngân hàng. Với NamViet, tối thiểu ba persona: người lớn tuổi mắt kém + run tay (nhóm 40–65 đông nhất), người dùng screen reader hoàn toàn, và người khiếm khuyết vận động thao tác một tay. Mỗi persona sẽ soi ra một lớp lỗi khác nhau.

Bước 3 — Đi bộ qua từng luồng bằng ba "chế độ" kiểm thử. Với mỗi journey: (a) chỉ dùng bàn phím/switch, (b) chỉ dùng screen reader (VoiceOver/TalkBack), (c) phóng to chữ 200% và bật chế độ tương phản cao. Ghi lại mọi điểm tắc.

Bước 4 — Đặc biệt soi bốn "điểm nóng ngành ngân hàng": OTP/timeout, định dạng con số, màn hình xác nhận giao dịch, và eKYC. Đây là nơi các audit chung chung thường bỏ sót.

Bước 5 — Phân loại lỗi theo mức độ rủi ro tài chính, không chỉ theo mức WCAG. Một lỗi khiến người dùng chuyển nhầm số tiền là "chặn giao dịch" (blocker) dù về kỹ thuật chỉ là WCAG mức A. Ưu tiên theo hậu quả tiền bạc.

Bước 6 — Thiết kế luồng thay thế cho những rào cản không giải được bằng kỹ thuật (như eKYC thị giác). Luôn có "cửa sau" hợp lệ: hỗ trợ video, đặt lịch tại quầy trong app.

Bước 7 — Đo lại bằng số liệu kinh doanh. Không chỉ đếm lỗi WCAG. Đo tỷ lệ bỏ dở giao dịch theo nhóm tuổi, số cuộc gọi tổng đài liên quan a11y, tỷ lệ hoàn tất eKYC. Đây là ngôn ngữ mà ban lãnh đạo ngân hàng lắng nghe.

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

Lỗi 1 — Đối xử với người lớn tuổi như "người không biết dùng công nghệ". Nhóm 40–65 không kém thông minh; họ chỉ gặp rào cản thị lực, vận động và tốc độ. Đừng thiết kế "chế độ đơn giản cho người già" mang tính miệt thị. Hãy làm app tốt cho tất cả: chữ đủ lớn, nút đủ to, thời gian đủ rộng.

Lỗi 2 — Timeout cứng nhắc vì "bảo mật". Timeout phiên 60 giây nghe có vẻ an toàn nhưng thực ra đẩy người dùng khuyết tật ra ngoài. Mẹo: cho phép cảnh báo trước khi timeout kèm nút "Tôi vẫn ở đây" (WCAG 2.2.1). Bảo mật thật sự nằm ở xác thực mạnh, không phải ở việc phạt người dùng chậm.

Lỗi 3 — Che số dư mặc định nhưng nút "hiện" không có nhãn. Icon con mắt để ẩn/hiện số dư rất phổ biến, nhưng thường thiếu aria-label mô tả trạng thái ("Hiện số dư" / "Ẩn số dư"). Screen reader chỉ đọc "nút", người mù không biết đang bật hay tắt.

Lỗi 4 — Đọc số tài khoản như một số nguyên khổng lồ. "1903456789" bị screen reader đọc là "một tỷ chín trăm lẻ ba triệu...". Mẹo: với số tài khoản, tách thành cụm và dùng aria-label đọc từng chữ số, hoặc thêm khoảng trắng ngữ nghĩa.

Lỗi 5 — Validation lỗi chỉ báo bằng màu đỏ. "Số dư không đủ" hiện chữ đỏ nhưng không có role="alert", người mù chuyển tiền xong không biết vì sao thất bại. Luôn dùng vùng live region để thông báo lỗi giao dịch.

Mẹo vàng: Trong ngân hàng, hãy luôn tự hỏi "Nếu người dùng này không nhìn thấy màn hình, họ có chắc chắn 100% biết mình đang chuyển bao nhiêu tiền, cho ai không?". Nếu câu trả lời là "không chắc", bạn còn việc phải làm.

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

• Audit màn hình xác nhận chuyển tiền. Mở app ngân hàng bạn đang dùng, đi tới bước xác nhận chuyển tiền (dừng trước khi nhấn xác nhận thật). Bật VoiceOver/TalkBack và nghe. Ghi lại: screen reader đọc số tiền như thế nào? Có diễn giải bằng chữ không? Người nhận và số tài khoản có nhãn rõ không? Viết 3 đề xuất cải thiện.

• Đo luồng OTP. Bấm giờ toàn bộ hành trình từ lúc nhận OTP qua SMS đến lúc nhập xong, giả lập tốc độ của người 60 tuổi (gõ chậm, phải thoát app đọc tin nhắn). So sánh với thời gian hết hạn OTP của app. App có bật autofill OTP không? Đề xuất thời gian OTP hợp lý.

• Thiết kế luồng thay thế cho eKYC. Với NamViet giả định, hãy phác thảo một luồng eKYC thay thế dành cho người khiếm thị hoàn toàn: các bước, điểm chạm với nhân viên hỗ trợ, và cách vẫn đảm bảo yêu cầu định danh của Ngân hàng Nhà nước.

• Viết lại nhãn accessibility. Cho một nút ẩn/hiện số dư và một ô nhập số tài khoản, viết aria-label và các thuộc tính (inputmode, autocomplete) phù hợp để screen reader và bàn phím số hoạt động đúng.

Tóm tắt

• App ngân hàng là địa hình a11y khắc nghiệt nhất vì rủi ro tài chính trực tiếp, tệp người dùng già hóa (40–65 tuổi chiếm chủ đạo tại Việt Nam), và xung đột thường trực giữa bảo mật với khả năng tiếp cận.
• Bốn "điểm nóng" đặc thù ngành: OTP/timeout, định dạng con số, màn hình xác nhận giao dịch, và eKYC. Đây là nơi các audit chung chung hay bỏ sót.
• Ba case của NamViet cho thấy: nâng thời gian OTP + autofill giảm bỏ dở giao dịch từ 34% xuống 12%; định dạng số tiền ngữ nghĩa giúp người dùng screen reader tự tin chuyển tiền; và eKYC dựa trên thị giác cần luồng thay thế, không thể giải hết bằng kỹ thuật.
• Nguyên tắc audit: bám vào critical journeys, xây persona thật, kiểm thử bằng ba chế độ (bàn phím, screen reader, phóng to), ưu tiên lỗi theo hậu quả tài chính, và đo lại bằng số liệu kinh doanh chứ không chỉ đếm lỗi WCAG.
• Câu hỏi kim chỉ nam: "Nếu không nhìn màn hình, người dùng có chắc 100% biết mình chuyển bao nhiêu, cho ai không?".

Ở bài tiếp theo, chúng ta sẽ rời khỏi bối cảnh sản phẩm cụ thể để bàn về thiết kế cho môi trường mạng yếu và ngoại tuyến — một chủ đề cực kỳ liên quan tới trải nghiệm của chính những người dùng ngân hàng ở vùng nông thôn Việt Nam.