Front-End-Checklist 焦点管理实战指南让键盘与屏幕阅读器用户在任何动态交互中都不迷路【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist动态交互弹窗开合、SPA 路由切换、列表增删、表单提交反馈是前端开发中最容易破坏无障碍体验的环节——焦点一旦失控键盘用户会迷失在已关闭的弹窗里、找不到新增内容、甚至被卡死。本文以开源项目 Front-End-Checklist 中focus-management技能skills/focus-management/SKILL.md为骨架系统讲解tabindex-1、focus()、焦点陷阱等核心机制并对照仓库设计系统的真实源码给出可直接落地的 React 实现。读完本文你将掌握四类高频场景的焦点管理方案、与其配套的验证方法并能用项目自带的验证清单独立完成代码审查。问题本质为什么糟糕的焦点管理会让键盘用户失联焦点focus是键盘用户与页面交互的唯一光标。鼠标用户可以随时点击任意位置但键盘用户只能依赖 Tab 键在可聚焦元素之间移动。当页面发生动态变化而焦点没有跟着移动时就会产生三类典型故障找不到新内容SPA 路由切换后页面主体变了但焦点仍停留在旧位置的链接或按钮上被困在已关闭的弹窗模态框关闭后焦点没有返回键盘焦点落在页面上一个已经不存在的元素上用户按 Tab 毫无反应仿佛卡死彻底丢失位置感列表项被删除、表单提交出现错误提示时焦点没有落在任何有意义的容器上屏幕阅读器用户不知道发生了什么。Front-End-Checklist 将这条规则定义为high 优先级、intermediate 难度、约 25 分钟可完成审查定位为无障碍accessibility分类下的键盘keyboard子类与keyboard-navigation、autofocus-avoidance、skip-navigation、focus-order等规则见 packages/content/rules/en/accessibility/共同构成键盘可达性审查体系。快速参考四条黄金法则审查任何动态交互组件前先把这四条法则刻进脑子里弹窗打开时焦点移入弹窗弹窗关闭时焦点返回触发它的元素SPA 导航或动态内容更新后焦点移到新内容上使用tabindex-1让非交互元素可以被程序化聚焦永远不要让焦点丢失到意料之外的位置。技能文件SKILL.md把这四条法则的落地拆成四个审查动作正好对应审查流程的四个阶段阶段任务Check验证打开/关闭弹窗、视图切换、动态内容更新时焦点是否被正确管理Fix使用tabindex、focus()与弹窗焦点陷阱实现正确的焦点管理Explain向团队解释正确的焦点管理如何让键盘与屏幕阅读器用户有效导航动态界面Code Review审查渲染后的标记与交互状态精确指出违反规则的元素、角色、标签、焦点行为或键盘交互并说明如何用浏览器无障碍工具或辅助技术验证修复核心机制tabindex-1 与 focus() 的配合tabindex-1是焦点管理的基石。它有一个反直觉但极其重要的特性元素可以从代码中被focus()聚焦但不会进入 Tab 键的天然导航顺序。这让我们可以把任意div、ul、main等默认不可聚焦的元素变成可编程焦点落点同时又不干扰键盘用户的正常 Tab 流程。其使用模式高度统一// 1. 用 ref 引用目标元素 const containerRef useRefHTMLDivElement(null) // 2. 在正确的时机调用 focus() containerRef.current?.focus()配合role与aria语义如roledialog、rolealerttabindex-1的元素既能接收程序化焦点又能向辅助技术正确宣告自身角色。下面四个场景都建立在这个机制之上。场景一Modal 弹窗的焦点转移与焦点陷阱弹窗是焦点管理最经典也最容易出错的场景需要同时解决三个问题打开时把焦点移入、关闭时把焦点还回去、打开期间把焦点困在弹窗内焦点陷阱。基础实现完整版代码以 references/rule.md 与规则源文件 focus-management.mdx 为准import { useEffect, useRef } from react function Modal({ isOpen, onClose, children }) { const modalRef useRefHTMLDivElement(null) const triggerRef useRefHTMLElement | null(null) useEffect(() { if (isOpen) { // 1. 记录打开弹窗的元素 triggerRef.current document.activeElement as HTMLElement // 2. 把焦点移入弹窗容器 modalRef.current?.focus() } else if (triggerRef.current) { // 3. 关闭时把焦点归还给触发元素 triggerRef.current.focus() } }, [isOpen]) if (!isOpen) return null return ( div ref{modalRef} roledialog aria-modaltrue tabIndex{-1} {children} button onClick{onClose}Close/button /div ) }关键点逐一拆解document.activeElement在弹窗打开瞬间捕获当前焦点元素并存入triggerRef这是归还焦点的依据modalRef.current?.focus()依赖tabIndex{-1}才能对div生效roledialog与aria-modaltrue向屏幕阅读器宣告这是模态对话框背景内容应被忽略useEffect的依赖数组[isOpen]确保只在开关状态变化时执行避免每次渲染都抢焦点。焦点陷阱真实项目如何实现上述示例本身不包含完整的焦点陷阱即 Tab 键在弹窗内循环、不逃逸到背景。生产项目中焦点陷阱通常由成熟的对话框原语库提供。Front-End-Checklist 设计系统的弹窗正是如此——dialog.tsx 整体基于radix-ui/react-dialog封装import * as DialogPrimitive from radix-ui/react-dialog const Dialog DialogPrimitive.Root const DialogTrigger DialogPrimitive.Trigger const DialogPortal DialogPrimitive.Portal const DialogClose DialogPrimitive.CloseRadix Dialog 在渲染层面自动完成了打开时聚焦到弹窗内的第一个可聚焦元素Tab / ShiftTab 在弹窗内部循环不会逃逸到背景页面Esc 关闭弹窗后焦点自动返回触发元素使用 Portal 将弹窗内容提升到 DOM 顶层规避了父级overflow、transform等 CSS 上下文对定位与焦点的干扰。值得注意的是 dialog.tsx 中关闭按钮的实现细节图标X用aria-hiddentrue隐藏真正可访问的名称由视觉隐藏的span classNamesr-onlyClose/span提供确保屏幕阅读器用户能听到Close按钮的名称——这呼应了 SKILL 中先检查原生语义再检查可访问名称的审查顺序。实际业务组件ConfirmDialog设计系统中 confirm-dialog.tsx 是上述 Dialog 的业务化封装展示了焦点管理 API 在真实项目中的用法Dialog open{isOpen} onOpenChange{open (!open ? onCancel() : undefined)} DialogContent showClose classNamemax-w-md onEscapeKeyDown{onCancel} onPointerDownOutside{onCancel} DialogHeader DialogTitle{title}/DialogTitle DialogDescription{description}/DialogDescription /DialogHeader DialogFooter Button variantsecondary onClick{onCancel}{cancelLabel}/Button Button onClick{onConfirm}{confirmLabel}/Button /DialogFooter /DialogContent /Dialog这里onEscapeKeyDown/onPointerDownOutside显式接管了两种关闭路径的取消回调说明焦点管理不只是打开时聚焦关闭路径的一致性同样需要在组件层面闭环。设计系统的测试文件 design-system.test.tsx 中对ConfirmDialog的渲染断言renders dialog actions验证了弹窗内容的可渲染性可在此基础上进一步用 axe 与交互测试断言焦点流向。场景二SPA 路由导航后的焦点迁移SPA 的页面切换不触发整页刷新浏览器不会自动重置焦点。如果不做处理路由跳转后焦点会停留在旧页面的元素上键盘用户听到的仍是已消失内容的上下文。解决方案是在路由变化时把焦点移到新的main内容容器import { useEffect, useRef } from react import { useLocation } from react-router-dom function MainContent({ children }) { const mainRef useRefHTMLElement(null) const location useLocation() useEffect(() { // 路由变化后聚焦主内容容器 mainRef.current?.focus() }, [location.pathname]) return ( main ref{mainRef} tabIndex{-1} {children} /main ) }location.pathname作为依赖保证仅在路由真正变化时触发。实践中更推荐将焦点落到新页面的h1标题而非整个main屏幕阅读器用户能立刻听到页面标题上下文更明确。更完善的做法是配合 skip-link 机制项目中有独立的 skip-navigation 规则让键盘用户可以一步跳过重复导航直接进入内容区。场景三动态内容更新列表项删除删除列表项后被删除元素上的焦点也随之消失浏览器会把焦点丢回body用户瞬间回到起点。正确做法是焦点落到被删项的下一个兄弟项如果没有下一项则回退到上一项列表空了就聚焦列表容器本身。function TodoList({ todos, onDelete }) { const listRef useRefHTMLUListElement(null) const [deletedIndex, setDeletedIndex] useStatenumber | null(null) const handleDelete (index: number) { setDeletedIndex(index) onDelete(index) } useEffect(() { if (deletedIndex ! null) { // 优先聚焦下一项其次上一项最后聚焦列表本身 const items listRef.current?.querySelectorAll(button) const nextItem items?.[deletedIndex] || items?.[deletedIndex - 1] if (nextItem) { nextItem.focus() } else { listRef.current?.focus() } setDeletedIndex(null) } }, [deletedIndex, todos]) return ( ul ref{listRef} tabIndex{-1} {todos.map((todo, index) ( li key{todo.id} {todo.text} button onClick{() handleDelete(index)}Delete/button /li ))} /ul ) }实现要点用deletedIndex状态记录被删项位置在渲染后useEffect执行聚焦querySelectorAll(button)拿到最新的兄弟节点集合此时被删项已从 DOM 移除原索引位置上的元素即下一项兜底逻辑保证列表为空时焦点仍落在tabIndex{-1}的ul上不会逃逸到body。场景四表单提交后的焦点落点表单提交后成功或失败的状态信息往往是动态插入的屏幕阅读器用户可能完全感知不到。方案是把状态区域做成可聚焦容器提交后把焦点移过去并用正确的role宣告状态语义function ContactForm() { const [status, setStatus] useStateidle | success | error(idle) const statusRef useRefHTMLDivElement(null) const handleSubmit async (e: FormEvent) { e.preventDefault() try { await submitForm() setStatus(success) } catch { setStatus(error) } } useEffect(() { if (status ! idle) { statusRef.current?.focus() } }, [status]) return ( form onSubmit{handleSubmit} {/* Form fields */} {status ! idle ( div ref{statusRef} tabIndex{-1} role{status error ? alert : status} {status success ? Message sent! : Please fix errors above} /div )} button typesubmitSend/button /form ) }两个role的语义差异值得注意rolealert错误时会主动打断并立即播报适合需要用户马上处理的错误汇总rolestatus成功时使用无打扰式播报polite适合不打断当前操作的确认信息。错误场景的完整做法还应把焦点移到错误摘要本身或在各出错字段间建立可跳转的关联这与表单相关的 form-labels、form-validation 规则相互呼应。焦点转移速查表无论遇到哪种动态交互对照下表即可确定焦点的目标位置场景焦点应移到弹窗打开弹窗内第一个可聚焦元素弹窗关闭触发弹窗的那个元素SPA 导航主内容标题或内容容器内容被删除前一项 / 后一项 / 父容器表单提交成功消息或错误摘要例外情况与审查边界规则并非一刀切Front-End-Checklist 明确给出了三条例外与边界临时或刻意惰性化的 UI 可以移出焦点顺序但前提是同一状态也必须清晰传达给辅助技术用户例如用aria-hidden时需同步确认相关焦点无法落入隐藏区域相关规则见 aria-hidden-focus焦点问题必须基于渲染后的实际交互来评估不能只看静态标记——路由切换、浮层、JS 时序都可能改变真实行为若一个组件同时存在无标签和焦点断裂两个问题应先修复对用户方向感影响更大的那个而不是罗列一堆次要症状。标准依据实现需对齐以下标准并始终以渲染后的实际体验为准而非只检查源码W3C WAI / WCAG键盘可达性与焦点顺序相关成功标准MDN Accessibilitytabindex、focus()、对话框与焦点管理的权威参考实现细节。仓库中的规则源文件 focus-management.mdx 还维护了完整的元数据优先级、难度、TL;DR、审查提示词、来源标准、相关规则关联这保证了同一规则在网站、技能文件与 AI 审查上下文中的一致表述。验证方法自动化 手动双轨检查自动化检查使用 axe、Lighthouse 或等效的浏览器无障碍工具针对一个有代表性的渲染状态运行检查。注意自动化工具对焦点流向的覆盖有限——它们能检测tabindex使用不当、缺少可访问名称等静态问题但关闭弹窗后焦点是否正确归还这类时序行为必须靠下面的手动检查兜底。手动检查清单以下是原技能文档规定的验收步骤可在任何动态交互组件上逐条执行用键盘打开弹窗 → 焦点应在弹窗内部关闭弹窗 → 焦点应返回触发元素切换 SPA 路由 → 焦点应移到新内容上删除列表项 → 焦点应保持逻辑位置下一项 / 上一项 / 列表容器。建议将以上步骤固化为团队的交互验收流程结合 keyboard-navigation、focus-order、modal-accessibility 等相邻规则共同审查形成完整的键盘可达性防线。小结焦点管理的核心其实只有一句话每一次动态交互都要让焦点有一个明确、合理、用户可预期的下一个落点。以tabindex-1focus()为基本工具弹窗遵循移入—困住—归还闭环SPA 导航聚焦新内容容器列表删除聚焦邻近项表单提交聚焦状态区域优先复用 Radix 这类原语库内置的焦点陷阱能力最后用自动化工具加手动键盘清单双重验证。这套方法论覆盖了 skills/focus-management/SKILL.md 定义的全部审查面也直接适用于你正在开发的任何 React 交互组件。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Front-End-Checklist 焦点管理实战指南：让键盘与屏幕阅读器用户在任何动态交互中都不迷路
Front-End-Checklist 焦点管理实战指南让键盘与屏幕阅读器用户在任何动态交互中都不迷路【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist动态交互弹窗开合、SPA 路由切换、列表增删、表单提交反馈是前端开发中最容易破坏无障碍体验的环节——焦点一旦失控键盘用户会迷失在已关闭的弹窗里、找不到新增内容、甚至被卡死。本文以开源项目 Front-End-Checklist 中focus-management技能skills/focus-management/SKILL.md为骨架系统讲解tabindex-1、focus()、焦点陷阱等核心机制并对照仓库设计系统的真实源码给出可直接落地的 React 实现。读完本文你将掌握四类高频场景的焦点管理方案、与其配套的验证方法并能用项目自带的验证清单独立完成代码审查。问题本质为什么糟糕的焦点管理会让键盘用户失联焦点focus是键盘用户与页面交互的唯一光标。鼠标用户可以随时点击任意位置但键盘用户只能依赖 Tab 键在可聚焦元素之间移动。当页面发生动态变化而焦点没有跟着移动时就会产生三类典型故障找不到新内容SPA 路由切换后页面主体变了但焦点仍停留在旧位置的链接或按钮上被困在已关闭的弹窗模态框关闭后焦点没有返回键盘焦点落在页面上一个已经不存在的元素上用户按 Tab 毫无反应仿佛卡死彻底丢失位置感列表项被删除、表单提交出现错误提示时焦点没有落在任何有意义的容器上屏幕阅读器用户不知道发生了什么。Front-End-Checklist 将这条规则定义为high 优先级、intermediate 难度、约 25 分钟可完成审查定位为无障碍accessibility分类下的键盘keyboard子类与keyboard-navigation、autofocus-avoidance、skip-navigation、focus-order等规则见 packages/content/rules/en/accessibility/共同构成键盘可达性审查体系。快速参考四条黄金法则审查任何动态交互组件前先把这四条法则刻进脑子里弹窗打开时焦点移入弹窗弹窗关闭时焦点返回触发它的元素SPA 导航或动态内容更新后焦点移到新内容上使用tabindex-1让非交互元素可以被程序化聚焦永远不要让焦点丢失到意料之外的位置。技能文件SKILL.md把这四条法则的落地拆成四个审查动作正好对应审查流程的四个阶段阶段任务Check验证打开/关闭弹窗、视图切换、动态内容更新时焦点是否被正确管理Fix使用tabindex、focus()与弹窗焦点陷阱实现正确的焦点管理Explain向团队解释正确的焦点管理如何让键盘与屏幕阅读器用户有效导航动态界面Code Review审查渲染后的标记与交互状态精确指出违反规则的元素、角色、标签、焦点行为或键盘交互并说明如何用浏览器无障碍工具或辅助技术验证修复核心机制tabindex-1 与 focus() 的配合tabindex-1是焦点管理的基石。它有一个反直觉但极其重要的特性元素可以从代码中被focus()聚焦但不会进入 Tab 键的天然导航顺序。这让我们可以把任意div、ul、main等默认不可聚焦的元素变成可编程焦点落点同时又不干扰键盘用户的正常 Tab 流程。其使用模式高度统一// 1. 用 ref 引用目标元素 const containerRef useRefHTMLDivElement(null) // 2. 在正确的时机调用 focus() containerRef.current?.focus()配合role与aria语义如roledialog、rolealerttabindex-1的元素既能接收程序化焦点又能向辅助技术正确宣告自身角色。下面四个场景都建立在这个机制之上。场景一Modal 弹窗的焦点转移与焦点陷阱弹窗是焦点管理最经典也最容易出错的场景需要同时解决三个问题打开时把焦点移入、关闭时把焦点还回去、打开期间把焦点困在弹窗内焦点陷阱。基础实现完整版代码以 references/rule.md 与规则源文件 focus-management.mdx 为准import { useEffect, useRef } from react function Modal({ isOpen, onClose, children }) { const modalRef useRefHTMLDivElement(null) const triggerRef useRefHTMLElement | null(null) useEffect(() { if (isOpen) { // 1. 记录打开弹窗的元素 triggerRef.current document.activeElement as HTMLElement // 2. 把焦点移入弹窗容器 modalRef.current?.focus() } else if (triggerRef.current) { // 3. 关闭时把焦点归还给触发元素 triggerRef.current.focus() } }, [isOpen]) if (!isOpen) return null return ( div ref{modalRef} roledialog aria-modaltrue tabIndex{-1} {children} button onClick{onClose}Close/button /div ) }关键点逐一拆解document.activeElement在弹窗打开瞬间捕获当前焦点元素并存入triggerRef这是归还焦点的依据modalRef.current?.focus()依赖tabIndex{-1}才能对div生效roledialog与aria-modaltrue向屏幕阅读器宣告这是模态对话框背景内容应被忽略useEffect的依赖数组[isOpen]确保只在开关状态变化时执行避免每次渲染都抢焦点。焦点陷阱真实项目如何实现上述示例本身不包含完整的焦点陷阱即 Tab 键在弹窗内循环、不逃逸到背景。生产项目中焦点陷阱通常由成熟的对话框原语库提供。Front-End-Checklist 设计系统的弹窗正是如此——dialog.tsx 整体基于radix-ui/react-dialog封装import * as DialogPrimitive from radix-ui/react-dialog const Dialog DialogPrimitive.Root const DialogTrigger DialogPrimitive.Trigger const DialogPortal DialogPrimitive.Portal const DialogClose DialogPrimitive.CloseRadix Dialog 在渲染层面自动完成了打开时聚焦到弹窗内的第一个可聚焦元素Tab / ShiftTab 在弹窗内部循环不会逃逸到背景页面Esc 关闭弹窗后焦点自动返回触发元素使用 Portal 将弹窗内容提升到 DOM 顶层规避了父级overflow、transform等 CSS 上下文对定位与焦点的干扰。值得注意的是 dialog.tsx 中关闭按钮的实现细节图标X用aria-hiddentrue隐藏真正可访问的名称由视觉隐藏的span classNamesr-onlyClose/span提供确保屏幕阅读器用户能听到Close按钮的名称——这呼应了 SKILL 中先检查原生语义再检查可访问名称的审查顺序。实际业务组件ConfirmDialog设计系统中 confirm-dialog.tsx 是上述 Dialog 的业务化封装展示了焦点管理 API 在真实项目中的用法Dialog open{isOpen} onOpenChange{open (!open ? onCancel() : undefined)} DialogContent showClose classNamemax-w-md onEscapeKeyDown{onCancel} onPointerDownOutside{onCancel} DialogHeader DialogTitle{title}/DialogTitle DialogDescription{description}/DialogDescription /DialogHeader DialogFooter Button variantsecondary onClick{onCancel}{cancelLabel}/Button Button onClick{onConfirm}{confirmLabel}/Button /DialogFooter /DialogContent /Dialog这里onEscapeKeyDown/onPointerDownOutside显式接管了两种关闭路径的取消回调说明焦点管理不只是打开时聚焦关闭路径的一致性同样需要在组件层面闭环。设计系统的测试文件 design-system.test.tsx 中对ConfirmDialog的渲染断言renders dialog actions验证了弹窗内容的可渲染性可在此基础上进一步用 axe 与交互测试断言焦点流向。场景二SPA 路由导航后的焦点迁移SPA 的页面切换不触发整页刷新浏览器不会自动重置焦点。如果不做处理路由跳转后焦点会停留在旧页面的元素上键盘用户听到的仍是已消失内容的上下文。解决方案是在路由变化时把焦点移到新的main内容容器import { useEffect, useRef } from react import { useLocation } from react-router-dom function MainContent({ children }) { const mainRef useRefHTMLElement(null) const location useLocation() useEffect(() { // 路由变化后聚焦主内容容器 mainRef.current?.focus() }, [location.pathname]) return ( main ref{mainRef} tabIndex{-1} {children} /main ) }location.pathname作为依赖保证仅在路由真正变化时触发。实践中更推荐将焦点落到新页面的h1标题而非整个main屏幕阅读器用户能立刻听到页面标题上下文更明确。更完善的做法是配合 skip-link 机制项目中有独立的 skip-navigation 规则让键盘用户可以一步跳过重复导航直接进入内容区。场景三动态内容更新列表项删除删除列表项后被删除元素上的焦点也随之消失浏览器会把焦点丢回body用户瞬间回到起点。正确做法是焦点落到被删项的下一个兄弟项如果没有下一项则回退到上一项列表空了就聚焦列表容器本身。function TodoList({ todos, onDelete }) { const listRef useRefHTMLUListElement(null) const [deletedIndex, setDeletedIndex] useStatenumber | null(null) const handleDelete (index: number) { setDeletedIndex(index) onDelete(index) } useEffect(() { if (deletedIndex ! null) { // 优先聚焦下一项其次上一项最后聚焦列表本身 const items listRef.current?.querySelectorAll(button) const nextItem items?.[deletedIndex] || items?.[deletedIndex - 1] if (nextItem) { nextItem.focus() } else { listRef.current?.focus() } setDeletedIndex(null) } }, [deletedIndex, todos]) return ( ul ref{listRef} tabIndex{-1} {todos.map((todo, index) ( li key{todo.id} {todo.text} button onClick{() handleDelete(index)}Delete/button /li ))} /ul ) }实现要点用deletedIndex状态记录被删项位置在渲染后useEffect执行聚焦querySelectorAll(button)拿到最新的兄弟节点集合此时被删项已从 DOM 移除原索引位置上的元素即下一项兜底逻辑保证列表为空时焦点仍落在tabIndex{-1}的ul上不会逃逸到body。场景四表单提交后的焦点落点表单提交后成功或失败的状态信息往往是动态插入的屏幕阅读器用户可能完全感知不到。方案是把状态区域做成可聚焦容器提交后把焦点移过去并用正确的role宣告状态语义function ContactForm() { const [status, setStatus] useStateidle | success | error(idle) const statusRef useRefHTMLDivElement(null) const handleSubmit async (e: FormEvent) { e.preventDefault() try { await submitForm() setStatus(success) } catch { setStatus(error) } } useEffect(() { if (status ! idle) { statusRef.current?.focus() } }, [status]) return ( form onSubmit{handleSubmit} {/* Form fields */} {status ! idle ( div ref{statusRef} tabIndex{-1} role{status error ? alert : status} {status success ? Message sent! : Please fix errors above} /div )} button typesubmitSend/button /form ) }两个role的语义差异值得注意rolealert错误时会主动打断并立即播报适合需要用户马上处理的错误汇总rolestatus成功时使用无打扰式播报polite适合不打断当前操作的确认信息。错误场景的完整做法还应把焦点移到错误摘要本身或在各出错字段间建立可跳转的关联这与表单相关的 form-labels、form-validation 规则相互呼应。焦点转移速查表无论遇到哪种动态交互对照下表即可确定焦点的目标位置场景焦点应移到弹窗打开弹窗内第一个可聚焦元素弹窗关闭触发弹窗的那个元素SPA 导航主内容标题或内容容器内容被删除前一项 / 后一项 / 父容器表单提交成功消息或错误摘要例外情况与审查边界规则并非一刀切Front-End-Checklist 明确给出了三条例外与边界临时或刻意惰性化的 UI 可以移出焦点顺序但前提是同一状态也必须清晰传达给辅助技术用户例如用aria-hidden时需同步确认相关焦点无法落入隐藏区域相关规则见 aria-hidden-focus焦点问题必须基于渲染后的实际交互来评估不能只看静态标记——路由切换、浮层、JS 时序都可能改变真实行为若一个组件同时存在无标签和焦点断裂两个问题应先修复对用户方向感影响更大的那个而不是罗列一堆次要症状。标准依据实现需对齐以下标准并始终以渲染后的实际体验为准而非只检查源码W3C WAI / WCAG键盘可达性与焦点顺序相关成功标准MDN Accessibilitytabindex、focus()、对话框与焦点管理的权威参考实现细节。仓库中的规则源文件 focus-management.mdx 还维护了完整的元数据优先级、难度、TL;DR、审查提示词、来源标准、相关规则关联这保证了同一规则在网站、技能文件与 AI 审查上下文中的一致表述。验证方法自动化 手动双轨检查自动化检查使用 axe、Lighthouse 或等效的浏览器无障碍工具针对一个有代表性的渲染状态运行检查。注意自动化工具对焦点流向的覆盖有限——它们能检测tabindex使用不当、缺少可访问名称等静态问题但关闭弹窗后焦点是否正确归还这类时序行为必须靠下面的手动检查兜底。手动检查清单以下是原技能文档规定的验收步骤可在任何动态交互组件上逐条执行用键盘打开弹窗 → 焦点应在弹窗内部关闭弹窗 → 焦点应返回触发元素切换 SPA 路由 → 焦点应移到新内容上删除列表项 → 焦点应保持逻辑位置下一项 / 上一项 / 列表容器。建议将以上步骤固化为团队的交互验收流程结合 keyboard-navigation、focus-order、modal-accessibility 等相邻规则共同审查形成完整的键盘可达性防线。小结焦点管理的核心其实只有一句话每一次动态交互都要让焦点有一个明确、合理、用户可预期的下一个落点。以tabindex-1focus()为基本工具弹窗遵循移入—困住—归还闭环SPA 导航聚焦新内容容器列表删除聚焦邻近项表单提交聚焦状态区域优先复用 Radix 这类原语库内置的焦点陷阱能力最后用自动化工具加手动键盘清单双重验证。这套方法论覆盖了 skills/focus-management/SKILL.md 定义的全部审查面也直接适用于你正在开发的任何 React 交互组件。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
