Next.js V15 App Router SSR渲染非整洁HTML是否影响无障碍访问？

1. 对无障碍访问的影响 #

肯定会造成问题。不少无障碍工具（尤其是旧版本屏幕阅读器、轻量型辅助软件）不会执行JavaScript，完全依赖页面初始加载的HTML结构识别内容和语义。

比如你给出的<ul>示例里，初始HTML中<time>和<h4>标签只有空的<template>占位符，实际内容藏在页面底部的隐藏<div>里。这类工具会直接读取空标签，视障用户根本获取不到日期、职位名称等关键信息——你做的语义化优化等于失效，完全起不到辅助作用。就算是支持JS的工具，也可能因为内容注入延迟，导致用户操作时出现内容突然加载的混乱情况。

2. 搜索引擎与a11y工具是否默认执行JS #

主流搜索引擎（谷歌、必应）确实会执行JavaScript抓取内容，但存在局限性：

• 抓取时机有延迟，新页面可能需要更长时间才能被完全索引；
• 小众搜索引擎、部分SEO审计工具可能不执行JS，只会读取初始HTML；
• 谷歌的渲染资源有限，复杂页面可能无法完全执行所有JS逻辑。

至于无障碍工具，像Lighthouse这类自动化审计工具会执行JS，但手动审计工具、旧版屏幕阅读器（比如NVDA旧版本）、部分移动设备辅助技术可能不会。依赖JS渲染核心内容，等于把一部分用户和搜索引擎拒之门外。

3. SSR的意义何在？ #

你看到的这种渲染方式，是Next.js 15为优化首屏加载速度和交互延迟采用的「选择性水合」或「流式渲染」变种：

• 服务端确实生成了所有内容，但不会一次性把所有HTML塞进初始页面，而是先发送轻量DOM结构（带<template>占位符），让浏览器更快完成DOM解析和页面渲染；
• 后续通过小脚本把隐藏<div>里的内容注入到对应占位符中，同时完成组件水合，让页面具备交互能力。

这种设计初衷是平衡「服务端渲染的内容完整性」和「首屏性能」——既保证内容能被JS执行后的工具/搜索引擎抓取，又避免首屏加载过大的HTML文件。但代价就是初始HTML失去语义化和可读性，牺牲了不支持JS的场景。

如果你的业务更看重初始HTML的语义化和无障碍兼容性，可以尝试：

• 对关键内容关闭这类延迟注入优化，直接在SSR时渲染完整HTML；
• 改用静态生成（SSG）模式，预渲染完整页面HTML；
• 检查是否误用了客户端组件（比如把本该服务端渲染的组件标记为'use client'），导致内容被延迟加载。

内容的提问来源于stack exchange，提问作者theredled