在 Drupal 本地提供 Sa11y：可靠性胜于便利性

抱歉，我需要您提供要翻译的正文内容（除代码块和 URL 之外的文字），才能为您完成简体中文翻译。请把文章的文本粘贴在这里，我会保持原有的 Markdown 格式并只翻译正文部分。

TL;DR — 30 秒版

• 本地 Sa11y 资源提升在受限/CSP 严格环境中的可靠性。
• 权衡在于：您需要自行承担上游更新的维护负担。
• “稳定加载”胜过“默认最新”，更适合编辑可访问性工作流。
• CSP 严格的环境强烈表明应从第一天起就优先使用本地库。

我想为在受限环境、严格 CSP 设置或政府网络中运行的 Drupal 站点提供一种更安全的可访问性集成路径，这些环境下第三方资源的交付可能会悄然失败。可访问性工具只有在始终可用时才有价值；如果您的脚本托管出现波动，您的 QA 信心也会随之下降。

实际的做法很简单：下载 Sa11y 资源，将它们随模块/主题一起发布，并将其作为本地库附加，而不是依赖远程 URL。

flowchart LR
  A[Install/update module] --> B[Store Sa11y CSS/JS locally]
  B --> C[Declare Drupal library]
  C --> D[Attach library where needed]
  D --> E[Run editor QA with stable assets]
  E --> F{New upstream version?}
  F -->|Yes| G[Download + update local copy]
  F -->|No| E

# Example library definition
my_module.sa11y:
  version: 1.x
  css:
    theme:
      css/sa11y.css: {}
  js:
    js/sa11y.min.js: {}
  dependencies:
    - core/drupal

⚠️ 警告：维护权衡
本地资源提升了可靠性，但也将维护工作转移到您身上。如果忘记更新 Sa11y 版本，可能会落后于上游修复。请将上游更新视为周期性的维护任务，而不是一次性设置。

💡 小贴士：核心要点
CSP 严格的环境强烈表明应从第一天起就优先使用本地库。不要等到 CDN 故障在生产环境中破坏您的可访问性工作流时才采取行动。

注意事项

• 当你的部署流程已经处理静态资源版本控制时效果最佳。
• 当团队假设“本地”意味着“永不更新”，并停止跟踪上游更改时会出错。
• 除非你为库更新制定了明确的缓存破坏规则，否则可能与激进的缓存策略冲突。

The Code

没有单独的仓库。这是基于上游 Drupal 讨论的实现评审和集成模式研究，而不是一个独立的构建。

我学到的

• 当合规性或网络控制使 CDN 使用变得脆弱时，本地优先的资产交付是值得的。
• 对于编辑可访问性工作流，“稳定加载”胜过“默认最新”。
• 如果自行托管可访问性工具，应将上游更新视为持续的维护任务，而不是一次性设置。
• CSP 严格的环境强烈表明应从第一天起就优先使用本地库。

信号摘要

为什么这对 Drupal 和 WordPress 很重要

在政府或企业环境中的 Drupal 站点通常会强制执行严格的内容安全策略（Content Security Policies），阻止 CDN 托管的脚本，这使得本地交付 Sa11y 对于在内容编辑期间进行可靠的可访问性审计至关重要。WordPress 团队也面临相同的 CSP 限制，可以使用 wp_enqueue_script 加载捆绑的本地资产，而不是远程 CDN URL，从而采用本地优先的库模式。对于同时维护这两种 CMS 平台的机构来说，统一使用本地可访问性工具可以消除一类“在我的机器上可以工作”的故障，因为 CDN 可用性在预发布和生产环境之间可能不同。

参考文献

• Download and serve Sa11y CSS and JS files locally