屏幕阅读器的辅助功能（例如 Jaws）
我的一位同事向我提出了他的一个项目的问题。 由于我缺乏屏幕阅读器和技术的经验，无法帮助他，所以我向你们求助，你们是一群骄傲而强大的 SO 用户。
给 TLDR 人士的总结： UpdatePanel 中的网格在屏幕阅读器中不起作用。 可能与 AJAX 工具包有关？
任何人都可以就我们下一步可以采取的步骤提供帮助或提供建议吗？
这是我从同事那里收到的信息（重点是我的，不是他的，希望提高可扫描性）：
我目前正在研究辅助功能 当我遇到一些问题时 来到使用 Ajax 的页面。 我用了 屏幕阅读器来测试页面的 可达性。 屏幕阅读器 试图识别或解释 屏幕上显示的内容 在音频的帮助下 （文本转语音）然后传输 向用户提供的信息。 这是 对于盲人来说非常有帮助 视力障碍、文盲或 学习障碍。 这是一个简短的 屏幕阅读器如何工作的摘要。 屏幕阅读器会拍摄以下内容的快照 网页并将内容放入 虚拟缓冲区。 屏幕阅读器 使用虚拟缓冲区来允许 用户浏览内容。 如果内容更改为 脚本，那么这需要是 转发到屏幕阅读器。 没有 一种发现什么的机制 更改后，屏幕阅读器用户可能会 不会被告知该内容已 完全改变，或仅被通知 内容已更改，但是 需要阅读全文 文档以准确发现内容 改变了。 为了测试，我使用了两个 屏幕阅读器类型、Access To Go 3.0.76 和大白鲨 10.0。
我在测试时的发现是 在具有网格视图的页面上 在更新面板中，典型的 例如，搜索页面，屏幕 读者会像往常一样阅读所有 之前页面的信息 搜索（搜索条件）。 之上 按下搜索按钮，我们的 包含列标题的 gridview 并生成结果集。 这 屏幕阅读器无法获取 信息将告知它 新内容已写入 页面因此会听到沉默。 A 技术已被推荐 涉及的微软员工 在中插入隐藏的 IFrame 更新面板将触发 屏幕阅读器导航至 更新内容并阅读。 网络 网站解释了如何实现 仅可访问性 更新面板控件。 我已经测试过这个 技术并没有成功制作 这行得通。 它呈现一个 iframe 但 屏幕阅读器仍然不知道 页面更新。
我们的AjaxControlToolKit版本是 1.0.11119.0并且不提供ARIA（Accessible Rich Internet 应用程序）实时区域标记。 居住 区域表明内容发生变化 可能会在没有元素的情况下发生 集中注意力并提供辅助 有关如何进行的技术信息 处理这些内容更新。 万维网联盟 推荐了关于如何 组织页面的内容， 基本上给每个人一个角色 页面上的元素以便提供辅助 技术可以传达 向用户提供适当的信息。 我不确定这意味着什么 就我们的技术水平而言。
A colleague of mine came to me with a problem on one of his projects. Unable to help him, due to my lack of experience with screen readers and the technology, I turn to you, the proud and mighty mass of SO users.
Summary for the TLDR-folks:
Our Grids in UpdatePanels aren't working in screen-readers. Might be something with the AJAX toolkit?
Can anyone help or provide suggestions on what steps we might be able to take next?
Here is what I received from my colleague (the emphasis is mine, not his, hoping to improve scannability):
I’m presently working on accessibility
and I ran into some issues when it
came to pages using Ajax. I used
screen readers to test the page’s
accessibility. A screen reader
attempts to identify or interpret
what’s being displayed on the screen
with the help of audio
(text-to-speech) and then transmits
the information to the user. This is
very helpful for people who are blind,
visually impaired, illiterate or
learning disabled. Here’s a brief
summary of how a screen reader works.
The screen reader takes a snapshot of
the web page and places the content in
a virtual buffer. The screen reader
uses the virtual buffer to allow the
user to navigate through the content.
If the content is changed with
scripting, then this needs to be
relayed to the screen reader. Without
a mechanism to discover what has
changed, a screen reader user might
not be notified that the content has
changed at all, or only be notified
that the content has been changed, but
will be required to read the whole
document to discover exactly what has
changed. For testing, I used two
types of screen readers, Access To Go
3.0.76 and Jaws 10.0.My findings while testing were that
on the pages that have a gridview
within an update panel, a typical
search page for example, the screen
reader would read, as per usual, all
the information on the page before
searching (search criteria). Upon
pressing the search button, our
gridview containing the column headers
and the result set is generated. The
screen reader does not get the
information that would inform it that
new content has been written to the
page therefore silence is heard. A
technique has been recommended by a
Microsoft employee that involves
inserting a hidden IFrame within the
update panel that would trigger the
screen reader to navigate to the
updated content and read it. The web
site explains how to achieve
accessibility only with the
UpdatePanel control. I’ve tested this
technique and had no success in making
it work. It renders an iframe but the
screen reader still doesn’t know about
an update to the page.Our AjaxControlToolKit version is
1.0.11119.0 and does not provide ARIA (Accessible Rich Internet
Applications) live region markup. Live
regions indicate that content changes
may occur without the element having
focus and provides the assistive
technology information on how to
process those content updates. The W3C
has recommended a semantic on how to
organize the content of a page,
basically giving a role to every
element on the page so that assistive
technologies can convey the
appropriate information to the user.
I’m not sure what this implies in
terms of where we are technologically.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
AJAX 网页对于屏幕阅读器来说不是问题，至少对于 Jaws 来说是这样，那是大约 2 年前的事（我开发了一些带有大量 AJAX 的 Web 应用程序，这些应用程序与 Jaws 配合得很好）。
无论如何，您应该使用良好的屏幕 CSS 布局和 HTML 锚点以获得更好的可访问性（标题、alt、tabindex、标签）。
不管怎样，如果你真的担心可访问性，你应该通过 iframe 加载所有内容并使用回调来更新父级（一个小的
编辑：那里有好东西： 有关 AJAX 和屏幕阅读器的 Sitepoint 文章
AJAX webpages are not a problem for screen-readers, at least for Jaws, and that is about 2 years ago (I developed some web apps with lots of AJAX which worked great with Jaws).
Anyway, you should use good screen CSS layout, and HTML anchors for better accessibility (title, alt, tabindex, label).
Anyway, if you really worry about accessibility, you should load everything through an iframe and use a callback to update the parent (a little
<script>tag which updates the parent container DIV with the iframe content). Have also a look at PORK.Iframe (http://schizofreend.nl/Pork.Iframe).EDIT: There's good stuff there: Sitepoint article about AJAX and screenreaders
好吧，这完全取决于您想要提供给用户的更新的优先级，请记住，您最终不会使屏幕阅读器变得更加冗长，您可能想要浏览 ARIA 实时区域并取决于在优先级上，您可以将更新标记为“poliyteatomic”或“assertive”。
Well, it completely depends upon the level of priority of the updates you want to give to the users, keep this in mind that you don't end up in making screen reader more verbose, you may want to go through ARIA live regions and depending on the priority you can mark the updates as poliyte atomic or assertive.