# Focus management Source: https://ordergroup.co/glossary/focus-management/ Last updated: 2026-10-10 > Focus management for teams ordering an app: WCAG focus criteria, dialogs and focus traps, focus after navigation, and what React Native and iOS change. [Accessibility](https://ordergroup.co/glossary/accessibility/) 4 min read # Focus management Focus management (keyboard and screen reader focus) Also known as: focus order, focus trap, accessibility focus Definition Focus management is how an app decides which element receives keyboard or screen reader focus when the screen changes: after navigation, when a dialog opens or closes, or when an error appears. Done right, the user always knows where they are and cannot reach controls that are hidden. Cite this entry Text "Focus management". Order Group, Software glossary, 10 October 2026. https://ordergroup.co/glossary/focus-management/ HTML `Focus management - Order Group` Reviewed by [Daria Gusieva](https://ordergroup.co/authors/daria-gusieva/), Head of Design Last reviewed 10 October 2026 ## How focus management works 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. WCAG criteria that focus management serves CriterionLevelWhat it means in the app 2.1.2 No Keyboard TrapAKeyboard focus can always leave a component; a modal dialog meets this because the user can close it, for example with Escape2.4.3 Focus OrderAFocus moves in an order that keeps meaning and operation, including into and out of dialogs2.4.7 Focus VisibleAAKeyboard focus has a visible indicator2.4.11 Focus Not Obscured (Minimum)AASticky headers, banners and chat widgets do not fully hide the focused control3.2.1 On FocusAReceiving focus does not by itself change the context, for example open a new page4.1.3 Status MessagesAAMessages such as {qsaved} are announced without moving focus away from the user's task ## What focus management means for your software 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. Writing the specification? Add Focus management to your requirements checklist Collect the terms your project touches and get their system requirements in one e-mail, ready for an RFP. ## From our projects 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. ## Related terms - [Accessibility audit](https://ordergroup.co/glossary/accessibility-audit/) Accessibility audit (WCAG audit) An accessibility audit is a structured check of a website or app against a standard, usually WCAG 2.1 or 2.2 at level AA. It combines automated scans with manual testing by keyboard and screen reader, and ends with a report that lists each failed success criterion, where it fails and how to fix it. - [Screen reader testing](https://ordergroup.co/glossary/screen-reader-testing/) Screen reader testing (VoiceOver, TalkBack, NVDA) Screen reader testing checks an app or website with VoiceOver, TalkBack, NVDA or another reader that blind and low-vision people use to hear the interface. A tester goes through every screen and checks what is announced, in what order, and whether every task can be finished. - [WCAG 2.2](https://ordergroup.co/glossary/wcag-2-2/) Web Content Accessibility Guidelines 2.2 WCAG 2.2 is the W3C standard for accessible web content. It sets 86 testable success criteria at three levels, A, AA and AAA. Content that meets WCAG 2.2 also meets 2.1, the version that EU and Polish rules for websites and apps point to at level AA. ## Sources 1. [Understanding Success Criterion 2.4.3: Focus Order](https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html) - W3C 2. [Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html) - W3C 3. [ARIA Authoring Practices Guide: Dialog (Modal) Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/) - W3C 4. [Accessibility in React Native](https://reactnative.dev/docs/accessibility) - React Native Daria Gusieva reviewed this entry. Ask how it applies to your project. [Ask an engineer](https://ordergroup.co/contact-us/) ## FAQ ![Daria Gusieva](https://ordergroup.co/media/images/T02DHCC1Z-U0B48S6GQTV-7fae05753481-512.format-webp.webp) Daria Gusieva Head of Design [Talk to an engineer](https://ordergroup.co/contact-us/) ### What is a focus trap? A focus trap keeps keyboard and screen reader focus inside a component, usually a modal dialog, until it closes. It is correct for modal dialogs and wrong anywhere else: a trap on a normal page stops keyboard users from leaving it and fails WCAG 2.1.2. ### Where should focus go when a new screen opens? To an element that tells the user where they are: usually the screen heading, or the back button where the platform convention expects it. Agree on one rule for the whole app and test it on each platform. ### Is focus management only for keyboard users? No. Screen reader users depend on it as much, and on mobile they are the main group affected. Focus that lands in the wrong place on a phone means the user hears the wrong content first. ### Why did a dialog work on Android and fail on iOS? Each platform isolates dialogs differently, and cross-platform frameworks do not always pass accessibility properties to the native view. Test dialogs with VoiceOver and TalkBack separately, and check the native behavior, not only the component's props. Building a system that depends on Focus management? See how we build software for this domain, with case studies and the stack we use. [See User Experience Design](https://ordergroup.co/services/design/user-experience-ux/) Requirements checklist For each term we send the definition and what it requires from your software. Free, no sales call needed. Your checklist is empty. Use the plus next to a term to add it.