Lesson 4 of 5
Devices, browsers and accessibility
9 min
Listen to this lesson
SAP Fiori runs in a browser, and SAPUI5 is designed to adapt to desktop, tablet and phone screens. That flexibility creates test scope. You cannot test every app on every browser and device, so you need a deliberate coverage plan that matches what Contoso's users will actually use.
What is supported
SAP publishes supported browsers and platforms for SAPUI5 and points to the Product Availability Matrix (PAM) as the authoritative source for each product. In general, current versions of Chrome and Edge, Firefox (current and extended support releases) and Safari on Apple platforms are supported, and Internet Explorer is not. Check the PAM and the SAPUI5 documentation for your release before you fix your matrix; support changes as browser vendors drop old versions.
Each app also declares the device types it supports: desktop, tablet, phone or a combination. The SAP Fiori apps reference library shows this. An app supported only on desktop is out of scope on phones, and a defect there is not a defect unless your organization extended it.
Building the coverage matrix
Start from the user population, not the browser list. Ask the business which devices and browsers each role uses. Contoso's office staff use managed Windows laptops with Edge. Chicago warehouse staff use rugged tablets with Chrome. Sales managers approve orders on iPhones. That gives a short list of combinations that matter.
| Role | Primary combination | Apps in full scope |
|---|---|---|
| Sales clerk | Windows laptop, Edge, desktop width | Manage Sales Orders, customer object pages |
| Warehouse clerk, Chicago | Android tablet, Chrome, touch | Goods receipt and goods movement apps |
| Sales manager | iPhone, Safari, phone width | Approval apps that support phones |
| AP clerk | Windows laptop, Edge, two monitors | Create Supplier Invoice, Manage Supplier Invoices |
Part of Contoso's browser and device coverage matrix.
What changes on smaller screens
- Tables collapse columns into pop-ins or hide them; check that key fields are still visible or reachable.
- Filter bars collapse; check that mandatory filters can still be set.
- Toolbars move actions into overflow menus; check that critical actions like Save and Post are reachable.
- Touch replaces hover and right-click; check that nothing depends on hover.
- Long texts truncate; check that product names such as CMC-ALT-100 descriptions remain readable.
| Element | Desktop | Tablet or phone | Check |
|---|---|---|---|
| Tables | All columns shown | Columns collapse into pop-ins or are hidden | Key fields still visible or reachable |
| Filter bar | Expanded | Collapsed | Mandatory filters can still be set |
| Toolbar actions | Buttons in view | Moved into an overflow menu | Save and Post reachable by touch |
| Input | Mouse, hover, right-click | Touch only | Nothing depends on hover |
| Long texts | Full width | Truncated | CMC-ALT-100 descriptions still readable |
Network conditions belong in the matrix too. A warehouse in Chicago may run on Wi-Fi with weak spots between racks, and a sales manager may approve orders on a mobile network. Apps that work instantly on the office network can time out or lose a draft on a slow connection. For critical apps used away from the desk, run at least one test in the real location or with a throttled connection, and check what the user sees when a request fails.
Themes and personal settings
Users can change the theme, language, date and number formats in their launchpad settings. Most of these are cosmetic, but date and decimal formats affect input: a tester in the US enters 1,500.00 while a colleague with a European format enters 1.500,00. Include at least one test per critical input app with each format your users have, and confirm that amounts and dates are stored correctly, not just displayed.
Accessibility basics
SAP builds accessibility features into SAPUI5 and SAP Fiori, including keyboard navigation, screen reader support and high-contrast themes. Your organization may have legal or policy obligations, often expressed against the Web Content Accessibility Guidelines (WCAG). Custom apps and extensions are where accessibility usually breaks. A basic accessibility pass for each critical app checks:
- The whole task can be completed with the keyboard alone, with a visible focus indicator.
- Fields have labels that a screen reader announces, and errors are announced, not just colored red.
- The app works in a high-contrast theme and at 200% browser zoom without losing content.
- Information is not conveyed by color alone, for example status shown with text or an icon as well.
- Keyboard onlyComplete the whole task without a mouse, with a visible focus indicator.
- Screen readerField labels and error messages are announced, not just colored red.
- High contrast and 200% zoomNo content is lost in the high-contrast theme or when zoomed.
- Not color aloneStatuses carry text or an icon as well as color.
What would you do?
Contoso's Chicago warehouse tablets will run a goods receipt app. The app works perfectly on testers' laptops. What is the most important additional test?
- Use the PAM and SAPUI5 documentation as the source for supported browsers; Internet Explorer is not supported.
- Check each app's supported device types in the apps reference library.
- Build the coverage matrix from real user populations and prioritize by usage and criticality.
- On small screens, check columns, filters, overflow actions and touch; run a basic keyboard, screen reader and contrast pass.
Check your understanding · not graded
Lesson check
1. Which is the authoritative source for supported browsers for an SAP product?
2. Where can a tester see which device types an app supports?
3. How should a browser and device coverage matrix be built?
4. Which is a basic accessibility check?