Xem Trước Trình Đọc Màn Hình

Lịch sử ngắn của các tiêu chuẩn khả năng truy cập web

Khả năng truy cập trên web được điều chỉnh bởi một chồng nhỏ các tiêu chuẩn từ Sáng kiến Khả năng Truy cập Web W3C (WAI), cộng với các luật quốc gia tham chiếu chúng. WCAG 1.0 được xuất bản vào tháng 5 năm 1999, hướng dẫn chính thức đầu tiên về việc làm cho nội dung web có thể truy cập được. Nó chủ yếu tập trung vào HTML và nhanh chóng trở nên lỗi thời. WCAG 2.0 (tháng 12 năm 2008) là một viết lại lớn được tổ chức xung quanh bốn nguyên tắc (Có thể Nhận thức, Có thể Vận hành, Có thể Hiểu, Mạnh mẽ) và ba mức độ tuân thủ (A, AA, AAA). Nó trở thành một tiêu chuẩn ISO (ISO/IEC 40500) vào năm 2012 và là mục tiêu tuân thủ mà hầu hết các luật vẫn tham chiếu. WCAG 2.1 (tháng 6 năm 2018) đã thêm 17 tiêu chí thành công mới bao gồm di động, thị lực kém và khuyết tật nhận thức. WCAG 2.2 (tháng 10 năm 2023) đã thêm 9 cái nữa, đặc biệt là 2.4.11 Tiêu điểm Không bị Che khuất và 3.3.8 Xác thực Có thể Truy cập. WAI-ARIA 1.0 được hoàn thiện vào tháng 3 năm 2014; 1.2 vào tháng 6 năm 2023 là Khuyến nghị hiện tại. Về mặt pháp lý, Cập nhật Section 508 của Hoa Kỳ (tháng 1 năm 2018) đã kết hợp WCAG 2.0 AA vào việc mua sắm liên bang Hoa Kỳ. Đạo luật Khả năng Truy cập Châu Âu (Chỉ thị 2019/882) có hiệu lực vào 28 tháng 6 năm 2025, yêu cầu hầu hết các sản phẩm kỹ thuật số hướng đến người tiêu dùng ở EU đáp ứng các tiêu chuẩn khả năng truy cập. Hầu hết các quốc gia tham chiếu WCAG, vì vậy xây dựng cho WCAG 2.2 AA là mục tiêu thực tế cho bất kỳ sản phẩm toàn cầu nào ngày nay.

Bối cảnh trình đọc màn hình ngày nay

WebAIM Screen Reader User Survey #10 (2024) là nguồn quy chuẩn về việc người ta thực sự sử dụng trình đọc màn hình nào. Năm sản phẩm thống trị máy tính để bàn, di động và ChromeOS.

• JAWS (Freedom Scientific, phát hành lần đầu 1989) là người dẫn đầu thương mại lâu đời trên Windows. Chi phí ~$1000+. WebAIM 2024 tìm thấy nó là trình đọc màn hình chính cho khoảng 40% người trả lời khảo sát, hơi dưới NVDA.
• NVDA (NV Access, phát hành lần đầu 2006, viết bằng Python) là giải pháp thay thế mã nguồn mở cho Windows. Miễn phí. WebAIM 2024 báo cáo nó là trình đọc màn hình chính được sử dụng nhiều nhất, khoảng 47% người trả lời. Sự phát triển của NVDA từ một công cụ ngách trở thành người dẫn đầu thị trường trong 15 năm là một trong những câu chuyện thành công mã nguồn mở vĩ đại trong công nghệ hỗ trợ.
• VoiceOver (Apple, 2005 trên macOS, 2009 trên iOS) đi kèm sẵn trong mọi Mac, iPhone, iPad, Apple Watch, Apple TV. Đây là trình đọc màn hình di động được sử dụng nhiều nhất. Tích hợp chặt chẽ với Safari và bộ điều hướng iOS để điều hướng.
• TalkBack (Google, 2009 trên Android) là đối tác Android. Mã nguồn mở từ Android 4. Sử dụng cử chỉ và menu điều hướng.
• ChromeVox (Google, 2012) và Narrator (Microsoft, 2000, được hiện đại hóa trong Windows 10) hoàn thiện bức tranh. Mỗi cái có cơ sở người dùng nhỏ nhưng trung thành.

Một trang duy nhất có thể được thông báo khác nhau bởi mỗi sản phẩm. Các trang mạnh mẽ kiểm tra sạch trong ít nhất hai: thường là NVDA + Firefox hoặc Chrome, và VoiceOver + Safari.

Khi nào nên sử dụng công cụ này

• Kiểm toán trước khi ra mắt. Dán một trang chính (trang chủ, biểu mẫu đăng ký, thanh toán) và đọc to đầu ra tuyến tính. Nếu nó không có ý nghĩa với bạn, nó sẽ không có ý nghĩa với người dùng trình đọc màn hình.
• Đánh giá mã. Trước khi hợp nhất PR với những thay đổi đánh dấu đáng kể, hãy dán HTML đã render và xác nhận rằng tiêu đề, mốc và alt text vẫn còn nguyên vẹn.
• Xác minh bàn giao thiết kế. Các nhà thiết kế có thể dán HTML cuối cùng của họ để xác nhận rằng hệ thống cấp bậc trực quan khớp với hệ thống cấp bậc ngữ nghĩa. Một trang trông giống tiêu đề cũng nên là một trong DOM.
• Dạy khả năng truy cập. Cho lớp học hoặc nhóm thấy những gì trình đọc màn hình thực sự nhận. Khoảng cách giữa bố cục trực quan và đầu ra tuyến tính thường là lần đầu tiên các nhà phát triển không khuyết tật hiểu tại sao HTML ngữ nghĩa lại quan trọng.
• Kiểm tra tuân thủ với WCAG. Kiểm tra điểm nhanh cho bốn tiêu chí bị vi phạm nhiều nhất: 1.1.1 Nội dung không phải văn bản (alt text), 1.3.1 Thông tin và Quan hệ (cấu trúc ngữ nghĩa), 2.4.4 Mục đích liên kết, 4.1.2 Tên, Vai trò, Giá trị.
• Kiểm tra trang CMS / no-code. Trình chỉnh sửa trực quan thường tạo ra divs thay vì tiêu đề hoặc liên kết không có văn bản. Dán HTML đã xuất bản, xem những gì đã trượt qua.
• Khả năng truy cập của mẫu email. Email HTML nổi tiếng khó làm cho có thể truy cập. Sử dụng bản xem trước để xác minh alt text trên mọi hình ảnh, thứ tự tiêu đề thích hợp và luồng đọc có thể đọc được.

Những sai lầm phổ biến mà trình đọc màn hình tiết lộ

• Alt text bị thiếu hoặc vô dụng. alt="image", alt="photo", alt="logo" hầu như không tốt hơn gì cả. Lazar et al. (2007) đã xác định alt text bị thiếu là sự thất vọng hàng đầu của người dùng web mù. Viết alt text truyền tải mục đích của hình ảnh trong ngữ cảnh xung quanh, hoặc sử dụng alt="" cho hình ảnh thuần trang trí để trình đọc màn hình bỏ qua chúng.
• Các cấp độ tiêu đề bỏ qua hoặc khởi động lại. Chuyển từ h1 sang h3 bỏ qua h2 làm rối loạn điều hướng. Việc sử dụng nhiều phần tử h1 trên cùng một trang (một mô hình khá phổ biến trong thiết kế dựa trên thành phần) phá vỡ phác thảo tài liệu mà người dùng trình đọc màn hình điều hướng theo. WebAIM 2024 cho thấy tiêu đề là chiến lược điều hướng phổ biến nhất cho người dùng trình đọc màn hình.
• Divitis. Bọc văn bản có thể nhấp trong <div> với một trình xử lý click thay vì sử dụng <button> hoặc <a> có nghĩa là không có hỗ trợ bàn phím, không có vòng tiêu điểm, không có thông báo vai trò. Luôn bắt đầu từ HTML ngữ nghĩa và chỉ thêm ARIA khi không có phần tử gốc nào phù hợp.
• ARIA được sử dụng nơi HTML sẽ làm được. Quy tắc đầu tiên của ARIA (theo W3C WAI-ARIA Authoring Practices): «nếu bạn có thể sử dụng phần tử HTML gốc... hãy làm như vậy». <button role="button"> là dư thừa; <div role="button"> là dấu hiệu bạn nên sử dụng nút thật.
• ARIA được sử dụng không chính xác. aria-hidden="true" trên phần tử có thể được tập trung làm cho nó vô hình với trình đọc màn hình nhưng vẫn có thể được tập trung bằng bàn phím, một công thức cho thứ tự tab gây mất phương hướng. role="button" mà không có tabindex="0" và trình xử lý bàn phím không làm gì hữu ích.
• Đầu vào biểu mẫu không có nhãn. Một <input> không có <label>, aria-label hoặc aria-labelledby liên kết được thông báo là «edit, blank» mà không có ngữ cảnh. Văn bản giữ chỗ không phải là thay thế, nó biến mất khi tập trung và thường thất bại về độ tương phản.
• Liên kết «nhấp vào đây» và «đọc thêm». Người dùng trình đọc màn hình thường điều hướng bằng cách kéo lên danh sách tất cả các liên kết trên trang. «Nhấp vào đây» một mình không nói cho họ điều gì. Làm cho văn bản liên kết mô tả đích đến: «Đọc khảo sát WebAIM 2024» đánh bại «Đọc thêm tại đây».
• Loại bỏ các kiểu tập trung. outline: none mà không có chỉ báo tập trung thay thế là một trong những tiêu chí WCAG bị vi phạm nhiều nhất (2.4.7 Tiêu điểm Có thể Nhìn thấy). Người dùng bàn phím, bao gồm nhiều người dùng trình đọc màn hình, cần thấy nơi tập trung là.

ARIA tổng quan: mỗi loại vai trò làm gì

• Vai trò mốc (banner, navigation, main, complementary, contentinfo, search) chia trang thành các khu vực mà người dùng trình đọc màn hình có thể nhảy giữa. Hầu hết đều có tương đương HTML gốc (<header>, <nav>, <main>, <aside>, <footer>). Sử dụng phần tử gốc trước.
• Vai trò widget (button, checkbox, combobox, menu, tabpanel, v.v.) mô tả các điều khiển tương tác. Vai trò widget ngụ ý các mẫu tương tác bàn phím mà W3C ARIA Authoring Practices Guide (APG) ghi lại chi tiết. Nếu bạn không thể khớp chính xác với đặc tả APG, hãy thích HTML gốc hơn.
• Vai trò cấu trúc tài liệu (article, list, listitem, row, cell, v.v.) mô tả nội dung không tương tác. Hầu hết cũng có tương đương HTML gốc. Chỉ sử dụng chúng khi phần tử gốc không có sẵn (ví dụ: xây dựng lưới dữ liệu tùy chỉnh nơi <table> không phù hợp).
• Vùng trực tiếp (aria-live="polite", aria-live="assertive", role="status", role="alert") yêu cầu trình đọc màn hình thông báo các cập nhật động mà không cần di chuyển tập trung. Được sử dụng cho tin nhắn trò chuyện, lỗi biểu mẫu, trạng thái tải. Sử dụng quá mức gây ra mệt mỏi thông báo; dành assertive cho các trường hợp khẩn cấp thực sự như trạng thái lỗi.

Các câu hỏi thường gặp khác

Bản xem trước này có khớp với những gì NVDA / JAWS / VoiceOver thực sự sẽ nói không?

Nó xấp xỉ. Công cụ này đọc cây khả năng truy cập của trình duyệt (cùng cấu trúc mà trình đọc màn hình sử dụng) và tạo ra phiên bản tuyến tính của những gì sẽ được thông báo. Trình đọc màn hình thực thêm các hành vi cụ thể cho sản phẩm: thông báo thay đổi tập trung, điều hướng bảng, tiêu đề bảng, đếm mục danh sách, xử lý lịch sự ARIA-live, cài đặt độ chi tiết tùy chỉnh. Coi bản xem trước như một kiểm tra sự tỉnh táo đầu tiên; đối với việc ra mắt sản xuất, hãy thử nghiệm với ít nhất một trình đọc màn hình thực trên các hệ điều hành mà khán giả của bạn sử dụng.

Sự khác biệt giữa WCAG và ARIA là gì?

WCAG (Web Content Accessibility Guidelines) là một danh sách các yêu cầu: «mọi nội dung không phải văn bản phải có một thay thế văn bản». Nó cho bạn biết cái gì để đạt được nhưng không phải lúc nào cũng làm thế nào. ARIA (Accessible Rich Internet Applications) là một trong những công cụ để đáp ứng WCAG: một bộ thuộc tính HTML (vai trò, trạng thái, thuộc tính) phơi bày ngữ nghĩa cho công nghệ hỗ trợ khi HTML gốc không đủ. Bạn có thể đáp ứng WCAG mà không cần ARIA nào nếu HTML của bạn đủ ngữ nghĩa. ARIA dành cho các trường hợp mà nó không phải.

Tôi viết alt text tốt như thế nào?

Ba quy tắc từ An alt Decision Tree của W3C: (1) Nếu hình ảnh thuần trang trí, sử dụng alt="" để trình đọc màn hình bỏ qua hoàn toàn. (2) Nếu hình ảnh truyền tải thông tin chưa có trong văn bản xung quanh, hãy mô tả thông tin đó một cách ngắn gọn (thường dưới 125 ký tự). (3) Nếu hình ảnh có chức năng (ví dụ: một logo liên kết đến trang chủ hoặc một nút biểu tượng), hãy mô tả hành động hơn là vẻ ngoài. «Tìm kiếm» đánh bại «biểu tượng kính lúp». Tránh «hình ảnh của...», «ảnh của...», trình đọc màn hình đã thông báo rằng phần tử là một hình ảnh.

Trang web của tôi sử dụng divs ở mọi nơi. Tôi bắt đầu từ đâu?

Bắt đầu bằng cách thêm năm phần tử mốc: <header>, <nav>, <main>, <aside>, <footer>. Sau đó thay thế các divs có thể nhấp bằng <button> (cho hành động) hoặc <a> (cho điều hướng). Sau đó kiểm tra các tiêu đề: mỗi trang nên có một <h1> và phần còn lại theo thứ tự lồng nhau. Ba bước này có thể khắc phục khoảng 70% các vấn đề về khả năng truy cập trên một trang web điển hình nặng divs. ARIA và quản lý tập trung JavaScript đến sau, một khi nền tảng ngữ nghĩa đã có sẵn.

HTML tôi dán ở đây có được gửi đi đâu không?

Không. Phân tích sử dụng DOMParser tích hợp của trình duyệt và phân tích chạy hoàn toàn ở phía máy khách. Mở tab Mạng trong DevTools và nhấp Phân tích, bạn sẽ thấy không có yêu cầu đi ra trong quá trình tuyến tính hóa. An toàn cho các mẫu nội bộ, các trang chưa phát hành hoặc HTML chứa dữ liệu khách hàng.