为什么我会从< h1>中跳下来对WordPress标头的ADA合规性失败。 to< h3>?
我的任务是将当前网站纳入ADA合规性,很难更新所有内容,因此我对标题有一些疑问。
我们在“页面模板”中具有以下代码:
<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>
我们有entity.get_content()
呼叫,它在WordPress“ post content” box:
问题:
当某人在帖子内容中传递标题标签(WordPress允许)时,它会从ADA标头结构“跳过标头”中抛出:
有人知道某人如何安全地传递“帖子内容”中的任何标头标签,而我们仍然符合ADA?如果他们传递H2
标签,那很好,但是如果它们传递到h3
标签中,如屏幕截图所示,则ADA标头将与主题构建相比会投掷。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
76.7%的屏幕读取器用户依赖于在页面上的标题中导航作为在冗长的网页上查找信息的主要手段。
- webaim屏幕读取器读取器用户调查#9结果,2021
就像看到的用户也一样(浏览)。
当试图通过内容表浏览长文档时,任何人都会感到困惑,该目录的差距和无关标题分组。
因此,尽管目前没有一致的标题级别(AFAIK)的硬符合标准,但这很重要。
许多扫描工具会错误地标记它,但是如果您的扫描工具允许您关闭警告和最佳实践,并且仅显示真正的错误,则此问题不应显示。
开发人员可以做什么?
这是CMS的工作,可以在不同的上下文(自适应内容)中使用内容。这包括将标题级别适应上下文。
一个解决方案可能是以下内容:
将
&lt; h3&gt;
变成&lt; h2&gt;
,H4→H3等:也许有人已经为WordPress写了一个扩展名?
您可以在采购中做什么?
支持提供良好自适应内容的作者应该是CMS的工作。这意味着,如果您关心符合ADA的最终输出,则应选择一个有助于您实现这一目标的CMS。
B部分:支持创作工具可访问性指南(ATAG)的可访问内容的生产说明CMS需要做什么才能合规。您可以去找到经认证的CMS。
在这种情况下,它可能会警告作者有关标题级别的信息,以及标题文本太长。
为了从开发人员的角度解决问题,我可以想象一个有助于保持标题级别一致的过滤器。因为是开发人员将内容纳入上下文。
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:
which turns the
<h3>
into a<h2>
, h4 → h3 and so on: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.