UX 指南

使用 k-ID API 构建自定义年龄门控时，请遵循这些 UX 指南来创建合规且用户友好的体验。这些建议有助于确保玩家能够顺利完成年龄验证，同时满足监管要求。

何时使用这些指南

当您使用 k-ID API 直接构建自定义年龄门控时，请遵循这些指南。如果您使用的是 k-ID 嵌入式小部件，UX 已经为您处理好了。

年龄输入方法

您的实现应至少支持两种收集玩家年龄的方法：年龄滑块或日期选择器。请检查 /age-gate/get-requirements 端点的 approvedAgeCollectionMethods 字段，以确定玩家所在司法管辖区允许的收集方法。

年龄滑块

年龄滑块为玩家提供了一种简单直观的年龄输入方式。这是大多数司法管辖区推荐的方法。

设计建议：

• 将滑块范围设置为 0 至 35 岁以上（根据 ESRB 指南）
• 以中立状态开始，默认位置设为 0
• 在玩家与滑块交互之前保持继续按钮为非活动状态
• 当玩家调整滑块时清晰显示所选年龄
• 支持键盘导航以确保无障碍访问

移动版：

日期选择器

日期选择器用于收集玩家的完整出生日期。某些司法管辖区要求使用此方法。

设计建议：

• 支持以当地日期格式输入日/月/年
• 为无效日期显示清晰的验证消息
• 使日期格式符合当地惯例（DD/MM/YYYY 或 MM/DD/YYYY）

年龄确认

收集玩家年龄后，在继续之前显示确认屏幕。此步骤有助于防止意外错误并强调准确年龄信息的重要性。

设计建议：

• 清晰地总结输入的年龄或出生日期
• 说明输入的年龄会影响玩家的体验
• 提供明确的选项以返回修改年龄或确认并继续

监护人同意

当玩家低于其所在地区的数字同意年龄时，需要获得监护人的批准。您的 UI 应展示所有三种同意方式以最大化完成率。

同意方式

为监护人提供三种完成同意的选项：

1. 电子邮件：允许玩家输入父母或监护人的电子邮件地址。调用 /challenge/send-email 发送同意请求。

2. 二维码：显示来自 challenge.url 字段的可扫描二维码。监护人用手机扫描即可访问同意门户。

3. 手动输入代码：显示 challenge.oneTimePassword 并引导监护人到 asktoplay.com 输入代码。

设计建议

• 以同等的可见度显示所有三个选项
• 为需要稍后返回的玩家包含"稍后再做"选项
• 添加一次性代码的复制按钮以提高可用性
• 存储 challengeId 以便玩家在同意授予前返回时可以恢复流程

二维码和一次性密码会过期

二维码和一次性密码在 1 小时后过期，必须使用 /challenge/generate-otp API 刷新。请设计您的 UI 以优雅地处理过期情况，提供刷新选项或自动重新生成凭据。有关更多详情，请参阅挑战过期和基于时间的认证。

数据精简模式

如果您的游戏支持数据精简模式，低于数字同意年龄的玩家可以在等待监护人批准期间访问有限的功能。

设计建议：

• 清楚说明数据精简模式下可用的功能
• 解释同意授予后将可用的其他功能
• 提供让玩家检查同意状态或重新发送同意请求的方式

无障碍访问

确保您的自定义年龄门控 UI 符合无障碍访问标准：

要求	实现
键盘导航	所有交互元素可通过键盘访问
屏幕阅读器支持	适当的 ARIA 标签和语义化 HTML
颜色对比度	文本和交互元素具有足够的对比度
点击目标	按钮最小 44×44 像素的点击目标
错误消息	说明如何解决问题的描述性错误消息

相关资源

• 自定义年龄门控快速入门 - 分步实现指南
• 年龄门控 - 年龄门控端点的 API 文档
• 最佳实践 - CDK 集成的通用最佳实践