When your organization buys software or application services, it should go through a governance process to ensure that it meets your organization’s requirements for security, integration, AI, accessibility, and overall architecture.

For example, administrators may manage the app through a text-based command-line interface (CLI). Or they manage it through a different app’s interface, connecting to it via an application programming interface (API).

To determine whether an app needs to go through an accessibility review, follow these steps.

High-level decision tree

API question

Does the app rely on an external control for installation, and does it function without a user interface to perform application programming interface (API) calls without generating any formatted output?

• If yes:
  • Accessibility evaluation not required: Close this process.
• If no:
  • Proceed to the CLI question.

CLI question

Do users control the app via a command line interface (CLI)?

• If yes:
  • Proceed to Subtree (A).
• If no:
  • Proceed to the Library question.

Subtree (A)

Does the app offer an alternate graphical user interface (GUI)?

• If yes:
  • Does the GUI offer more functionality than the CLI?
    • If yes:
      • Accessibility evaluation is required, and the app continues through the accessibility review process.
    • If no, proceed to Subtree (B).
  • If no:
    • Proceed to Subtree (B).

[End subtree (A)].

Subtree (B)

Does the app create digital content or user interface components (e.g., a command results in a modal that requires an end-user to perform an action)?

• If yes:
  • Accessibility evaluation is required, and the app continues through the accessibility review process.
• If no,
  • Accessibility evaluation not required: Close this process.

[End subtree (B)].

[End CLI question].

Library question

Is the app solely a set of libraries for an existing system?

• If yes:
  • Do the libraries contribute to a user interface?
    • If yes:
      • Accessibility evaluation is required, and the app continues through the accessibility review process.
    • If no,
      • Accessibility evaluation not required for this app. Close this process.
    • If no:
      • Accessibility evaluation is required, and the app continues through the accessibility review process.

Note: In situations where users can choose to use either a CLI or GUI to operate the app, if the GUI provides more functionality than the CLI, then you need to review its accessibility. It goes against the purpose of accessibility to offer CLI as an alternative for people with disabilities if the GUI users have more options, ease of use, or other functional advantages.

Final Takeaway

When evaluating tools that aren’t for the end-user — whether backend systems, libraries, or plug-ins — consider how users interact with the technology. The decision tree outlined above provides a structured approach to determine when an accessibility evaluation is necessary. By distinguishing between APIs, CLIs, GUIs, and libraries, this process ensures that you can focus your accessibility efforts where they matter most: on interfaces and outputs that impact human users.

The goal of digital accessibility is equity. If a graphical interface offers more functionality than a command-line alternative, it must be accessible to everyone. This review process helps uphold that principle, ensuring that all users have equal access to the tools and technologies your organization adopts.