Restore Full Keyboard Access to Finder's replace dialog

At some point in time, the Finder's replace dialog lost the ability to be manipulated using the Full Keyboard Access setting. In other words, I can no longer find a way to use ⇥ (tab) to select a button in a replace dialog and ⏎ (return) to press it. Is there any way to restore that functionality?
(Actually, I seem to remember now that the spacebar, not ⏎ (return), pressed the button.)

Try changing the setting at the bottom of this window:

Sorry, no. I should've probably included a screen shot of my instance of that window. The "All Controls" setting has no effect for those dialogs. I'm in Mojave 10.14.6.

Well I had the exact same problem as you and when I switched from "Text Boxes and Lists only" to "All Controls" it started working correctly. I'm also in 10.14.6.

That's odd. I had the same problem. And that solution worked for me. Do you own more than one Mac where you can compare settings and symptoms?

Thanks. Now I'm just angry. I toggled that setting by alternatively trying the prefpane radio button and by pressing ⌃F7 while the dialog was active. The only thing that worked was to press ⌃F7 twice in succession when the dialog activated. It does allow ⇥ to select a button, but only for that dialog. The setting appears to be retained in the prefpane, but nothing happens next time I press tab when the dialog activates unless I press ⌃F7 twice in succession again. I guess I'll try another Mac, or another user account, then figure out which preference file(s) became corrupted and must be replaced, assuming that will fix it.

Did you check the setting at the top of this page. Mine is disabled. I tend to disable things I don't use.

That appears to allow the shortcut for Full Keyboard Access to be changed, or to prevent Full Keyboard Access from being toggled at all. If I set the radio button choice to All controls and leave the check mark out of the box next to Change the way Tab moves focus, Tab does nothing in the replace dialog. The behavior is the same for a freshly created account. Haven't yet tried another Mac. There's a chance that a software setting caused interference, or even that a conflicting software solution did it, or that one or more setting files caused the issue. There's also the chance that having a Touch Bar (mine does) makes a difference.

I don't have a Touch Bar to test with. Do you have other keyboard utilities installed like BetterTouchTool? I don't have utilities like that myself. So I'm running dry of ideas.

No, I don't have that, and I can't think of anything other than Keyboard Maestro that could potentially interfere. I do have OnMyCommand installed to enhance contextual menus, but I can't figure how that could be related. How a problem like this could exist under a new admin account login is intriguing.

that tells you it is likely something in your startup items common to both user accounts. You might try starting your Mac in Safe mode and see if it persists.

I've reached the conclusion that the issue involves some software/hardware configuration related to my T2 chip Early 2018 MacBook Pro with Touch Bar. I normally use an extended keyboard and mouse with the MacBook Pro, having the MacBook Pro's body supported on a shelf to bring its screen closer to eye level at my workstation. I started without the keyboard and mouse as well as in safe boot mode, and here's what I discovered. I can no longer use the toggling workaround that I previously discovered (pressing ⌃F7 twice while the dialog is in front), because I haven't found a way to force the Touch Bar to display anything other than the three buttons on the dialog while the dialog is in front (no Fkeys appear otherwise). So I don't know if it's possible to configure the Touch Bar to display Fkeys while the dialog is active, but I would have to change the Full Keyboard Access shortcut to try it, and I'm not eager to.

What I did find was that clicking the dialog window with the cursor over the text above the buttons makes tabbing between buttons work as expected. Clicking elsewhere in the window has no effect. So maybe there is a window text selection setting or tweak that I've enabled at some point in time that is affecting the issue. But it's hard to imagine a setting like that following a new user.

I don't think it will be practical for me to try to define the properties involved with this behavior any more than that. If someone else with the same model is able to refute my findings, then it might be worth looking into further.

I suppose, as a workaround, I could tell KM to trap a Tab keystroke in Finder if and only if a replace dialog is in front, then execute a click in the text field above the buttons followed by Tab keystroke. I haven't tried that yet, because I'm not quite sure about what obstacles or complications might be in store for me.

I did implement a workaround to handle the issue, such as it is.