وضع التصفح مقابل وضع التركيز

Desktop screen readers have two gears. Browse mode reads content, while focus mode types into it. Knowing both ends a lot of confusion. 🔁

In browse mode, keys like H, K, and arrows navigate the page. The reader intercepts them so you can skim headings and links.

Browse mode works on a flattened virtual buffer of the page. That is why you can arrow through text the same way in any document.

When you reach a text field, the reader switches to focus mode. Now your keystrokes pass straight to the input instead of navigating.

Without two modes, typing the letter H would jump headings instead of writing it. Focus mode lets you actually fill in a form.

NVDA flips to focus mode on its own when focus lands on an editable field or a widget that needs raw keystrokes.

You can switch by hand too. In NVDA, NVDA plus Space toggles between browse and focus when automatic guessing gets it wrong.

VoiceOver calls its typing state Quick Nav off. Turning Quick Nav on or off shifts between exploring and interacting much like the two modes.

A fake button or a div pretending to be a menu can leave the reader in the wrong mode, so keystrokes go nowhere useful.

Correct roles tell the reader when to enter focus mode. Real form controls and proper ARIA roles make the switch happen on cue.

When you audit, check that reading works in browse mode and that every input accepts text once focus mode kicks in.

What does a screen reader's focus mode let the user do?

Browse mode reads and navigates; focus mode types and interacts. Correct roles flip the switch automatically so users never get stuck. ✅