【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载导读本文基于 Front-End-Checklist 仓库中的 orientation 技能文档skills/orientation/SKILL.md系统讲解如何让内容与功能在竖屏portrait与横屏landscape两种方向下都保持可用以满足 WCAG 2.1 成功标准 1.3.4 的要求。你将掌握检测方向锁定的方法、用响应式 CSS 替代请旋转设备阻塞层的最佳实践、判定方向必需orientation-essential的边界条件以及完整的双方向验证清单——这些能力可直接应用于移动端优先布局、平板体验、全屏流程、表单与仪表盘等场景的审查与修复。为什么方向锁会挡住真实用户很多用户无法随意旋转设备设备可能被固定在轮椅上、放置在支架上或与辅助硬件assistive hardware绑定。如果网站只在单一方向下可用这些用户可能完全失去访问内容或执行关键操作的能力。WCAG 1.3.4 Orientation 的要求很明确内容与功能必须同时支持竖屏与横屏除非某一特定方向对活动本身是必需的essential。这与 MDN 关于管理屏幕方向的指南的立场一致——设备旋转应当被布局适应而不是被布局阻断。在 Front-End-Checklist 仓库中这一规则被定义在 packages/content/rules/en/accessibility/orientation.mdx其元数据标注为priority: high高优先级、difficulty: intermediate中等难度、预计耗时 20 分钟归类于accessibility与css两个类别下的visual子类别。也就是说方向问题不仅是移动端可用性问题也是视觉呈现层面的可访问性问题评审时应把它与缩放重排zoom-reflow、横向滚动horizontal-scroll、文本缩放text-resizing等规则放在一起看——它们在窄屏与平板场景中常常一起失败。快速参考四条核心准则引用技能文档 skills/orientation/SKILL.md 中的 Quick Reference方向审查的底线是不要将界面锁定为仅竖屏或仅横屏除非任务确实需要确保设备旋转后所有核心内容与控件仍然可用使用能自适应adapt的响应式布局而不是在某一方向下隐藏功能如果某一特定方向是必需的说明原因并提供尽可能好的替代方案。这四条准则覆盖了方向问题的全部三种典型表现orientation lock调用锁定 API、rotate-device overlay旋转提示阻塞层、layout hiding某个方向下布局隐藏了关键功能。如何检查在两种方向下实测技能文档给出了标准检查流程在移动端和平板视口上将页面在竖屏与横屏之间来回旋转验证所有主要内容、导航、表单与交互控件在两种方向下都保持可访问、可用。需要标记的问题包括使用了方向锁定orientation lock存在阻塞内容的请旋转设备rotate-device覆盖层布局在某个方向下隐藏了必需功能。实操时可以直接用浏览器开发者工具的 Device Mode 模拟手机和平板视口分别切换竖屏/横屏逐页route检查。规则源文件 packages/content/rules/en/accessibility/orientation.mdx 的sources字段也推荐了 Chrome DevTools Device Mode 作为工具资源。注意仅验证布局技术上能旋转是不够的要验证的是真实任务能否在两种方向下完成。修复方法适应布局而非阻塞内容❌ 错误做法锁定方向或竖旋转墙以下两种做法是方向可访问性最常见的反面教材出自 skills/orientation/references/rule.md// ❌ 错误没有任务层面的理由就把体验锁定为竖屏 screen.orientation.lock(portrait) // ❌ 错误用通用的请旋转设备墙挡住整个页面 if (window.innerWidth window.innerHeight) { document.body.innerHTML pPlease rotate your device/p }screen.orientation.lock()来自 Screen Orientation API它确实存在合法使用场景但绝大多数内容型、交易型、仪表盘型网站都没有理由调用它。而直接覆写document.body.innerHTML这种粗暴做法会把整页内容替换成一句提示等于在旋转方向上彻底杀死了页面——比一个不完美的自适应布局要糟糕得多。✅ 正确做法用网格与媒体查询自适应修复的核心思路是让布局在两种方向下都换形而不是消失。规则文档提供了一个 checkout结算布局的完整示例/* ✅ 好布局在任一方向下都能自适应 */ .checkout-layout { display: grid; gap: 1rem; grid-template-columns: 1fr; } media (min-width: 768px) { .checkout-layout { grid-template-columns: minmax(0, 2fr) minmax(280px, 1fr); } } .summary, .form-panel { min-width: 0; }main classcheckout-layout section classform-panel !-- 结算表单在竖屏和横屏下都保持可用 -- /section aside classsummary !-- 订单摘要换行显示而不是消失 -- /aside /main这个示例包含三个值得记住的技术细节移动优先mobile-first的单列基线默认grid-template-columns: 1fr窄视口竖屏下一切纵向堆叠min-width: 768px媒体查询横屏手机与平板进入双列布局minmax(0, 2fr)让表单列占据剩余空间minmax(280px, 1fr)让摘要列保持至少 280px 可读宽度min-width: 0防溢出这是网格子项最常见的隐藏陷阱——没有它内容较长的面板如表单、表格会撑破网格轨道产生横向滚动与仓库中horizontal-scroll规则关注的问题直接相关。提示hint而不是阻塞block是可以的如果横屏确实能带来更好的体验比如更宽的图表视图可以给出非阻塞的方向提示但必须确保竖屏下所有控件依然可用p classorientation-tip Landscape gives you a wider chart view, but all controls still work in portrait. /p关键区别在于提示是内容的一部分旋转墙是内容之外的阻塞层。前者可被辅助技术读取、可被跳过后者则挡住了用户与页面的全部交互。为什么这很重要物理约束的现实W3C 对 Orientation 的理解文档Understanding document恰好聚焦于这一问题许多用户无法为了满足某个随意的布局假设而旋转支架上的设备。规则文档总结了四个层面的原因物理约束各不相同设备可能被固定安装、连接辅助硬件或难以旋转平板与手机的用法不同只在一种姿态下可用的布局构成了不必要的障碍方向变化很常见用户会旋转设备来阅读、输入、对比信息或使用分屏应用阻塞层比不完美布局更糟能凑合自适应的内容仍然好过完全消失的内容。最后一条是优先级判断的关键宁可布局在某一方向下不完美也不能让内容在某一方向下不可达。什么时候允许限制方向Orientation-Essential 的边界方向限制只有在活动真正方向必需时才被接受规则文档给出了三类典型例子钢琴键盘类应用必须用横屏才能正确呈现乐器支票存款流程必须与银行的相机取景要求对齐绑定固定方向物理设备或头显的体验。即便属于这些情况也要提供尽可能清晰的解释并且不要锁定网站中与该活动无关的其他部分。换句话说方向必需必须按活动activity粒度判定而不是整站一锁了之。常见错误清单在代码评审中以下五种情况应作为方向问题的重点排查对象引用自 packages/content/rules/en/accessibility/orientation.mdx用请旋转设备覆盖层挡住整个页面在某一方向下隐藏主导航或提交按钮使用旋转后会被压垮的固定高度或固定宽度想当然地把横屏等同于桌面空间而没有在真实平板和小屏手机上测试因为某个组件不方便重新设计而锁定方向而不是因为任务确实需要。代码评审的实操要点技能文档对 Code Review 阶段的要求是审查响应式布局、viewport 处理、覆盖层以及任何与设备旋转相关的 JavaScript。需要标记的对象要精确到具体的选择器、组件或路由状态而非笼统的这个页面方向有问题包括要求某一特定方向的代码如screen.orientation.lock调用旋转后隐藏必需内容的样式如media (orientation: landscape) { .nav { display: none } }显示阻塞式旋转提示消息而非自适应布局的组件。也就是说评审报告应当给出哪个文件、哪个选择器、哪种路由状态触发了方向问题方便开发者直接定位修复。相关规则一起评审的四个邻居规则元数据中的relatedRules字段明确指出方向问题通常与以下四个规则联动出现建议在评审中一并处理zoom-reflow两者都影响响应式可访问性在移动端和平板布局上可能同时失败horizontal-scroll旋转后崩溃的布局通常也会在窄宽度下产生横向溢出text-resizing与方向同属accessibility/visual区域常一起评审dark-mode-css同为accessibility/visual区域视觉类审查的常规组合。异常与豁免不要把规则当成教条规则文档的 Exceptions 部分给出了三条重要的判断原则先评估渲染后的真实体验再决定是否把静态代码的可疑点当作阻塞项交互时机、浏览器行为和辅助技术输出往往决定实际严重程度不必对每个次要问题都给予同等权重优先处理最直接阻碍感知、操作或理解的问题避免为了迎合规则而堆砌多余的标记或 ARIA——如果更简单的语义实现能彻底消除问题就不要画蛇添足。这提醒我们方向问题最终是用户能不能完成任务的问题而不是代码里有没有可疑写法的问题。验证清单五步确认双方向可用方向修复后的验收应当依据 W3C 的 Orientation 理解文档进行——验证的是实际任务而非布局是否技术上转了。完整验证步骤如下在手机和平板尺寸视口上分别以竖屏与横屏测试目标路由确认用户在两种方向下都能触达导航、阅读内容、填写表单并触发关键操作检查是否存在方向锁定 API、阻塞式旋转提示覆盖层或旋转后隐藏必需控件的 CSS如果页面内容密集配合放大或更大字号重新测试——方向与重排reflow失败经常同时出现如果方向限制仍然保留记录其为何对活动必需并验证只有该活动受影响而不是整个站点被锁定。深入原理这份技能文档从何而来值得一提的是Front-End-Checklist 仓库中的每个 skill 并非手写散落而是由脚本从规则 MDX 的前置元数据frontmatter生成的。scripts/generate/generate-skills.ts 中的buildSkillMd函数把规则的aiContext或description、prompts.check、prompts.fix、prompts.explain、prompts.codeReview等内容组装为SKILL.md并写入对应技能目录。生成器对描述有两条硬性约束描述必须以 Use when 开头以适配 Agent 的意图匹配skill-check 要求且长度不低于 50 个字符——你可以对照本技能文件开头的 description 验证这一点。这意味着本篇文章所依据的 skills/orientation/SKILL.md 与其完整版 references/rule.md、规则源文件 packages/content/rules/en/accessibility/orientation.mdx 三者在内容上是同源的SKILL.md 是给 Agent 使用的压缩指令集references/rule.md 是给人工开发者的完整实现指南。当 Agent 在审查移动端布局、平板体验、全屏流程、表单、仪表盘或媒体界面时会基于这份技能在竖屏与横屏下分别检查渲染行为把真实布局约束与不必要的方向假设区分开来——这正是本文全部实践的核心目标。赞分享【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载相关推荐Front-End-Checklist 屏幕方向适配实战基于 WCAG 1.3.4 的横竖屏兼容指南Front End Checklist 屏幕方向适配实战基于 WCAG 1.3.4 的横竖屏兼容指南 本文以 Front End Checklist 仓库的MusicFree响应式布局多设备适配与横竖屏切换处理MusicFree响应式布局多设备适配与横竖屏切换处理 引言移动端音乐播放器的布局挑战 在移动应用开发中响应式布局是确保应用在不同设备尺寸和屏幕方向上都能音视频移动开发插件系统视频号、抖音、小红书一次搞定res-downloader 免费抓包下载完整上手指南视频号、抖音、小红书一次搞定res downloader 免费抓包下载完整上手指南 深夜刷到一段想留下来的视频翻遍菜单也找不到保存按钮想存几张小红书图集桌面应用网络音视频创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考