ไขปมคำเตือน Blocked aria-hidden และวิธีแก้โค้ดโมดัลที่ถูกต้อง
เจาะลึกปัญหาเบื้องหลังคำเตือน aria-hidden ในเบราว์เซอร์ Chromium และเหตุผลว่าทำไมวิธีแก้ปัญหายอดฮิตส่วนใหญ่ถึงส่งผลเสียต่อผู้ใช้งานสกรีนรีดเดอร์

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- คำเตือน aria-hidden ในคอนโซลไม่ใช่ข้อผิดพลาดด้านสไตล์แต่เป็นการฟ้องเรื่องสถาปัตยกรรมโค้ด
- วิธีแก้อยอดนิยม เช่น การใช้ blur(), setTimeout หรือการลบแอตทริบิวต์ทิ้ง ส่งผลเสียต่อผู้ใช้งานสกรีนรีดเดอร์
- ปัญหาหลักเกิดจากลำดับการทำงานที่ผิดพลาดระหว่างการซ่อนเร้นและการย้ายโฟกัสคีย์บอร์ด
- แนวทางแก้ไขที่ถูกต้องคือการปรับลำดับคำสั่งและใช้คุณสมบัติ inert กับโอเวอร์เลย์ที่กำลังปิด
ผลลัพธ์การค้นหาส่วนใหญ่มักจะมองข้ามประเด็นสำคัญไป นั่นคือคำเตือนที่ปรากฏขึ้นนั้นมีความถูกต้อง เพราะเบื้องหลังหน้าจอมีผู้ใช้งานจริงที่พึ่งพาสกรีนรีดเดอร์ ซึ่งโฟกัสของพวกเขากำลังจะร่วงหล่นลงไปในช่องว่างของหน้าเว็บที่คุณสร้างขึ้น
แนวทางแก้ไขที่ติดอันดับต้นๆ ในตอนนี้ต่างก็ทำสิ่งเดียวกันด้วยชื่อที่แตกต่างกัน ไม่ว่าจะเป็นเทคนิคการใช้ blur() แบบบรรทัดเดียว การห่อหุ้มการปิดด้วย setTimeout หรือลูกเล่นในการดึงแอตทริบิวต์ aria-hidden ออกไป ซึ่งแต่ละวิธีช่วยทำให้คอนโซลเงียบลงได้ก็จริง แต่กลับสร้างความเสียหายเงียบๆ ให้กับผู้คนที่เบราว์เซอร์พยายามปกป้องอยู่ หากคุณเคยใช้งานวิธีเหล่านี้ไปแล้ว คุณไม่ได้สะเพร่า แต่คุณกำลังถูกนำทางด้วยผลลัพธ์การค้นหาที่ล้มเหลว
ในทางปฏิบัติ ปัญหานี้คือเรื่องของลำดับการทำงาน (Order of Operations) โค้ดโมดัลส่วนใหญ่มีชิ้นส่วนที่ถูกต้องครบถ้วนแล้ว เพียงแต่วางไว้ผิดลำดับ การแก้ไขจึงเป็นการจัดเรียงลำดับใหม่ทั้งหมด โดยมีขั้นตอนสำคัญที่แทบไม่มีใครทำกันคือการใส่สถานะ inert ให้กับตัวโอเวอร์เลย์ปิด ซึ่งมักจะถูกระบุไว้ในคอมเมนต์ของนักพัฒนา
เมื่อเบราว์เซอร์รันคำสั่งซ่อนเร้น มันจะเกิดขึ้นทันทีในแบบซิงโครนัส (Synchronous) ก่อนที่การย้ายโฟกัสในบรรทัดถัดไปจะทันได้ทำงาน ความเสียหายจึงอยู่ที่ลำดับการทำงานและสถานะที่ไม่ถูกต้องซึ่งเกิดขึ้นระหว่างสองคำสั่งนั้น ไม่ใช่ช่องว่างของเวลาจริงๆ หากจัดการลำดับได้ถูกต้อง ผลลัพธ์ที่ได้จะเรียบง่ายและไร้ที่ติ ผู้ใช้กดปุ่ม Esc ได้ยินเสียงโฟกัสกลับมาที่ปุ่มเดิมที่ใช้เปิด และใช้งานต่อได้ทันที

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ความสับสนเริ่มต้นจากคำว่าคำเตือนที่เบราว์เซอร์พยายามบอกเล่า เพราะมันทำให้เข้าใจว่าเป็นเพียงคำแนะนำที่ไม่บังคับ แต่ในความเป็นจริงแล้วไม่ใช่เลย เมื่อคุณเห็นข้อความนั้น เบราว์เซอร์ได้ตรวจสอบมาร์กอัปของคุณ ตัดสินว่าคุณทำผิด และจัดส่ง Accessibility Tree ที่แตกต่างจากที่คุณเขียนขึ้นมาเรียบร้อยแล้ว
เมื่อเปิดโมดัลที่ทำให้เกิดปัญหานี้แล้วดูที่แผง Elements คุณจะพบแอตทริบิวต์ aria-hidden="true" อยู่บนแบ็คกราวด์แร็ปเปอร์อย่างถูกต้อง ไม่มีอะไรโกหกใน DOM inspector แต่ถ้าสลับไปที่แผง Accessibility คุณจะเห็นต้นไม้ที่ Chromium ส่งต่อไปยัง API สกรีนรีดเดอร์ของระบบปฏิบัติการ โดยซับทรีที่คุณสั่งให้ซ่อนนั้นยังคงอยู่ เปิดเผย และอ่านได้เต็มรูปแบบ
เบราว์เซอร์อ่านแอตทริบิวต์ของคุณ เห็นโหนดที่โฟกัสอยู่ภายในซับทรีนั้น และเดินย้อนกลับขึ้นไปตามสายตระกูลของโหนดที่โฟกัส โดยเพิกเฉยต่อ aria-hidden ของคุณตลอดทาง ทันทีที่โฟกัsย้ายออก การซ่อนเร้นก็จะดีดกลับมาทำงานตามที่คุณขอ ช่องว่างระหว่างสองแผงนี้คือบั๊กทั้งหมด ซึ่งเกิดจากความย้อนแย้งที่ฝังอยู่ในตัว aria-hidden เอง
"เบราว์เซอร์ไม่ได้เตือนคุณเรื่องความสวยงามตามสไตล์ไกด์ แต่มันกำลังฟ้องถึงสถาปัตยกรรมโค้ดของคุณเอง"
CSS-Tricks
Chromium ได้ทำการแพตช์ปัญหานี้เงียบๆ มานานกว่าที่ตัวคำเตือนจะปรากฏเสียอีก โดยปัญหาแบบเปิด (Open-time variant) เริ่มปรากฏในตัวติดตามปัญหาทั่วทั้ง Chromium เวอร์ชัน 127 ในช่วงฤดูร้อนปี 2024 เช่นใน MUI #43106, Ant Design #50170 และ Flowbite #943 ส่วนปัญหาแบบปิด (Close-time variant) มาถึงในอีกหลายเดือนต่อมาใน Chromium เวอร์ชัน 131 ช่วงปลายปี 2024 ซึ่งมีผู้พบใน Bootstrap #41005 วันที่ 5 พฤศจิกายน และ Angular #30187 ในเดือนธันวาคม
ที่มา: CSS-Tricks
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น