如果你想从零创建一个按钮，你必须先创建宇宙
在现代 Web 上，从零重新创建像按钮这样简单的东西，会暴露出原生 HTML 控件已经提供了多少行为、无障碍能力以及跨设备细节——也说明把这些细节做错有多容易。评论者围绕为什么更丰富的原生组件（例如真正的组合框）几十年来几乎停滞不前展开争论，原因包括浏览器政治、像 Web Components 这样的尴尬标准，以及“文档型”HTML 与类应用界面的张力。无障碍既被视为真实的技术与伦理问题，也被视为法律雷区；有人认为 AI 和更智能的工具很快就能处理其中大部分复杂性，而另一些人警告，把这些交给不透明的代理可能会让可用性、隐私和可靠性变得更糟。
讽刺、按钮与无障碍复杂性
- 许多人认为这篇文章尽管以讽刺方式呈现，但内容是准确的：重新实现一个合格的按钮出乎意料地困难。
- 一些读者觉得它很有教育意义，因为他们一直依赖框架，并不了解许多无障碍方面的考量。
- 另一些人指出，示例代码仍然有 bug（例如，指针/鼠标松开逻辑不正确），这反而强化了这一观点：把这件事“做对”很棘手。
原生 HTML vs 自定义组件与缺失的小部件
- 有几位评论者认为，复杂的小部件（例如带服务器端过滤的组合框）很难或几乎不可能仅用原生 HTML 实现，这迫使开发者转向自定义实现。
<input>+<datalist>被提及为一种部分的组合框方案，但动态/高效更新以及更丰富的行为仍然存在空缺。- 让人沮丧的是，HTML 直到今天仍然缺少许多高级小部件，而这些在原生工具包中几十年前就已经存在。
浏览器厂商、标准与停滞
- 有些人把原生、无需 JavaScript 的 HTML 组件进展缓慢归咎于所有主流浏览器。
- 也有人反驳“只有 Apple 在阻碍进展”的说法，指出像 Open UI 这样的标准，以及对速度与安全不同的理念。
- 讨论中提到 Safari 拒绝支持扩展内建类（例如
class MyButton extends HTMLButtonElement）；批评者认为这迫使开发者完全重新实现，而不是轻量定制。
Web vs “语义网”与应用需求
- 评论者区分了以文档为中心的“语义网”和高度交互的 Web 应用。
- 业务和 UX 需求往往与原生表单控件所提供的能力不同；用纯原生元素满足这些期望被认为不切实际或成本过高。
AI 对 UI 与无障碍的影响
- 一方声称，AI 现在已经能轻松从零生成复杂且无障碍的组件和测试，这削弱了“不要重复造按钮”的论点。
- 另一方则反驳说，AI 会重复常见错误（例如把按钮误用于导航），不会自动覆盖所有边缘情况，而且还可能鼓励代码膨胀。
- 有些人表示，要求 LLM 为现有应用补做无障碍改造时体验不错；也有人担心，基于“糟糕代码”训练出来的模型会传播坏模式。
无障碍合规、诉讼与“套路”担忧
- 有人分享了一起无障碍诉讼的故事：结果是昂贵且大多流于表面的改动，以及持续的“合规”订阅。
- 讨论中还争论：未来的 AI 屏幕阅读器/代理是否会让严格的技术合规变得不那么重要，还是法律与激励机制会继续维持现有体系。