用清楚的链接名称改善邮件与网页

三个相同名称让人猜测

活动邮件包含日程、报名和地点。如果每个链接都叫这里或更多信息，读者必须查看周围文字才知道会打开什么。短地址也不一定说明用途：字符更少，仍可能是一串不透明代码。选择颜色和按钮之前，先说清任务和资源。活动日程、活动报名、会面地点可以区分选项，不必让读者解释短链接代码。文字应帮助选择，而不只是宣布可以点击。

查阅的问题显示，人们确实困惑于通用短语和指向不同页面的多个阅读更多。本文是编辑和功能检查，不是无障碍认证。W3C说明，用途可以由文本或程序可确定的上下文识别；名称本身有描述性是一种有用技术，不代表每个这里都自动不合格。无需让每个链接变成完整句子，只要选项可辨认、忠于内容，并适合受众。不要把实用改善误当成整体合规保证。

区分显示名称与实际地址

链接有目标和呈现方式。HTML示例中，href是虚构地址，西班牙语文字表示活动日程。域名无法使用，实际使用前应替换地址和名称。MDN将带href的a元素描述为超链接，并建议文字说明目标。邮件编辑器支持插入链接时，先写合适名称，再分配检查过的地址。不要为了匹配标签文字而修改URL自身的标识符。示例解释机制，不要求所有语言使用同一名称，也不提供可用文件。

名称要忠于实际动作。如果打开日程页面，不要承诺立即下载。目标是文件时，可在有助判断时说明格式，不编造大小或可用性。不同选项使用可区别名称，同一资源重复时保持一致。W3C G91用链接文本描述用途，便于把选项当成列表检查，但不意味着所有辅助技术或邮件客户端总有相同界面。名称应支持实际任务，而不是依赖某种被假设为通用的阅读模式。

<a href="https://example.invalid/programa/">Programa de la jornada</a>

检查公开目标和最终消息

插入链接前，只把不含秘密的公开目标提交给WikiURL。查看响应和检测到的最终目标，再打开页面确认资源、日期和内容。不要提交私人管理链接、令牌或个人数据。HTTP状态不评估名称是否准确，200也不证明所有读者都有权限。技术检查和文字审阅回答不同问题。先记录获准目标，再制作分发链接，未来修改才有明确依据。正确地址仍可能配着难懂的文字。

如需短地址，从已验证公开目标在WikiURL创建，然后在支持命名链接的编辑器里放到描述性文字后面，再测试最终结果。短链接服务不会自动替每个应用生成易懂名称，也不会改写邮件。有些渠道只显示地址，应配简短说明。不要让标签看起来像与真实目标不同的官方地址。清楚用途应帮助知情选择，而不是隐藏读者识别目标所需的信息。短链接也是实际路径的一部分，需要测试。

按受众实际使用方式检查

先只读最终消息里的链接名称：不用重读段落，能区分日程、报名和地点吗？如果用词依赖组织者才知道的事情，请其他人再读。还要检查视觉上能否辨认为链接，以及发布环境中能否用键盘到达并激活。清楚名称不能单独修复焦点、对比度或错误控件。不要用没有功能目标的仿按钮文字替代真实链接。这些实用试验不代替完整无障碍评估，而是揭示仅靠文字或地址检查无法排除的问题。

向自己的邮箱发送测试或导出文件后，重新打开收到的版本检查目标，不只看编辑器。使用辅助技术时，也检查实际播报名称；视觉修改不保证无障碍名称正确。不要以互相矛盾的隐藏标签自动修补含糊文字。把获准地址、名称和最终测试记录放一起，便于更新。完成标准是可识别选项通向预期内容。WikiURL帮助处理地址，作者仍负责解释每个用途并验证实际分发材料。