https://www.sitepoint.com/practical-javascript-accessibility/

This article will show you some simple things you can do right now, to make your JavaScript more accessible. This is not bleeding-edge technology, but stuff we’ve been doing for years. This post expands on our introductory article, “JavaScript Accessibility 101.”

Three Core Principles

JavaScript accessibility comes down to three core principles:

• All JavaScript functionality must take a form that can be interpreted as text.
• All JavaScript functionality must be accessible to the keyboard.
• Time-based activity in JavaScript should be user-controllable, unless that would change its meaning.

Let’s take each of those principles, and look at some of the practical stuff we can do to make it happen.

Text Interpretation

The point of this principle is to represent information as text which has meaningful structure, that can be programatically determined. Solid element semantics should be the basis of all interactive content, but this is particularly true with assistive technologies.

A sighted user isn’t always affected by semantics – a menu is a menu because it looks like a menu, whether it’s built from a list or <div>s. But a blind user can only understand what their screenreader can interpret – a menu is a menu because it’s a hierarchy of structured links. If we were building a tab-box, for example, it might look like the following example. Notice how various semantic tags are used.

<div class="box">
  <section class="panel">
    <h3 class="tab" tabindex="0">Section 1</h3>
    <p class="content">This is the content for Section 1</p>
  </section>
  <section class="panel">
    <h3 class="tab" tabindex="0">Section 2</h3>
    <p class="content">This is the content for Section 2</p>
  </section>
</div>

It’s also important to make information programatically accessible. This means using standard DOM functions to add new content to the page, rather than using document.write() or innerHTML.

innerHTML is undeniably convenient, and usually much faster than adding new content node-by-node. The problem with innerHTML is that browsers often change the markup, so the resulting DOM is different from what you specified. In some rare cases, content added this way doesn’t appear in the DOM at all.

To fix this problem, add the HTML via an intermediate, non-appended element as shown below. To use this function, pass it an HTML string and a target element reference. The function creates a virtual DOM then appends its node(s) to the target.

function appendHTML(target, html)
{
  var fragment = document.createElement('div');
  fragment.innerHTML = html;

  while(fragment.hasChildNodes())
  {
    target.appendChild(fragment.firstChild);
  }

  return target;
}

Keyboard Accessibility

When making interactive content accessible to the keyboard, stick to a core set of keys: Tab, Enter, the four Arrow Keys, and Escape. These keys should be used unmodified, i.e. without Shift or other modifier keys having to be held down. If you really need to use other keys or modifier keystrokes, you should provide instructions to the user. Alt combinations are still best avoided though, because they’re used for native menu shortcuts.

Most keys also have a default browser action, and it’s sometimes necessary to block the default, to prevent a behavioural conflict. For example, when using the Up-Arrow and Down-Arrow keys in a dropdown menu, you wouldn’t want them to scroll the page at the same time. The standard way to do this is to use preventDefault(), as in this example, taken from a menu script: