Node.js Reference Architecture, Part 10: Accessibility

Making applications accessible to disabled users is both good business and often required by law. We must develop the Node.js components that are part of these applications in a way that facilitates accessibility. This installment of the ongoing Node.js reference architecture series covers the key questions that Node.js developers need to understand about accessibility:

• Do Node.js developers need to worry about accessibility?
• Are there standards and guidelines for accessibility?
• What do I need to do as a Node.js developer?

Read the series:

• Part 1: Overview of the Node.js reference architecture
• Part 2: Logging in Node.js
• Part 3: Code consistency in Node.js
• Part 4: GraphQL in Node.js
• Part 5: Building good containers
• Part 6: Choosing web frameworks
• Part 7: Code coverage
• Part 8: Typescript
• Part 9: Securing Node.js applications
• Part 10: Accessibility
• Part 11: Typical development workflows
• Part 12: npm development
• Part 13: Problem determination
• Part 14:Testing
• Part 15: Transaction handling
• Part 16: Load balancing, threading, and scaling
• Part 17: CI/CD best practices in Node.js
• Part 18: Wrapping up

Why Node.js developers need to provide accessibility

When the Node.js reference architecture team started discussing recommendations for accessibility, one of the accessibility leaders within Red Hat brought us up to speed. We quickly learned that the focus on accessibility is most often on the front end during the development of many applications, giving minimal attention to JavaScript running under Node.js on the back end.

For software developed with JavaScript, the user interface (UI) typically falls into one of the following categories:

1. Browser-based UIs delivered through JavaScript, HTML, and CSS
2. Desktop-type applications built on something like electron
3. Command-line scripts and applications

The first two categories are similar in using JavaScript, HTML, and CSS to create the UI, which runs in the browser or an equivalent utility. We call these categories the front end.

The front end can access business logic and data through REST APIs, WebSockets, or other API interfaces. In these contexts, the focus of accessibility is on front-end development. But Node.js developers still need to consider accessibility because the APIs they provide will affect the accessibility of the front end. (More on this topic later.)

On the other hand, Node.js developers usually build the UI for a command-line script or application, so they are responsible for making the UI accessible.

Do Node.js developers need to worry about accessibility? Definitely, yes! If you develop command-line scripts or applications, you are responsible for ensuring their accessibility. You might not own the responsibility for applications where you provide the back end, but you still need to support the effort.

Are there standards and guidelines for accessibility?

There is good news and bad news on this front. Web applications with a front end can follow well-defined standards and guidelines, including the Web Content Accessibility Guidelines (WCAG). On the other hand, accessibility in command-line tools has not historically been considered a problem, and we are unaware of any standards to help.

Our team's experience is that it is helpful for organizations to define guidelines and/or to design systems that apply to their product or organization to help ensure that accessibility is part of the interface from the start. Defining your guidelines allows the team to develop its interfaces more efficiently and achieve better consistency in their accessibility. You can find specific examples of guidelines and design systems listed in the Accessibility section of the Node.js Reference Architecture.

What should Node.js developers do?

If you are a Node.js developer working in a team building an application with a front end, you should code your APIs in conformance with the requirements of the front-end team. In addition, you should:

• Avoid hard-coding resources returned to the front end and ensure that your APIs can provide all required forms of a resource. Resources required by the front end might need an alternative format to support accessibility (i.e., alternative text for audio playback).
• Ensure that error messages are understandable when read aloud. Error messages returned to users can be read by screen readers.

If you are building command-line scripts or applications that integrate visual elements such as color, review the corresponding sections of the web accessibility guidelines that apply.

Although there are no standards or guidelines specific to command-line scripts or applications, the paper, Accessibility of Command Line Interfaces, provides several good recommendations, including:

• Ensure that an HTML version of all documentation is available.
• Provide a way to translate long outputs into another accessible format.
• Document the output structure for each command.
• Provide a way to translate tables in command-line interface (CLI) output into another accessible format.
• Ensure that all commands provide status and progress indicators.
• Ensure that all status and progress indicators used are friendly for screen readers.
• Ensure that error messages are understandable when read aloud.

In addition, some tools for accessibility testing are written in Node.js. As a result, Node.js developers might have to assist in automating accessibility testing.

Please check out the accessibility section in the Node.js reference architecture for details.

What's next?

We cover new topics regularly as part of the Node.js reference architecture series. Next, read about typical development workflows that the Node.js team has encountered.

We invite you to visit the Node.js reference architecture repository on GitHub, where you can view our work. To learn more about what Red Hat is up to on the Node.js front, check out our Node.js page.