我一直在思考网站上的**声音**。
当我们谈论在网站上使用声音时，我们大多数人都会皱眉，想起过去网站加载时播放的刺耳背景音乐。
今天，这已经不再是，也不需要成为一种现象。我们可以巧妙地运用声音。我们现在有了Web 音频 API，它让我们能够很好地控制如何在 Web 应用程序中设计声音。
在这篇文章中，我们将尝试一个简单的例子：**一个表单**。
如果在填写表单时，它除了提供视觉反馈外，还提供听觉反馈呢？我能看到你们在皱眉！但请给我一点时间。
我们已经在使用的数字产品中拥有大量的听觉反馈。手机上的键盘会发出敲击声。即使您关闭了“消息已收到”的声音，您也很有可能听到手机振动。我的 MacBook 在我重启时会发出声音，游戏主机也是如此。听觉反馈无处不在，并且已经很好地集成，以至于我们并没有真正考虑它。您上次什么时候因为微波炉的蜂鸣声而皱眉？我敢打赌您很高兴不用盯着它就能知道它什么时候做好了。
当我写这篇文章的时候，我的电脑正好发出蜂鸣声。我打开的一个标签页给我发送了一个有用的通知。我的意思是声音可以很有用。我们可能并不都需要用耳朵来判断我们是否正确填写了表单，但可能有很多人会发现它很有帮助。
所以我要尝试一下！
为什么现在？我们现在拥有了触手可及的能力。我已经提到了Web 音频 API，我们可以使用它来创建/加载和播放声音。将它与HTML 表单验证功能结合起来，我们应该就可以开始了。
让我们从一个简单的表单开始。
这是一个简单的注册表单。
查看示例 简单表单 by Chris Coyier (@chriscoyier) on CodePen.
我们可以使用非常强大的验证功能来连接这个表单。
利用从 Chris Ferdinandi 的表单验证指南中学到的所有知识，这里有一个带有验证功能的表单版本。
查看示例 带验证功能的简单表单 by Chris Coyier (@chriscoyier) on CodePen.
准备声音
我们不希望听到令人讨厌的刺耳声音，但我们确实希望这些声音能够代表成功和失败。一个简单的方法是使用更高、更明亮的声音，向上代表成功，使用更低、更失真 的声音，向下代表失败。这仍然给了我们非常广泛的选择，但这是一个通用的声音设计模式。
使用Web 音频 API，我们可以在浏览器中创建声音。以下是播放正面和负面声音的小函数示例。
查看示例 创建声音 by Chris Coyier (@chriscoyier) on CodePen.
这些是使用振荡器创建声音的示例，这很酷，因为它不需要任何 Web 请求。您实际上是在编写声音代码。这有点像声音世界的 SVG。它可能很有趣，但它可能需要很多工作和很多代码。
当我玩这个想法时，Facebook 发布了他们的SoundKit，它是
为了帮助设计师探索声音如何影响他们的设计，Facebook 设计团队创建了一系列用于原型交互的声音。
以下是从中选择一些声音并播放它们的示例。
查看示例 播放声音文件 by Chris Coyier (@chriscoyier) on CodePen.
另一种方法是获取声音文件并使用audioBufferSourceNode。由于我们使用的是小文件，因此这里没有太多开销，但是上面的演示会在每次播放时从网络上获取文件。如果我们将声音放在缓冲区中，就不必这样做。
弄清楚何时播放声音
将声音添加到表单的这个实验引发了许多关于在界面中使用声音的 UX 问题。
到目前为止，我们有两个声音，一个正面/成功声音和一个负面/失败声音。很明显，我们会播放这些声音来提醒用户这些情况。但具体在什么时候呢？
以下是一些思考的问题：
- 我们是为所有人播放声音，还是用户可以选择？选择退出？是否有可以用来确定默认设置的 API 或媒体查询？
- 我们是在表单提交时播放成功和失败的声音，还是在单个输入级别播放？或者甚至是在组/字段集/页面级别播放？
- 如果我们为每个输入播放声音，我们应该在什么时候播放？在
blur事件中吗？ - 我们是否在每次
blur事件中播放声音？成功和失败声音的逻辑是否不同，例如只播放一次失败声音，直到它被修正？
对于这些问题，还没有非常确定的最佳实践。我们所能做的就是做出明智的选择并进行用户研究。**也就是说，这篇文章中的示例只是想法，而不是金科玉律。**
演示
这里有一个！
这里还有一个带有声音的工作视频
语音
Greg Genovese 有一篇关于表单验证和屏幕阅读器的文章。“阅读器”在这里很重要，因为这完全是关于音频的！我们可以用 aria 角色、移动焦点等方法来确保错误信息清晰，并且明确如何修正它们。
Web 音频 API 也可以在其中发挥作用，或者更可能的是Web 语音 API。表单验证的音频反馈并不局限于屏幕阅读器软件。尝试朗读实际的错误信息，也许与我们在这里尝试的其他的声音结合起来，肯定会很有趣。
想法
所有这些都属于我所谓的**Web 设计中的声音设计**。这不仅仅是播放音乐和声音，而是像对待设计和构建的任何其他方面一样，对声音环境进行思考、规划和设计。
关于这个主题还有很多话要说，还有很多方法可以将声音应用到您的设计中。让我们谈谈它！
我可以继续说下去，但这样听起来越来越消极了，这与我的本意不符。我不是想要尖刻或粗鲁。这是一篇关于使用声音的有用文章。我不赞成这种用例，也不相信我们的世界充满了蜂鸣声，也不应该充满了蜂鸣声。
很棒的文章！我同意我们在网络上对音频存在不必要的顾虑。有趣的是，我们在桌面或移动应用程序上对音频反馈没有同样的顾虑。两年前我在 Fluent 上做了一个关于这种音频反馈的演讲（https://www.safaribooksonline.com/library/view/fluent-conference-2015/9781491927786/video213375.html），但尽管网络音频有了长足的发展，但变化并不大——我们仍然主要害怕使用它。
谢谢，很棒的文章。
同意，这肯定可以以非侵入式的方式实现。
操作系统可以做到，为什么 UA 不行呢 ;-)
作为一名视障人士，我发现公交车站的标志，当它们将视觉和听觉提示结合在一起时，比单一提示指标要好得多。
我得承认，当我看到标题的时候，我非常怀疑。我认为在可访问性方面，这只会是一场噩梦。用 VO 检查后，它并没有我想象的那么令人讨厌。我认为，随着广泛的采用和一致性，这将是一个额外的优势。否则，我认为我们将不得不教育用户，声音 1 是好的，声音 2 是不好的。有趣的文章。
我认为只有负面声音会不那么烦人。我不同意网络上的所有声音都很烦人，但频繁的声音肯定很烦人，而且由于人们普遍认为它们很烦人，将它们与离开输入联系起来会让人感觉像是惩罚。所以也许它们应该只与你搞砸了，应该受到惩罚的输入相关联！无论哪种方式，那个积极的叮当声都是不停的，如果我必须填写一个超过三个字段的表格，我会把声音关掉。
关于微波炉的说明：我目前没有微波炉，因为人们在评论或比较中往往不会注意到它们的蜂鸣声有多大，所以我觉得很难买到微波炉。我以前的那个听起来像卡车倒车，我再也忍受不了了。我宁愿买一个煮完后不会发出声音的微波炉——它本身就一直在嗡嗡作响。
完全偏离主题，我们拥有的一些微波炉有一个选项（尽管有时被隐藏了）可以禁用所有蜂鸣声。当我们的孩子还小的时候，任何奇怪的声音都会把他们吵醒，我们就把刺耳的蜂鸣声禁用了。所以你不必放弃微波炉，只要买一个可以让你关闭声音的微波炉就行了。
（虽然我的补充已经偏离主题，但就目前而言，在我们现在的微波炉上，它禁用了*所有*蜂鸣声，包括与烹饪计时器不同的倒计时计时器，这使得它成为了世界上最无用的倒计时计时器，除非你在整个倒计时过程中盯着它看。不过对于这一点，我可以切换到使用手机上的倒计时计时器，享受微波炉的寂静。）
我也非常怀疑——但读完这篇文章并看了演示之后，我确实看到了考虑声音的优点。但最终，我仍然不会在任何项目中实现它。需要考虑的因素太多了。
用户是否期望音频，以及如果他们不期望，他们的反应会是什么。
音频是否产生了预期的结果（即用户听到声音，知道有什么问题）而不是不希望的结果（即用户将声音与手机通知联系起来，查看是否有短信，或者认为他们的烟雾报警器电池没电了，等等等等）。
基于操作系统通知中音频的普遍性而支持这一观点的论点似乎忽视了一个事实，即这些系统提供了无数选项来控制这些音频——有充分的理由：调动另一种感官可能会产生混合的结果。
一些用户会发现它是一种受欢迎的提醒方式。而另一些人会被分散注意力，甚至感到不安；声音不受欢迎，甚至在某些情况下不合适。
这种方法的最大优势（调动另一种感官来帮助用户）同样也是其最大的缺陷。
我认为最大的区别因素是声音的侵入性。一个微妙的，音量很低，你几乎听不到的“你做到了”的啾啾声，或者“抱歉，伙计”的悲伤小号声，会带来与微妙的淡入淡出或运动动画相同的舒适感。但是，就像动画一样，很容易过头。就像我不希望我的动画干扰我的工作或注意力一样，声音也不应该干扰。
感谢大家参与讨论！
对我来说，最有趣的考虑因素实际上是“界面上的音频是侵入性的还是增强性的，有帮助的？”而且是的，我认为这归结于大多数人以某种方式提到的内容，声音的类型以及我们使用它的时候。绝对地@goose，没有人喜欢重复的卡车倒车蜂鸣声，但有了 Web Audio API 的功能范围，我们没有理由制作侵入性的声音 :)
我们还可以考虑更大的 UX 图像——比如静音切换。是的，@aminimalanimal，只产生一个小错误声音可能更合适，也更不令人讨厌 :)
还有@Brian Rinaldi，我正在查看那个演讲——因为它和我上次在 CSS Day 上的演讲基本上是一样的。我们多少会期望并在操作系统级别、软件和应用程序中接受声音，但一旦我们转向浏览器，它就成了文化上不可接受的。
也许又回到了静音切换……
对我来说，这看起来很有希望。当电子商务界尝试并测试这种类型的反馈并看到它对转化率的影响时，我们很快就会得到一些最佳实践。
我们避免声音，因为它在大多数情况下都很烦人。举手，如果你喜欢自动播放视频。
但是，声音可能是改善可访问性的一个好工具。振动也是——Apple 使用触觉反馈来指示成功和错误状态。
为了避免烦人的因素，我认为将声音和振动与用户媒体查询（如 reduced motion 查询）结合起来，可能是提高可访问性的一个重大胜利。
Earcons（我知道这些音频提示的名称）会产生很多观点。我也有自己的观点，一些是基于研究和测试的，一些是仅仅作为用户得到的。我不会让每个人都听到这些。
我正在链接一个我制作的演示视频，该视频是在 NVDA 2017.3 和 Firefox 55 中观看的，因为我认为很少有读者有这种设置：http://adrianroselli.com/wp-content/uploads/2017/09/CSS-tricks_form-validation-web-audio_NVDA-FF.mp4
我并没有说这是好还是坏，因为这取决于许多因素（用户、上下文、音频选择、技术实现等等）。至少，我认为用屏幕阅读器（以非常慢的语速）听到它可能有助于了解屏幕阅读器用户如何体验它。
我发现了一个问题——当我从提交按钮中 Shift + Tab 时。离开提交按钮会触发成功声音。如果我是一个屏幕阅读器用户，我直到到达提交按钮才会知道我搞砸了最后一个字段，因此当我 Shift + Tab 时，成功声音可能会让人感到困惑。
与音频部分无关，多年来进行可用性研究后的一些（未经请求的）建议：1. 避免在用户只是将焦点放到一个字段上时将其标记为错误；2. 错误消息应该识别受影响的字段（我知道这只是一个演示）；3. 我很喜欢你使用
aria-describedby来将这些错误消息与字段关联起来。感谢你添加了这一点。