Jelly UI 发布了 1.0 版本，这是一套主打软体质感的 Web Components 组件库。40 个自定义元素，零依赖，一行 <script> 标签就能接入，还内置深色模式、从右到左（RTL）布局和符合 WCAG AA 标准的色彩令牌。按钮按下去有回弹动画，开关滑块像被拉伸的液滴，进度和加载状态也带连续形变。
这类“皮肤系”组件库不新鲜，真正要问的是：软体动效这层视觉效果之下，原生表单控件该有的键盘操作、屏幕阅读器语义和浏览器兼容性，有没有被完整保留。看官网的组件说明，答案是“部分做到了”，不是全部——这正是评估要不要用进正式项目时最该盯住的地方。
40个组件、一个 script 标签：先把架子搭起来
Jelly UI 的接入方式很简单。一个 <jelly-theme> 包裹整棵子树，mode="auto" 跟随系统深浅色。往里塞 <jelly-button>、<jelly-select>、<jelly-dialog> 这类自定义标签就能用。
40 个元素覆盖表单、反馈提示、卡片容器、标签页、弹窗抽屉这些常见场景。官网列出的分类里，表单类控件——输入框、单选、复选、滑块、下拉、分段控制器——占了近一半。
零依赖不是全部：语义得看每个组件怎么写
零依赖的 Web Components 组件库不是新故事。Google 的 Material Web、社区里流传多年的 Shoelace，走的都是同一条路：不绑框架、用原生元素、能嵌进任何前端技术栈。这两个库经过多版本迭代和大量真实项目验证，无障碍问题基本被踩过一遍。Jelly UI 才到 v1.0，差异化押在视觉风格上，工程成熟度暂时没有对照组。
| 维度 | Jelly UI v1.0 | Material Web | Shoelace |
|---|---|---|---|
| 版本积累 | 首个正式版 | 多个大版本迭代 | 多个大版本迭代 |
| 依赖 | 零依赖 | 零依赖 | 零依赖 |
| 设计目标 | 软体动效视觉风格 | 遵循 Material Design 规范 | 通用可组合基础组件 |
| 无障碍验证积累 | 暂无公开验证记录 | 大量真实项目检验过 | 大量真实项目检验过 |
更值得较真的是组件内部怎么实现。官网写明，jelly-button 里包了一个真实的原生 <button>，键盘操作和屏幕阅读器语义直接继承浏览器。jelly-slider 背后也是一个原生 range 输入框，负责表单参与和无障碍语义。
但双滑块的 jelly-range 和下拉框 jelly-select 走的是另一条路。它们按 ARIA 的 slider、combobox/listbox 模式自己写 role 属性和方向键逻辑，不是原生控件套皮。
判断很直接：“零依赖 Web Components”不能等于“无障碍有保障”。得按组件逐个确认，语义到底来自浏览器原生实现，还是开发者自己手写的 ARIA 模式。
零依赖是标配，不是护城河。
色彩达标不是无障碍认证，性能账也没人替你算
WCAG AA 色彩令牌解决的是文字和背景的对比度问题，离“通过完整无障碍认证”还差得远。键盘陷阱、焦点管理、屏幕阅读器在不同浏览器组合下的实际表现，官网信息都没给出验证结果。动效对前庭功能障碍用户是否友好、有没有遵循系统的“减少动态效果”偏好设置，也是空白。
40 个组件里不少带持续动画：骨架屏在形变，加载指示器也在变形，进度条会随进度抖动。效果好看，但放进长列表、复杂仪表盘这类渲染压力大的场景，会不会拖累性能，目前没有第三方数据支撑。零依赖只保证不多下载别的库，不保证运行时开销为零。
对前端和设计系统团队，现实的做法是小范围试用，不要整体替换现有组件库。挑 jelly-button、jelly-select 这类高频组件做键盘导航和屏幕阅读器实测，再决定要不要收进设计系统规范。
对评估采购或采用方案的产品设计负责人，判断标准更直接。如果目标只是短期内做出有辨识度的视觉风格，小范围 POC 没问题。如果项目对无障碍合规有硬性要求——比如政府项目或大型企业客户的验收标准——现在证据还不够，应该等 Jelly UI 出无障碍审计报告或社区实测反馈，不要现在就写进技术选型文档。
接下来最该盯的是三件事：Jelly UI 会不会补一份无障碍审计报告，社区有没有出现键盘和屏幕阅读器的实测反馈，有没有公开的性能和浏览器兼容数据。这三项目前都是空白。