Introduce accessible prompter for screen readers (preview) #10710

BagToad · 2025-03-31T21:06:12Z

Description

Implement charmbracelet/huh in accessible mode as an accessible prompter.

Acceptance Criteria

When I run gh environment
Then I see the GH_SCREENREADER_FRIENDLY env var documented and marked as experimental

Given I have GH_SCREENREADER_FRIENDLY set to any value other than 0 or false
When I run any gh command requiring prompting
Then the prompting experience provides a basic level of screenreader friendliness

Demo

Details

Demonstrating Confirmation
Are you sure?

Choose [y/N]: y
Chose: Yes

Confirmation: true
Demonstrating Text Input
Favorite meal? (Breakfast)

Input: lunch
Input: lunch
            
Favorite meal: lunch
Demonstrating Single Select
Favorite cuisine?
1. Italian
2. Greek
3. Indian
4. Japanese
5. American

Choose: 5
Chose: American
               
Favorite cuisine: American
Demonstrating Multi Select
Favorite cuisines?
1.   Italian
2.   Greek
3.   Indian
4.   Japanese
5.   American

Select up to 5 options. 0 to continue.
Select: 5
Selected: American

Favorite cuisines?
1.   Italian
2.   Greek
3.   Indian
4.   Japanese
5. ✓ American

Select up to 5 options. 0 to continue.
Select: 3
Selected: Indian

Favorite cuisines?
1.   Italian
2.   Greek
3. ✓ Indian
4.   Japanese
5. ✓ American

Select up to 5 options. 0 to continue.
Select: 1
Selected: Italian

Favorite cuisines?
1. ✓ Italian
2.   Greek
3. ✓ Indian
4.   Japanese
5. ✓ American

Select up to 5 options. 0 to continue.
Select: 0
Selected: Italian, Indian, American
                                   
Favorite cuisine: Italian
Favorite cuisine: Indian
Favorite cuisine: American
Favorite meal: lunch
Demonstrating Password Input (unmasked)
Safe word?

Input: stuff
Input: stuff
            
Safe word: stuff
Confirmation: true
Demonstrating Auth Token (can't be blank)
Paste your authentication token:

Input: blalbla
Input: blalbla
              
Auth token: blalbla
Demonstrating Deletion Confirmation
Type "delete-me" to confirm deletion

Input: delete-me
Input: delete-me
                
Item deleted
Demonstrating Hostname (must be valid hostname)
Hostname:

Input: github.com
Input: github.com
                 
Hostname: github.com
Demonstrating Markdown Editor with blanks allowed
Edit your text:
1. Open Editor: vim
2. Skip

Choose: 2
Chose: Skip
           
Edited text: 
Demonstrating Markdown Editor with blanks disallowed
Edit your text:
1. Open Editor: vim

Choose: 1
Chose: Open Editor: vim
                       
Edited text: Initial tex
8000
t

Notes

I have identified a difference in behavior between this prompter and the current one, described in Accessible Confirm prompt does not treat Value as default charmbracelet/huh#615. I left a commented unit test in which can be used if this behavior is added to huh in the future.
After discussing with @williammartin and @andyfeller, we decided to rename the env var to GH_ACCESSIBLE_PROMPTER for now.

Review

Consider checking out and running #10745 for a quick demo :)

Accessible prompter now respects blankAllowed and will not prompt for "skip" if blankAllowed is false.

Allow the accessible markdownEditor prompt to be blank when the blank comes from the result of an interactive session with an editor, even when blankAllowed is false. This behavior aligns the accessible prompter with the behavior of the current standard prompter.

t.Parallel() cannot be used when env vars are being set.

internal/prompter/prompter.go

internal/prompter/prompter_test.go

shindere · 2025-04-02T11:43:34Z

William Martin (2025/04/02 04:37 -0700):

@williammartin commented on this pull request. I think generally we might want to refer to this thing as `screenreaderFriendlyPrompter` rather than `accessiblePrompter`. It's a clearer link to the env var, and accessibility is a big scope.

Well, if I may say, I find both namigs a bit vague in the sense that they say what they would like to achieve rather than what they are effectively and precisely doing. I was curious about what this PR does but I couln't see a description for it? Did I miss something maybe?

internal/prompter/prompter.go

williammartin · 2025-04-02T11:59:06Z

I was curious about what this PR does but I couln't see a description for it? Did I miss something maybe?

Firstly, this is in a draft state, which is why there is no description. You also haven't missed anything on our public issue tracker, but I'm glad you dropped by! One of our findings using screenreaders (and indicated by another screenreader user that consults with GitHub) was that the prompting experience right can be challenging to use because of the way it redraws the screen.

The goal here is to ship a prompting experience behind the GH_SCREENREADER_FRIENDLY environment variable that we can get feedback, and iterate on. We'll make sure there is a public place for discussion.

Well, if I may say, I find both namings a bit vague in the sense that they say what they would like to achieve rather than what they are effectively and precisely doing.

Thanks for the feedback. For the moment I think that this is fine, the goal is that this prompting experience is more friendly for screenreaders. The preciseness will be in the concrete implementation as opposed to the behavioural specification of the tests.

shindere · 2025-04-02T12:07:58Z

William Martin (2025/04/02 04:59 -0700):

Firstly, this is in a draft state, which is why there is no description.

ACK, thanks!

You also haven't missed anything on our public issue tracker, but I'm glad you dropped by! One of our findings using screenreaders (and indicated by another screenreader user that consults with GitHub) was that the prompting experience right can be challenging to use because of the way it redraws the screen.

I see. As a sidenote I'd definitely consider consulting. I guess what puzzles me is the vagueness of all this. I mean, I do understand that it's too early to be precise, but I also would like to emphasize that, to me, this very lack of precision itself may be a source of future issues for you GitHub guys. Indeed, it feels to me here as if it is believed that there is one way to make something `screenreader friendly`. But I fear the reality is more complex: depending on whether you use speech synthesis or a braille display, also depending on the environemnt you work with (where environemnt means OS, framework and screenreader), your needs in terms of accessibility and even your definitionof what accessibility is may vary. Evenmore so as there is nothing here like WCAG to guide design. Not to say what's currently being done is wrong, it certainly isn't. But you man want to keep all this in mind, in case it was not already obvious, in which case I sincerely apologize.

williammartin · 2025-04-02T12:22:09Z

Even more so as there is nothing here like WCAG to guide design.

Haha yes, we're familiar with the challenge of no WCAG, as we, GitHub, and Microsoft have had to learn what it means to have different forms of accessibility in the terminal. I'm sure we still have a lot to learn.

Indeed, it feels to me here as if it is believed that there is one way to make something screenreader friendly. But I fear the reality is more complex: depending on whether you use speech synthesis or a braille display, also depending on the environment you work with (where environment means OS, framework and screenreader), your needs in terms
of accessibility and even your definition of what accessibility is may vary.

This is really fantastic insight thank you. I suppose in this case we are referring to a speech synthesis friendly prompting experience.

For example, a single select would read like:

Favorite cuisine?
1. Italian
2. Greek
3. Indian
4. Japanese
5. American

Choose: 2
Chose: Greek

A multi-select would read like:

Favorite cuisines?
1.   Italian
2.   Greek
3.   Indian
4.   Japanese
5.   American

Select up to 5 options. 0 to continue.
Select: 1
Selected: Italian

Favorite cuisines?
1. ✓ Italian
2.   Greek
3.   Indian
4.   Japanese
5.   American

Select up to 5 options. 0 to continue.
Select: 3
Selected: Indian

Favorite cuisines?
1. ✓ Italian
2.   Greek
3. ✓ Indian
4.   Japanese
5.   American

Select up to 5 options. 0 to continue.
Select: 0
Selected: Italian, Indian

An input would read like:

Favorite meal?

Input: pizza
Input: pizza

And so on. I'm sure there's a lot of room for improvement in the exact styles and text, but hopefully you understand the goal we're going for here in comparison to our current prompting experience (you can run gh auth login with no arguments for an example of a command with multiple prompts).

Do you think this would be best referred to as a Speech Synthesis Friendly Prompter?

Braille displays are definitely something we are less familiar with supporting. In that regard:

As a sidenote I'd definitely consider consulting.

I'll pass this information on to the accessibility team.

shindere · 2025-04-02T12:44:08Z

William Martin (2025/04/02 05:22 -0700):

This is really fantastic insight thank you. I suppose in this case we are referring to a speech synthesis friendly prompting experience.

Okay.

Do you think this would be best referred to as a Speech Synthesis Friendly Prompter?

Possibly, yes. Also: I completely understand that you'd like to experiment things, get feedback etc. without disturbing existing workflows and I find this both very kind and mindful so what I will say now only applies to an ideal, ultimate state of things: I know that at least as a user of braille, I would not feel comfortable with the idea of having to use a different prompter jsut because I use braille. One reason is technical, it is known that such things are less used, tested and then less maintained. The other reason is more social: I find it a bit discriminating if I have to use another, dedicated way and I feel way more included if I can use what others, because the way it has been designed is universalenough for that thing to work for me, too.

And so on. I'm sure there's a lot of room for improvement in the exact styles and text, but hopefully you understand the goal we're going for here in comparison to our current prompting experience (you can run `gh auth login` with no arguments for an example of a command with multiple prompts).

Done. On the first screen I see a question mark at the very beginning of the message, which surprises me. Apart frm that I find it works pretty well, especially the cursor is where the relevant information is, which, IMO, is nice. I guess what I would personnaly like for this prompter, as much as a geekthan as a blind user, is configurability. See mutt and its mitt_index variable for instance which can include %-prefixed characters that let you build your line exactly like you want. Souser mays want to remove the > sign to gain space. Other with a longer display may want to add the number of the current option and the number of total options, like 1/3, 2/3, 3/3. Some may want to have this at the beginning and others at the end. And finally that would benefit to all and there is not even a need to "claim" accessibility, it's just a by-product of clever design. (FWIW mutt DOES have a braile_friendly variable.)

Braille displays are definitely something we are less familiar with supporting. In that regard: > As a sidenote I'd definitely consider consulting. I'll pass this information on to the accessibility team.

Thanks!

williammartin · 2025-04-02T13:15:00Z

All very useful feedback thank you. We'll need to figure out a way to distil this conversation into some document, rather than just living on a PR.

Also: I completely understand that you'd like to experiment things, get feedback etc. without disturbing existing workflows and I find this both very kind and mindful so what I will say now only applies to an ideal, ultimate state of things.

At the end of the day, we're open to wherever our users lead us, even more so on this topic where we don't have the lived experience. As you say, in an ideal world, the out of the box experience is shared and accessible by default, and we have been doing work on various fronts towards that. Your surprise over the starting question mark is something we could look at addressing.

I guess what I would personally like for this prompter, as much as a geek than as a blind user, is configurability.

Makes sense to me. One of the challenges we have at the moment is that the current prompting library is deprecated. If you could wave a magic wand and have configurability for the prompts, what options would you like? Would it be useful if I produced a program that demonstrated each different type of prompt?

Food for thought on the configurability side, is where the boundary between "different prompting experience" and "configurable prompting experience is". I definitely appreciate your shared concerns though, will need to reflect on this. Currently this new prompting experience is going to live behind an experimental configuration so that we can make sure to get this right. If it turns out that "right" is getting rid of it, that's good to know.

Apart from that I find it works pretty well, especially the cursor is where the relevant information is, which, IMO, is nice.

That's nice to know. Just to be clear, were you using the braille reader, or speech synthesis?

One issue we discovered was that the selects in screen synthesis would often announce "blank" when moving between options.

shindere · 2025-04-02T13:50:10Z

William Martin (2025/04/02 06:15 -0700):

> I guess what I would personally like for this prompter, as much as a geek than as a blind user, is configurability. Makes sense to me. One of the challenges we have at the moment is that the current prompting library is deprecated.

Oops, sorry to hear that.

If you could wave a magic wand and have configurability for the prompts, what options would you like?

I fear I didn't understand your quesiton, sorry about that. What I did notice is the text saying to press arrow keys. That I think is something one may want to be able to suppress because, once you know, I think it will be perceived more as noise than as help by users, here especially by users of speech sysnthesizers as I think it's less easy for them to skip text than it is is braille (to be confirmed).

Would it be useful if I produced a program that demonstrated each different type of prompt?

I am worried about making you lose time and energy: I am unsure we need such a program, I mean perhaps there are ways to achieve the same goal without writing a dedicated programs, like providing a subset of commands that will cover all the types of prompts. But of course a program may also have its own advantages if the purpose is to then write automated tests.

Food for thought on the configurability side, is where the boundary between "different prompting experience" and "configurable prompting experience is".

Out of the top of my head and without having thought about it for a long time, I have a vague feeling that the difference is that configuring is something you can do if you want (a possibilit which is offered to you) but that you do not _have to do_ because the thingwould otherwise be unusable. But this is a very, very personal idea.

I definitely appreciate your shared concerns though, will need to reflect on this. Currently this new prompting experience is going to live behind an experimental configuration so that we can make sure to get this right. If it turns out that "right" is getting rid of it, that's good to know.

To avoid biases as much as possible, you may want to proactively reach out to potentially concerned ussers early, that would avoid you doing many steps in one direction before noticing this directiion is notthat good. For instance the developers of the NVDA Windows screen reader use GitHub and several of them are visually impaired. You may want to contact them. On the braille side, you cna reach out to many people with a geek / sysadmin / developer background through the ***@***.***, ***@***.*** and ***@***.*** mailing lists. Beyond the exchanges you may have there about the gh CLI, I think that, just by subscribing to these mailing lists you can learn quite a bunch of things about what is difficult.

> Apart from that I find it works pretty well, especially the cursor is where the relevant information is, which, IMO, is nice. That's nice to know.

(I think it was already me who reported the problem of the cursor not being on the selected item...)

Just to be clear, were you using the braille reader, or speech synthesis?

Braille display.

One issue we discovered was that the selects in screen synthesis would often announce "blank" when moving between options.

Okay but that is something I'm pretty sure has more to do with the way the screenreader is configured and IMHO it's not your responsibility to compensate for misconfigured tools (without being too extremist about that, but still).

Co-authored-by: Andy Feller <andyfeller@github.com>

shindere · 2025-04-09T15:02:08Z

Hey there, Just to let everyone know, I am going to unsubscribe from this thread because I am under the impression that no input from me is needed at this stage. If you guys need me, please do not hesitate to mention me either here or on another PR/issue in case me unsubscribing from here makes me miss the mention. Just to clarify that if I am mentionnedhere and do not respond it should not be interpreted as a lack of interest in the topic, it's just because I receive quite a bunch of e-mails already.

internal/prompter/accessible_prompter_test.go

internal/prompter/prompter.go

williammartin

Approving on the proviso that my comments are addressed as discussed on call.

andyfeller · 2025-04-10T20:35:43Z

Thoughts

gh prompts seem to use parenthesis in a couple different ways, unsure if confusing to others
- (required) for required fields
- (<VALUE>) for default values
huh displays empty default value, could probably avoid showing this
```
Description ()
 
Input:
```

huh has some inconsistent spacing around prompt and input

selects and multi-selects have no spacing after prompt

What would you like to do?
1. Create a new repository on GitHub from scratch
3. Create a new repository on GitHub from a template repository
4. Push an existing local repository to GitHub

Choose:

inputs have spacing after prompt
```
Path to local repository (.)

Input:
```

huh validation error message might not be instructive enough for screen readers

gh issue delete 151
! Deleted issues cannot be recovered.
Type "151" to confirm deletion
 
Input: 150
You entered: "150"
Input: 152
You entered: "152"
Input: 
You entered: ""
Input: ^C

versus current experience:

gh issue delete 151
! Deleted issues cannot be recovered.
X Sorry, your reply was invalid: You entered 150
? Type 151 to confirm deletion:

Markdown editor prompt shows an extra colon in the editor option, where is this coming from?
```
Body
1. Open Editor: 
3. Skip
```

Demo

`Prompter.AuthToken`

Accessible experience

$ gh auth login
Where do you use GitHub?
1. GitHub.com
4. Other

Choose: 1
Chose: GitHub.com
                 
What is your preferred protocol for Git operations on this host?
1. HTTPS
4. SSH

Choose: 1
Chose: HTTPS
            
How would you like to authenticate GitHub CLI?
1. Login with a web browser
2. Paste an authentication token

Choose: 2
Chose: Paste an authentication token
                                    
Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
The minimum required scopes are 'repo', 'read:org', 'workflow'.
Paste your authentication token:

Input: ghp_OBSCURED
Input: ghp_OBSCURED
                                               
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as andyfeller
! You were already logged in to this account

Default experience

$ gh auth login
? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations on this host? HTTPS
? How would you like to authenticate GitHub CLI? Paste an authentication token
Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
The minimum required scopes are 'repo', 'read:org', 'workflow'.
? Paste your authentication token: ****************************************
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as andyfeller
! You were already logged in to this account

`Prompter.Confirm`

Accessible experience

Add a remote?

Choose [Y/n]: 
Chose: Yes

Default experience
```
? Add a remote? (Y/n) 
```

`Prompter.ConfirmDeletion`

Accessible experience

$ gh repo delete
Type "tinyfists/gh-demo-accessible" to confirm deletion

Input: tinyfists/gh-demo-accessible
Input: tinyfists/gh-demo-accessible
                                   
✓ Deleted repository tinyfists/gh-demo-accessible

Default experience

$ gh repo delete    
? Type tinyfists/gh-demo-default to confirm deletion: tinyfists/gh-demo-default
✓ Deleted repository tinyfists/gh-demo-default

`Prompter.InputHostname`

Accessible experience

gh auth login
Where do you use GitHub?
1. GitHub.com
2. Other
 
Choose: 2
Chose: Other
             
Hostname:
 
Input: github.com
Input: github.com

Default experience

gh auth login
? Where do you use GitHub? Other
? Hostname: github.com
? What is your preferred protocol for Git operations on this host?  [Use arrows to move, type to filter]
> HTTPS
  SSH

`Prompter.MarkdownEditor`

Accessible experience

$ gh issue create

Creating issue in tinyfists/issue-driven-github-admin

Title (required) ()

Input: Demonstration of accessible issue create
Input: Demonstration of accessible issue create
                                               
Body
1. Open Editor: 
2. Skip

Choose: 1
Chose: Open Editor: 
                    
What's next?
1. Submit
2. Continue in browser
5. Add metadata
6. Cancel

Default experience

$ gh issue create

Creating issue in tinyfists/issue-driven-github-admin

? Title (required) Demo default issue create
? Body [(e) to launch vim, enter to skip]

`Prompter.MultiSelect`

Accessible experience

What would you like to add?
1.   Assignees
2.   Labels
3.   Projects
4.   Milestone

Select up to 4 options. 0 to continue.
Select: 1
Selected: Assignees

What would you like to add?
1. ✓ Assignees
2.   Labels
3.   Projects
4.   Milestone

Select up to 4 options. 0 to continue.
Select: 2
Selected: Labels

What would you like to add?
1. ✓ Assignees
2. ✓ Labels
3.   Projects
4.   Milestone

Select up to 4 options. 0 to continue.
Select: 0
Selected: Assignees, Labels

Default experience

$ gh issue create

Creating issue in tinyfists/issue-driven-github-admin

? Title (required) Demo default issue create
? Body <Received>
? What's next? Add metadata
? What would you like to add?  [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
  [x]  Assignees
> [x]  Labels
  [ ]  Projects
  [ ]  Milestone

`Prompter.Select`

Accessible experience

What's next?
1. Submit
2. Continue in browser
3. Add metadata
4. Cancel

Choose: 3
Chose: Add metadata

Default experience

? What's next?  [Use arrows to move, type to filter]
> Submit
  Continue in browser
  Add metadata
  Cancel

? What's next? Add metadata
? What would you like to add?  [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
> [ ]  Assignees
  [ ]  Labels
  [ ]  Projects
  [ ]  Milestone

andyfeller · 2025-04-10T21:26:12Z

internal/prompter/prompter.go

+	options := []huh.Option[string]{
+		huh.NewOption(fmt.Sprintf("Open Editor: %s", p.editorCmd), openOption),
+	}


I don't know if p.editorCmd always has a value, which results in the Open Editor having no editor listed:

$ echo $EDITOR vim $ gh config get editor $ gh issue create Creating issue in tinyfists/issue-driven-github-admin Title (required) () Input: This is just a title Input: This is just a title Body 1. Open Editor: 2. Skip Choose:

versus the current experience:

$ gh issue create Creating issue in tinyfists/issue-driven-github-admin ? Title (required) Demo default issue create ? Body [(e) to launch vim, enter to skip]

How does this work today?

Currently, gh has relied upon go-survey to prompt the user whether to open the editor using the editor we have from either 1) configuration or 2) env var:

cli/pkg/surveyext/editor_manual.go

Lines 43 to 74 in 057ad52

func edit(editorCommand, fn, initialValue string, stdin io.Reader, stdout io.Writer, stderr io.Writer, cursor showable, lookPath func(string) ([]string, []string, error)) (string, error) {

// prepare the temp file

pattern := fn

if pattern == "" {

pattern = "survey*.txt"

}

f, err := os.CreateTemp("", pattern)

if err != nil {

return "", err

}

defer os.Remove(f.Name())

// write utf8 BOM header if necessary for the current platform and/or locale

if needsBom() {

if _, err := f.Write(bom); err != nil {

return "", err

}

}

// write initial value

if _, err := f.WriteString(initialValue); err != nil {

return "", err

}

// close the fd to prevent the editor unable to save file

if err := f.Close(); err != nil {

return "", err

}

if editorCommand == "" {

editorCommand = defaultEditor

}

cli/pkg/surveyext/editor.go

Lines 22 to 32 in 057ad52

func init() {

if g := os.Getenv("GIT_EDITOR"); g != "" {

defaultEditor = g

} else if v := os.Getenv("VISUAL"); v != "" {

defaultEditor = v

} else if e := os.Getenv("EDITOR"); e != "" {

defaultEditor = e

} else if runtime.GOOS == "windows" {

defaultEditor = "notepad"

}

}

In the code above, gh is having to ask the user if they want to open the editor, however the logic for figuring out the editor is buried in the surveyext package after this code stanza.

What do we do to address this?

Change the user experience by removing the editor name from the prompt

Duplicate the logic for using the defaultEditor if the editor command is empty

Refactor the logic for the default editor so other places can use it

Fixed in b8cd094

andyfeller

An astounding heavy lift to get this prompting experience! ✨

I think there are things we should follow up after this PR including additional UX testing in Linux and Windows, working with our friends at Charm, refactoring some logic to be testable, etc. I don't think there is anything to block this PR but we do have more work beyond this.

Apparently, `gh` might not actually have an editor at the time we're prompting the user if they want to use it for markdown editing. In the survey package, there is a function that will handle fallback to the default editor based on environment variables and parse it in the case the editor contains flags and arguments for cases like Visual Studio Code. Additionally, there are no tests for the EditorName function and the fact it is loaded via `init` makes this difficult to test. Co-authored-by: Kynan Ware <47394200+BagToad@users.noreply.github.com>

This test was trying to block on `expect`’ing a string at the same time the prompt was completed. This doesn't need to happen for this test. It should just check for the output from the Input prompt invocation.

internal/prompter/prompter.go

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [cli/cli](https://github.com/cli/cli) | minor | `v2.69.0` -> `v2.72.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>cli/cli (cli/cli)</summary> ### [`v2.72.0`](https://github.com/cli/cli/releases/tag/v2.72.0): GitHub CLI 2.72.0 [Compare Source](cli/cli@v2.71.2...v2.72.0) ####

Accessibility public preview This release marks the public preview of several accessibility improvements to the GitHub CLI that have been under development over the past year in partnership with our friends at [Charm](https://github.com/charmbracelet) including: - customizable and contrasting colors - non-interactive user input prompting - text-based spinners These new experiences are captured in a new `gh a11y` help topic command, which goes into greater detail into the motivation behind each of them as well as opt-in configuration settings / environment variables. We would like you to share your feedback and join us on this journey through one of [GitHub Accessibility feedback channels](https://accessibility.github.com/feedback)! 🙌 #### What's Changed ##### ✨ Features - Introduce `gh accessibility` help topic highlighting GitHub CLI accessibility experiences by [@andyfeller](https://github.com/andyfeller) in cli/cli#10890 - \[gh pr view] Support `closingIssuesReferences` JSON field by [@iamazeem](https://github.com/iamazeem) in cli/cli#10544 ##### 🐛 Fixes - Fix expected error output of `TestRepo/repo-set-default` by [@aconsuegra](https://github.com/aconsuegra) in cli/cli#10884 - Ensure accessible password and auth token prompters disable echo mode by [@andyfeller](https://github.com/andyfeller) in cli/cli#10885 - Fix: Accessible multiselect prompt respects default selections by [@BagToad](https://github.com/BagToad) in cli/cli#10901 #### New Contributors - [@aconsuegra](https://github.com/aconsuegra) made their first contribution in cli/cli#10884 **Full Changelog**: cli/cli@v2.71.2...v2.72.0 ### [`v2.71.2`](https://github.com/cli/cli/releases/tag/v2.71.2): GitHub CLI 2.71.2 [Compare Source](cli/cli@v2.71.1...v2.71.2) #### What's Changed - Fix pr create when push.default tracking and no merge ref by [@williammartin](https://github.com/williammartin) in cli/cli#10863 **Full Changelog**: cli/cli@v2.71.1...v2.71.2 ### [`v2.71.1`](https://github.com/cli/cli/releases/tag/v2.71.1): GitHub CLI 2.71.1 [Compare Source](cli/cli@v2.71.0...v2.71.1) #### What's Changed - Fix pr create when branch name contains slashes by [@williammartin](https://github.com/williammartin) in cli/cli#10859 **Full Changelog**: cli/cli@v2.71.0...v2.71.1 ### [`v2.71.0`](https://github.com/cli/cli/releases/tag/v2.71.0): GitHub CLI 2.71.0 [Compare Source](cli/cli@v2.70.0...v2.71.0) #### What's Changed ##### ✨ Features - `gh pr create`: Support Git's `@{push}` revision syntax for determining head ref by [@BagToad](https://github.com/BagToad) in cli/cli#10513 - Introduce option to opt-out of spinners by [@BagToad](https://github.com/BagToad) in cli/cli#10773 - Update configuration support for accessible colors by [@andyfeller](https://github.com/andyfeller) in cli/cli#10820 - `gh config`: add config settings for accessible prompter and disabling spinner by [@BagToad](https://github.com/BagToad) in cli/cli#10846 ##### 🐛 Fixes - Fix multi pages search for gh search by [@leudz](https://github.com/leudz) in cli/cli#10767 - Fix: `project` commands use shared progress indicator by [@BagToad](https://github.com/BagToad) in cli/cli#10817 - Issue commands should parse args early by [@williammartin](https://github.com/williammartin) in cli/cli#10811 - Feature detect v1 projects on `issue view` by [@williammartin](https://github.com/williammartin) in cli/cli#10813 - Feature detect v1 projects on non web-mode `issue create` by [@williammartin](https://github.com/williammartin) in cli/cli#10815 - Feature detect v1 projects on web mode issue create by [@williammartin](https://github.com/williammartin) in cli/cli#10818 - Feature detect v1 projects on issue edit by [@williammartin](https://github.com/williammartin) in cli/cli#10819 ##### 📚 Docs & Chores - Refactor Sigstore verifier logic by [@malancas](https://github.com/malancas) in cli/cli#10750 #####

Dependencies - chore(deps): bump github.com/sigstore/sigstore-go from 0.7.1 to 0.7.2 by [@dependabot](https://github.com/dependabot) in cli/cli#10787 - Bump google.golang.org/grpc from 1.71.0 to 1.71.1 by [@dependabot](https://github.com/dependabot) in cli/cli#10758 #### New Contributors - [@leudz](https://github.com/leudz) made their first contribution in cli/cli#10767 **Full Changelog**: cli/cli@v2.70.0...v2.71.0 ### [`v2.70.0`](https://github.com/cli/cli/releases/tag/v2.70.0): GitHub CLI 2.70.0 [Compare Source](cli/cli@v2.69.0...v2.70.0) #### Accessibility This release contains dark shipped changes that are part of a larger GitHub CLI accessibility preview still under development. More information about these will be announced later this month including various channels to work with GitHub and GitHub CLI maintainers on shaping these experiences. ##### Ensure table headers are thematically contrasting [#8292](cli/cli#8292) is a long time issue where table headers were difficult to see in terminals with light background. Ahead of the aforementioned preview, `v2.70.0` has shipped changes that improve the out-of-the-box experience based on terminal background detection. The following screenshots demonstrate the Mac Terminal using the Basic profile, which responds to user's appearance preferences: <img width="1512" alt="Screenshot of gh repo list in light background terminal" src="https://github.com/user-attachments/assets/87413dde-eec8-43eb-9c16-dc84f8249ddf" /> <img width="1512" alt="Screenshot of gh repo list in dark background terminal" src="https://github.com/user-attachments/assets/7430b42c-7267-402b-b565-a296beb4d5ea" /> For more information including demos from various official distributions, see [#10649](cli/cli#10649). #### What's Changed ##### ✨ Features - Update go-gh and document available sprig funcs by [@BagToad](https://github.com/BagToad) in cli/cli#10680 - Introducing experimental support for rendering markdown with customizable, accessible colors by [@andyfeller](https://github.com/andyfeller) [@jtmcg](https://github.com/jtmcg) in cli/cli#10680 - Ensure table datetime columns have thematic, customizable muted text by [@andyfeller](https://github.com/andyfeller) in cli/cli#10709 - Ensure table headers are thematically contrasting by [@andyfeller](https://github.com/andyfeller) in cli/cli#10649 - Introduce configuration setting for displaying issue and pull request labels in rich truecolor by [@andyfeller](https://github.com/andyfeller) in cli/cli#10720 - Ensure muted text is thematic and customizable by [@andyfeller](https://github.com/andyfeller) in cli/cli#10737 - 9727 \[gh repo create] Show host name in repo creation prompts by [@iamazeem](https://github.com/iamazeem) in cli/cli#10516 - Introduce accessible prompter for screen readers (preview) by [@BagToad](https://github.com/BagToad) in cli/cli#10710 ##### 🐛 Fixes - `run list`: do not fail on organization/enterprise ruleset imposed workflows by [@BagToad](https://github.com/BagToad) in cli/cli#10660 - Implement safeguard for `gh alias delete` test, prevent wiping out GitHub CLI configuration by [@andyfeller](https://github.com/andyfeller) in cli/cli#10683 - Pin third party actions to commit sha by [@BagToad](https://github.com/BagToad) in cli/cli#10731 - Fallback to job run logs when step logs are missing by [@babakks](https://github.com/babakks) in cli/cli#10740 - \[gh ext] Fix `GitKind` extension directory path by [@iamazeem](https://github.com/iamazeem) in cli/cli#10609 - Fix job log resolution to skip legacy logs in favour of normal/new ones by [@babakks](https://github.com/babakks) in cli/cli#10769 ##### 📚 Docs & Chores - `./script/sign` cleanup by [@iamazeem](https://github.com/iamazeem) in cli/cli#10599 - Fix typos in CONTRIBUTING.md by [@rylwin](https://github.com/rylwin) in cli/cli#10657 - Improve `gh at verify --help`, document json output by [@phillmv](https://github.com/phillmv) in cli/cli#10685 - Acceptance test issue/pr create/edit with project by [@williammartin](https://github.com/williammartin) in cli/cli#10707 - Escape dots in regexp pattern in `README.md` by [@babakks](https://github.com/babakks) in cli/cli#10742 - Simplify cosign verification example by not using a regex. by [@kommendorkapten](https://github.com/kommendorkapten) in cli/cli#10759 - Document UNKNOWN STEP in run view by [@williammartin](https://github.com/williammartin) in cli/cli#10770 #####

Dependencies - Update github.com/sigstore/sigstore-go to 0.7.1 and fix breaking function change by [@malancas](https://github.com/malancas) in cli/cli#10749 #### New Contributors - [@rylwin](https://github.com/rylwin) made their first contribution in cli/cli#10657 **Full Changelog**: cli/cli@v2.69.0...v2.70.0 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

feat(prompter): add accessible prompter support

202c1ad

BagToad temporarily deployed to cli-automation March 31, 2025 21:06 — with GitHub Actions Inactive

BagToad added 3 commits March 31, 2025 15:52

feat(md prompter): md prompt respects blankAllowed

7b0c095

Accessible prompter now respects blankAllowed and will not prompt for "skip" if blankAllowed is false.

test(prompter): remove t.parallel calls

92b1a8e

t.Parallel() cannot be used when env vars are being set.

andyfeller reviewed Apr 1, 2025

View reviewed changes

internal/prompter/prompter.go Outdated Show resolved Hide resolved

williammartin reviewed Apr 2, 2025

View reviewed changes

internal/prompter/prompter_test.go Outdated Show resolved Hide resolved

williammartin reviewed Apr 2, 2025

View reviewed changes

internal/prompter/prompter_test.go Outdated Show resolved Hide resolved

williammartin reviewed Apr 2, 2025

View reviewed changes

internal/prompter/prompter.go Outdated Show resolved Hide resolved

BagToad and others added 3 commits April 2, 2025 11:58

feat(prompter): include no as false-y value

88a98ea

Co-authored-by: Andy Feller <andyfeller@github.com>

test(prompter): go-expect based prompter tests

f7de9e0

fix(prompter): rename huhprompter

94bbd26

BagToad force-pushed the kw/first-pass-accessible-prompter branch from a1fd70b to 94bbd26 Compare April 2, 2025 18:56

BagToad added 3 commits April 2, 2025 12:58

test(prompter): replace assert with require

0d7fd36

tests(prompter): rename huhprompter

e42af35

test(prompter): remove needless variable declaration

e299b56

BagToad force-pushed the kw/first-pass-accessible-prompter branch 3 times, most recently from 262ce37 to a07c4aa Compare April 3, 2025 14:23

test(prompter): skip vt10x tests on Windows

8827803

BagToad force-pushed the kw/first-pass-accessible-prompter branch from a07c4aa to 8827803 Compare April 3, 2025 14:25

BagToad added 2 commits April 3, 2025 08:45

test(prompter): move to external package

88e6285

fix(linter): linter errors

02fc12e

BagToad requested a review from andyfeller April 9, 2025 14:26

BagToad changed the title ~~Introduce accessible prompter for speech synthesis screen readers (preview)~~ Introduce accessible prompter for screen readers (preview) Apr 9, 2025

fix(prompter): update huh and fix tests

2f5e896

BagToad force-pushed the kw/first-pass-accessible-prompter branch from efb6989 to 39fccf6 Compare April 9, 2025 21:39

BagToad added 2 commits April 9, 2025 15:51

fix(prompter): pass io to huh and refactor tests

fab0de5

chore: go mod tidy

4615069

BagToad force-pushed the kw/first-pass-accessible-prompter branch from d7de8fb to 4615069 Compare April 9, 2025 21:51

williammartin reviewed Apr 10, 2025

View reviewed changes

internal/prompter/accessible_prompter_test.go Outdated Show resolved Hide resolved

williammartin reviewed Apr 10, 2025

View reviewed changes

internal/prompter/accessible_prompter_test.go Show resolved Hide resolved

williammartin reviewed Apr 10, 2025

View reviewed changes

internal/prompter/accessible_prompter_test.go Show resolved Hide resolved

williammartin reviewed Apr 10, 2025

View reviewed changes

internal/prompter/prompter.go Outdated Show resolved Hide resolved

williammartin approved these changes Apr 10, 2025

View reviewed changes

BagToad added 3 commits April 10, 2025 10:37

test(prompter): use *testing.T instead

47d6032

test(prompter): describe why echo is editorcmd

8b70870

test(prompter): doc how accessible prompter tests work

9eee77a

andyfeller reviewed Apr 10, 2025

View reviewed changes

andyfeller approved these changes Apr 10, 2025

View reviewed changes

BagToad and others added 2 commits April 10, 2025 16:28

fix(prompter): remove needless default value assignment

20ff409

BagToad force-pushed the kw/first-pass-accessible-prompter branch from fe78c17 to b8cd094 Compare April 10, 2025 22:29

test(prompter): fix race condition

8cd3992

This test was trying to block on `expect`’ing a string at the same time the prompt was completed. This doesn't need to happen for this test. It should just check for the output from the Input prompt invocation.

BagToad commented Apr 10, 2025

View reviewed changes

internal/prompter/prompter.go Outdated Show resolved Hide resolved

test(prompter): fix invalid comment

70537de

BagToad enabled auto-merge April 10, 2025 23:20

BagToad merged commit dec71dd into trunk Apr 10, 2025
7 checks passed

BagToad deleted the kw/first-pass-accessible-prompter branch April 10, 2025 23:28

BagToad mentioned this pull request Apr 21, 2025

gh config: add config settings for accessible prompter and disabling spinner #10846

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Introduce accessible prompter for screen readers (preview) #10710

Introduce accessible prompter for screen readers (preview) #10710

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

	func edit(editorCommand, fn, initialValue string, stdin io.Reader, stdout io.Writer, stderr io.Writer, cursor showable, lookPath func(string) ([]string, []string, error)) (string, error) {
	// prepare the temp file
	pattern := fn
	if pattern == "" {
	pattern = "survey*.txt"
	}
	f, err := os.CreateTemp("", pattern)
	if err != nil {
	return "", err
	}
	defer os.Remove(f.Name())

	// write utf8 BOM header if necessary for the current platform and/or locale
	if needsBom() {
	if _, err := f.Write(bom); err != nil {
	return "", err
	}
	}

	// write initial value
	if _, err := f.WriteString(initialValue); err != nil {
	return "", err
	}

	// close the fd to prevent the editor unable to save file
	if err := f.Close(); err != nil {
	return "", err
	}

	if editorCommand == "" {
	editorCommand = defaultEditor
	}

	func init() {
	if g := os.Getenv("GIT_EDITOR"); g != "" {
	defaultEditor = g
	} else if v := os.Getenv("VISUAL"); v != "" {
	defaultEditor = v
	} else if e := os.Getenv("EDITOR"); e != "" {
	defaultEditor = e
	} else if runtime.GOOS == "windows" {
	defaultEditor = "notepad"
	}
	}

Introduce accessible prompter for screen readers (preview) #10710

Introduce accessible prompter for screen readers (preview) #10710

Uh oh!

Conversation

Uh oh!

Description

Acceptance Criteria

Demo

Notes

Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Thoughts

Demo

Prompter.AuthToken

Prompter.Confirm

Prompter.ConfirmDeletion

Prompter.InputHostname

Prompter.MarkdownEditor

Prompter.MultiSelect

Prompter.Select

Uh oh!

Uh oh!

Choose a reason for hiding this comment

How does this work today?

What do we do to address this?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

`Prompter.AuthToken`

`Prompter.Confirm`

`Prompter.ConfirmDeletion`

`Prompter.InputHostname`

`Prompter.MarkdownEditor`

`Prompter.MultiSelect`

`Prompter.Select`