Thank you for taking your time and helping us improve the GitHub CLI, @jscholes! 🫶

First, my sincere apologies about the blog post audio samples. I am working with our Blog and Accessibility teams as I've re-recorded the audio samples with a narrated script; we're working on getting the captions added and will update them.

Second, your feedback on the gh a11y example format is something I can raise up with maintainers as this is the format for examples on any gh command. Personally, I could see the terminal prompt indicator ($) removed all together. Again, I would like to address this holistically rather than an inconsistent experience.

Third, I would like to discuss this further to understand alternative configuration setting names.

Configuration setting names have been a recurring topic for a number of reasons:

• how fine grained should a given setting be?
• how do we clearly yet simply explain the effect of a setting?

Truthfully, I think this is a research opportunity as there are few CLIs that have documented their accessibility journey and how they address many of these concerns. One example we discovered was gcloud uses gcloud config set accessibility/screen_reader true to enable multiple effects.

Part of the effort in this public preview is to work with our community to balance these and other concerns while figuring which of these should be a out-of-the-box experience.

In the case of accessible_colors, other alternatives were ansi_colors, 4bit_colors, customizable_colors, and more. However, terminal users might not understand these technical terms and it also focused on the technology rather than the effect.

In the case of accessible_prompter, there was a lot of back and forth because of what is technically being done with this new dependency. Previously, gh prompting experience would act like a text UI that redrew parts of the screen when users were prompted. The aim is making user prompts easier for speech synthesizers and braille readers to detect and communicate. Would noninteractive_prompter be better?

Really open to ideas 🙇

And finally: in a few places you refer to "Speech synthesis screen reader" (which is a kind of awkward, uncommon phrase), but the changes you're making improve things for braille users too.

I would greatly appreciate guidance on more commonly used terminology! 🙌

Through this journey, we have come to appreciate the "screen reader" is a broad category and that these changes can benefit both text-to-speech and text-to-braille use cases. The primary challenge being we want to work with our users with lived experiences before we make such claims.

It is my hope the GitHub CLI maintainers in collaboration with GitHub's Accessibility Discussion Panel can find clear and simple language we can consistently use.

Thank you for taking the time to opt-in to the public preview and share this feedback, @n0ot! 🫶

First, I think your point on reducing the cognitive load and effort on selects and multi-selects is an important concern. 🤔

• should the new prompting experience support a fuzzy finder experience, allowing users to enter a partial term to refine further?
• do users need an option to repeat the prompt or actions?

I would appreciate any thoughts you might have including any other CLI experiences we can examine! 🙇

This would allow us to continue the discussion with our friends at Charm, who created charmbracelet/huh in collaboration with us to supersede a previously maintained module. 🦸

Second, thank you for feedback on typography! This is an area I would love to expand on further across gh with you and others on GitHub's Accessibility Discussion Panel. All of that said, let me see what we can do regarding this.