Windows Accessibility Settings - Acceptance Delay / Hold Delay on Keyboard

Question

Windows Accessibility Settings - Acceptance Delay / Hold Delay on Keyboard

McCartney, Ruth 20

Hi there,

I work in an Assistive Technology Service supporting people with a range of communication disabilities.. we're working with a man who has no sight, and early onset Parkinson's disease..

We're looking for a set up from a bluetooth keyboard that would mean he could press a letter to hear it echo, in order to know which letter he is on (narrator can facilitate this), but then we need a 'hold' time that would mean he doesn't 'send' / select the key unless he holds it for a certain amount of time - say 2 seconds.

I can't see this as an option? Any ideas? Or could it be added?

Thank you!!

Ruth

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hendrix-V 19,470 Microsoft External Staff Moderator

Hi McCartney, Ruth,

Thank you for sharing this detailed use case, it’s a great example of how accessibility features are being thoughtfully applied.

In Windows, the closest built‑in option for introducing a delay before a keypress is accepted is Filter Keys. This feature can help reduce unintended input by requiring a key to be held briefly before it registers.

Press Windows + U to open Accessibility > Keyboard
Turn on Filter Keys then expand settings and enable“Ignore quick keystrokes (Slow Keys)”
Increase the delay to the highest available value

This setup can approximate a “hold before accept” behavior by ignoring very short presses. The delay is adjustable but not exact (e.g., not a fixed 2‑second confirmation threshold). It works best for filtering accidental input rather than acting as a strict “press‑and‑hold to confirm” mechanism.

If the goal is to confirm each key before committing input, pairing this with a screen reader (such as Narrator) can help provide immediate audio feedback while typing.

While the current settings may not fully match this specific workflow, the combination above can still improve control and reduce unintended selections.

I hope this helps move you closer to a workable setup. Let me know if you need any further help. Feel free to ask by clicking "Add Comment" or "Add Reply" if you are unable to add a comment, so that your reply is visible. I appreciate your effort.

Note: Follow the instructions in our documentation to enable email notifications if you wish to receive notifications about this conversation.

McCartney, Ruth 20 Reputation points

2026-05-27T08:03:04.9733333+00:00

Thank you so much for this - slow keys is exactly what I was looking for, not sure how I hadn't spotted that!

Any tips on how to set narrator up to only echo the keys from the keyboard, and not everything on the screen? The guy we're working with will only be using the keyboard, but for supporting staff etc, the narration is a bit of a distraction... could confuse some of the staff...
McCartney, Ruth 20 Reputation points

2026-05-27T14:33:01.5166667+00:00

Sorry thinking about this again... when you're using narrator on screen, it looks like you can touch an area of the screen and hear the description without selecting it? Seems that you double tap to select? This is what we want for the keyboard input? If that makes sense? although I suspect this works on the on screen keyboard, but the keyboard hardware may be more challenging..
Hendrix-V 19,470 Reputation points Microsoft External Staff Moderator

2026-05-28T01:19:59.7566667+00:00
Hi McCartney, Ruth,

You can reduce Narrator so that it mainly reads what’s typed rather than everything on screen:

Press Ctrl + Windows + N > open Narrator settings

Go to Verbosity, set a lower level (e.g. Minimal)

Turn off options like hints and contextual details

Go to “What to hear when typing”

Turn on: Hear characters as you type

Turn off: Hear words/other feedback (if not needed)

About “touch to explore” vs keyboard input, you’re right in your observation:

On touch/onscreen keyboard, Narrator allows Explore (hear item) > then double‑tap to activate

With a physical keyboard, input is handled differently:

Keys are accepted once pressed (after the Slow Keys delay)

There isn’t a separate “preview before commit” step for hardware keys

As a practical setup for your scenario, the closest working approach is:

Slow Keys (Filter Keys) > prevents accidental activation

Narrator (character echo only) > confirms each key press audibly

With these adjustments, it should feel much simpler and more predictable for both the user and supporting staff.

In addition, if you found my answer helpful, I’d really appreciate it if you could click "Accept Answer" and kindly give it an upvote.

Thanks for your time and effort.
McCartney, Ruth 20 Reputation points

2026-05-28T08:25:09.9666667+00:00

Thanks so much for this - clears it up for me, and definitely something to work with....

I'm not sure if you have a list for future developments.... but the 'preview before commit' feature for hardware keys would be such a brilliant solution! Thanks for all you help!
Hendrix-V 19,470 Reputation points Microsoft External Staff Moderator

2026-05-29T00:18:24.7733333+00:00

Hi,

I hope the insights shared in the forum help address your concerns effectively. And thank you for accepting my answer since accepting it helps others with similar concerns can find useful information.