Focus management

Keyboard focus marks the element that receives input; a keyboard user sees it as a highlighted outline and moves it with Tab. A screen reader keeps its own focus, which the user moves with swipes or keys and hears instead of seeing. The two often sit on the same element, but a screen reader can also read text that keyboard focus never reaches. When nothing on the screen changes, the order of focus follows the order of elements in the code. Focus management is about the moments when the screen does change: a new page loads, a dialog opens, content is added or removed, or an error appears.

At each of those moments the app has to put focus somewhere on purpose. If it does not, the platform guesses. On a web page focus may stay on a button that no longer exists and fall back to the top of the document. In a mobile app the screen reader may land on the first element it finds, which is often a toolbar button instead of the screen title. The user then has to search the screen to find out what happened.

Dialogs need the most care. The modal dialog pattern in the W3C ARIA Authoring Practices Guide describes three behaviors: when a modal dialog opens, focus moves into it; while it is open, focus stays inside it and cannot reach the page behind; when it closes, focus returns to the element that opened it, usually the button the user pressed. On the web, aria-modal and the native dialog element opened with showModal() help keep a screen reader inside the dialog. On iOS the equivalent is the accessibilityViewIsModal property, and on Android content behind a dialog can be hidden from TalkBack with importantForAccessibility.

Focus problems rarely show in screenshots or design reviews, because they live in transitions. Requirements for an app you are ordering:

• For every screen, the design states where focus lands on arrival: usually the screen heading, or the back button if the platform convention expects it.
• After an action that changes the screen, such as submitting a form, focus moves to the result: the confirmation heading, or the first field with an error.
• Every dialog follows the same rules: focus moves in, stays in, and returns to the trigger. This is built once, in a shared component, and tested on each platform.
• Content that appears without user action, such as a progress bar or a countdown, is announced as a status message rather than stealing focus.
• Pages with a sticky header or a cookie or chat banner are checked with the keyboard, because these elements can cover the focused field.
• Tests use both a keyboard and a screen reader, on each platform. A fix that works on Android can fail on iOS, so retests cover both.

In the mobile app for Centrum Komunikacji, built in React Native for deaf, hard-of-hearing, blind and deafblind users, we found in August 2026 that the accessibilityViewIsModal property set on a React Native Modal never reached the native view. The Modal component passes on only the props it lists, and this one was not among them. A file source dialog was shown as a transparent overlay (the overFullScreen presentation style), which keeps the screen behind it in the accessibility tree. Our check of the component tree found 25 controls behind the dialog that VoiceOver could reach, including the menu and notifications, against 4 in the dialog itself. The overlay was fully opaque anyway, so we switched the dialog to the fullScreen style, in which iOS removes the screen behind it from the accessibility tree, and removed the dead property from the three components that used it. That check read only the React tree, so before the merge we asked for a test on a physical device with VoiceOver.

In September 2026 a blind accessibility expert testing the production app reported that focus on a service screen started at the order button, while users expect it at the top of the screen. After the fix, focus on the final ordering screen landed on the text size button instead of the order received heading, so the change went through another round of fixes and retests.

For PSONI, mobile tests of Generator ETR in September and October 2026 found focus jumping to the close button when a document opened instead of to its text, and focus going to the page heading during a file upload instead of to the upload status. Those points are part of the mobile screen reader round still in testing.