# เช็กลิสต์ WCAG 2.2 AA สำหรับผลิตภัณฑ์ SaaS และเว็บแอป

<https://www.fixreports.com/th/blog/wcag-2-2-checklist-saas-web-apps>

อัปเดต 2026-10-26

ผลิตภัณฑ์ SaaS มีพื้นผิวด้านการเข้าถึงสองส่วน คือเว็บไซต์การตลาดที่ใช้ขายผลิตภัณฑ์ และแอปพลิเคชันที่ผู้คนใช้งานทุกวัน เว็บไซต์การตลาดมีปัญหาแบบเดียวกับเว็บไซต์ทั่วไป เช่น คอนทราสต์ต่ำ ไม่มีข้อความ alt และฟอร์มที่ไม่มีป้ายกำกับ ส่วนแอปพลิเคชันมีปัญหาเฉพาะของตัวเองเพิ่มเข้ามา เช่น ขั้นตอนเข้าสู่ระบบที่บล็อกโปรแกรมจัดการรหัสผ่าน กล่องโต้ตอบที่กักโฟกัสคีย์บอร์ดไว้ การนำทางแบบหน้าเดียวที่โปรแกรมอ่านหน้าจอไม่รับรู้ ตารางข้อมูลและแผนภูมิที่ไม่มีข้อความ การลากวางที่ไม่มีทางเลือกอื่น และเซสชันที่หมดอายุโดยไม่มีการเตือน เช็กลิสต์นี้ไล่ตาม WCAG 2.2 ระดับ AA ตามส่วนต่างๆ ของผลิตภัณฑ์ SaaS ทั่วไป

**ประเด็นสำคัญ**

- WCAG 2.2 ได้เป็น W3C Recommendation ในเดือนตุลาคม 2023 และเพิ่มเกณฑ์ความสำเร็จ 9 ข้อ ซึ่ง 6 ข้ออยู่ในระดับ A หรือ AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/))
- Accessible Authentication (3.3.8, AA) หมายความว่าการเข้าสู่ระบบต้องไม่ขึ้นอยู่กับการจำหรือพิมพ์รหัสผ่านตามที่เห็น เว้นแต่ผู้ใช้จะวางรหัสผ่านหรือใช้โปรแกรมจัดการรหัสผ่านได้ ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum))
- เป้าหมายที่โต้ตอบได้ต้องมีขนาดอย่างน้อย 24 × 24 พิกเซล CSS หรือมีพื้นที่รอบๆ เพียงพอ (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum))
- ข้อความอย่าง “บันทึกแล้ว” หรือ “3 ผลลัพธ์” ต้องส่งถึงโปรแกรมอ่านหน้าจอโดยไม่ย้ายโฟกัส (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages))
- ผู้ซื้อภาคธุรกิจและภาครัฐมักขอ Accessibility Conformance Report ซึ่งมักจัดทำบนเทมเพลต VPAT ของ Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat))

## ทำไมการเข้าถึงจึงสำคัญกับ SaaS มากกว่าเว็บไซต์แนะนำบริษัท

ผู้คนใช้ผลิตภัณฑ์ SaaS ครั้งละหลายชั่วโมง และมักเป็นเพราะนายจ้างเลือกให้ใช้ อุปสรรคบนหน้าการตลาดทำให้เสียผู้เข้าชมหนึ่งคน แต่อุปสรรคในผลิตภัณฑ์อาจทำให้ใครสักคนทำงานของตัวเองไม่ได้ นี่คือเหตุผลที่ลูกค้ารายใหญ่ มหาวิทยาลัย และหน่วยงานภาครัฐถามเรื่องการเข้าถึงก่อนซื้อมากขึ้นเรื่อยๆ และเหตุผลที่คำตอบต้องครอบคลุมแอปพลิเคชัน ไม่ใช่แค่เว็บไซต์

อีกเหตุผลหนึ่งคือการทดสอบอัตโนมัติจับปัญหาได้เพียงบางส่วน เครื่องมืออย่าง axe-core หาปัญหาใน markup ได้ เช่น ป้ายกำกับที่ขาดหายและคอนทราสต์ต่ำ แต่บอกไม่ได้ว่ากล่องโต้ตอบคืนโฟกัสไปยังตำแหน่งที่ถูกต้องหรือไม่ ข้อมูลของแผนภูมิมีให้ในรูปข้อความหรือไม่ หรือขั้นตอนการทำงานหนึ่งๆ ทำจนจบด้วยคีย์บอร์ดได้หรือไม่ แอปพลิเคชันจึงต้องมีทั้งการตรวจอัตโนมัติและการทดสอบด้วยคน

## ทำให้การสมัครใช้งานและการเข้าสู่ระบบเข้าถึงได้อย่างไร

การยืนยันตัวตนคือส่วนที่ WCAG 2.2 เพิ่มข้อกำหนดใหม่ที่สำคัญที่สุดสำหรับ SaaS

- **อนุญาตให้วางข้อความและใช้โปรแกรมจัดการรหัสผ่าน (3.3.8, AA)** อย่าบล็อกการวางในช่องรหัสผ่านหรือช่องรหัสยืนยัน และใช้ `autocomplete="username"`, `autocomplete="current-password"` และ `autocomplete="one-time-code"` เพื่อให้เบราว์เซอร์และโปรแกรมจัดการรหัสผ่านกรอกให้ได้
- **อย่าใช้ปริศนาเป็นทางเข้าเพียงทางเดียว** CAPTCHA ที่ให้พิมพ์ตัวอักษรที่บิดเบี้ยวหรือแก้ปริศนาถือเป็นการทดสอบการทำงานของสมอง (cognitive function test) ให้มีทางเลือกอื่น และเลือกใช้การตรวจที่ไม่ต้องให้ผู้ใช้ทำอะไร ([W3C](https://www.w3.org/TR/turingtest/))
- **ใส่ป้ายกำกับให้ทุกช่อง (1.3.1 และ 3.3.2, A)** ใช้ `<label>` ที่มองเห็นได้และเชื่อมกับช่องกรอก ข้อความ placeholder จะหายไปเมื่อเริ่มพิมพ์และไม่ใช่ป้ายกำกับ
- **ระบุข้อผิดพลาดเป็นข้อความ (3.3.1, A) และเสนอวิธีแก้ (3.3.3, AA)** ข้อความ “รหัสผ่านต้องมีอย่างน้อย 12 อักขระ” ช่วยได้ แต่ขอบสีแดงเพียงอย่างเดียวช่วยไม่ได้
- **อย่าถามซ้ำ (3.3.7, A)** หากการสมัครแบบหลายขั้นตอนถามชื่อบริษัทหรือที่อยู่ไปแล้ว ให้กรอกให้อัตโนมัติหรือให้ผู้ใช้เลือกแทนการพิมพ์ใหม่
- **วางความช่วยเหลือไว้ที่เดิม (3.2.6, A)** หากคุณมีแชต ลิงก์ความช่วยเหลือ หรือข้อมูลติดต่อ ให้วางไว้ในตำแหน่งสัมพัทธ์เดียวกันในทุกหน้าของขั้นตอนนั้น

## รูปแบบฟอร์มและข้อผิดพลาดแบบใดทำให้เกิดปัญหามากที่สุด

ปัญหาส่วนใหญ่ของแอปพลิเคชันอยู่ในฟอร์ม แบบสำรวจของ WebAIM ปี 2026 กับหน้าแรก 1 ล้านหน้าพบว่า 51% ไม่มีป้ายกำกับฟอร์ม ([WebAIM](https://webaim.org/projects/million/)) และแอปพลิเคชันมีฟอร์มมากกว่าหน้าแรกหลายเท่า

- ให้ช่องกรอกทุกช่องมีชื่อที่โปรแกรมอ่านได้ (programmatic name) และจัดกลุ่มตัวควบคุมที่เกี่ยวข้องกัน เช่น ปุ่มตัวเลือก ด้วย `<fieldset>` และ `<legend>`
- แจ้งข้อผิดพลาดในตำแหน่งที่ผู้ใช้จะสังเกตเห็น เช่น ย้ายโฟกัสไปที่สรุปข้อผิดพลาดด้านบนฟอร์ม หรือไปที่ช่องแรกที่ไม่ถูกต้อง และลิงก์รายการในสรุปแต่ละรายการไปยังช่องของมัน
- ระบุช่องที่จำเป็นเป็นข้อความ ไม่ใช่ใช้สีเพียงอย่างเดียว (1.4.1, A)
- อย่าส่งฟอร์มหรือเปลี่ยนบริบทเพียงเพราะผู้ใช้เลือกตัวเลือก (3.2.2, A) ให้รอการกระทำที่ชัดเจน

## กล่องโต้ตอบ เมนู และป๊อปโอเวอร์ควรทำงานอย่างไร

คอมโพเนนต์ที่สร้างขึ้นเองเป็นจุดที่การรองรับคีย์บอร์ดและโปรแกรมอ่านหน้าจอเสียบ่อยที่สุด WAI-ARIA Authoring Practices Guide อธิบายพฤติกรรมที่ควรเป็นของแต่ละรูปแบบไว้ ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/))

- **กล่องโต้ตอบ**: ย้ายโฟกัสเข้าไปในกล่องเมื่อเปิด ให้ Tab วนอยู่ภายในขณะที่เปิดอยู่ ปิดได้ด้วย Escape และคืนโฟกัสไปยังตัวควบคุมที่เปิดกล่องนั้น ใช้องค์ประกอบ `<dialog>` ของเบราว์เซอร์ หรือ `role="dialog"` พร้อม `aria-modal="true"` และชื่อ
- **ไม่มีกับดักคีย์บอร์ด (2.1.2, A)**: ทุกคอมโพเนนต์ต้องออกได้ด้วยคีย์บอร์ด
- **โฟกัสที่มองเห็นได้ (2.4.7, AA)** และไม่ถูกบังด้วยส่วนหัวแบบติดหน้าจอ แบนเนอร์คุกกี้ หรือวิดเจ็ตแชต (2.4.11, AA ซึ่งเพิ่มใหม่ใน 2.2)
- **Tooltip และป๊อปโอเวอร์ (1.4.13, AA)** ที่ผู้ใช้ปิดได้ด้วย Escape ชี้เมาส์ไปบนนั้นได้โดยไม่หายไป และยังแสดงอยู่จนกว่าจะปิด
- **คีย์ลัดแบบปุ่มเดียว (2.1.4, A)**: หากการกดปุ่มตัวอักษรทำให้เกิดการกระทำ ให้ผู้ใช้ปิดหรือกำหนดคีย์ลัดใหม่ได้ หรือให้คีย์ลัดทำงานเฉพาะเมื่อคอมโพเนนต์ที่เกี่ยวข้องได้รับโฟกัส

## จัดการการนำทางในแอปแบบหน้าเดียวอย่างไร

ในแอปแบบหน้าเดียว (single-page app) URL จะเปลี่ยนโดยไม่โหลดหน้าใหม่ โปรแกรมอ่านหน้าจอจึงอาจไม่ประกาศว่ามีอะไรเกิดขึ้น

- อัปเดตชื่อเอกสาร (document title) ทุกครั้งที่เปลี่ยนเส้นทาง เพื่อให้ทุกมุมมองมีชื่อที่สื่อความหมาย (2.4.2, A)
- ย้ายโฟกัสไปที่หัวข้อหลักของมุมมองใหม่ หรือประกาศการเปลี่ยนแปลงใน live region แบบ polite เฟรมเวิร์กอย่าง Next.js มีตัวประกาศเส้นทาง (route announcer) สำหรับเรื่องนี้
- รักษาลำดับโฟกัสให้สมเหตุสมผล (2.4.3, A) หลังลบรายการใด โฟกัสควรไปยังรายการข้างเคียงที่เหมาะสม ไม่ใช่กลับไปด้านบนสุดของหน้า
- มีวิธีข้ามการนำทางที่ซ้ำกัน (2.4.1, A) เช่น ลิงก์ข้าม (skip link) หรือ landmark

## ทำให้แดชบอร์ด ตารางข้อมูล และแผนภูมิเข้าถึงได้อย่างไร

- **ตาราง**: ใช้ markup `<table>` จริงพร้อม `<th>` และ `scope` สำหรับส่วนหัว และมีคำอธิบายตาราง (1.3.1, A) กริดที่สร้างจากองค์ประกอบ `<div>` ต้องใช้รูปแบบ ARIA grid แบบเต็ม ซึ่งทำให้ถูกต้องได้ยากกว่ามาก
- **แผนภูมิ**: ให้แผนภูมิแต่ละอันมีข้อความทดแทนที่บอกประเด็นหลัก และมีข้อมูลในรูปตาราง (1.1.1, A) อย่าใช้สีเพียงอย่างเดียวในการแยกชุดข้อมูล (1.4.1, A) ให้เพิ่มป้ายกำกับหรือลวดลาย
- **คอนทราสต์**: ข้อความต้องได้ 4.5:1 (1.4.3, AA) ส่วนเส้นในแผนภูมิ ไอคอน และเส้นขอบช่องกรอกต้องได้ 3:1 เทียบกับพื้นหลัง (1.4.11, AA) ตรวจโหมดมืดแยกต่างหาก [เครื่องมือตรวจสอบคอนทราสต์สี](/th/color-contrast-checker) ของเราทดสอบคู่สีได้ทุกคู่
- **ข้อความสถานะ (4.1.3, AA)**: “บันทึกแล้ว” “อัปโหลดเสร็จแล้ว” และจำนวนผลลัพธ์ควรใช้ `role="status"` หรือ live region เพื่อให้โปรแกรมอ่านหน้าจอได้ยินโดยไม่เสียตำแหน่งที่อ่านอยู่

## เกณฑ์ใหม่ของ WCAG 2.2 เปลี่ยนอะไรสำหรับเว็บแอป

| เกณฑ์ | ระดับ | ความหมายในแอป |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | แถบเครื่องมือแบบติดหน้าจอ แบนเนอร์ และวิดเจ็ตแชตต้องไม่บังองค์ประกอบที่ได้รับโฟกัสจนมิด |
| 2.5.7 Dragging Movements | AA | ทุกอย่างที่ทำด้วยการลาก เช่น การจัดลำดับบอร์ดคัมบัง ต้องมีทางเลือกที่ใช้ตัวชี้เพียงจุดเดียว เช่น เมนูหรือปุ่มเลื่อนขึ้นและลง |
| 2.5.8 Target Size (Minimum) | AA | ปุ่มและลิงก์ขนาดอย่างน้อย 24 × 24 พิกเซล CSS หรือเว้นระยะจนวงกลมขนาด 24 พิกเซลรอบแต่ละอันไม่ทับกัน |
| 3.2.6 Consistent Help | A | ลิงก์ความช่วยเหลือ แชต และข้อมูลติดต่ออยู่ในตำแหน่งสัมพัทธ์เดียวกันในทุกหน้า |
| 3.3.7 Redundant Entry | A | ข้อมูลที่กรอกไปแล้วในกระบวนการเดียวกันจะถูกกรอกให้หรือเลือกได้ |
| 3.3.8 Accessible Authentication (Minimum) | AA | เข้าสู่ระบบได้โดยไม่ต้องจำหรือพิมพ์ตามที่เห็น เว้นแต่อนุญาตให้วางข้อความ ใช้โปรแกรมจัดการรหัสผ่าน หรือวิธีอื่น |

WCAG 2.2 ยังตัด 4.1.1 Parsing ออก เพราะไม่มีผลในทางปฏิบัติต่อการเข้าถึงแล้ว ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/))

## แล้วเรื่องการหมดเวลา เลย์เอาต์ และการซูมล่ะ

- **การหมดเวลาของเซสชัน (2.2.1, A)**: เตือนผู้ใช้ก่อนเซสชันหมดอายุ และให้ขยายเวลาได้ด้วยการกระทำง่ายๆ เว้นแต่การจำกัดเวลานั้นจำเป็นหรือยาวกว่า 20 ชั่วโมง การบันทึกงานที่ทำค้างไว้ช่วยป้องกันผลที่แย่ที่สุด
- **การจัดเรียงใหม่ (1.4.10, AA)**: เนื้อหาต้องใช้งานได้ที่ความกว้าง 320 พิกเซล CSS (เทียบเท่าการซูม 400% บนหน้าจอ 1280 พิกเซล) โดยไม่ต้องเลื่อนสองทิศทาง ตารางข้อมูลและเนื้อหาลักษณะเดียวกันได้รับการยกเว้น
- **ระยะห่างของข้อความ (1.4.12, AA)**: การเพิ่มความสูงบรรทัดและระยะห่างตัวอักษรต้องไม่ทำให้ข้อความถูกตัด ซึ่งมักเกิดกับกล่องที่กำหนดความสูงตายตัว
- **การวางแนวหน้าจอ (1.3.4, AA)**: อย่าล็อกแอปไว้ที่แนวตั้งหรือแนวนอน เว้นแต่จำเป็น

## ACR คืออะไร และคุณจำเป็นต้องมีหรือไม่

Accessibility Conformance Report (ACR) บันทึกว่าผลิตภัณฑ์ทำตามเกณฑ์การเข้าถึงแต่ละข้ออย่างไร ได้แก่ รองรับ รองรับบางส่วน หรือไม่รองรับ พร้อมหมายเหตุ ส่วนใหญ่จัดทำบนเทมเพลต VPAT ที่เผยแพร่โดย Information Technology Industry Council ซึ่งมีฉบับสำหรับ WCAG มาตรฐาน Section 508 ของสหรัฐฯ และมาตรฐานยุโรป EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat))

หน่วยงานรัฐบาลกลางของสหรัฐฯ ต้องซื้อเทคโนโลยีที่เข้าถึงได้ตาม Section 508 ([Section508.gov](https://www.section508.gov/)) และหน่วยงานภาครัฐในสหภาพยุโรปอ้างอิง EN 301 549 ผลิตภัณฑ์ B2B ที่ขายให้ลูกค้าเหล่านี้จึงมักถูกขอ ACR ในขั้นตอนจัดซื้อ ACR ที่ซื่อตรงและระบุช่องโหว่ที่ทราบไว้มีประโยชน์ต่อผู้ซื้อมากกว่า ACR ที่อ้างว่ารองรับทั้งหมด ACR ควรอ้างอิงจากการทดสอบผลิตภัณฑ์ รวมถึงการทดสอบด้วยคน การสแกนอัตโนมัติเพียงอย่างเดียวไม่สามารถกรอก ACR ได้

หากคุณขายให้ผู้บริโภคในสหภาพยุโรป European Accessibility Act อาจใช้บังคับกับวิธีที่คุณขายออนไลน์ด้วย [คู่มือ EAA](/th/blog/european-accessibility-act-online-stores) ของเราอธิบายขอบเขตไว้ เนื้อหานี้ไม่ใช่คำแนะนำทางกฎหมาย

## ทีม SaaS ควรทดสอบการเข้าถึงอย่างไร

1. **ทำส่วนพื้นฐานให้เป็นอัตโนมัติ** รัน axe-core หรือเอนจินที่คล้ายกันในการทดสอบแบบ end-to-end และบนเว็บไซต์การตลาด และให้ build ล้มเมื่อพบการละเมิดใหม่ [เครื่องมือตรวจสอบการเข้าถึงฟรี](/th/website-accessibility-checker) ของเราใช้เอนจินเดียวกันกับหน้าสาธารณะใดก็ได้
2. **ทดสอบด้วยคีย์บอร์ด** ทำขั้นตอนการทำงานหลัก เช่น การสมัคร การสร้างระเบียนข้อมูล และการเปลี่ยนการตั้งค่า โดยใช้เพียง Tab, Shift+Tab, Enter, Space, Escape และปุ่มลูกศร
3. **ทดสอบด้วยโปรแกรมอ่านหน้าจอ** NVDA บน Windows และ VoiceOver บน macOS และ iOS ใช้ได้ฟรี ตรวจว่ามีการประกาศชื่อ บทบาท สถานะ และข้อความ
4. **ซูมและปรับขนาด** ตรวจการซูมข้อความ 200% และหน้าต่างกว้าง 320 พิกเซล
5. **แก้ที่ระบบดีไซน์** ปัญหาส่วนใหญ่มาจากคอมโพเนนต์ที่ใช้ร่วมกัน การแก้ปุ่มหรือกล่องโต้ตอบครั้งเดียวจะแก้ได้ทุกที่

## คำถามที่พบบ่อย

### WCAG ใช้กับส่วนของเว็บแอปที่ต้องเข้าสู่ระบบหรือไม่

WCAG ใช้กับเนื้อหาเว็บทุกประเภท รวมถึงหน้าที่อยู่หลังการเข้าสู่ระบบ กฎหมายจะบังคับให้ผลิตภัณฑ์หนึ่งๆ ต้องทำตามหรือไม่ขึ้นอยู่กับเขตอำนาจศาลและลูกค้า แต่ผู้ซื้อที่ถามเรื่องการเข้าถึงมักหมายถึงทั้งผลิตภัณฑ์

### โอเวอร์เลย์ทำให้ผลิตภัณฑ์ SaaS เข้าถึงได้หรือไม่

ไม่ได้ โอเวอร์เลย์ไม่ได้เปลี่ยนโค้ดพื้นฐานของคอมโพเนนต์ที่สร้างขึ้นเอง ซึ่งเป็นจุดที่ปัญหาของแอปพลิเคชันเกิดขึ้น คู่มือของเราเรื่อง[โอเวอร์เลย์ด้านการเข้าถึง](/th/blog/accessibility-overlays-ftc-order) อธิบายการดำเนินการของ FTC ต่อผู้ให้บริการโอเวอร์เลย์รายใหญ่

### เครื่องมืออัตโนมัติตรวจ WCAG ได้มากแค่ไหน

ได้เพียงบางส่วน กฎอัตโนมัติหาชื่อและป้ายกำกับที่ขาดหาย รวมถึงปัญหาคอนทราสต์ได้อย่างน่าเชื่อถือ แต่เกณฑ์จำนวนมาก เช่น ลำดับโฟกัสที่สมเหตุสมผล ข้อความ alt ที่มีประโยชน์ และข้อความแจ้งข้อผิดพลาดที่เข้าใจได้ ต้องให้คนเป็นผู้ตัดสิน

### เราควรตั้งเป้า WCAG เวอร์ชันใด

WCAG 2.2 ระดับ AA เป็นเวอร์ชันปัจจุบัน กฎหมายและกฎการจัดซื้อจำนวนมากยังอ้างอิง WCAG 2.1 AA การผ่าน 2.2 AA ก็ถือว่าผ่าน 2.1 AA ด้วย ยกเว้นเกณฑ์ Parsing ที่ถูกตัดออกไป

### เราต้องผ่านระดับ AAA หรือไม่

W3C ไม่แนะนำให้กำหนด AAA กับทั้งผลิตภัณฑ์ เพราะเนื้อหาบางอย่างไม่สามารถผ่านเกณฑ์ AAA ได้ทุกข้อ ระดับ AA จึงเป็นเป้าหมายทั่วไป

## แหล่งที่มา

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)