新闻

当前项目

最后更新:

进行中

面向 Drupal 与 WordPress 的失效链接检查

Drupal 模块现已可供测试;WordPress 版预计于 2026 年第四季度推出。

2027 年第二季度:为 WordPress 开发发布前的内容管控工具

本项目已获得一批有意共同设计该功能的高校慷慨资助,资金已全部到位。

  • 开发基于角色的配置,用于指定哪些用户可以保存存在已知问题的页面。
  • 开发编辑器内的向导,供作者在发布内容前逐步复查尚未处理的警告。
2027 年初:面向 Drupal 与 WordPress 的 PDF 检查

状态:正在寻找合作伙伴与协作者。本项目已获得学术基金的部分资助,但尚未启动开发。

近期完成

2026 年第二季度:启动 Editoria11y CSA 社区

待完成工作:

  • 建立财务实体以处理订阅和赞助款项。
  • 搭建授权系统。
2026 年第二季度:自定义规则构建器
  1. Drupal 版已完成。
  2. WordPress 版已完成。
2026 年第三季度:将 3.x 库移植到 WordPress
  1. 创建含社区支持功能的 CSA 子模块
    • 创建仪表板维护工具,用于清除过期结果并重新爬取现有内容。
    • 支持将特定检测项标记为全站通过,而非仅限单个页面。
    • 支持分离配置,为开发者和内容编辑提供独立的设置和检测项。
2026 年第一季度:库 3.x 重写
  • 合并 Editoria11y 和 Sa11y 规则集。自分叉以来,Sa11y 新增了约 50 项检测并引入了 ESM 工具链,Editoria11y 则实施了性能优化并增加了支持实时检测的参数。Sa11y 4.2.2 与 Editoria11y 3.0.0 将开启两者的共同未来。
  • 新增"分离配置"支持,允许为开发者和内容创作者提供独立规则集。
  • 新增中文、丹麦语、荷兰语、德语、希腊语、匈牙利语、意大利语、日语、挪威书面语、波兰语、葡萄牙语(巴西)、葡萄牙语(葡萄牙)、西班牙语、瑞典语和乌克兰语的机器翻译,作为人工精修的模板。
2026 年第一季度:Drupal 模块 3.x 重写
  1. 扩展仪表板,提供更强大的报告和筛选工具。
  2. 新增中文、丹麦语、荷兰语、德语、希腊语、匈牙利语、意大利语、日语、挪威书面语、波兰语、葡萄牙语(巴西)、葡萄牙语(葡萄牙)、西班牙语、瑞典语和乌克兰语的机器翻译,作为人工精修的模板。
  3. 使 CSV 导出功能可自定义
  4. 创建含社区支持功能的 CSA 子模块
    • 创建仪表板维护工具,用于清除过期结果并重新爬取现有内容。
    • 支持将特定检测项标记为全站通过,而非仅限单个页面。
    • 支持分离配置,为开发者和内容编辑提供独立的设置和检测项。

讨论中

在 Editoria11y 库论坛中讨论这些想法并投票。

  • 多站点监控仪表板
  • 提示气泡代码位置标签
  • 提示气泡页面报告导出
  • 标记词语
  • CLI 开发者工具
  • 书签工具/浏览器插件
  • ACT 规则验证
  • 扩展名称/角色/值验证

v3:完整的质量保证套件

在 DrupalCon Europe 2026 上首次亮相

YouTube 视频:Getting the most out of Editoria11y v3
会议演讲: Getting the most out of Editoria11y v3 (YouTube) (查看幻灯片)

高等教育峰会演讲:
Just Annoying Enough:
The Editoria11y Ambient Accessibility Model
(幻灯片)

主要新功能

  • 与 Sa11y 合并检测核心。双方共同开发的新规则集在核心内容检测规则集中加入了开发者检测、对比度检查和可读性评分。
  • 多语言支持
  • 自定义检测项构建工具
  • 仪表板维护工具
  • 用于补充新结果的全站爬取工具。
  • 允许特定检测(例如“这个 PDF 是否无障碍?”)针对特定角色在全站范围内忽略警告。
  • 分离配置:按开发者与内容两类角色区分检测和报告视图。

而对项目的未来来说,也许最重要的是:

v2:忽略与报告

两年前,我们推出了 Editoria11y 无障碍检查器。它是一款开箱即用的 Drupal 网站插件,能自动为作者提供即时反馈,并附上改进内容的实用提示。

我们认为这能填补一项尚未被满足的需求。现有方案都要求经过培训并勤加使用才能发挥作用,而经验告诉我们,在大型组织中培训并监督成千上万名内容作者,并不是解决问题的高效方式。我们确信,这样的项目要想成功,就必须高度自动化:在检测到常见错误时,礼貌地为内容作者提供“即时培训”。

果然奏效。

在 Princeton,它在很大程度上扭转了我的沟通方向。在安装了它的平台上,我们从不断发送千篇一律的邮件、请内容作者改进替代文本、链接或标题,变成了收到内容作者的提问,询问如何改进写法,以免内容频频被标记。

外界的反应则是欣喜若狂:

面向内容作者的最佳 Drupal 无障碍检查器是……Editoria11y
Devcollaborative 对 Drupal 平台各方案的比较得出结论:Editoria11y 是“面向内容作者的最佳无障碍检查器”。
每周项目使用统计图,显示两年内从 0 增长到 2500 以上
使用统计显示,目前已有超过 2,500 个 Drupal 网站在运行 Editoria11y。
YouTube 视频中展示的 Editoria11y 界面
Danielle Sheffler 在 DrupalSouth 上特别介绍了 Editoria11y,称其为“我最喜爱的无障碍模块之一”。

编写自成一体的提示

在 v1 的提示中,我们采用了“摘要与详情”的做法:简短说明问题,并附上详情链接。

相比为开发者编写的工具,这已是一种改进:提示简短明了。但链接到哪里始终是个难题。一些政府和高校用户觉得有必要修改提示,删除指向 Princeton 文档的链接,这给他们增加了额外工作。于是我们重写了默认提示,使其自成一体,并内嵌示例。

事实证明,红色警告(确定的问题)与黄色警告(可能的问题)之间的区别令人困惑,有时还很烦人。

因此我们把黄色警告改为“手动检查”以明确其含义,并添加了按钮,让作者可以忽略警告。“已忽略”的警告仅对点击者隐藏;“标记为无误”的警告则对所有网站编辑隐藏。网站管理员可以选择谁有权限执行这两项操作。

标题为“手动检查:图片没有替代文本”的提示气泡,其中包含一张照片的替代文本示例,以及用于隐藏警告或将其标记为无误的按钮。
新的提示气泡内嵌了关键信息,例如用示例说明替代文本应如何体现图片在上下文中的含义,而不是罗列图中有哪些物体。作者还可以通过按钮忽略警告,因为视上下文而定,内容可能本身就没有问题。

创建仪表板

网站所有者常常感叹:这个工具能很好地发现全站各处的问题,却无法查看全站报告。

重写后新增了一个选项,可将检测结果同步回网站数据库。网站所有者现在可以按页面或问题浏览结果,查看哪些问题已被忽略或标记为无误;如有异议,还可以恢复这些问题!

V2 代码导览(面向开发者)

两张表格,分别列出问题最多的页面和最常见的问题,并附各自的数量。
Drupal 仪表板的一部分,显示问题最多的页面和最常见的问题。

V2 几乎是完全重写。部分新功能包括:

  • 移除 jQuery 依赖后,它可以安装在更多平台上,性能也提升了一倍。
  • 现在可以配置检查器,使其检查页面的多个独立部分(例如文章内容和页脚)。
  • 检查器现在可以检测影子 DOM 内的元素,各种 Web 组件和 JavaScript 库都会用到它。
  • 许多新参数让平台集成更加轻松。例如,如果某些用户不负责某些页面的内容,但仍可能想按需查看结果,就可以为他们自动忽略这些页面上的所有问题。
  • 检查器现在附带多套基础主题,并提供用于自定义颜色的参数。
  • 自动化测试有助于防止代码回归。

2024 年 A11yTalks

视频:Author-friendly Content Quality Assurance with Editoria11y - John Jameson(A11yTalks - 2024 年 6 月)
会议演讲: Author-friendly Content Quality Assurance with Editoria11y (YouTube)

回顾一些历史,并讨论 v3 功能的进展。

Drupal GovCon 2023

视频:Content Creators Want Automatic Accessibility Checks
第 1 场: Content Creators Want Automatic Accessibility Checks (YouTube) (查看幻灯片)

深入探讨 Sa11y 和 Editoria11y 等内联检查器的工作方式,与面向开发者的手动工具和基于爬虫的仪表板有何不同。
议题介绍
视频:Editoria11y v2: Building a Drupal-integrated Accessibility Checker
第 2 场: Editoria11y v2: Building a Drupal-integrated Accessibility Checker (YouTube) (查看幻灯片)

面向开发者的导览,介绍构成 Editoria11y 检查器的 JavaScript、Web 组件、JSON API 和 Drupal 功能。
议题介绍

DrupalCamp NJ 2023

视频:Editoria11y v2: Building a Drupal-integrated Accessibility Checker
会议演讲: Editoria11y v2: Building a Drupal-integrated Accessibility Checker (YouTube)

议题介绍
幻灯片 / 幻灯片(.pdf)

v1:内联帮助

创建高度无障碍的网页内容十分复杂,而且往往要从大量培训开始。

有些习以为常的做法必须加以劝阻:

  • 不应使用表格来制造假分栏
  • 连续文本不应居中或两端对齐
  • 不应仅依靠视觉格式(字重和字号)向用户传达含义,因为用户可能是在收听内容,或在“阅读模式”下浏览

有些新做法必须加以提倡:

  • 图片需要符合上下文、有意义的替代文本
  • 页面需要真正的结构
  • 链接应有意义明确的标题

当然,我们开展的一些培训确实是因为在教授新概念,但总有一刻要问:对新技能的需求有多少是因为概念本身是新的,又有多少是因为我们提出了新要求,却没有更新工具?某样东西是新的,并不意味着它不能是直观的。

拼写史的启示

第一阶段:怪作者

分两栏刻有数百个锥形印记的泥板
一部有 2,100 年历史的苏美尔—阿卡德语词典,共 24 块泥板,此为第 16 块。
© Marie-Lan Nguyen / Wikimedia Commons

从有文字记载的历史开端直到 20 世纪 80 年代初,单词拼错了,我们都怪作者。学会正确拼写是作者自己的责任。

人们怎样提高拼写水平?接下来的话听起来会很耳熟:

  1. 他们去参加培训,跟随家庭教师或在课堂上学习
  2. 他们拿到一份份清单、指南和词典用来学习,这种做法可以追溯到刻在泥板上的古代楔形文字词典。

第二阶段:怪词典

但 20 世纪 80 年代发生了变化,姑且称之为“拼写第二阶段”:最流行的文字处理软件都加入了拼写检查。

那么这场甩锅游戏怎么样了?几乎一夜之间,责任转到了工具身上:

  • 不知道某个词怎么拼?猜一个,盼着能匹配上。如果匹配不上,就怪词典。
  • 用了一个真实存在的词,词典却因为不认识而标出来?嘟囔几句,然后决定是无视下划线,还是右键点击把它加入词典。

拼写检查解决了我们所有的拼写问题吗?当然没有。但它确实有帮助。而且它把大部分负担和责任从作者转移给了机器。

不过,事情还没完……

第三阶段:怪写作工具

近年来又向前迈进了一步:计算机开始替我们拼写了:

  • 预测算法试图猜出下一个词、下一句话,甚至整条短信回复。
  • 自动格式化工具试图把星号、数字和字母转换成列表,把短代码转换成特殊字符和表情符号,等等。
  • 听写工具试图识别语意,从而在同音词之间作出选择。

出了岔子该怪谁?怪工具!

社交媒体聚合平台最爱那种令人尴尬的“我不是这个意思!”截图。

Editoria11y:迈向第二阶段的一步

在培训中,我们经常谈到测试,并介绍几款相当不错的测试工具。这些工具都不可能发现所有问题:像“避免通过颜色或空间指代来解释概念”这样的要求必须由人来检查;工具通常只能发现网站实际问题的不到一半。但在发现编辑内容中的许多常见错误方面,这些工具做得非常好。

不过,存在三个问题:

  1. 大多数是手动工具。内容创作者需要学过如何使用,需要在写作时记得它们的存在,还需要在写完后记得运行。这三个失败点凑在一起,让大量(大部分?)内容未经检查。
  2. 它们标记得太多。它们不只标出作者刚犯的错误,还会标出设计师造成的颜色问题、开发者造成的技术问题,以及仅供参考的结构元素,等等。这就提高了培训的门槛:作者不仅要懂工具,还要学会忽略一长串误报,或者确实存在、但并非他们今天写这篇文章时该负责修复的问题。
  3. 自动化工具往往采用“爬取网站、访问仪表板”的模式。同样,这假定作者已接受过访问仪表板的培训,并且记得这样做。

于是 Princeton 着手打造一种新工具:集成到网站中的自动检查器,只关注常见的编辑错误。

自动化……可不容易。

  1. 自动检查器必须拿捏分寸:太强势,会打断作者、惹人烦躁;太客气,又容易沦为被忽视的背景噪音。
  2. 自动检查器必须具备很高的性能:如果运行时页面卡顿或迟滞,作者就会对它心生反感并将其禁用。
  3. 自动检查器需要对新手友好的提示。对许多作者来说,这将是他们第一次听说能让内容更加无障碍的标记、结构和语言。警告必须使用简单、非技术性的语言,并提供改进内容的实用建议。

于是我们从最接近这些目标的工具入手:Sa11y,出自 Toronto Metropolitan University。我们借鉴了它的检测架构和用户友好的“信息面板加提示气泡”方式,并花了半年时间改造这个工具:让检测始终自动运行,优化性能,调整提示气泡,还创建了一长串配置选项,让开发者能快速将其适配到任何平台。

它现在的样子是这样的:

一个已展开的提示气泡,位于一个包裹着无替代文本图片的链接上,提示此链接对屏幕阅读器而言是静默的
Editoria11y 面板标记出一个没有无障碍文本的链接。

作者登录网站后,Editoria11y 的开关会显示每个页面上问题的数量和类型(通过、需要手动检查、发现可能的问题)。点击后可显示内联高亮和提示。如果错误是新的(因为他们正在查看刚编辑过的页面),面板会自动弹开。

截至 2021 年 3 月,这意味着 Princeton 有 400 多个网站正在自动检查以下内容:

  • 良好的文档大纲
    • 标题跳过层级
    • 标题为空
    • 标题过长
    • 短得可疑、实际上可能是标题的引用块。
  • 文本替代
    • 没有替代文本的图片
    • 替代文本是文件名的图片
    • 替代文本过长的图片
    • 替代文本含冗余词语,如“图片显示”或“照片中是”
    • 链接中的图片,其替代文本似乎在描述图片而不是链接目标
    • 通常需要文本替代的嵌入式可视化内容
  • 有意义的链接
    • 没有文本的链接
    • 以文件名作为标题的链接
    • 只有通用文字的链接:“点击此处”“了解更多”“下载”等
    • 在新窗口中打开但没有外部链接图标的链接
  • 常规质量保证
    • 确保使用列表格式,而不是用星号、数字和字母模拟列表
    • 大量 CAPS LOCK 全大写文本
    • 没有表头的表格,以及使用文档标题(“标题 3”)而非表头(<th>)的表格
    • 指向 PDF 和其他文档的链接,提醒用户检测下载文件的无障碍性,或提供无障碍的替代格式
    • 嵌入视频,提醒用户添加隐藏式字幕
    • 嵌入音频,提醒用户提供文字稿
    • 嵌入社交媒体内容,提醒用户提供 alt 元素

我们已向社区发布 JavaScript 库,创建了开箱即用的 Drupal 集成,并已着手开发开箱即用的 WordPress 集成。

迈向第三阶段:默认无障碍

从很多方面看,Editoria11y 都只是权宜之计。它发现的大多数错误之所以出现,是因为我们对内容作者提出了新要求(“用良好的结构标记内容”),给他们的工具却在鼓励相反的做法。

前进的道路是让创建无障碍内容变得更容易,并尽可能自动化。具体会是什么样子尚不明朗,但可能包括以下这些:

  • 重新思考提供哪些选项。例如:既然我们一直告诉用户不要在网页上使用两端对齐,是不是该让那个“两端对齐”按钮退役了?
  • 重新思考默认选项。例如:大多数内容管理系统中的默认表格都没有表头。用户得自己知道要点击“属性”并添加无障碍功能;也许是时候反过来了?
  • 思考预测式格式化和“工作时的提示”。如果用户把一整行设为粗体,能否建议将其设为标题?如果用户要选择标题,能否猜出他们可能想要的标题级别,而不是给出六个选项?能否针对较难的概念提供即时培训?