AVADA · TS ELITE
Training nội bộ · CS & TS

Accessibility:
WCAG, DFY và flow CS → TS sắp tới

Vì sao khách care accessibility (không chỉ đạo đức, mà là rủi ro kiện thật), app SEA giúp gì, và flow mới: CS phân tích checklist trước → cái nào fix được thì assign cho TS.

WCAG · ADA/EAA 4 nhóm owner Flow CS → TS mới Case kiện ADA thật
Vì sao buổi này quan trọng

Rủi ro pháp lý thật — không phải chuyện hình thức

Website bán hàng cần dùng được cho người khuyết tật — người mù/kém thị lực dùng screen reader (phần mềm đọc màn hình), người chỉ dùng bàn phím, người khó phân biệt màu.

Đây là rủi ro pháp lý + tiền thật, không phải checklist hình thức. Khách Mỹ hay bị kiện ADA. Sau buổi này, mỗi người cần phân biệt được "điểm SEA đẹp" và "thật sự đúng chuẩn pháp lý" — 2 thứ khác nhau.

Luật thật, rủi ro thật

WCAG AA = ngưỡng pháp lý thực tế. ADA (Mỹ), EAA (châu Âu).

4 nhóm owner rõ ràng

Mỗi lỗi scan ra thuộc đúng 1 nhóm — biết ai xử lý.

Flow mới: CS phân loại trước

CS phân tích checklist khách gửi → cái nào fix được thì giao cho TS.

01
Phần 1

Luật + app SEA
giúp được gì

Trước khi nói về flow xử lý, phải hiểu app SEA Accessibility tự làm được gì, và chỗ nào vẫn cần con người.

Bối cảnh pháp lý

WCAG là chuẩn, ADA/EAA là luật ép theo

WCAG

Web Content Accessibility Guidelines

Mức AA = ngưỡng thực tế

Chuẩn kỹ thuật quốc tế. Level AA là mức được toà công nhận phổ biến nhất.

ADA / EAA

Luật ép theo chuẩn

Rủi ro kiện thật

ADA (Mỹ), EAA (châu Âu). Khách Mỹ hay bị gửi demand letter pre-litigation.

SCORE

Cách app SEA chấm

≥90 = AA = rủi ro thấp

Scan trả về score + "AA / Not Compliant" + lawsuitRisk.

Thông điệp cốt lõi khi nói với khách: app + support giảm rủi ro rất nhiều nhưng "điểm SEA đẹp" ≠ "compliant pháp lý 100%" cho các lỗi chưa được fix thật trong code. Đừng hứa "đã fix / đủ compliant" khi thực tế mới chỉ "không bị trừ điểm".
App SEA Accessibility giúp gì

Scanner · Widget · Solved-by-SEA · AI

Bản đồ

Scanner

  • Quét storefront, tìm 18 tiêu chí WCAG
  • Chấm score + lawsuitRisk
Cho visitor

Widget

  • Contrast, cỡ chữ, font dễ đọc, TTS, profiles
  • KHÔNG sửa code trang — toà không coi là đủ compliant
Score-excluded

Solved by SEA

  • Contrast + target-size: đã LIVE
  • Focus + labels: đã build, CHƯA LIVE
No-code

AI gợi ý

  • Auto Alt Text (Scale plan)
  • Soạn sẵn aria-label/role cho theme
Support (CS + TS) làm phần còn lại: CS lo phần không cần code (alt text, tư vấn policy); TS lo sửa theme code (heading, aria, markup...) + nhóm chưa-live nếu khách cần gấp.
02
Phần 2

4 nhóm owner
mỗi lỗi rơi đúng 1 nhóm

Đây là khung phân loại quyết định "ai làm" — nền tảng cho toàn bộ flow CS → TS phía sau.

Khung phân loại

Solved-by-SEA · AI-text · Policy · Theme-code

Score-excluded

Solved by SEA

WCAG 1.4.11, 2.4.11, 2.5.8, 3.3.2. Badge tự động loại khỏi score. Contrast/target-size đã LIVE; focus/labels build xong chưa live — gấp thì vẫn cần theme.

CS

AI-text (no-code)

WCAG 1.1.1 (alt). AI soạn alt → CS đưa merchant dán Admin > Content > Files. Ảnh hardcode trong theme section → TS sửa .liquid.

CS tư vấn

Policy

WCAG 2.2.6, 3.3.4, 3.3.8. Quyết định nghiệp vụ/UX của merchant — CS tư vấn lựa chọn, không tự quyết thay khách.

TS

Theme-code

1.3.1, 1.4.13, 2.4.2, 3.1.1, 3.2.1, 3.2.2, 3.3.3, 4.1.1 + 4.1.2/4.1.3 (aria). AI soạn giá trị, TS áp vào theme.

Đừng hứa "bật overlay/widget là compliant". Widget panel visitor là tiện ích thật, nhưng heading/tooltip/lang/markup/aria vẫn là theme code — việc của TS.
Trong 18 tiêu chí scanner — vài ví dụ tiêu biểu

Mỗi lỗi, đọc score/tier là biết cách trả lời

AI-text

missing-alt — WCAG 1.1.1 (Critical)

Ảnh không có mô tả text, screen reader không biết đó là ảnh gì. Fix: bật Auto Alt Text (Scale plan) hoặc dán alt AI gợi ý vào Admin > Content > Files.

Theme-code

heading-structure — WCAG 1.3.1 (Critical)

H1 nhảy thẳng xuống H3/H4, bỏ qua cấp giữa. Screen reader + Google bị lẫn cấu trúc trang. Fix: đổi lại heading tag đúng thứ tự trong theme editor.

Solved by SEA

overlay-elements — WCAG 2.4.11 (Critical)

Focus indicator bị overlay khác che mất khi tab bằng bàn phím. Score-only — feature ghi đè đã build, chưa live; cần gấp thì vẫn phải sửa theme.

Merchant policy

no-confirmation — WCAG 3.3.4 (Critical)

Hành động quan trọng (đặt hàng, xoá) không có bước xác nhận. Quyết định UX của merchant — CS tư vấn thêm bước confirm, không tự ý sửa thay khách.

Chi tiết đủ 35 loại (severity + selector + fix): tài liệu accessibility-35-checklist.md. Đọc tier là biết ngay câu trả lời cho merchant — không cần thuộc lòng từng loại.
03
Phần 3

Flow sắp tới:
CS triage → assign TS

Về bản chất giống mô hình DFY hiện có: CS phân tích checklist khách gửi trước, cái nào fix được thì mới assign cho TS — thay vì mọi lỗi đổ thẳng sang TS.

Mô hình gốc — DFY (Done For You)

2 lớp xử lý mỗi case

Bước 1

Scan / nhận checklist

Lấy storefront URL, chạy scan hoặc đọc checklist khách gửi.

Lớp 1 — CS

CS audit

Báo nhóm Solved-by-SEA score-only, viết alt text (AI-text), tư vấn policy — không đụng code.

Lớp 2 — TS

TS escalate

Chỉ nhận nhóm Theme-code (gồm aria 4.1.2/4.1.3) — case CS đã lọc sẵn.

Điểm mấu chốt: TS không nhận raw checklist từ khách — chỉ nhận phần CS đã lọc là "theme-code, cần sửa thật". Đây chính là flow sắp tới, áp rộng hơn ra ngoài phạm vi DFY trả phí.
Luồng chuẩn từng bước

4 bước, mỗi case

  • 1 Lấy storefront URL (+ password nếu có gate)
  • 2 Scan: /scan-accessibility <url> hoặc POST /scan-page-agent (triage sẵn theo owner)
  • 3 Đọc kết quả → tách theo 4 nhóm owner: Solved-by-SEA báo không tính điểm · AI-text CS viết alt · Policy CS tư vấn · Theme-code escalate TS kèm handoff_note
  • 4 Báo merchant rõ ràng: "X lỗi không tính điểm, Y lỗi mình đưa alt để bạn dán, Z lỗi cần đội kỹ thuật sửa theme — đã chuyển."

API hỗ trợ:

/scan-accessibility <url>

Scan + report nhanh.

POST /scan-page-agent

Trả sẵn solved_by_sea / cs_layer / ts_escalation + handoff_note.

Focus mode

Thêm focusType/focusWcag → deep-dive 1 lỗi (root cause, fix, edge cases).

Flow sắp tới thay đổi gì

Cũ: khách → TS trực tiếp. Mới: khách → CS lọc → TS

Trước đây
Khách gửi checklist / báo lỗi
Escalate thẳng cho TS, kể cả phần không cần code
TS mất thời gian lọc lại việc nào thật sự thuộc mình
Flow sắp tới
CS phân tích checklist trước bằng scan/API MỚI
CS tự xử Solved-by-SEA / AI-text / Policy — chỉ những gì thật sự "theme-code" mới lên TS
TS nhận case đã lọc sẵn + handoff_note, làm đúng phần kỹ thuật
Nói cách khác: CS trở thành lớp triage đầu tiên cho mọi case a11y (không chỉ case DFY trả phí) — TS chỉ vào khi có việc code thật.
Thực tế về quyền

Recommend trước, đừng tự sửa khi chưa có quyền

Không cần quyền

  • Tư vấn policy (2.2.6, 3.3.4, 3.3.8)
  • Nhóm Solved-by-SEA score-only — chỉ cần giải thích, không thao tác
  • Alt text — merchant tự dán vào Admin của họ

Cần quyền edit theme

  • Nhóm Theme-code — thường không được cấp quyền trực tiếp
  • Default: đưa merchant đúng snippet/aria value để họ tự áp
  • Handoff kèm handoff_note để không mất context khi chuyển tay
Khi nào KHÔNG scan: câu hỏi thuần khái niệm (không URL) · than về config widget (không phải lỗi scan) · URL admin/backend · merchant đã gửi full output rồi.
Cảnh báo bắt buộc nhớ

Score đẹp KHÔNG đồng nghĩa đã fix xong

Điểm được cộng "trên giấy"

  • Nhóm Solved by SEA: điểm được cộng theo đúng mã WCAG — kể cả khi merchant đã tắt app embed/widget trên theme.
  • Nhóm AI-text: điểm được cộng ngay khi bật toggle Auto Alt Text — kể cả khi chưa có ảnh nào thật sự được sinh alt.

Vì vậy, luôn phải verify thật

Không bao giờ dùng số điểm làm bằng chứng duy nhất khi báo khách "đã xử lý xong". Trước khi báo khách, luôn kiểm tra: widget có thật sự đang chạy trên theme published không, và với nhóm AI-text — visitor bật Text to Speech thì alt có thật sự xuất hiện trên ảnh không.

Score đẹp mà widget đang tắt hoặc feature chưa sinh gì thật = CHƯA xong, dù report hiển thị đã cộng điểm.
Trước khi báo khách "đã xử lý xong"

Checklist verify — chạy đủ 4 bước, đúng thứ tự

  • 1 Xác nhận app embed đang bật trên theme published (Online Store > Themes > Customize > App embeds). Embed tắt → điểm vẫn cộng nhưng storefront không có fix nào thật — trạng thái nguy hiểm nhất khi trả lời khách.
  • 2 Re-scan lại đúng URL cũ. Danh sách lỗi cũ bị thay hoàn toàn bằng kết quả mới; những lỗi đã Mark as Solved vẫn giữ nguyên qua lần scan mới.
  • 3 Đối chiếu điểm với kỳ vọng: mỗi lỗi Critical chưa xử lý trừ 10, Moderate trừ 5, Minor trừ 1 — sàn điểm là 20. Lệch số → đừng vội báo khách, kiểm tra lại.
  • 4 Kiểm chứng thủ công trên storefront thật (tab ẩn danh): widget mở được popup · AI-text — bật Text to Speech rồi soi DevTools xem alt đã gắn chưa · theme-code — soi đúng chỗ vừa sửa (heading đúng cấp, thẻ lang có mặt, aria-label xuất hiện...).
Chỉ khi qua đủ 4 bước mới được báo khách "đã xử lý xong". Score đẹp mà bước 1 hoặc bước 4 fail = chưa xong.
Nút hay bị hiểu nhầm

Mark as Solved — dùng thận trọng, không phải để "làm đẹp điểm"

Ai được tick

  • Merchant tự tick. CS/TS gửi hướng dẫn (vị trí nút + căn cứ đã kiểm chứng) — không tick giùm khách.
  • Hiệu lực: lỗi bị loại khỏi tính điểm nhưng vẫn hiện trong danh sách, và trạng thái giữ nguyên qua các lần re-scan sau.

Chỉ dùng khi

  • Merchant xác nhận đã fix bằng cách khác ngoài app, và CS/TS đã tự kiểm chứng thủ công trên storefront.
  • Hoặc: đã cùng khách chạy bài kiểm tra thủ công cho các lỗi hay "báo nhầm" (Timeouts, On Focus, Error Prevention...) và xác nhận không có vi phạm thật.
KHÔNG dùng Mark as Solved chỉ để đáp ứng yêu cầu "cho điểm đẹp" của khách khi lỗi còn tồn tại thật — báo cáo sai lệch, không giảm rủi ro thực tế cho store.
04
Phần 4

Case thật
khách bị kiện ADA

2 ca thật tháng 6/2026 — cùng mức độ nghiêm trọng cao nhất: văn bản pháp lý thật, không phải than phiền thông thường.

Case thật · Mediriser · 6/2026

Khách bị kiện, đòi "giấy chứng nhận 100% compliant"

Tình huống

Khách đang bị kiện ADA thật, đã thuê dev tự sửa theo scanner, muốn Avada xác nhận store "100% WCAG 2.2 AA compliant" để nộp toà.

Xử lý đúng

KHÔNG cấp giấy chứng nhận pháp lý. Chỉ cấp technical review statement: đã scan, không phát hiện lỗi trong phạm vi rà soát — không phải legal certification. Việc pháp lý → escalate BA.

Bài học chính

  • "Marked as Solved" khách tự tick ≠ app confirm đã fix. Score 100 có thể gồm mục tự đánh dấu.
  • Fix xong phải re-scan — sửa 1 chỗ có thể lộ lỗi khác (thực tế: 84→60→90→70→100).
  • Email pháp lý gửi qua Crisp hiện như chat, không phải email chuẩn — văn bản chính thức phải gửi email thật.
  • Lỗi thật chính: 1.3.1 heading hierarchy skip cấp (H1→H4).
Case thật · Big Joe / ComfortResearch · 6/2026

Demand letter pre-litigation — map allegation → owner

Tình huống

Khách nhận pre-litigation demand letter ("Mueller v. ComfortResearch") qua email + USPS Certified Mail, kèm cảnh báo ESI preservation. Allegations ghi rõ "illustrative, not exhaustive".

Map allegation → WCAG → owner

"Ambiguous link text" → 2.4.4 (content, CS hướng dẫn) · "Hidden elements đọc blank" → 4.1.2 (TS, theme aria) · "Vague alt trên review images" → 1.1.1 nhưng ảnh do app review bên thứ 3 sinh ra → ngoại lệ, không sửa được ở Content > Files.

Playbook rút ra

  • Nhận diện văn bản pháp lý → escalate ngay BA + PM + ticket High risk. AI/CS không tư vấn pháp lý.
  • Khách trả phí + bị kiện → KHÔNG bảo khách "tự scan tự review". Chủ động review + sửa phần in-scope.
  • All-page scan có thể bị gate (nút greyed out) → CS bật DevZone cho khách trước.
  • Trả lời đúng scope: widget hỗ trợ visitor, nhưng không tự sửa HTML/ARIA hay alt text app bên thứ 3.
Kỹ năng quan trọng

Nhận diện false positive / ngoài scope theme

  • ! 2.2.6 Timeouts = Level AAA → không bắt buộc cho AA, đừng bắt khách fix vô ích.
  • ! 1.4.13 hover content từ component bên thứ 3 (vd Globo app) → ngoài theme, ngoài scope.
  • ! 3.2.1 On Focus = false positive nếu không có element đổi context khi focus.
  • ! Script của Shopify → ngoài theme-controlled code, không phải việc của TS.

Nguyên tắc trả lời

TS xác định + giải thích rõ cho khách tại sao đây không phải lỗi cần sửa (level AAA / component ngoài theme / false positive) — thay vì im lặng bắt khách tự fix những thứ vô ích. Đây cũng là kỹ năng CS cần có khi triage checklist trong flow mới, trước khi assign sang TS.

Tổng kết

App giảm rủi ro —
không thay được sửa code thật

Widget + score hỗ trợ rất nhiều, nhưng compliance pháp lý thật vẫn nằm ở theme code. Flow mới giúp CS lọc đúng việc trước khi tới TS — nhớ 4 nhóm owner, đừng hứa quá tay, và luôn re-scan sau khi fix.

4 nhóm owner CS triage → TS Không cấp legal cert Re-scan sau fix
1 / 18
Accessibility Training · 2026
← → chuyển slide · F fullscreen