Trình Kiểm Tra Tiêu Đề WCAG

Trình kiểm tra tiêu đề WCAG là gì?

Một trình kiểm tra tiêu đề WCAG xác thực rằng các phần tử tiêu đề trên một trang web (h1, h2, h3, h4, h5, h6) hình thành một hệ thống phân cấp logic mà các trình đọc màn hình và các công nghệ hỗ trợ khác có thể điều hướng. Tiêu đề là cách người dùng mù và thị lực kém lướt qua một trang: họ sử dụng phím tắt trình đọc màn hình để nhảy từ tiêu đề này sang tiêu đề khác, xây dựng một mục lục tinh thần trong vài giây. Nếu các tiêu đề bị thiếu, không đúng thứ tự hoặc được sử dụng theo cách trang trí, sự điều hướng đó sụp đổ. Tiêu chí Thành công WCAG 2.2 1.3.1 (Thông tin và Mối quan hệ) và 2.4.6 (Tiêu đề và Nhãn) yêu cầu các tiêu đề truyền tải cấu trúc một cách chính xác.

Các quy tắc đơn giản để phát biểu và dễ vi phạm. Phải có chính xác một h1 trên mỗi trang (tiêu đề trang). Mỗi tiêu đề tiếp theo phải sâu hơn tối đa một cấp so với cấp cha của nó (một h2 có thể được theo sau bởi một h2 khác hoặc bởi một h3, nhưng không trực tiếp bởi một h4). Tiêu đề không được trống. Các cấp độ tiêu đề phải mô tả cấu trúc tài liệu, không phải kích thước hình ảnh (không sử dụng h4 chỉ vì bạn muốn văn bản nhỏ hơn). Hầu hết các đánh giá khả năng truy cập gắn cờ các vấn đề về phân cấp tiêu đề là điều đầu tiên cần khắc phục vì chúng phổ biến, dễ xác minh và có tác động cao đối với người dùng trình đọc màn hình.

Công cụ này phân tích HTML mà bạn dán vào (không tải lên, không khứ hồi máy chủ), đi qua các phần tử tiêu đề theo thứ tự tài liệu và báo cáo các vấn đề: thiếu h1, nhiều h1, cấp độ bị bỏ qua, tiêu đề trống và một dàn ý của cấu trúc trang. Đầu ra là văn bản đơn giản mô tả mỗi vấn đề. Chạy nó trên bất kỳ trang nào trong quá trình phát triển, trước khi ra mắt hoặc như một phần của chu kỳ đánh giá khả năng truy cập thường xuyên. Đầu ra bằng ngôn ngữ đơn giản, không phải điểm số; mục tiêu là cung cấp cho bạn các vấn đề cụ thể để khắc phục, không phải một điểm đạt để theo đuổi.

Bên trong công cụ có gì

Phần trên cùng của trang là một textarea nơi bạn dán HTML của mình. Bạn có thể dán một tài liệu hoàn chỉnh (DOCTYPE, html, head, body) hoặc một đoạn (chỉ nội dung body). Công cụ trích xuất tất cả các phần tử h1 đến h6 theo thứ tự tài liệu sử dụng DOMParser tiêu chuẩn của trình duyệt, vì vậy việc phân tích cú pháp khớp với những gì một trình duyệt thực sẽ làm. Textarea xử lý đầu vào với kích thước bất kỳ; các tài liệu rất lớn (hàng chục nghìn dòng) hoạt động nhưng mất một phần giây lâu hơn để phân tích cú pháp.

Nhấp vào Kiểm tra Tiêu đề và kết quả xuất hiện bên dưới. Phần đầu tiên là dàn ý tiêu đề: mỗi tiêu đề theo thứ tự, thụt lề theo cấp độ, vì vậy bạn có thể đọc cấu trúc dưới dạng mục lục. Phần thứ hai là danh sách các vấn đề: mỗi vấn đề với vị trí cụ thể của nó, điều gì sai và lời giải thích ngắn gọn về lý do tại sao nó quan trọng. Các vấn đề được phân loại theo mức độ nghiêm trọng: lỗi (phải khắc phục để tuân thủ WCAG) và cảnh báo (thực hành tốt nhất nhưng không phải thất bại nghiêm ngặt).

Đầu ra ở lại trong trình duyệt; không có gì được tải lên. Bạn có thể dán cùng một HTML nhiều lần với các chỉnh sửa ở giữa để lặp lại các bản sửa lỗi. Công cụ cố ý không kiểm tra bất cứ điều gì ngoài cấu trúc tiêu đề (nó không xác minh văn bản alt, độ tương phản, thứ tự lấy nét, ARIA hoặc bất kỳ tiêu chí WCAG nào khác). Đối với những điều đó, hãy sử dụng công cụ này cùng với một công cụ đánh giá toàn diện như axe DevTools, Lighthouse hoặc WAVE.

Lịch sử và bối cảnh

Tiêu đề HTML từ khi bắt đầu (1991)

Tim Berners-Lee giới thiệu HTML vào năm 1991 với các phần tử h1 đến h6 như một phần của 18 thẻ ban đầu. Ý định ngữ nghĩa ban đầu luôn là cấu trúc tài liệu, không phải kiểu dáng hình ảnh. Hệ thống phân cấp tiêu đề của Web đến từ một truyền thống cũ hơn nhiều: tài liệu in (sách, bài báo, báo cáo của chính phủ) đã sử dụng các cấp độ phần đánh số trong nhiều thế kỷ để truyền tải cấu trúc. HTML đã thừa hưởng mô hình đó trực tiếp. Mặc dù 35 năm ngữ nghĩa ổn định, việc sử dụng sai tiêu đề là một trong những lỗi truy cập phổ biến nhất trên web hiện đại vì các nhà thiết kế thường tạo kiểu theo kích thước hình ảnh trước và kiểm tra cấu trúc sau.

Trình đọc màn hình học cách điều hướng bằng tiêu đề (1996 trở đi)

JAWS (Job Access With Speech) được phát hành bởi Henter-Joyce vào năm 1989 và thêm điều hướng tiêu đề trang Web khi Web trở nên phổ biến vào cuối những năm 1990. Nhấn phím H trong JAWS nhảy đến tiêu đề tiếp theo; các phím đánh số 1 đến 6 nhảy đến cấp độ tiêu đề cụ thể đó. Mọi trình đọc màn hình lớn kể từ đó (NVDA năm 2006, VoiceOver năm 2005, TalkBack trên Android) đều đã sao chép phím tắt này. Khảo sát Người dùng Trình đọc Màn hình hàng năm của WebAIM liên tục cho thấy 67 đến 70 phần trăm người dùng trình đọc màn hình điều hướng bằng tiêu đề như phương pháp chính của họ để hiểu một trang. Do đó, hệ thống phân cấp tiêu đề bị hỏng không phải là vấn đề thẩm mỹ.

WCAG 1.0 và sự trỗi dậy của các tiêu chuẩn truy cập (1999)

Hướng dẫn Truy cập Nội dung Web 1.0 được W3C công bố vào tháng 5 năm 1999, tiêu chuẩn quốc tế đầu tiên về khả năng truy cập Web. WCAG 1.0 yêu cầu rõ ràng các tiêu đề được sử dụng cho cấu trúc tài liệu (Điểm kiểm tra 3.5). WCAG 2.0 (2008) đã tinh chỉnh điều này thành Tiêu chí Thành công 1.3.1 (Thông tin và Mối quan hệ, Cấp độ A) và 2.4.6 (Tiêu đề và Nhãn, Cấp độ AA). WCAG 2.1 (2018) và 2.2 (2023) giữ các tiêu chí này không thay đổi vì yêu cầu cơ bản là vững chắc. Hầu hết các luật về khả năng truy cập trên thế giới (ADA ở Mỹ, EAA ở Châu Âu, AODA ở Ontario) hiện trích dẫn WCAG 2.1 AA làm cơ sở pháp lý.

Phân đoạn HTML5 và dàn ý tài liệu (2014)

HTML5 (Khuyến nghị W3C 2014) đã giới thiệu các phần tử phân đoạn (article, section, nav, aside) và một thuật toán dàn ý được cho là sẽ rút ra hệ thống phân cấp tiêu đề từ độ sâu lồng nhau. Thuật toán không bao giờ được triển khai trong bất kỳ trình duyệt hoặc trình đọc màn hình nào và chính thức bị phản đối vào năm 2022. Hướng dẫn thực tế là: sử dụng các cấp độ tiêu đề rõ ràng (h1 đến h6) và xử lý các phần tử phân đoạn như nhóm ngữ nghĩa, không phải là thay thế cho độ sâu tiêu đề. HTML Living Standard hiện nêu rõ ràng rằng các cấp độ tiêu đề phải được đặt rõ ràng.

Vai trò ARIA và aria-level (2014 trở đi)

WAI-ARIA 1.1 (Khuyến nghị W3C 2017) cung cấp role="heading" với aria-level="N" như một cách thay thế để đánh dấu các tiêu đề, hữu ích khi bạn không thể sử dụng các phần tử h1-h6 gốc (ví dụ, trong một thành phần framework cần kết xuất các cấp độ tiêu đề khác nhau trong các bối cảnh khác nhau). Các trình đọc màn hình xử lý role="heading" giống hệt với phần tử gốc. Thực hành tốt nhất là sử dụng các phần tử gốc nếu có thể; chỉ sử dụng ARIA khi ngữ nghĩa gốc không có sẵn. Công cụ này kiểm tra cả các phần tử tiêu đề gốc và các phần tử có role="heading".

Các vụ kiện về khả năng truy cập và lý do kinh doanh (2017 trở đi)

Domino's Pizza v. Robles (Tòa án Tối cao Hoa Kỳ 2019) đã thiết lập rằng Đạo luật Người Mỹ Khuyết tật (ADA, 1990) áp dụng cho các trang web thương mại. Hàng trăm vụ kiện tương tự đã theo sau mỗi năm (hơn 4.000 vụ kiện web ADA được nộp chỉ riêng năm 2024). Đạo luật Truy cập Châu Âu (EAA, có hiệu lực vào tháng 6 năm 2025) làm cho khả năng truy cập tương đương WCAG trở thành yêu cầu pháp lý cho hầu hết các trang web hướng tới người tiêu dùng trên khắp EU. Cấu trúc tiêu đề thất bại là một trong những vấn đề dễ nhất để các nguyên đơn xác định và lập tài liệu, điều này làm cho các kiểm tra tiêu đề cơ bản trở thành một bước tuân thủ có đòn bẩy cao.

Quy trình thực tế

Kiểm tra trước khi ra mắt trên các trang và mẫu mới

Trước khi bất kỳ trang hoặc mẫu mới nào được phát hành, hãy chạy HTML qua trình kiểm tra này. Các vấn đề về cấu trúc tiêu đề là những lỗi truy cập dễ nhất để giới thiệu (đặc biệt là trong nội dung được điều khiển bởi CMS, nơi các biên tập viên chọn các cấp độ tiêu đề dựa trên kích thước hình ảnh) và dễ nhất để khắc phục. Bắt chúng trước khi ra mắt rẻ hơn nhiều so với sau đó, khi các bản sửa lỗi yêu cầu phối hợp với các chủ sở hữu nội dung. Đối với các đại lý, hãy xây dựng kiểm tra này vào danh sách kiểm tra QA; đối với các nhóm nội bộ, hãy chạy nó như một phần của đánh giá mã hoặc trước khi hợp nhất vào main.

Đánh giá một trang web hiện có để tuân thủ khả năng truy cập

Đối với đánh giá khả năng truy cập (trước tố tụng, tuân thủ EAA, yêu cầu hợp đồng), hãy duyệt qua các trang có lưu lượng truy cập cao nhất và chạy HTML của từng trang qua trình kiểm tra này. Lập tài liệu các phát hiện: trang nào có vấn đề tiêu đề, loại nào, cách khắc phục. Kết hợp với axe DevTools hoặc Lighthouse cho các tiêu chí WCAG khác. Các phát hiện về cấu trúc tiêu đề thường là dễ nhất để khắc phục và hình thành một phần thắng nhanh vững chắc trong báo cáo đánh giá.

Đào tạo biên tập viên CMS và tạo mẫu

Nội dung do CMS điều khiển (WordPress, Drupal, Contentful, Sanity) thường cung cấp cho biên tập viên một menu thả xuống tiêu đề với các tùy chọn H1 đến H6. Biên tập viên không biết các quy tắc sẽ chọn các cấp độ theo kích thước hình ảnh. Trình diễn trình kiểm tra này cho biên tập viên để họ có thể thấy lựa chọn tiêu đề của họ tạo ra gì. Đối với các mẫu, chạy đầu ra đã kết xuất qua trình kiểm tra sau mỗi thay đổi thiết kế để xác nhận rằng các lựa chọn tiêu đề của biên tập viên vẫn tạo ra hệ thống phân cấp hợp lệ. Có nhiều plugin CMS cảnh báo các biên tập viên tại thời điểm viết; công cụ này phục vụ bước xác minh.

Xác thực mẫu email và bản tin HTML

Email HTML được đọc bởi các trình đọc màn hình nên tuân theo cùng một hệ thống phân cấp tiêu đề như các trang web. Chạy HTML của mẫu email của bạn qua trình kiểm tra này trước khi gửi đến danh sách lớn. Các vấn đề mẫu email phổ biến: nhiều h1 (khi mỗi phần có tiêu đề riêng), thiếu h1 (khi bố cục bắt đầu trực tiếp với h2) và h4 trang trí được sử dụng hoàn toàn cho các tiêu đề nhỏ. Khắc phục những điều này trước khi gửi; người dùng công nghệ hỗ trợ trên danh sách của bạn sẽ nhận thấy.

Xác thực chuyển đổi PDF sang HTML

Khi bạn chuyển đổi PDF thành HTML để dễ truy cập (để chúng có thể được đọc bởi các trình đọc màn hình với điều hướng tiêu đề), trình chuyển đổi phải ánh xạ các thẻ cấu trúc PDF sang các cấp độ tiêu đề HTML. Kết quả thường bị hỏng: các PDF không có thẻ thích hợp tạo ra HTML phẳng mà không có tiêu đề nào, và ngay cả các PDF có thẻ đôi khi cũng tạo ra đầu ra toàn h1 hoặc toàn h2. Chạy HTML đã chuyển đổi qua trình kiểm tra này để phát hiện vấn đề trước khi xuất bản trang đã chuyển đổi.

Đào tạo các nhà phát triển và nhà thiết kế mới

Các nhà phát triển front-end mới vào nghề và các nhà thiết kế được hưởng lợi từ việc nhìn thấy các ví dụ cụ thể về hệ thống phân cấp tiêu đề bị hỏng và trải nghiệm trình đọc màn hình kết quả. Ghép cặp công cụ này với một bản demo trình đọc màn hình (NVDA trên Windows miễn phí, VoiceOver trên Mac được tích hợp sẵn) để cho thấy các tiêu đề điều khiển điều hướng trình đọc màn hình như thế nào. Mối liên hệ giữa các quy tắc tiêu đề trừu tượng và trải nghiệm người dùng cụ thể thường là điều khiến bài học khắc sâu.

Các cạm bẫy phổ biến

Chọn cấp độ tiêu đề theo kích thước hình ảnh

Lỗi phổ biến nhất: sử dụng h4 vì bạn muốn văn bản nhỏ hơn, hoặc bỏ qua từ h2 đến h4 vì không có h3 nào có kích thước đúng trong thiết kế. Các cấp độ tiêu đề là cấu trúc, không phải hình ảnh; sử dụng CSS để kiểm soát kích thước và sử dụng cấp độ phù hợp với phân cấp tài liệu. Nếu hệ thống thiết kế của bạn không có kiểu hình ảnh cho mỗi cấp độ cần thiết, hãy thêm một (hoặc ghi đè bằng tên lớp) thay vì chọn cấp độ sai.

Nhiều h1 trên mỗi trang

Một trang nên có chính xác một h1 đại diện cho tiêu đề trang. Các lỗi phổ biến: logo trang web được bọc trong h1 cộng với tiêu đề bài viết cũng trong h1 (hai h1), một trang chủ với mỗi phần hero sử dụng h1 (nhiều h1), hoặc không có h1 nào vì bố cục bắt đầu với h2. Cách khắc phục mang tính cấu trúc: chọn nội dung quan trọng nhất trên trang làm h1 duy nhất và giáng cấp mọi thứ khác xuống h2 hoặc thấp hơn. Các công cụ như axe và Lighthouse cảnh báo về nhiều h1 vì lý do này.

Cấp độ tiêu đề bị bỏ qua

Đi từ h2 trực tiếp đến h4 phá vỡ dàn ý tài liệu. Người dùng trình đọc màn hình di chuyển từ tiêu đề đến tiêu đề mong đợi mỗi h4 được lồng dưới h3 và h3 bị thiếu làm rối cấu trúc. Cách khắc phục là chèn cấp độ trung gian bị thiếu hoặc giáng cấp h4 thành h3. Nguyên nhân phổ biến nhất là sao chép thiết kế từ một mô hình mà phân cấp hình ảnh sử dụng ba kích thước nhưng hệ thống thiết kế sử dụng bốn cấp độ tiêu đề; kiểm tra lại sau mỗi cập nhật thành phần.

Tiêu đề trống

Một h2 không có nội dung văn bản (thường vì một widget JavaScript đã xóa văn bản nhưng giữ phần tử) xuất hiện trong danh sách tiêu đề của trình đọc màn hình dưới dạng tiêu đề không nhãn, điều này gây nhầm lẫn và vô dụng. Hoặc điền vào tiêu đề với văn bản, hoặc xóa phần tử tiêu đề hoàn toàn. Điều này phổ biến trong các ứng dụng trang đơn, nơi các phần tử giữ chỗ được kết xuất trước khi dữ liệu tải; kết xuất tiêu đề chỉ khi có nội dung để đưa vào.

Tiêu đề bên trong các trình bao bọc phi ngữ nghĩa

Một tiêu đề được bọc trong một div với role="presentation" hoặc aria-hidden="true" được loại bỏ khỏi cây khả năng truy cập, có thể ẩn một tiêu đề đúng nếu không từ các trình đọc màn hình. Đánh giá các phần tử cha của mọi tiêu đề để đảm bảo chúng không loại bỏ tiêu đề khỏi cây khả năng truy cập. CSS display:none và visibility:hidden cũng loại bỏ tiêu đề; chỉ sử dụng những thứ này một cách có chủ ý và không bao giờ trên nội dung phải hiển thị cho trình đọc màn hình.

Sử dụng ARIA khi HTML gốc có thể đảm nhiệm

Thêm role="heading" aria-level="2" vào một div thay vì sử dụng một phần tử h2 hoạt động cho khả năng truy cập nhưng là sự phức tạp không cần thiết. Các phần tử h1-h6 gốc nhận được ngữ nghĩa tiêu đề miễn phí, kết xuất chính xác trong các kiểu trình duyệt mặc định và tồn tại tốt hơn các lỗi trình đọc màn hình so với các ghi đè ARIA. Quy tắc đầu tiên của ARIA (theo WAI-ARIA Authoring Practices) là: không sử dụng ARIA khi HTML gốc cung cấp cùng ngữ nghĩa. Sử dụng các phần tử tiêu đề gốc trừ khi một ràng buộc framework thực sự buộc phải dùng ARIA.

Quyền riêng tư và xử lý dữ liệu

HTML mà bạn dán vào ở lại trong trình duyệt của bạn trong suốt quá trình kiểm tra. DOMParser trích xuất các tiêu đề chạy bằng JavaScript trên máy của bạn; các kết quả được hiển thị trong trang bên dưới textarea. Không có bước tải lên, không xử lý từ xa và không có dữ liệu đo từ xa về HTML bạn đã dán. Điều này quan trọng vì HTML bạn muốn kiểm tra nhất (các mẫu trước khi ra mắt, các trang web khách hàng theo NDA, các trang quản trị nội bộ) chính xác là những gì bạn không nên dán vào một trình xác thực SaaS bên thứ ba.

Sau khi trang được tải, công cụ hoạt động ngoại tuyến. Bạn có thể ngắt kết nối khỏi internet, dán HTML, chạy kiểm tra và xem xét kết quả mà mã đánh dấu của bạn không bao giờ chạm vào một máy khác. Hầu hết các trình kiểm tra khả năng truy cập đám mây (PowerMapper, Tenon, Site Improve) yêu cầu tải lên URL trang hoặc HTML; đối với các trang bí mật, đó chính xác là chế độ thất bại cần tránh.

Khi không sử dụng công cụ này

Đối với các đánh giá WCAG đầy đủ (sử dụng một công cụ toàn diện)

Cấu trúc tiêu đề là một trong hàng chục tiêu chí WCAG. Đối với một đánh giá hoàn chỉnh, hãy sử dụng axe DevTools (tiện ích Chrome/Firefox miễn phí từ Deque), Lighthouse (tích hợp sẵn trong Chrome), WAVE (công cụ miễn phí của WebAIM) hoặc một giải pháp trả phí như Tenon hoặc PowerMapper. Chúng kiểm tra độ tương phản màu, văn bản alt, sử dụng ARIA, nhãn biểu mẫu, thứ tự lấy nét và nhiều hơn nữa. Chạy công cụ này cùng với, không phải thay thế, những công cụ toàn diện.

Đối với nội dung động (kiểm tra DOM đã kết xuất)

Nếu các tiêu đề của bạn được tạo bởi JavaScript (React, Vue, Svelte, Angular), nguồn HTML tĩnh không chứa các tiêu đề cuối cùng. Bạn cần phải dán DOM đã kết xuất sau khi JavaScript chạy. Sử dụng DevTools của trình duyệt: mở trang, mở DevTools, tab Elements, nhấp chuột phải vào body hoặc main, Copy outerHTML, sau đó dán vào trình kiểm tra này. Hoặc sử dụng một tiện ích mở rộng trình duyệt đi trực tiếp qua DOM trực tiếp.

Đối với các đường ống CI/CD tự động (sử dụng thư viện Node)

Nếu bạn muốn các kiểm tra tiêu đề chạy tự động trên mỗi cam kết hoặc yêu cầu kéo, hãy tích hợp axe-core, Pa11y hoặc jest-axe vào bộ thử nghiệm của bạn. Chúng chạy các kiểm tra tiêu đề (và nhiều kiểm tra WCAG khác) không đầu trong CI. Công cụ trình duyệt này dành cho sử dụng tương tác trong quá trình phát triển và đánh giá, không phải để tự động hóa. Cả hai đều có vị trí của chúng; sử dụng công cụ trình duyệt cho các đánh giá một lần và thư viện CI cho xác thực liên tục.

Đối với khả năng truy cập tài liệu PDF hoặc Word

PDF và tài liệu Word có hệ thống gắn thẻ khả năng truy cập riêng (PDF/UA, các kiểu tiêu đề Word). Chúng không sử dụng tiêu đề HTML, vì vậy công cụ này không áp dụng. Đối với khả năng truy cập PDF, sử dụng Trình kiểm tra Khả năng truy cập Adobe Acrobat Pro hoặc PAC 2024 (miễn phí, tập trung PDF/UA). Đối với Word, sử dụng Trình kiểm tra Khả năng truy cập tích hợp sẵn (tab Review). Chuyển đổi sang HTML trước nếu bạn muốn sử dụng công cụ này, nhưng việc chuyển đổi có thể đưa ra các vấn đề về tiêu đề.

Các câu hỏi khác

Có bao giờ ổn không khi bỏ qua một cấp độ tiêu đề?

Không trong nội dung tài liệu thẳng. WCAG 2.2 SC 1.3.1 ngụ ý các tiêu đề phải hình thành một chuỗi phân cấp. Một trường hợp phổ biến mà nó trông giống như bỏ qua là dàn ý trang bắt đầu ở h1 sau đó h2 bên trong khu vực nội dung chính, trong khi thanh bên hoặc điều hướng cũng có h2; điều đó ổn vì cả hai đều là anh chị em dưới h1 của trang. Quy tắc thực tế là: không bỏ qua các cấp độ trong một luồng nội dung liên tục. Trình kiểm tra chỉ đánh dấu các bỏ qua thực sự.

Nếu framework của tôi chỉ hỗ trợ một cấp độ tiêu đề thì sao?

Một số thư viện thành phần kết xuất các tiêu đề ở một cấp độ cố định (luôn là h2, bất kể lồng nhau). Cách khắc phục là phơi bày một prop cấp độ trên thành phần tiêu đề (h2, h3, v.v.) và để cho các cha mẹ truyền giá trị thích hợp. Các framework như React thường làm điều này; nếu của bạn không, hãy thêm aria-level trên thành phần và sử dụng role="heading" như một giải pháp tạm thời cho đến khi bạn có thể tái cấu trúc. Về lâu dài, mỗi thành phần tiêu đề có thể tái sử dụng nên chấp nhận một prop cấp độ.

Công cụ có kiểm tra các vai trò ARIA như role="heading" không?

Có. Bất kỳ phần tử nào có role="heading" và một thuộc tính aria-level hợp lệ (1 đến 6) được coi là một tiêu đề ở cấp độ được chỉ định. Các phần tử h1-h6 gốc luôn được ưu tiên, nhưng các tiêu đề được đánh dấu ARIA cũng có hiệu lực bằng nhau đối với các trình đọc màn hình và được kiểm tra cùng với các phần tử gốc.

Phân cấp tiêu đề quan trọng như thế nào so với các tiêu chí WCAG khác?

Rất quan trọng. Khảo sát Người dùng Trình đọc Màn hình hàng năm của WebAIM liên tục cho thấy 67-70% người dùng trình đọc màn hình điều hướng bằng tiêu đề như cách chính của họ để hiểu một trang. Tiêu đề xấu hiệu quả chặn một trong những phương pháp điều hướng khả năng truy cập chính. Trong phân tích WebAIM Million hàng năm của WebAIM, các vấn đề về tiêu đề nằm trong số năm thất bại khả năng truy cập phổ biến nhất trên toàn web. Sự kết hợp của tác động cao đến người dùng và phát hiện dễ dàng khiến chúng trở thành ưu tiên hàng đầu.

Mọi trang có nên có một h1?

Có, với những ngoại lệ hiếm. Mọi tài liệu HTML hoàn chỉnh nên có chính xác một h1 đại diện cho tiêu đề trang. Ngoại lệ là các đoạn được chèn rõ ràng vào một trang lớn hơn (chữ ký email, một widget được nhúng trong một trang khác); trang chủ cung cấp h1 và đoạn bắt đầu ở h2 hoặc thấp hơn. Đối với các trang độc lập, h1 bị thiếu là một thất bại khả năng truy cập rõ ràng.

Tôi có thể tin cậy công cụ này cho các cuộc đánh giá tuân thủ pháp lý không?

Đối với cấu trúc tiêu đề cụ thể, có: các quy tắc chính xác và công cụ triển khai chúng một cách chính xác. Đối với tuân thủ WCAG tổng thể, không có công cụ tự động duy nhất nào là đủ; kiểm tra thủ công với công nghệ hỗ trợ, đánh giá chuyên gia và kiểm tra người dùng với người dùng khuyết tật được yêu cầu cho các cuộc đánh giá cấp độ pháp lý. Sử dụng công cụ này như một trong nhiều đầu vào cho cuộc đánh giá của bạn, không phải là nguồn duy nhất của sự thật cho tuân thủ.