WebAIM - Web Accessibility In Mind

Accessible JavaScript
Other Issues

JavaScript Generated Content

Content generated or written to the page by JavaScript (such as is common with AJAX and Single Page Applications) is generally accessible to assistive technologies, such as screen readers. DOM changes are typically immediately available. In some cases, however, if the dynamic content is constantly changing or if it changes while the user is reading it or has set focus to it, this can interfere with navigation or browser functionality and cause accessibility problems. For example, if an element that has keyboard focus is significantly changed, hidden, or removed from the page, keyboard focus may revert to the very beginning of the page.

Ensuring that the content is generated via user command or interaction (such as pressing a button), rather than automatically or randomly, can ensure that the content does not change when it is focused or being read. If dynamic changes are required, care must be taken to ensure that the changes do not interfere. An ARIA live region or alert might be utilized (with great care) to have dynamic content read, even if focus is not placed on it.

Additionally, sometimes dynamic content needs to receive immediate keyboard focus. For example, a dialog box that appears will likely need to be given focus (using JavaScript focus()) after it appears to ensure it is navigated or read immediately. Additional techniques may be necessary to ensure accessibility for such dynamic elements - a modal dialog, for example, may need to be programmed to maintain keyboard focus (rather than allowing focus into other parts of the page that are not visually available).

Widgets and Complex Interactions

When possible, HTML should be used to provide web page functionality. When HTML does not support the desired functionality, such as for pop-up windows, complex menus, tab panels, accordions, sliders, etc., then JavaScript might be necessary to create complex widgets and controls. These can often be made accessible, especially be following the ARIA Design Patterns and Widgets.

There are many difficulties in both usability and accessibility that may arise with non-standard widgets and interactions. Care must be taken in making the decision to use them. If they are used, thorough user testing of your implementation is vital.

Redirecting and Refreshing Browser Windows

When the page the browser is presenting suddenly changes or refreshes with scripting or <meta> tags, the person viewing that page may become disoriented or confused, especially if that person is using an assistive technology. Accessibility guidelines require that users be given control over time sensitive content changes. Do not automatically change or refresh the browser window without first alerting the user that the change will occur and giving him/her the ability to disable or postpone the change, or even better, give the user full control over the page change or redirect.

Using Pure CSS Instead of JavaScript

Element styles are often modified using JavaScript to create dynamically changing content. However, much of the dynamic functionality often controlled with JavaScript is now available directly within the specifications for CSS itself. This allows the construction of interactive and dynamic navigation and layout elements without the need for JavaScript events. You can create drop-down menus, interactive images, animation, and other exciting features in web sites without worrying about device dependent event handlers.

CSS is intended for visual styling. As such, screen readers largely ignore CSS. It should not generally be used to present content or functionality, at least not without testing in a variety of browsers and screen readers to ensure the content or functionality is fully accessible.