a11y aria web无障碍标准的窘境 - 如何搭建一个简洁的现代web网页 - 对于前后端生态的思考

a11y官网已失效的链接

见 https://www.a11yproject.com/checklist/#double-check-that-good-proximity-between-content-is-maintained ，the straw test 实际上指向一个已失效的违法网页😂

根本没有多少人关心这个无障碍（甚至是i18n国际化）标准，基本上残障人士的生活成本也比普通人要高很多，这是很难解决的问题。

一次尝试

我希望搭建一个一劳永逸的web模板，作为下次web项目的脚手架，目前方案是：

功能	框架/库	原因
i18n国际化
a11y无障碍	原生html标签与aria	基本没有纯js库来静态渲染aria标签的
直接操作DOM	vue 3.6 vapor mode	vue将从运行时转为编译器，为仪表盘dashboard提供一定的性能提升。 开发者会议视频
探索css最佳写法	tailwind css	对AI友好的，减少token的css预编译库。高级功能仍需回退至 scss
rpc	connect-rpc	减少前后端字段绑定的时间，restful在我工作时感觉多余（全部都用GET/POST，甚至用POST做查询）

前后端都使用ts

好处：api字段定义可共享
坏处：tsc编译可能比其他语言更慢，tsc 语言服务器在大项目下容易卡死。
有一些ts库转向了js + .d.ts的模式，即使tsc支持增量编译。
Bun.js运行时，再一次让ts成为后端语言提供了采纳的可能性。
不过总的来说，还是不建议用ts做后端语言，上限比静态语言低。当业务稳定时，就可以考虑将ts后端重构为静态语言，来减少成本。
这个时候，就需要rpc来快速迁移接口字段了。

SSR服务器渲染

通常是为了首屏加载速度与 SEO 排名，而这里的首屏收益最明显的是偏静态或更新频率不高的网页（如公司首页、产品页、个人博客），而高度动态、每秒刷新的仪表盘类页面通常更适合 CSR客户端渲染。

说到这个，我就想到“云游戏/云渲染”的概念，这本质上也是游戏领域的 SSR（服务器端先生成画面像素，再视频流传输）。

• 端到端操作延迟（input-to-screen) ≈ 网络 RTT（来回） + 编码延迟 + 解码延迟 + 显示延迟 + 输入采样延迟。
  理想 ≤ 40ms（≈ 60fps 下 2–3 帧），极致追求 < 20–30ms
  网络 RTT（ping）通常需控制在 < 40ms（优秀）或 < 20–30ms（极佳）。
• 网络必须高度稳定，2小时内接近 0% 明显卡顿/丢帧。但网络抖动、偶发拥塞、丢包 是云游戏永恒的痛点，即使平均延迟很低，一次尖峰也能毁掉体验——这是物理链路 + 类似TCP重传机制的先天限制，永远难以根治。
• 目前在同城/优化线路下，P2P IPv6 直连常可做到 20–30ms；不支持 P2P 或需打洞中继（TURN）后，一般升到 40–80ms+