用途
富文本编辑器模式帮助团队创建一种可靠的方式，让用户创建格式化文本，同时保持编辑界面可理解、可访问且可安全提交。它最适用于团队需要知识库撰写的场景。
与相邻模式相比，该模式应在不隐藏用户持续操作所需的状态、规则或恢复路径的前提下减少摩擦。
适用场景
- 知识库撰写
- 长文内容创作
- 带格式的内部备注和描述
不适用场景
- 当值是二元的、极小的或完全受限时，使用更简单的原生控件。
- 当原生浏览器输入已能很好地解决主要任务时，避免自定义行为。
- 如果产品无法从额外的格式化或校验中获益，不要添加它们。
实现流程
- 在复制示例之前，确认该模式与问题和约束匹配。
- 从 references/pattern.md 中的结构和示例开始，然后选择最小的可行变体。
- 在叠加视觉打磨之前，先应用无障碍、性能和交互护栏。
- 使用测试指南验证键盘、屏幕阅读器、响应式和失败场景下的行为。
无障碍护栏
键盘交互
- 验证富文本编辑器可以仅用键盘完成操作。
- 当模式打开、更新或显示额外 UI 时，保持焦点顺序合乎逻辑。
- 保持可见的焦点状态，在高倍缩放时仍然可读。
屏幕阅读器支持
- 优先使用语义元素，仅在语义不足时添加 ARIA。
- 在正确的位置以正确的礼貌程度宣布状态变化，如错误、加载或完成。
- 在有用时，使用 aria-describedby 或结构化标题连接标签、提示和状态文本。
视觉可访问性
- 不要仅依赖颜色来传达严重程度、完成或选择状态。
常见错误
使用错误的校验时机
问题：对部分输入立即校验会让模式显得惩罚性和嘈杂。
修复方式：等待用户在字段中有足够信息后，再根据规则风险在失焦、暂停或提交时校验。
分离标签、提示和错误
问题：当文案在视觉上分离时，人们无法判断哪条消息属于哪个控件。
修复方式：保持标签、辅助文本和校验消息紧密分组，并在适当处用 aria-describedby 连接。
忘记触屏和自动填充行为
问题：仅桌面端的样式掩盖了移动键盘、自动填充和粘贴流程行为不同的事实。
修复方式：在宣布模式完成之前，用自动填充、粘贴、缩放和屏幕键盘测试控件。
相关模式
- https://uxpatterns.dev/patterns/forms/button
- https://uxpatterns.dev/patterns/forms/tag-input
- https://uxpatterns.dev/patterns/forms/textarea
完整实现细节、示例和测试说明，请参见 references/pattern.md。
模式页面：https://uxpatterns.dev/patterns/forms/rich-text-editor