为什么我在 WordPress 标头上的 ADA 合规性失败，从<h1>至</h1><h3> ?</h3>

Question

I am tasked with structuring our current website into ADA compliance and it has been a pain to get everything updated, so I have some questions regarding the headers.

We have the following code in on of our "Page Templates":

<main class="content">
    <div class="row">
        <div class="small-12 columns text-center">
            <header class="collection__header">
                <h1>{{ entity.site.get_site_name | raw }}</h1>
                <div class="expanded row">
                    <div class="small-12 large-offset-1 large-10 columns">
                        <div class="page-description">{{ entity.get_content | raw }}</div>
                    </div>
                </div>
            </header>
        </div>
    </div>
</main>

We have our entity.get_content() call, which pulls in the WordPress "Post Content" box:

---

The Problem :

When someone passes in a header tags (Which WordPress allows) within the post content, it throws off the ADA Header structure "Skipped Header" as shown below:

Does anyone know how someone can safely pass in any header tags inside the "Post Content" and we still are ADA compliant? If they pass in the h2 tag, that's fine, but if they pass in the h3 tag as shown in the screenshot, the ADA headers get throws compared to the theme build.

Answer 1

76.7 % of screen reader users rely on Navigating through the headings on the page as the primary means to Finding Information on a lengthy webpage.

– WebAIM Screen Reader User Survey #9 Results, 2021

Just as sighted users do as well (skimming).

Anybody would be confused when trying to navigate a long document via the table of contents which has gaps and unrelated headings grouped.

So while there currently is no hard conformance-criteria for a consistent heading-level-order (afaik), it is important.

Many scanning tools will flag it in error but if your scanning tool allows you to turn off warnings and best practices and only show true errors, this issue should not show up.

What could a developer do?

It's a CMS's job to manage content and make it usable in different contexts (adaptive content). That includes adapting heading levels to the context.

One solution might be the following:

<div class="page-description">{{ entity.get_content | start_at_h2 }}</div>

which turns the <h3> into a <h2> , h4 → h3 and so on:

<div class="page-description">
<hgroup>
  <h2 style="text-align: center;">We’re the people…
</hgroup>
</div>

Maybe somebody already wrote an extension for WordPress?

What can you do in procurement?

It should be a CMS's job to support authors providing good adaptive content. Meaning that if you care about your final output being ADA compliant, you should choose a CMS that helps you achieve that.

Part B: Support the production of accessible content of the Authoring Tool Accessibility Guidelines (ATAG) explains what a CMS needs to do to be compliant. You could go and find a CMS that is certified.

In this case, it could warn the author about the heading level, and about the heading text being way too long.

To fix the issue from a developer's perspective, I could imagine a filter that helps keep the heading levels consistent. Because it's the developer who puts the content into context.