fix(modal): focus the dialog wrapper on present so screen readers can enter the modal#31260
Merged
Conversation
…resent
IONIC-91 / FW-7611: Android TalkBack users could not navigate into or
interact with modal content after opening it.
`present()` in overlays.ts moved DOM focus to `overlay.el` (the shadow
host) when no descendant was already focused. Every overlay built on
this shared utility (modal, alert, action-sheet, loading, popover)
declares `role="dialog"`/`aria-modal` on an inner `.ion-overlay-wrapper`
element inside its shadow root, never on the host itself. Focusing the
host therefore handed assistive tech a focus target with no accessible
role or name, so TalkBack's accessibility-focus never landed on the
actual dialog and its linear navigation cursor never entered the
overlay's content.
Focus the `.ion-overlay-wrapper` instead (falling back to the host if
none exists), and make modal's wrapper focusable via tabIndex={-1} so
the retargeted focus() call actually takes effect.
…ually focusable Alert declares role="alertdialog" and tabindex="0" on .alert-wrapper, so redirecting focus there (as done for modal) is correct and already works. Action-sheet, loading, and popover keep role/aria-modal on the host and never gave .ion-overlay-wrapper a tabindex, so it was never meant to be focused directly. The previous version of this fix called .focus() on that non-focusable wrapper unconditionally, which silently failed and left focus on <body> instead of the host -- a regression against their prior, correct behavior. Guard the redirect on the wrapper actually declaring a tabindex so only overlays authored to use it are affected; others keep focusing the host exactly as before.
Popover set aria-modal="true" on the host but declared no role at all. Per the ARIA spec, aria-modal is only defined on elements with role dialog or alertdialog, so assistive technologies were silently ignoring it -- popovers were never actually exposed as modal to screen readers. ion-select already declares aria-haspopup="dialog" on its trigger when using the popover interface, so this also fixes a pre-existing mismatch between what select promised and what the popover actually exposed. Default to role="dialog", placed before the htmlAttributes spread so consumers can still override it (e.g. role="menu") the same way modal and alert allow.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
gnbm
changed the title
…ocus for sheet/card
The initial fix made the modal's `.modal-wrapper` (which carries
role="dialog") the focus target on present so Android TalkBack can enter
the dialog. For sheet and iOS card modals that wrapper is also the
drag-gesture surface: leaving focus on it interferes with pointer-drag
recognition (observed as the sheet "drag events" e2e timing out on
Firefox). Real users are unaffected (the gesture works once focus
settles), but it is a genuine behavior change and broke a merge-gating
test.
Scope the wrapper `tabIndex={-1}` to default modals only. Sheet and card
modals keep focusing the host exactly as before, so their drag gestures
are untouched, while the reported IONIC-91 case (default modal) still
gets the accessible focus target. Also focus the wrapper with
`preventScroll` so the a11y focus move never scrolls the viewport.
Review + a new axe scan showed that defaulting role="dialog" on ion-popover makes every *unlabeled* popover fail axe's serious `aria-dialog-name` rule (an ARIA dialog must have an accessible name) -- a consumer-facing regression. Revert the popover role change (and its tests) so this PR stays scoped to the verified modal (IONIC-91) focus fix. Popover's missing role can be revisited with a proper accessible- name strategy. Also tighten the modal a11y test comment to match the surrounding concise style.
gnbm
changed the title
Match the focus-assertion style used across the modal suite (expect(locator).toBeFocused()) and the existing `.modal-wrapper` locator in this file, instead of a manual page.evaluate over shadowRoot.activeElement.
gnbm
changed the title
gnbm
commented
Jul 2, 2026
Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com>
Co-authored-by: Brandy Smith <brandyscarney@users.noreply.github.com>
…dals too The wrapper now carries tabindex=-1 for all modal types, not just the default modal, so present() moves focus to the element that declares the dialog role and TalkBack users can enter sheet and card modals. The previous exclusion existed because making the wrapper focusable made the 'sheet modal: drag events' e2e hang on Firefox. Root cause: Gecko treats an element with tabindex as a selection root - a pointer press inside it places a text caret, and a later press over that caret starts a native drag and drop session instead of delivering pointer events. The gesture then never receives the final pointerup. The sheet and swipe-to-close gestures now cancel any native dragstart while a drag is active, which prevents the hijack without affecting drag and drop when the modal is not being dragged. Adds wrapper-focus e2e coverage for sheet and card modals.
…le options
present() runs on a critical path, so wrap the focus({ preventScroll })
call in a try/catch that falls back to a plain focus(). This keeps the
no-scroll behavior on modern browsers while ensuring a focus call can
never reject present() on an engine that mishandles the options object.
joselrio
approved these changes
Jul 14, 2026
joselrio
left a comment
joselrio
left a comment
Contributor
There was a problem hiding this comment.
After looking into the suggested stuff and also run tests around this directly on the android device through the https://github.com/OutSystems/ui-comp-ionic-sandboxes repo and everything's running as expected.
codeCraft-Ritik
left a comment
codeCraft-Ritik
left a comment
There was a problem hiding this comment.
This is a well-considered fix. Updating focus management to target the dialog element makes the modal much more accessible for screen reader users, while preserving compatibility with overlays that keep the role on the host. The cross-browser consideration is a nice touch.
brandyscarney
approved these changes
Jul 16, 2026
ShaneK
added a commit
that referenced
this pull request
Jul 23, 2026
When a sheet modal defaults handleBehavior to "cycle" (the new default on major-9.0), the host becomes focusable and onModalFocus redirects focus to the drag handle. present() (from #31260) focuses the shadow-DOM dialog wrapper for screen readers, but that focus event is retargeted to the host at the shadow boundary, so onModalFocus saw ev.target === el and bounced focus onto the handle. The wrapper never kept focus, which failed the "focus the sheet modal wrapper on present" e2e on Firefox. Guard the redirect on el.shadowRoot.activeElement being null, which is true only when the host itself was focused directly (e.g. tabbing into the modal). When present() focuses the wrapper, activeElement is the wrapper, so the redirect is skipped and the dialog focus is left intact. Tabbing to the handle from outside still works.
2 tasks
pull Bot
pushed a commit
to goldtoad6/ionic-framework
that referenced
this pull request
Jul 23, 2026
…1293) Issue number: internal --------- ## What is the current behavior? When a sheet modal uses `handleBehavior="cycle"`, the host element is focusable (`tabIndex=0`) and `onModalFocus` redirects focus to the drag handle whenever the host is focused. `present()` moves focus to the `.modal-wrapper` (the `role="dialog"` element) inside the shadow DOM, but that focus event is retargeted to the host, so `onModalFocus` sees `ev.target === el` and treats it as a direct host focus. It then bounces focus onto the handle. This is latent on the default `handleBehavior="none"` (the host isn't focusable, so the redirect never runs), but reproduces on any sheet modal that opts into `cycle`. ## What is the new behavior? `onModalFocus` now redirects to the handle only when the host itself was focused directly, detected by `el.shadowRoot?.activeElement` being `null`. When `present()` focuses the dialog wrapper, `activeElement` is the wrapper (not null), so the redirect is skipped and the dialog keeps focus. Tabbing into the modal from outside still lands on the handle, since the host is the focused element in that case. ## Does this introduce a breaking change? - [ ] Yes - [x] No ## Other information Related to the dialog focus work in ionic-team#31260 . That change is correct under the default `handleBehavior`, but the `cycle` path was not covered until now. Adds an e2e test to `utils/test/overlays/overlays.e2e.ts` that presents a sheet modal with `handle-behavior="cycle"` and asserts focus stays on the wrapper. The same fix ships on the major-9.0 sync (ionic-team#31290), where `cycle` is the default and this bug is hit on every sheet modal. Preview (sheet modal test page): - iOS: https://ionic-framework-git-fix-modal-focus-cycle-ionic1.vercel.app/src/components/modal/test/sheet?ionic:mode=ios - MD: https://ionic-framework-git-fix-modal-focus-cycle-ionic1.vercel.app/src/components/modal/test/sheet?ionic:mode=md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue number: internal
What is the current behavior?
When a modal is opened with Android TalkBack enabled, the screen reader cannot enter or navigate the modal's content. On present, focus is moved to the modal host, but the host is role-less. The
role="dialog",aria-modal, and the label live on the inner.ion-overlay-wrapperso assistive technologies have no dialog to land on.What is the new behavior?
present()now focuses the overlay's[role="dialog"]element (the wrapper) instead of the role-less host, falling back to the host when the role is on the host (action-sheet, loading).tabIndex="-1"so it can receive that programmatic focus (an element with onlyrole="dialog"is not focusable). Its focus ring is suppressed since the focus is programmatic, not keyboard-driven.modal/test/a11y/modal.e2e.tsto verify no visible outline added to the wrapper.utils/test/overlays/overlays.e2e.tsto verify the focus is on the wrapper instead of the host for all modals.mouse.down()to prevent the selection from blocking gesture detection in the test environment.