<noscript> 标签本身不提升可访问性，仅提供 JS 禁用时的静态 HTML 后备内容；其无障碍效果完全取决于内部语义化、结构化和功能完整的 HTML 编写。
noscript 标签本身不提升可访问性，只提供静态后备内容
noscript 不是无障碍增强手段，它只是浏览器在 JS 完全禁用时渲染的一块纯 HTML 片段。屏幕阅读器能否读取它，取决于里面写的是否是语义化、有结构的内容——noscript 自身不带任何可访问性属性，也不触发焦点管理、键盘导航或 ARIA 行为。
常见错误是往里面塞一句 <p>请启用 JavaScript</p>：这句话对视障用户毫无价值，既没说明功能上下文，也没提供替代操作路径。
- 它不参与 DOM 构建流程，不会被
aria-live监听，也不会响应tabindex或焦点事件 - 如果里面只有
<div>登录失败</div>，屏幕阅读器会读作“登录失败”，但用户不知道这是表单区域、无法按 Enter 提交、也看不到关联的输入框 - 写
<img src="chart.png" alt="Q2 销售增长 12%">是安全且有效的；写<canvas></canvas>加一段文字说明则无效——canvas在无 JS 环境下本就不可见，文字若没包裹在语义标签里，可访问性仍为零
真正影响无障碍的是 noscript 里的 HTML 写法，不是标签本身
可访问性由内容决定，而非容器。把 noscript 当成普通 <section> 来写，才可能起作用：
- 用
<form method="post" action="/login">替代<button onclick="login()">，确保提交能走原生 HTTP 请求 - 链接必须带真实
href，不能只靠onclick模拟跳转；否则 JS 禁用后，<a>变成不可点击的纯文本 - 关键信息（如联系方式、产品参数）要直出，别依赖 JS 注入；否则
noscript区域里空着，用户什么也得不到 - 避免嵌套在
<div id="app">内部——JS 禁用时整个 div 不渲染，noscript被连带吞掉
noscript 在现代框架项目中基本失效，别指望它兜底
React/Vue 默认 CSR（客户端渲染），<body> 初始为空。JS 被禁用 → 页面白屏 → noscript 根本没机会解析，更别说渲染。Next.js/Nuxt 等支持 SSR 的框架，只有在服务端输出的 HTML 中包含 noscript，它才可能生效。
立即学习“前端免费学习笔记（深入）”；
- create-react-app 默认模式下，
noscript放在 public/index.html 里，但实际 DOM 是 JS 注入的，禁用 JS 后页面仍是空白 - SSR 模板里硬塞的
noscript，服务端不会“执行”它——它只是字符串，得靠浏览器解析；而浏览器 JS 关了，就只渲染初始 HTML 中已存在的部分 - 检查是否真生效，唯一方式是手动关闭 Chrome 的
chrome://settings/content/javascript后刷新，别信本地开发时的模拟
比 noscript 更可靠的无障碍兜底是语义化 HTML + SSR + 静态 fallback
依赖 noscript 等于把可访问性押在“用户主动关 JS”这个极小概率事件上。现实中更多问题是 JS 加载失败、CSP 拦截、网络中断或执行崩溃——这些场景 noscript 完全无感。
- 所有交互元素优先用原生语义标签：
<button>、<input type="submit">、<select>，它们自带键盘支持和屏幕阅读器识别 - 关键区块（如搜索、导航、主内容）必须在 SSR 输出的 HTML 中直出，而不是等 JS 注入
- 构建阶段生成独立的
fallback.html，内联样式、硬编码内容、禁用所有<script>，由 Nginx 或 Spring Boot 在 5xx 时直接返回 -
noscript若还保留，应紧贴功能区块放置（如登录表单下方），而非堆在<head>里——用户刷不出页面，根本看不到那行字
noscript，不代表你做了无障碍；你放了文字，不代表它可被理解；你部署了 SSR，不代表 noscript 就自动可用——它始终是一块静态内容区域，写得再全，缺语义、缺结构、缺替代操作，对残障用户就是一道新障碍。 
