JavaScript 和辅助功能

发布于 2024-07-08 14:31:46 字数 508 浏览 10 评论 0 原文

作为一名网络开发人员,我从事的许多项目都属于政府的范畴,因此受到 508 Accessibility 的约束法律,有时还有W3C 无障碍指南。 在满足这些要求的同时,JavaScript 可以使用到什么程度呢?

沿着这些思路,JavaScript,特别是 AJAX 和使用 jQuery 之类的包来执行诸如显示模式对话、弹出窗口等功能,在多大程度上受到 JAWS、Orca 等现代辅助软件的支持? 过去,规则类似于“如果它在 Lynx 中不起作用,那么它也不适用于屏幕阅读器”。 这仍然是事实吗?或者这些领域是否取得了更多进展?

编辑:共识似乎是只要存在非 javascript 后备,javascript 就可以,但是屏幕阅读器软件对 AJAX 的支持似乎仍然不确定。 如果有人对此有具体经验,那将是最有帮助的。

As a web developer, a number of the projects I work on fall under government umbrellas and hence are subject to 508 Accessibility laws, and sometimes W3C accessibility guidelines. To what extent can JavaScript be used while still meeting these requirements?

Along these lines, to what extent is JavaScript, specifically AJAX and using packages like jQuery to do things such as display modal dialogues, popups, etc. supported by modern accessibility software such as JAWS, Orca, etc? In the past, the rule went something like "If it won't work in Lynx, it won't work for a screen reader." Is this still true, or has there been more progress in these areas?

EDIT: The consensus seems to be that javascript is fine as long as there are non-javascript fallbacks, however it still seems uncertain about the support for AJAX in screen reader software. If anyone has specific experience with this, that would be most helpful.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

放手` 2024-07-15 14:31:46

如果可访问性是您最关心的问题,请始终使用符合标准的 HTML(选择文档类型定义并坚持使用)来启动网站。 如果它是一个 Web 应用程序(表单提交等),请确保表单仅使用 HTTP GET 和 POST 即可工作。 一旦您拥有了完整的网站/应用程序,只要网站仍然可以运行,您就可以添加一些 CSS 和 JavaScript,无论其中一个或全部关闭。

这里最重要的概念是渐进增强。 您使用 CSS/JavaScript 添加了额外的功能,但是您的网站/应用程序无需也可以完美运行。

用于测试 508WAI,CSS 关闭,JavaScript 关闭尝试使用 Web Developer 插件。

If accessibility is your primary concern, always start a website using standards-compliant (pick a Document Type Definition and stick to it) HTML. If it's a web application (form submissions, etc), make sure the forms will work using just HTTP GET and POST. Once you have a complete website/application you can add bits of CSS and JavaScript as long as the site still functions, with either or both off.

The most important concept here is Progressive Enhancement. You're adding additional bells and whistles using CSS/JavaScript, but your web site/application will function perfectly well without either.

A great tool for testing 508, WAI, CSS off, JavaScript off try using the Web Developer plugin for Firefox.

锦欢 2024-07-15 14:31:46

我认为答案实际上在于你如何构建事物。 JQuery 具有不引人注目的能力,因此易于访问。 诀窍是在 AJAX 调用周围提供冗余,以便没有 JavaScript 的浏览器仍然可以使用您的服务。 换句话说,无论你有 JavaScript 响应、对话框等,你都需要有一个降级的等价物。

如果您考虑到可访问性并且正确测试了两种用例(JavaScript 与非 JavaScript),您应该能够编写满足这两种受众的应用程序。

示例 ($(document).ready 调用为了清晰和简洁而省略:

<script>
  $("#hello").click(function(){
    alert("Hi");
  });
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>

一个简单的示例,但基本上,如果支持 JavaScript,这只会评估单击 JavaScript 事件。否则,它将像普通链接一样执行并转到 say_hello.htm - 您的作为开发人员的工作是确保这两种结果都得到适当的处理,

希望有所帮助!

I think the answer is really in how you architect things. JQuery has the capability to be unobtrusive and therefore accessible. The trick is to have redundancy around your AJAX calls so browsers without JavaScript can still utilize your service. In other words, wherever you have JavaScript responses, dialogs, etc you need to have a degraded equivalent.

If you have accessibility in mind and you're properly testing for both use cases (JavaScript vs. Non-JavaScript) you should be able to write applications that cater to both audiences.

Example ($(document).ready call omitted for clarity and brevity:

<script>
  $("#hello").click(function(){
    alert("Hi");
  });
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>

A trivial example but basically this will only evaluate the click JavaScript event if JavaScript is supported. Otherwise, it will perform like a normal link and go to say_hello.htm - your job as the developer is to make sure that both outcomes are handled for appropriately.

Hope that helps!

猫九 2024-07-15 14:31:46

渐进式增强当然是一种途径,但不引人注目并不是 JavaScript 可访问性的全部和最终目的,因为屏幕阅读器倾向于使用浏览器作为其工作的基础。 由于这些浏览器支持 JavaScript,因此页面上的脚本仍然会运行。 这是 AJAX 的一个特殊问题,因为单击页面的一个部分可能会更改屏幕阅读器不知道的页面的另一部分。

然而,随着 AJAX 的成熟,使其易于访问的方法正在出现。 查看 WAI-ARIA 了解使 AJAX 易于访问的现代方法,以及 Google 的 AxsJAX 了解实现它的好方法。


Progressive enhancement is certainly one route but unobtrusiveness is not the be all and end all of JavaScript accessibility as screen readers tend to use browsers as a basis for their work. Since those browsers support JavaScript, scripts on your page will still run. This is a particular problem with AJAX as clicking on one part of the page could change another part of the page that the screen reader isn't aware of.

As AJAX matures, however, methods of making it accessible are emerging. Look into the WAI-ARIA for modern methods of making AJAX accessible, and Google's AxsJAX for a good way of implementing it.


小…红帽 2024-07-15 14:31:46

请参阅

您也可以看看 FlashAid,尽管它远非完美的解决方案。 (但是,如果您使用渐进式增强,并且仅在 Flash 存在且用户没有使用辅助功能 API 时使用 AJAX,那么对于 Windows,您可能有一个合理的解决方案。)

从长远来看,WAI-ARIA 是解决方案。 它在 JAWS 10(测试版)和 Firevox 中得到了一定程度的支持,但这对于当今的所有用户来说肯定是不够的。

See

You might also take a look at FlashAid, although it is far from a perfect solution. (But, if you used progressive enhancement and only used AJAX when Flash was present and the user wasn't using the accessibility API, you might have a reasonable solution... for Windows.)

In the long run WAI-ARIA is the solution. It is somewhat supported in JAWS 10 (beta) and Firevox, but it certainly isn't sufficient for all of today's users.

夏日落 2024-07-15 14:31:46

JQuery 具有不引人注目的能力,因此易于访问。 诀窍是在 AJAX 调用周围提供冗余,以便没有 JavaScript 的浏览器仍然可以使用您的服务。 换句话说,无论您在哪里有 JavaScript 响应、对话框等,您都需要有一个降级的等价物。

重用代码的一种方法是让“简单”页面调用可自行调用的“函数”(或用于服务器端逻辑的任何内容),返回 JSON 或 XML。

例如:
/static/myform.asp(在服务器端,“包含”与/ajax/myform.asp相同的逻辑)
这样你就可以使用 asp 作为 django 的模板。

当然,使用功能齐全的花哨框架,您可以使这变得更加容易(想象一下在 django 中为同一视图提供一个 html 和一个 xml “模板”),但同样的想法也适用。

完成此操作后,使用 jQuery 迭代文档上的所有锚点并使用锚点自己的链接添加 onclick 事件,替换 /static/ajax/ 可以让您的生活更轻松。

谁能想到这会造成太大负担的原因吗? 想知道这个“设计理念”是否存在严重缺陷。

JQuery has the capability to be unobtrusive and therefore accessible. The trick is to have redundancy around your AJAX calls so browsers without JavaScript can still utilize your service. In other words, wherever you have JavaScript responses, dialogs, etc you need to have a degraded equivalent.

One way to do this to reuse your code, is to have your "simple" page calling a "function" (or whatever you use for server side logic) that can be called by itself, returning JSON or XML.

For example:
/static/myform.asp (in the server side, 'includes' the same logic as /ajax/myform.asp)
that way you'd be using asp as django's templates.

Of course, with a full featured bell and whistles framework, you could make this a lot easier (think of having an html and an xml 'template' for the same view in django), but the same idea applyes.

Having done this, iterating over all anchors on document ready using jQuery and adding onclick events using the anchor's own link, remplacing /static/ajax/ could make your life easier.

Can anyone think of reasons for this to be too much of a burden? Would like to know if there is any serious flaw on this 'design idea'.

神魇的王 2024-07-15 14:31:46

我认为接受的答案虽然在当时还不错,但现在已经过时了。 (写这个答案时已经有十年了。WCAG 2.1 几周前完成......)

W3C WAI-创作设计模式实践文档包含常见小部件的各种示例,这些小部件需要 javaScript 以便向辅助技术传达正确的语义、状态和角色。

只要您在用户激活页面内更新之前小心地为屏幕阅读器提供有关页面内更新内容的相关语义线索,就可以使 AJAX 变得可访问。 您可能还需要通知屏幕阅读器之后实际发生的更改,例如 aria-live 区域可能会宣布“已加载 20 个新项目”或其他内容。 这是通过 javaScript 实现的。

如果您的可访问性知识停留在“渐进增强”,并且您将上面接受的答案视为该职位的基本原理,那么您很可能需要更新。 这些天事情进展很快。

I think the accepted answer, while fine for its time, is now out of date. (Literally a decade old at time of writing this answer. WCAG 2.1 was finalized a few weeks ago...)

The W3C WAI-Authoring Design Patterns Practices document includes various examples of common widgets which require javaScript in order to communicate the right semantics, states and roles to assistive technologies.

AJAX can be made accessible, as long as you are careful to give screenreaders relevant semantic clues about what the in-page-update will be before the user activates it. You may also need to notify the screenreader about what actually changed afterwards, e.g. an aria-live region might announce "20 new items have been loaded" or whatever. This is achieved with javaScript.

If your accessibility knowledge stops at 'progressive enhancement', and you see the accepted answer above as rationale for that position, then you may well be in need of an update. Things are moving fast these days.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文