受众专页 · 酒店业

酒店、餐厅与旅行预订的无障碍合规——专为诉讼最密集的数字行业打造。

酒店业是美国ADA 第三章诉讼最为密集的行业之一——Acheson Hotels v. Laufer 案在 2023 年以争议消失为由被驳回前已提交至最高法院,而基础性无障碍义务丝毫未动。 《欧洲无障碍法案》(EAA)明确将"客运服务"和旅游活动纳入适用范围。本页提供 30 条 WCAG 2.2 AA 检查清单以及各团队在预订引擎、客房描述 PDF 和会员积分门户实际需要的平台说明。

酒店业为何诉讼尤为密集

两个监管体系,数字无障碍领域最密集的诉讼档案之一。

在美国,酒店业是 ADA 第三章诉讼的主要被告行业,与电商和餐饮业并列。连续诉讼律师专门针对预订流程和 客房描述页面——这正是ADA 第三章规定的义务 最明显附着于网页内容之处,而单一无障碍性缺陷的控件可能引发数十起几乎相同的投诉。Acheson Hotels v. Laufer 案一度被认为会限制测试原告的诉讼资格;2023 年 10 月,最高法院以争议消失为由驳回该案,基础性无障碍义务完整保留。

美国司法部关于预订系统的规则(28 CFR 36.302(e))已施加具体义务:识别无障碍客房,以足够详细的方式描述其 无障碍功能以供知情预订,并通过与普通客房相同的渠道提供预订。该规则自 2010 年起生效,无论酒店整体的网页 无障碍状况如何,均可对其执行。应将其作为与 WCAG 并行的独立合规事项对待。

餐饮连锁面临同等性质的风险,菜单是反复出现的诉讼目标。纯 PDF 菜单——从印刷运营沿袭而来的习惯——是 餐厅网站投诉中引用最多的单一问题;指向无障碍性欠缺 PDF 的 QR 码菜单紧随其后。在线点餐和预订流程 (嵌入的 OpenTable、Resy、Tock)在连锁品牌自有营销网站之外又增加了额外的审计面。

在欧盟,《欧洲无障碍法案》在其适用范围列表中 明确列出"客运服务",更广泛的旅游经济则通过各国实施法规涵盖其中。航空公司依据 ECAC 框架和欧盟旅客权利 法规单独受到约束,对预订和值机界面有其自身的技术合规要求。无障碍义务贯穿整个旅行购买旅程,而不仅限于 收取信用卡付款的网站。

OTA 平台——Booking.com、Expedia、Agoda、Trip.com、Hotels.com、Vrbo、Airbnb——对其自有界面承担义务。 酒店不能以向 OTA 提供准确无障碍数据为由规避 28 CFR 36.302(e) 义务,若 OTA 删除或隐藏了这些数据, 酒店作为公共设施仍须承担责任。但 OTA 作为独立数字服务提供商,对其自有网站和应用程序承担独立的 ADA 第三章义务(美国)和 EAA 义务(欧盟)。数据交接的双方均须确保无障碍性。

违规的代价是具体的。酒店和餐厅 ADA 和解金额通常为首次被告 20,000 至 50,000 美元,多次被起诉的对象 支付金额显著更高。在欧盟,执法工作已从 2025 年大部分时间以警告函为主的阶段,进入 2026 年在德国、 法国、意大利、西班牙和荷兰开始开具罚款的阶段。酒店业正处于两大监管体系的核心靶区。

酒店业 30 条检查清单

六个界面 × 五项检查。打印、勾选,再审计。

  1. 01 预订引擎

  2. 02 客房与库存描述

  3. 03 菜单与餐饮

  4. 04 会员积分与账户

  5. 05 地图与位置

  6. 06 客户服务与无障碍住宿申请

各平台实施说明

检查清单在代码层面的落地位置,按平台系列分类。

Sabre / Amadeus / Oracle Hospitality(传统 CRS/PMS)

三大预订核心系统比现代网页无障碍要求早出现数十年,其前端界面通常是机构在 Synxis(Sabre)、 iHotelier(Amadeus)或 OPERA Cloud(Oracle)之上定制的外观层。平台自身的 VPAT 或 EN 301 549 声明几乎无法反映定制外观的实际表现。常见问题包括:日期选择器未暴露 role="grid"、客房卡片网格使用无表格语义的 div 构建,以及价格比较表以定位 span 渲染。 应将平台的无障碍声明视为基准下限,再对定制外观单独审计。

Mews / Cloudbeds / Hotelogix(新一代 PMS)

新一代 PMS 供应商的预订引擎控件通常具有更好的基础语义——真实的表单标签、可聚焦的日期选择器、 价格变动时的 aria-live 区域。问题在于白标主题化层:当品牌定制预订引擎以匹配酒店设计系统时, 提供主题的机构往往会覆盖焦点样式、重新设计日历,从而破坏平台原本的无障碍性。应要求机构提供 无障碍测试协议,而非仅依赖平台的无障碍声明。

SiteMinder / RateGain(渠道管理器)

渠道管理器主要处于后台——将库存分发至 OTA 和 GDS,而非直接服务终端用户。其无障碍义务范围较窄 但确实存在:酒店员工使用的管理控制台须可由残障员工操作;向下游传递的结构化数据(尤其是 28 CFR 36.302(e) 要求的无障碍功能数据载荷)须在映射过程中完整保留。应审计两项内容: 员工端控制台,以及实际传递至 Booking.com、Expedia 和 GDS 端点的数据样本。

OpenTable / Resy / Tock(餐厅预订)

餐厅预订平台通常通过 iframe 或控件脚本嵌入餐厅网站。主要失效模式在于 iframe 边界——跨边界 的焦点管理脆弱,屏幕阅读器的地标结构崩溃,跳过链接也无法到达控件。应先将控件作为独立 URL 审计(多数平台会提供),再审计其嵌入网站后的状态,最后审计回传至本域名的预订确认流程。 需三次审计,而非一次。

Booking.com / Expedia / Trip.com(OTA 平台)

OTA 平台与其所列酒店处于不同的审计周期。作为酒店方,无法审计 Booking.com,但可以审计 库存在该平台的呈现方式,以及通过 SiteMinder 或渠道管理器传递的无障碍功能数据载荷是否 在 OTA 列表中实际渲染。作为 OTA,义务覆盖全部界面:搜索、筛选、列表详情、结账、账户 及移动应用程序。OTA 越来越多地以独立主体身份被列为被告,依据 ADA 第三章和 EAA—— 而非作为酒店义务的派生。

Toast / Square / Lightspeed(POS + 数字菜单)

与 POS 捆绑的数字菜单和 QR 码点餐界面是餐厅无障碍领域最新的诉讼目标。扫码后渲染的菜单 为 HTML,但平台默认模板往往缺少语义化标题、使用无文字等效内容的纯图标过敏原徽章, 并渲染无替代文本的菜品图片。多数平台现已在主题层面提供无障碍设置——应启用这些设置, 然后审计实际渲染输出,而非平台营销页面对菜单效果的截图展示。

监测与审计周期

一次性修复撑不过下一次季节性菜单更新。

酒店业网站处于持续变化中。物业周二上线季节性套餐,餐饮团队周四更换晚餐菜单,营销部门 周末上线节日首图。一次性无障碍修复的有效期大约等同于下一次客房类型上线的周期——这正是 真正有效的模型需要三个层次而非一个的原因。

首先,立即对线上网站运行免费 WCAG 2.2 扫描器,建立预订引擎、 客房描述页面和菜单界面的基准线。其次,针对每次预览构建和每次生产部署接入持续自动化监测—— 这一层能在用户之前发现回归问题,也是大多数团队在收到首封律师函之前所忽略的层次。第三, 至少每年委托一次由残障测试人员完成的 人工审计, 并在重大改版、OTA 集成上线或 PMS 平台迁移后重新进行。自动化工具永远无法发现酒单页面 对屏幕阅读器的可读性问题、多房间预订流程中焦点顺序的设计意图,以及无障碍客房申请流程 是否真正可用至全程。

关于监测与人工审计的交接,我们的 监测平台选购指南 涵盖端到端处理扫描至审计工作流的平台—— Qualibooth、axe Monitor、 Siteimprove 和 Level Access。选型应基于与 CI 的集成契合度,以及平台的人工审计网络是否 真正包含与贵方客人残障情况相符的测试人员——并非所有平台都能做到。对于酒店业团队无法回避 的 PDF 界面(团体价格表、宴会菜单、无障碍声明),应将监测平台与我们的 无障碍 PDF 端到端指南配合使用。

常见问题

酒店业团队在决策前最常提出的问题。

酒店移动应用程序是否属于 ADA 的适用范围?

实践中,是的。联邦法院已多次将 ADA 第三章适用于与公共设施服务相关的移动应用程序——酒店应用程序是其中最典型的例子,因为预订、客房门禁和礼宾等功能均属于以数字方式提供的核心酒店服务。美国司法部已正式表明立场:ADA 适用于公共设施的网络和移动端资产;连续诉讼律师现在也定期对酒店应用程序提起诉讼,与针对酒店网站的诉讼并行。应将 iOS 和 Android 应用程序作为独立于营销网站的审计对象。

美国司法部的预订规则是否要求酒店在第三方 OTA 平台上描述无障碍客房?

28 CFR 36.302(e) 要求酒店识别并描述无障碍客房,提供充分细节以便残障人士判断客房是否满足其需求,并通过与普通客房相同的渠道提供预订。该规则约束作为公共设施的酒店方。实践中,酒店集团将该义务向下传导——将结构化无障碍功能数据传递给 Booking.com、Expedia 及主要 GDS——但若 OTA 删除或隐藏了这些数据,酒店仍承担该义务。应将 OTA 列表视为合规范围,而非他人的问题。

如何制作无障碍 PDF 菜单?

诚实的回答是:不要使用 PDF 菜单。PDF 是驱动点餐且需在带屏幕阅读器的手机上正常运行的文档的错误格式。如果菜单确须以 PDF 提供(出于印刷一致性或监管要求),则必须具备正确的阅读顺序标签、真实文字(而非扫描图片)、价格表的无障碍表格以及装饰性图片的替代文本——请参阅我们的无障碍 PDF 端到端指南。更好的方案是发布 HTML 菜单,将 PDF 作为可选下载提供,不再与 Acrobat 作斗争。

预订引擎中的动态价格筛选是否需要特殊的无障碍处理?

是的。常见的失效模式是静默重新渲染:用户拖动价格筛选滑块,客房列表重新排序,而屏幕阅读器对结果的变化毫无反应。应将结果区域包裹在 aria-live="polite" 容器中,在每次筛选变更后触发播报("12间客房符合您的筛选条件"),并确保焦点停留在合理位置。滑块本身应暴露 role="slider" 以及 aria-valuemin、aria-valuemax 和 aria-valuenow 属性——大多数现代滑块组件已实现这一点,但多数自定义构建的组件尚未实现。

餐饮连锁网站无障碍性不足的诉讼风险有多高?

风险高且集中。餐饮连锁与酒店和电商并列,是 ADA 第三章诉讼中的顶级被告行业。Acheson Hotels v. Laufer 案于 2023 年提交至最高法院,最终以争议消失为由驳回,这意味着基础性无障碍义务从未被削弱——连续诉讼律师仍持续提起诉讼。餐饮行业的特定风险集中在菜单(尤其是纯 PDF 菜单)、在线点餐流程、预订流程(嵌入的 OpenTable / Resy / Tock)以及会员和账户门户。首次被告的和解金额通常在 20,000 至 50,000 美元之间;多次被起诉的对象支付金额会显著更高。

餐厅的 QR 码菜单是否存在无障碍风险?

可能存在,且有两种不同的方式。首先是 QR 码本身:如果阅读菜单的唯一方式是用智能手机摄像头扫描 QR 码,那么手机被锁定、没电或不在身边的顾客将被排除在外——这是服务交付问题,严格来说并非 WCAG 问题,但会导致相同的投诉。其次是 QR 码指向的页面:如果是 PDF,或者是不能被屏幕阅读器渲染的重度 JavaScript 单页应用,那么就只是将无障碍性欠缺的菜单从纸质转移到了手机端。应始终提供纸质或口头替代方案;始终确保链接页面为符合 WCAG 2.2 AA 的真实 HTML。

三个后续步骤

根据贵方物业当前所处阶段选择最适合的起点。

  1. 立即运行免费扫描器

    对任意公开 URL 运行免费 WCAG 2.2 扫描器—— 预订引擎、客房描述页面或餐厅菜单均可。若贵方物业数字界面当前尚无基准线,此为最佳起点。

    打开扫描器 →

  2. 查阅标准原文

    上方 30 条检查清单对应具体的 WCAG 2.2 成功准则。当审计方要求注明某项修复 对应哪条准则时,可使用标准页面进行引用。

    查阅 WCAG 2.2 →

  3. 委托人工审计

    阅读我们关于委托 残障测试人员人工审计 的指南——包括应要求哪些内容、预算如何规划,以及哪些平台拥有真实测试人员网络,哪些是外包转包。

    阅读指南 →