Keyboard
Keyboard trap
Open a panel and test whether keyboard users can move through and leave it predictably.
Course progress: 0 / 20 lessons
LESSON 4 OF 20
Compare web and app environments
Screen reader testing for product teams usually crosses websites, web apps, native mobile apps, and embedded web content. Each environment changes the accessibility layer, input model, focus behaviour, and recovery path.
In this lesson
Identify how browser, operating system, app framework, and embedded web content change the screen reader experience.
The environment is part of the interface
Accessibility does not stop at component code. A user also depends on the browser, operating system, app framework, device settings, input method, and transitions into system or embedded web content. A pattern that works in desktop Chrome can fail in a native mobile app or WebView.
- A desktop web app depends on browser semantics, keyboard commands, focus events, and responsive layout.
- A mobile web page depends on the browser, touch exploration, swipe order, viewport changes, and virtual keyboard behaviour.
- A native iOS or Android app depends on platform components, accessibility APIs, gestures, system dialogs, and app navigation.
- A hybrid app can move between native controls and embedded web content during one task.
- Authentication, permissions, payments, and external browser handoffs can change focus and context.
Browser and app layers
On the web, the browser turns markup and script-driven changes into an accessibility tree. In native apps, platform components and accessibility properties create the model. In WebViews, both layers may be involved, so teams must record where the task crosses boundaries.
- Record whether the task uses a browser, native app screen, or embedded web view.
- Check whether headings, labels, roles, states, and errors survive the transition.
- Confirm focus after route changes, authentication, permissions, and external handoffs.
- Test virtual keyboard entry and error recovery on mobile.
- Do not assume one passing web result proves the native app path.
A hybrid checkout example
Imagine a native shopping app that opens an embedded checkout. The user chooses delivery details in native screens, enters payment in a WebView, handles a one-time-code field, and returns to an order confirmation. A missing WebView heading, focus reset, unlabeled native close button, or unannounced return from payment can block the task even when each component looks complete.
- Native and web controls both need useful names, roles, states, and errors.
- The transition into checkout needs a clear starting point.
- The virtual keyboard must not hide essential instructions or errors.
- Returning from payment must restore focus to a meaningful location.
- The confirmation state needs to be announced and remain reviewable.
Test the complete task
A component inspection cannot validate a complete web or app journey. Test on the supported device, browser, operating system, app build, and screen reader. Include startup state, navigation, form entry, errors, dynamic updates, external handoffs, and the route back.
Define ownership across boundaries
Complex products often cross systems owned by different teams or suppliers. A mobile app can launch a browser for authentication, embed a third-party payment form, or open a platform permission prompt. The user experiences one task even when organisations divide the technology. Document each transition, agree who verifies it, and provide an accessible recovery route when an external system fails or returns unexpected focus.
Web and browser apps
Semantic markup, browser behaviour, focus management, keyboard support, and dynamic announcements strongly influence output. The browser and screen reader combination matters, and responsive layouts can change order or visibility.
Mobile web
Touch exploration, swipe order, responsive layout, virtual keyboards, browser chrome, and dynamic announcements shape the experience.
Native mobile apps
Platform components, gestures, system settings, accessibility APIs, notifications, permissions, biometric prompts, and embedded web content can cross ownership boundaries.
Embedded web views
A WebView can look like part of the app while relying on browser-backed content, script, and web semantics. Focus, headings, forms, and route changes need separate checks.
Desktop web
Keyboard productivity, browse or virtual cursor navigation, browser differences, tables, complex widgets, and braille workflows are common testing concerns.
TRY THIS NOW
Add the environment to the test
Choose the environment closest to your product and identify one constraint that belongs in the test plan.
- Desktop webAccount for browser support, keyboard operation, screen-reader mode changes, and page structure.
- Mobile webAccount for viewport changes, touch exploration, browser controls, and virtual keyboard behaviour.
- Native mobile appAccount for platform components, app navigation, system dialogs, permissions, and gestures.
- WebView or hybrid flowAccount for transitions between native UI and browser-backed content, including focus recovery.
What to remember
The accessibility principles recur, but the complete experience depends on the environment. Include browsers, app frameworks, WebViews, system prompts, input methods, focus, dynamic updates, and recovery in product decisions.
Try this with your team
Choose one important product task that crosses web and app contexts. Map the task from start to confirmation. Record where the user is in native UI, browser content, WebView content, system prompts, errors, and recovery steps.
Knowledge check
Answer every question, then use the forward lesson button to record this lesson as complete. The check is not scored and can be repeated.