Need for community-led CLI accessibility standards

[andyfeller]

As AI-powered development tools increasingly integrate with terminals and command-line interfaces, we have an opportunity—and responsibility—to establish accessibility standards that work for everyone. While the W3C has developed comprehensive accessibility guidelines for web browsers and mobile devices, terminals and CLIs have received minimal attention, despite being critical tools for developers and technical professionals.

This gap exists for historical reasons: terminals evolved from vendor-specific mid-20th century technology, serve a smaller user base, and support vastly different capabilities across implementations (see termcap and terminfo). However, as AI development tools like GitHub Copilot CLI, Claude Code, Cursor, and Gemini CLI become mainstream, we're seeing a groundswell of interest in accessible CLI experiences.

Why now?

Recent developments highlight both progress and fragmentation:

• Different approaches: Tools are implementing accessibility features independently—from --screen-reader flags to ANSI color schemes to accessible prompter settings—without shared standards

• Limited guidance: The Command Line Interface Guidelines focus on technical design but don't address accessibility, and scholarly work like Accessibility of Command Line Interfaces remains scarce

• Grassroots conventions: Community efforts like NO_COLOR demonstrate demand for common standards

We need your input

For CLI users: What accessibility challenges do you face when working in terminals? What features or conventions would improve your experience?

For CLI developers: What guidelines would help you build more accessible tools? What challenges require collaboration across the ecosystem?

For everyone: Are there barriers that require coordination between terminal emulators, CLIs, and assistive technology to solve?

Let's work together to establish community-led standards that make terminals and CLIs accessible by design.

Additional Resources

• Accessibility of Command Line Interfaces (CHI '21)
• Command Line Interface Guidelines
• WCAG 2 to Non-Web ICT
• Building a more accessible GitHub CLI
• NO_COLOR

[jrchamp]

For everyone: Are there barriers that require coordination between terminal emulators, CLIs, and assistive technology to solve

To me, the reason that web browser are able to have standard guidelines depends on the underlying semantic nature of the content and the integration between applications and common interfaces like each operating system's Accessibility API.

For the CLI, I don't imagine tool maintainers want to try and maintain a bespoke accessibility implementation. Instead, I imagine that CLI design system libraries like ncurses could be provided with semantic information and that information could either be made available to the operating system's accessibility API or in a format that is less-dependent on vision.

When I think of analogs for similar needs - a running service to handle things locally and the need to support that when connected to a remote system - I think of the X server and X11 forwarding. Running a daemon as the current user that can be exchange information through something like a socket can allow CLI accessibility libraries to be interacted with using accessible technologies. And remote connections could use "accessibility forwarding", essentially "rendering" the forwarded accessibility data to the local accessibility service.

I'm not the expert in this area, so I'm not sure how many of the necessary pieces already exist:

• Accessibility API
• daemon that connects to API
• CLI design library support for accessibility daemon
• CLI design library support for semantic navigation and interaction
• for remote support, accessibility "forwarding" similar to X11 forwarding