1

我在一个多语言网站上工作，其中包含许多通常不写的语言，我想知道是否有任何方法可以让使用屏幕阅读器的人使用它？是否可以为文本赋予属性以使屏幕阅读器播放预先录制的声音，而不是尝试自行阅读文本？

整个菜单系统将被翻译成任何屏幕阅读器都不支持的语言。

4

4 回答 4

2

两种流行的屏幕阅读器是 JAWS 和 NVDA。您可以查看JAWS 支持的语言，总共 28 种。NVDA 支持 43 种语言（我找不到列表）。

我想知道是否有任何方法可以让使用屏幕阅读器的人使用它

您可以想到一些事情：

  • 通过 声明页面的语言<body lang="">，这样如果屏幕阅读器碰巧知道如何解释它，它就会使用该语言
  • 将通用语言翻译的链接放在页面顶部附近，这样如果有人从搜索引擎命中随机访问页面，他们可以快速更改语言。

是否可以为文本赋予属性以使屏幕阅读器播放预先录制的声音，而不是尝试自行阅读文本？

如果屏幕阅读器能够理解，该lang属性会使屏幕阅读器切换到另一种语言。您可以提供要收听的音频文件的链接，我会谨慎提供您自己的音频播放器。并非所有音频播放器都可以访问，这两个常见问题是控件未标记，它们会导致焦点陷阱。

未标记的控件使辅助技术说“未标记”或类似的东西，因此您无法将按钮彼此区分开来。焦点陷阱影响使用键盘导航页面的人，这通常是使用Tab键，而不是离开音频播放器，而是再次进入音频播放器的第一个元素。

来自评论

如何让屏幕阅读器播放这些文件而不是尝试阅读文本。

您唯一能做的就是使用 ARIA 通过aria-hidden='true'属性隐藏内容。您可以查看我的回答aria-hidden以获取更多详细信息。基本上你会做类似的事情：

<article aria-hidden="true">
 <h1>Some Really cool language</h1>
 <p>Blah blah blah</p>
 <section aria-hidden="false">
  <h2>Audio of language</h2>
  <p>below is an audio sample of ____. Blah blah blah</p>
  <p class="offScreen"><!-- it may be a good idea to put additional 
  info for people using assistive tech --></p>
  <p>audio stuff</p>
 </section>
<article>

CSS

.offScreen{
 position: absolute;
 top: 0;
 left: -999px;
 }
于 2013-05-19T17:15:07.883 回答
2

瑞安，我在其他地方看到过这个关于“点击”语言的问题，就像非洲西南部一样。据我所知，这些语言没有固有的书面字母表。学者们可能会以语音方式记录语言，但更常见的技术包括添加感叹号和可能的其他基本键盘字符来指示欧洲字母无法传达的发声。Kx'a 语言家族就是这样一个群体。

如果您在 sourceforge.net 上查找 RFC 1766，您会发现 122 种语言或语言变体的列表，它们映射到 lang 属性的特定值。RFC 1766本身展示了如何将克林贡语和其他“实验性”语言添加到组合中。

所以有几个问题，似乎：

  1. 如果一种语言还没有被映射，如何创建它的字符和字符组（它的字素）到它的声音（它的音素）的映射？
  2. 假设这就是所需要的，那么如何获得与 lang 属性的新值相关联的映射？（为了获得这个新值，RFC 1766 要求创建、完成和提交一个简单的表单。但是，鉴于名为 RFC 1766 的文档已有 18 年的历史，该信息的可靠性如何？符号映射到哪里听起来适合图片吗？）
  3. 最终，如何让屏幕阅读器识别该映射和 lang 属性的相应值？
于 2013-05-20T23:44:33.993 回答
0

我有点相反的看法：不要试图用预先录制的内容自动替换文本；而是专注于确保用户知道两者都可用，并且可以根据他们拥有的工具访问最适合他们的工具。

更多背景背景可能会有所帮助：根据您的描述，这听起来可能是一个学术或研究网站，其中包含这些语言的文本片段，带有音频；但是网站结构的其余部分——标题和支持性叙述文本——是用某种“支持良好”的语言（英语等）吗？（此测试使用的编码系统是什么？）

如果是这样...

请注意，屏幕阅读器用户通常不会以完全线性的方式从上到下阅读整个页面；他们可以使用标题结构浏览页面。在标记良好的页面中，用户可以自由跳过他们不感兴趣或与他们无关的部分。专注于提供这种灵活性，而不是代表用户做出（善意但可能不正确的）政策决策。

不要假设屏幕阅读器用户首先使用语音；他们可能正在使用盲文，无论是因为语音输出不是他们的选择，还是仅仅因为盲文是他们首选的输出形式。

最后，不要假设由于屏幕阅读器用户无法正确听到文本（由于文本到语音的限制），内容的文本形式应该完全隐藏起来；例如，他们可能仍然希望能够剪切和粘贴代表文本的字符，以便将它们发送给同事。或者，根据所使用的写作方案，屏幕阅读器用户可能仍然能够逐个字母地浏览字符并逐个字母地向他们拼写单词 - 许多屏幕阅读器可以通过以下方式读出非拉丁字符他们的 Unicode 名称。

于 2013-05-29T08:57:05.513 回答
0

这里的问题不是关于 JAWS，而是关于拥有一个会说该语言并可以通过 SAPI 5 之类的驱动程序与 JAWS 通信的合成器。为各种合成器公司开发这些语言的成本可能很高，特别是如果没有一个好的驱动它的商业案例，例如 GPS、ATM、呼叫中心等。

您也可以考虑使用诸如 eSpeak 之类的开源解决方案。这不是最高质量，但如果您可以访问愿意从事此类项目的开发人员，则可能是一种方法。

关于通过网站预先录制的声音文件向 JAWS 传达信息的 API 或方法的问题？这并不能真正满足屏幕阅读器用户的需求，他们无法使用链接或表单字段元素导航信息或与之交互。不幸的是，我真的认为合成器开发是唯一的解决方案。

于 2013-06-05T17:49:51.137 回答