Tiếng Việt: Compliance and accessibility testing

Compliance (tuân thủ quy định) và accessibility (khả năng truy cập) là hai mảng test mà đa số team QA né tránh — không phải vì nó khó về mặt kỹ thuật, mà vì nó đòi hỏi kiến thức pháp lý và chuẩn kỹ thuật (WCAG, GDPR, SOC 2...) mà QA thường không được đào tạo bài bản. Kết quả là compliance testing thường bị dồn hết vào một audit lớn trước release, làm qua loa bằng checklist copy từ Internet, hoặc bỏ qua hoàn toàn cho tới khi bị khách hàng doanh nghiệp hoặc luật sư "hỏi thăm". AI thay đổi cục diện này theo một hướng cụ thể: nó không thay bạn ra quyết định pháp lý hay đạo đức, nhưng nó rút ngắn đáng kể thời gian dịch một chuẩn (WCAG, GDPR, SOC 2) thành test case cụ thể, executable, gắn với hệ thống thật của bạn. Bài này đi sâu vào 4 kỹ năng: sinh test case WCAG 2.1/2.2, sinh test scenario GDPR/CCPA, xây và theo dõi checklist compliance, và kết hợp AI với kiểm thử thủ công bằng assistive technology (AT - công nghệ hỗ trợ) thật trong accessibility audit.

Làm Thế Nào Để Sinh Test Case Tuân Thủ WCAG 2.1/2.2 bằng AI?

Hiểu Khoảng Trống Trong Coverage Test WCAG

WCAG (Web Content Accessibility Guidelines - hướng dẫn về khả năng truy cập nội dung web) là chuẩn quốc tế định nghĩa thế nào là một website/app "accessible" (có thể sử dụng được bởi người khuyết tật). Chuẩn này được tổ chức theo 4 nguyên tắc gọi là POUR (Perceivable, Operable, Understandable, Robust — Cảm nhận được, Vận hành được, Hiểu được, Vững chắc), với hàng chục Success Criterion (tiêu chí thành công) cụ thể, mỗi tiêu chí có một trong 3 mức độ tuân thủ: A, AA, hoặc AAA.

Khoảng trống coverage phổ biến nhất mà QA gặp phải không phải là "không biết WCAG là gì", mà là: automated scanner (axe, WAVE, Lighthouse) chỉ phát hiện được khoảng 30-40% vấn đề accessibility thực tế — chủ yếu là lỗi có thể kiểm tra bằng cấu trúc DOM (thiếu alt text, thiếu label, contrast ratio sai). Những Success Criterion liên quan đến hành vi — thứ tự focus khi tương tác, thông báo lỗi có announce đúng cho screen reader không, gesture có thể thực hiện bằng bàn phím không — thì scanner không thể tự động phát hiện. Đây chính là vùng mà QA cần test case thủ công, và cũng chính là vùng AI có thể giúp sinh test case rất nhanh nếu được prompt đúng.

Một sai lầm thường gặp: team chỉ chạy automated scan, thấy "0 lỗi", rồi coi như đã pass WCAG. Thực tế "0 lỗi automated" chỉ có nghĩa là bạn đã pass được phần dễ đo, không có nghĩa là ứng dụng accessible.

Sinh Test Case WCAG 2.1 cho Một Component Cụ Thể

Cách hiệu quả nhất để dùng AI sinh test case WCAG không phải là hỏi chung "check WCAG cho app của tôi", mà là feed cho AI mô tả component cụ thể kèm tech stack, rồi yêu cầu nó map ra đúng Success Criterion áp dụng được.

ROLE: You are a senior accessibility QA engineer certified in WCAG 2.1.

## Component Description
Component: Multi-step checkout form (3 steps: shipping info, payment
info, order review). Step 2 (payment info) contains a credit card
number field with real-time format validation, and a promo code field
that shows an inline error message if the code is invalid.
Navigation between steps uses a "Next" and "Back" button; there is no
page reload between steps (SPA behavior).

## Technology
- Framework: React 18, custom form components (not native <form> per step)
- Styling: Tailwind CSS
- State management: React Context
- Target conformance level: WCAG 2.1 AA

TASK:
1. List every WCAG 2.1 Success Criterion (level A and AA) that is
   plausibly applicable to this component. For each one, give a
   1-sentence reason why it applies to THIS component specifically
   (not a generic definition).
2. For the 5 criteria most likely to fail in a React SPA form like
   this (focus management, error identification, status messages),
   write a full test case with columns:
   | Success Criterion | Level | Test Steps | Pass/Fail Criteria |
3. Do not include criteria that clearly do not apply (e.g., criteria
   about pre-recorded video) — explicitly state why you excluded them.

Output mẫu cho một hàng trong bảng test case (rút gọn để minh họa):

Mẹo: Khi feed component description cho AI, luôn nói rõ đây là SPA hay có reload trang — hành vi focus và announce khác biệt rất lớn giữa hai kiểu này, và AI thường mặc định giả sử hành vi trang tĩnh nếu bạn không nói rõ.

Sinh Test Case Cho Các Tiêu Chí Bổ Sung Của WCAG 2.2

WCAG 2.2 (ban hành 2023) bổ sung 9 Success Criterion mới so với 2.1, tập trung nhiều vào mobile, cognitive accessibility, và các pattern tương tác hiện đại (drag-and-drop, focus indicator). Đây là vùng nhiều team bỏ sót vì tài liệu nội bộ hoặc checklist cũ của họ chỉ dừng ở 2.1. Khi prompt AI, nên chỉ định rõ tên các tiêu chí mới để AI không lẫn với 2.1:

The application under test uses drag-and-drop to reorder items in a
kanban board, and has several sticky/floating UI elements (a chat
widget, a "back to top" button) that can obscure focused elements.

Generate WCAG 2.2-specific test cases (new criteria only, not
inherited from 2.1) for these two behaviors, specifically covering:
- 2.4.11 Focus Not Obscured (Minimum) — AA
- 2.5.7 Dragging Movements — AA
- 2.5.8 Target Size (Minimum) — AA

For each criterion, write a test case that includes a scenario where
the floating chat widget appears WHILE the user is tab-navigating
through the kanban board.

Ví dụ test case cho 2.5.7 Dragging Movements: kéo thẻ trong kanban board là một dragging movement — theo tiêu chí này, phải có cách thực hiện hành động tương đương (di chuyển thẻ) mà không cần thao tác kéo (ví dụ: menu "Move to column" xuất hiện khi nhấn phím Enter trên thẻ, hoặc nút mũi tên di chuyển). Test case phải verify được rằng đường thay thế này tồn tại và hoạt động đầy đủ bằng bàn phím, không chỉ verify thao tác kéo bằng chuột hoạt động tốt.

Xây Ma Trận Test WCAG Cho Toàn Bộ Ứng Dụng

Với một ứng dụng nhiều màn hình, việc lặp lại prompt cho từng component riêng lẻ không hiệu quả. Cách làm ở quy mô ứng dụng là đưa cho AI một bản mô tả tổng quan (application overview) — liệt kê các loại màn hình/pattern UI lặp lại trong app — rồi yêu cầu AI xây ma trận test WCAG cho từng nhóm pattern, tránh việc test trùng lặp cho các component giống nhau.

## Application Overview
Application: B2B SaaS dashboard. Screen inventory:
- 1 login/auth screen (email + password, OTP via SMS)
- 1 main dashboard with 6 draggable/resizable widget cards
- 1 data table screen with sort, filter, and inline row editing
- 3 modal-heavy workflows (create project, invite user, billing setup)
- 1 settings screen with toggle switches and a color-picker component
Target conformance: WCAG 2.1 AA + WCAG 2.2 AA new criteria.

TASK: Build a WCAG test coverage matrix. Group screens by shared UI
PATTERN (not by screen name) — e.g., "modal dialogs" as one group
covering all 3 modal workflows, "data table" as its own group.
For each pattern group, list:
1. The applicable Success Criteria (2.1 + 2.2)
2. The ONE representative screen/component to test per criterion
   (to avoid redundant testing of visually identical patterns)
3. Any criteria that need per-screen testing anyway despite pattern
   reuse (e.g., color-picker contrast is unique per screen)

Kỹ thuật nhóm theo pattern UI (không phải theo tên màn hình) là điểm mấu chốt — nó giúp bạn không phải test contrast 6 lần cho 6 modal có cùng CSS, mà chỉ cần test đại diện 1 lần rồi verify các modal khác dùng đúng component chung. Ở quy mô ứng dụng, luôn yêu cầu AI liệt kê rõ tiêu chí nào nó loại trừ và tại sao — một ma trận WCAG tốt không chỉ sinh ra test case, mà còn cho bạn thấy được logic suy luận, để bạn phản biện lại nếu AI loại trừ sai.

Làm Thế Nào Để Dùng AI Sinh Test Scenario GDPR và Data Privacy?

Các Hành Vi Có Thể Test Được Trong GDPR

GDPR (General Data Protection Regulation - quy định bảo vệ dữ liệu chung của EU) là văn bản pháp lý, không phải một checklist kỹ thuật — điều này khiến nhiều QA bối rối vì không biết "test cái gì" khi được giao nhiệm vụ verify GDPR compliance. Chìa khóa là tách các Article (điều khoản) của GDPR ra thành 2 nhóm: nhóm hành vi hệ thống có thể quan sát và verify được (data export, xóa dữ liệu, consent flag, thời hạn phản hồi), và nhóm quy trình pháp lý/tổ chức không thuộc phạm vi test kỹ thuật (ký DPA - Data Processing Agreement, hợp đồng xử lý dữ liệu, với vendor; đào tạo nhân viên).

QA chỉ nên tập trung vào nhóm đầu. Các Article phổ biến nhất có hành vi test được:

• Article 15 (Right of Access) — user có quyền yêu cầu xem toàn bộ dữ liệu cá nhân hệ thống đang lưu về họ.
• Article 17 (Right to Erasure / "quyền được xóa") — user có quyền yêu cầu xóa dữ liệu cá nhân, hệ thống phải thực sự xóa (không chỉ soft-delete/ẩn) trong khoảng thời gian hợp lý.
• Article 20 (Right to Data Portability) — user có quyền nhận dữ liệu của họ ở định dạng có cấu trúc, máy đọc được (structured, machine-readable format), thường là JSON/CSV.
• Article 7 (Conditions for Consent) — consent phải được thu thập rõ ràng, có thể rút lại (withdraw) dễ như khi cho.

Sinh Test Scenario GDPR bằng AI

Để AI sinh scenario chính xác, cần cung cấp system context (mô tả kỹ dữ liệu cá nhân hệ thống đang lưu ở đâu) và scenarios needed (nhóm Article cụ thể cần cover), tránh prompt chung khiến AI trả về danh sách generic không gắn với hệ thống thật.

ROLE: You are a QA engineer specializing in data privacy compliance
testing, working alongside (not replacing) legal counsel.

## System Context
Application: E-commerce platform. Personal data is stored across:
- users table (name, email, phone, hashed password)
- orders table (shipping address, linked to user_id)
- analytics_events table (behavioral tracking, linked to a
  pseudonymous device_id, occasionally joined to user_id after login)
- A third-party email marketing tool (Mailchimp) synced via webhook
  whenever a user opts into the newsletter
- Support tickets stored in Zendesk, linked by email address

## Scenarios Needed
Generate QA-testable scenarios for:
1. Article 15 (Right of Access) — data export request
2. Article 17 (Right to Erasure) — deletion request
3. Article 20 (Data Portability) — structured export

For each scenario, include:
- Preconditions (what data must exist before the test)
- Test steps a QA engineer can execute against a staging environment
- Expected outcome, explicitly calling out THIRD-PARTY systems
  (Mailchimp, Zendesk) that must also reflect the change
- The GDPR-mandated time limit for this Article, and how to verify
  the system enforces (or can be shown to enforce) that limit

Ví dụ scenario output cho Article 20 (rút gọn nhưng đầy đủ chi tiết kỹ thuật):

Scenario: Verify data export completeness within 30 days per Article 15/20
Precondition: User test-user-gdpr-01@example.com có: 3 order, 1 lần opt-in newsletter (đã sync Mailchimp), 12 analytics event trong 90 ngày qua, 2 support ticket trên Zendesk.
Steps:
1. Đăng nhập bằng tài khoản test, gọi API/UI "Request my data" (hoặc endpoint tương ứng nếu chưa có UI).
2. Ghi lại timestamp request được tạo.
3. Chờ tới khi hệ thống trả file export (qua email hoặc download link).
4. Mở file export, đối chiếu từng field với dữ liệu gốc trong users, orders, analytics_events.
5. Kiểm tra file export có bao gồm dữ liệu từ Mailchimp và Zendesk không (2 hệ thống bên thứ ba).
Expected outcome: File export ở định dạng JSON hoặc CSV (machine-readable, đúng Article 20), chứa đầy đủ dữ liệu từ cả 5 nguồn liệt kê ở System Context — không thiếu dữ liệu từ hệ thống bên thứ ba. File phải được gửi/sẵn sàng trong vòng 30 ngày kể từ timestamp request (theo yêu cầu "without undue delay, and in any event within one month" của GDPR Article 12(3)).
Ghi chú QA: Nếu team chưa build tự động hoá đủ 30 ngày, ít nhất phải verify quy trình manual hiện tại có SLA nội bộ ngắn hơn 30 ngày và có người chịu trách nhiệm theo dõi deadline.

Xử Lý Test Case GDPR Có Yếu Tố Thời Gian

Nhiều nghĩa vụ GDPR gắn với deadline cụ thể (30 ngày cho request truy cập, "without undue delay" cho breach notification tới cơ quan giám sát trong 72 giờ theo Article 33). Test case cho các nghĩa vụ này khó vì QA không thể ngồi chờ thật 30 ngày để verify. Kỹ thuật thực tế:

• Test cơ chế đếm ngược (deadline tracking), không test bằng cách chờ thật. Verify hệ thống có ghi timestamp request, có job/alert cảnh báo khi gần tới deadline (ví dụ cảnh báo ở ngày 25) — verify logic này bằng cách seed dữ liệu với created_at giả lập trong quá khứ (ví dụ 26 ngày trước), rồi kiểm tra alert có kích hoạt đúng không.
• Với breach notification 72 giờ (Article 33), test không phải là "gây ra một data breach thật", mà là verify quy trình — có runbook (quy trình xử lý sự cố viết sẵn), có escalation path (quy trình leo thang báo cáo lên đúng người chịu trách nhiệm), có cơ chế log thời điểm phát hiện breach để tính ngược 72 giờ.

Design a test approach (not real 30-day waiting) to verify that:
1. A GDPR data-access request older than 25 days automatically
   triggers an internal alert to the DPO/compliance owner.
2. A request older than 30 days is flagged as "SLA breached" in
   the admin dashboard.
Use time-travel/seeded timestamps in a staging environment instead
of waiting in real time. Describe how to seed the `created_at`
timestamp and what to assert at each seeded time point (day 1,
day 25, day 30, day 31).

Sinh Test Case CCPA và Đa Quy Định

CCPA (California Consumer Privacy Act - luật bảo vệ quyền riêng tư người tiêu dùng California) có nhiều điểm tương đồng với GDPR (quyền truy cập, quyền xóa) nhưng khác ở thuật ngữ và một số quyền đặc thù (quyền "opt-out of sale/sharing" dữ liệu cá nhân — không có khái niệm tương đương trực tiếp trong GDPR vì GDPR dựa trên consent chứ không phải opt-out). Khi ứng dụng phải tuân thủ nhiều quy định (GDPR cho user EU, CCPA cho user California), prompt hiệu quả nhất là yêu cầu AI đối chiếu song song để lộ ra phần trùng và phần khác biệt, tránh việc test 2 lần cho cùng một hành vi.

Compare GDPR (Article 15, 17, 20) and CCPA (Right to Know, Right to
Delete, Right to Opt-Out of Sale/Sharing) for THIS system (same
context as above). Output a table:
| Right | GDPR basis | CCPA basis | Shared test scenario? | Unique test needed |
Flag any right that CCPA requires but GDPR does not (e.g., opt-out
of sale), since our current deletion-flow tests do not cover it.

Mẹo: Đừng để AI tự suy diễn điều luật — luôn dán trực tiếp văn bản Article/Section liên quan (hoặc tóm tắt chính xác từ nguồn pháp lý) vào prompt. AI dễ "nhớ nhầm" số điều khoản hoặc thời hạn nếu chỉ dựa vào kiến thức nền, và sai số điều khoản trong tài liệu test là rủi ro nghiêm trọng khi audit.

Làm Thế Nào Để Sinh và Theo Dõi Checklist Tuân Thủ Quy Định bằng AI?

Sinh Tập Con Có Thể Test Được (QA-Testable Subset) Từ Một Chuẩn

Các chuẩn compliance đầy đủ (toàn văn PCI DSS - Payment Card Industry Data Security Standard, chuẩn bảo mật dữ liệu thẻ thanh toán; toàn văn SOC 2 Trust Services Criteria) thường dài hàng chục tới hàng trăm trang, phần lớn là control (biện pháp kiểm soát) về quy trình tổ chức, không phải thứ QA test bằng cách chạy hệ thống. Việc đầu tiên khi nhận một chuẩn mới là dùng AI để lọc ra đúng tập con QA có thể test, tránh lãng phí thời gian đọc toàn văn.

ROLE: You are a QA engineer, not a compliance officer. You test
system BEHAVIOR, not organizational policy.

## Our Application's Payment Context
Application: Online payment gateway integration for an e-commerce
platform. We store: tokenized card references (via Stripe, we do
NOT store raw PAN/CVV), transaction logs, and refund records.
Infrastructure: AWS, with a WAF in front of the API layer.
We are scoping PCI DSS v4.0 SAQ A-EP applicability.

TASK: From PCI DSS v4.0 requirements, extract ONLY the subset that
is QA-testable by exercising the running application (not policy
review, not physical security, not vendor contract review).
For each testable requirement, specify:
- The requirement ID and short description
- What a QA engineer can concretely test (API call, UI action, log
  inspection) to verify it
- What is explicitly OUT of scope for QA and belongs to security/ops
  (e.g., key management procedures, physical data center access)

Kỹ thuật này quan trọng vì nó giúp QA tránh 2 sai lầm đối lập: (1) bỏ qua compliance hoàn toàn vì "không phải việc của QA", hoặc (2) cố gắng test cả những control tổ chức nằm ngoài khả năng test bằng công cụ (như audit hợp đồng vendor).

Sinh Test Verify Control Cho SOC 2 Type II

SOC 2 Type II (System and Organization Controls - báo cáo kiểm soát hệ thống và tổ chức) khác SOC 2 Type I ở điểm mấu chốt: Type I chỉ verify control có tồn tại tại một thời điểm, còn Type II verify control hoạt động hiệu quả trong suốt một khoảng thời gian (thường 6-12 tháng) — nghĩa là test case không thể chỉ là "chụp màn hình 1 lần", mà phải verify được tính liên tục.

Ví dụ control phổ biến: Access Review Control — yêu cầu định kỳ (thường mỗi quý) rà soát lại quyền truy cập của toàn bộ nhân viên vào hệ thống production, gỡ quyền của người đã nghỉ hoặc đổi vai trò.

Design a SOC 2 Type II test for the "Quarterly Access Review"
control. The control states: "Access to production systems is
reviewed quarterly; access for terminated employees or role changes
is revoked within 5 business days of the review."

Generate a test plan that verifies OPERATING EFFECTIVENESS across
a full audit period (not a single point-in-time check), including:
1. How to sample multiple quarters within the audit period (not
   just the most recent one)
2. What evidence to collect per quarter (review sign-off records,
   access logs, HR termination dates)
3. How to test the 5-business-day revocation SLA specifically —
   compare HR termination date vs. actual access-revocation
   timestamp in the identity provider's audit log
4. What constitutes a control EXCEPTION (a failure) vs. an
   acceptable deviation

Điểm khác biệt cần nhấn với AI: test SOC 2 Type II gần với sampling và đối chiếu log lịch sử hơn là test hành vi hệ thống trực tiếp — vì vậy prompt phải yêu cầu rõ AI thiết kế cách lấy mẫu (sampling) qua nhiều kỳ, không chỉ kiểm tra trạng thái hiện tại.

Xây System Prompt Cho Hệ Thống Theo Dõi Test Compliance

Vì compliance testing lặp lại theo kỳ (mỗi quý, mỗi lần release lớn, mỗi audit hàng năm), việc tạo lại prompt từ đầu mỗi lần rất lãng phí. Cách làm bền vững là xây một system prompt cố định, đóng vai trò "bộ não" cho một trợ lý AI theo dõi checklist compliance liên tục, thay vì random 1 lần.

SYSTEM PROMPT (persistent assistant for compliance test tracking):

You are the Compliance Test Tracking Assistant for [Product Name].
You maintain a running registry of compliance controls across
GDPR, PCI DSS SAQ A-EP, and SOC 2 Type II Common Criteria.

For every control tracked, maintain these fields:
- control_id, standard, description
- test_frequency (one-time / quarterly / per-release / annual)
- last_tested_date, last_result (pass/fail/exception)
- evidence_location (link to test report or log export)
- owner (QA engineer responsible)

When asked to "check status", output a table sorted by control_id
showing which controls are OVERDUE for retesting based on
test_frequency and last_tested_date (today's date will be provided
in each request).

When given new test results, update the relevant row and flag any
control that has failed 2 consecutive testing cycles as
"ESCALATE — recurring control failure", since this suggests a
systemic (not one-off) issue.

Never mark a control as "pass" based on a partial test — require
explicit confirmation that ALL sampled periods/scenarios passed.

Đăng ký (registry) này có thể lưu trong một file JSON/CSV thật, được đưa vào lại context AI mỗi lần cần cập nhật — biến AI thành một "compliance dashboard" hội thoại được, giúp cả team dễ tra cứu trạng thái mà không cần mở tool riêng.

Mẹo: Đừng để AI tự "chấm pass" cho một control chỉ vì nó nhìn hợp lý — luôn ép AI liệt kê rõ evidence cụ thể (link log, screenshot, file export) trước khi ghi nhận pass; thiếu evidence nghĩa là chưa test xong, không phải test đạt.

Làm Thế Nào Để Kết Hợp Phân Tích AI với Kiểm Tra Thủ Công trong Accessibility Audit?

Mô Hình Audit Accessibility 3 Lớp

Accessibility audit đáng tin cậy không dựa vào một công cụ duy nhất, mà kết hợp 3 lớp bổ trợ cho nhau, mỗi lớp bù đắp điểm yếu của lớp trước:

Lớp 1 — Automated scan. Chạy công cụ (axe-core, Lighthouse, WAVE) trên toàn bộ ứng dụng, phát hiện lỗi cấu trúc rõ ràng (thiếu alt, thiếu label, contrast sai, thiếu lang attribute). Nhanh, rẻ, chạy được trong CI/CD, nhưng chỉ bắt được ~30-40% vấn đề thực tế và không đánh giá được trải nghiệm sử dụng.

Lớp 2 — AI-assisted manual review. QA (con người) thao tác thủ công qua ứng dụng bằng bàn phím và trình đọc màn hình cơ bản, đồng thời dùng AI để: (a) diễn giải kết quả automated scan thành ngôn ngữ hành vi dễ hiểu, (b) sinh ra danh sách kịch bản thao tác cần thử thủ công dựa trên các Success Criterion mà scanner không đo được, (c) phân tích code/DOM structure để dự đoán trước những nơi có khả năng gây khó khăn cho AT trước khi đưa cho người dùng thật kiểm tra. Lớp này lấp phần lớn khoảng trống của Lớp 1, nhưng vẫn là suy luận — chưa phải trải nghiệm thật của người dùng khuyết tật.

Lớp 3 — Real assistive-technology user testing. Người dùng thật, sử dụng AT thật hàng ngày (screen reader như JAWS/NVDA/VoiceOver, phần mềm điều khiển bằng giọng nói, switch device cho người khó vận động) thao tác trực tiếp trên ứng dụng. Đây là lớp duy nhất phát hiện được vấn đề về trải nghiệm thực tế — thứ tự đọc gây khó hiểu, thao tác về lý thuyết "đúng chuẩn" nhưng thực tế gây mệt/khó dùng. Không có công cụ hay AI nào thay thế được lớp này.

Ba lớp này nên chạy theo trình tự: automated scan chạy liên tục (mỗi PR/release), AI-assisted manual review chạy theo mỗi feature lớn, real AT user testing chạy theo mốc lớn hơn (mỗi quý hoặc trước major release) — vì chi phí và thời gian tổ chức cao hơn nhiều.

Dùng AI Để Lập Kế Hoạch Cho Giai Đoạn Test Bằng Assistive Technology

Trước khi mời người dùng AT thật vào test (Lớp 3), AI có thể giúp lập kế hoạch để buổi test hiệu quả hơn — không lãng phí thời gian của người tham gia vào những case đã được Lớp 1/2 xử lý.

We are planning a real AT user testing session (screen reader users
with NVDA and VoiceOver, plus one switch-device user) for our
checkout flow. Automated scan and AI-assisted manual review already
covered: missing alt text (all fixed), color contrast (all fixed),
basic keyboard-only navigation (passes).

Design a test session plan that:
1. Prioritizes scenarios that automated/manual review CANNOT
   reliably validate (e.g., whether the reading order after a
   dynamic price update makes logical sense to a screen reader user)
2. Gives each participant 3-5 realistic tasks (not isolated
   component checks) that mirror real purchase behavior
3. Specifies what to observe/record during the session (task
   completion, time taken, verbal frustration cues, number of times
   the user has to re-orient after an unexpected focus jump)
4. Avoids leading questions — draft neutral prompts to ask
   participants after each task

Việc yêu cầu AI loại trừ những gì đã được Lớp 1/2 xử lý là điểm quan trọng nhất — nó giúp thời gian quý giá của người dùng AT thật (thường khó tuyển và có chi phí cao) tập trung vào đúng những vấn đề chỉ họ mới phát hiện được.

Tích Hợp Phân Tích AI với Kết Quả Test AT

Sau buổi test AT thật, bạn sẽ có ghi chú thô: video quay lại, lời phàn nàn của người dùng, thời gian hoàn thành task. AI có thể giúp cấu trúc lại các ghi chú này thành finding rõ ràng, ánh xạ về đúng Success Criterion, nhưng không nên để AI tự "phát hiện vấn đề" thay cho người dùng thật — vai trò của AI ở bước này là hệ thống hóa, không phải khám phá.

Below are raw observation notes from a screen reader user testing
session (NVDA, checkout flow). Do not invent findings not present in
the notes. For each distinct issue mentioned:
1. Restate the issue in objective, testable language
2. Map it to the most likely relevant WCAG Success Criterion
3. Classify severity: Blocker (task failed) / Major (task completed
   with significant difficulty) / Minor (cosmetic/annoyance)
4. Note if multiple participants hit the same issue (higher
   confidence) vs. a single participant (needs verification)

RAW NOTES:
"""
[paste session notes/transcript here]
"""

Kỹ thuật này giúp việc chuyển từ ghi chú buổi test hỗn loạn sang báo cáo có cấu trúc nhanh hơn nhiều, nhưng luôn giữ nguyên tắc: AI không được thêm finding, chỉ được diễn giải và phân loại finding đã có từ người dùng thật.

Sinh Test Regression Accessibility từ Kết Quả AT

Sau khi một vấn đề được phát hiện qua test AT thật và được fix, cần một test regression để đảm bảo nó không tái xuất hiện ở lần release sau — và test này cần được viết cụ thể hơn một test case WCAG chung, vì nó bắt nguồn từ một trải nghiệm thật đã ghi nhận.

The following issue was found during real AT user testing and has
now been fixed:

ISSUE: After submitting the payment form with an invalid card
number, the error message appeared visually but was not announced
by NVDA — the screen reader user did not know an error occurred
and tried to submit again 3 times before noticing the red text.

FIX APPLIED: Error message container now has aria-live="assertive"
and receives programmatic focus on error.

Generate a regression test case (for the automated test suite,
using [specify tool: Cypress + axe-core / Playwright]) that would
have caught this issue BEFORE it reached real AT users, including
an assertion that verifies the aria-live region content changes
and is not just visually present.

Output mẫu mà AI có thể sinh ra cho prompt trên (Playwright + axe-core, dùng lại đúng bối cảnh lỗi ở trên):

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Payment form accessibility regressions', () => {
  test('invalid card error is announced to screen readers (fix for AT finding)',
    async ({ page }) => {
      await page.goto('/checkout/payment');

      // Trigger the error state with an invalid card number
      await page.locator('[data-testid="card-number-input"]').fill('1234');
      await page.locator('[data-testid="submit-payment"]').click();

      const errorRegion = page.locator('[data-testid="payment-error"]');

      // The container must be an aria-live region, not just red text
      await expect(errorRegion).toHaveAttribute('aria-live', 'assertive');
      await expect(errorRegion).toContainText(/invalid card number/i);

      // It must also receive programmatic focus so AT announces it immediately,
      // without the user needing to tab back to find it
      await expect(errorRegion).toBeFocused();

      // Guard against regressions axe-core itself might catch (e.g. missing role)
      const axeResults = await new AxeBuilder({ page })
        .include('[data-testid="payment-error"]')
        .analyze();
      expect(axeResults.violations).toHaveLength(0);
  });
});

Việc gắn liền test regression với chính bối cảnh phát hiện lỗi (không chỉ viết test chung "check aria-live tồn tại") giúp test có giá trị bảo vệ thực sự — vì nó verify đúng cái đã từng gây thất bại thật cho một người dùng thật, không phải một tiêu chí trừu tượng.

Mẹo: Sau mỗi buổi test AT thật, luôn hỏi ngược AI một câu: "Trong các finding trên, cái nào automated scan hoặc AI-assisted review LẼ RA có thể bắt được nếu được prompt tốt hơn?" — câu trả lời chính là cách bạn cải thiện Lớp 1/2 cho vòng audit kế tiếp, giảm dần số vấn đề phải chờ tới tận Lớp 3 mới phát hiện.