A Beginner’s Guide to Accessibility in SAP Fiori/UI5

[GuruprasadGL]

Introduction

When I first started working on UI(user interface) development, accessibility sounded like one of those mysterious requirements that walked the thin line between “nice to have” and “an absolute waste of time and effort”.

Screen readers? ARIA(Accessible Rich Internet Applications) labels? Keyboard navigation and high contrast themes?

I had no idea what any of this meant – and honestly, I didn’t think I needed to. Who even used these things?

But the deeper I got into SAP Fiori/ UI5, the faster I realized something very important: Accessibility isn’t about extra work. It’s about building applications people can use, especially when you want your product to be used by a very wide audience.

SAP invests heavily in making its design systems accessible out of the box. The moment we start doing custom freestyle UI5 development, we, as developers, are responsible for keeping this quality intact.

This blog is meant to be a beginner friendly guide for anyone and everyone who wants to understand:

• What accessibility really is
• Why it matters
• Common pitfalls in UI5 apps
• How to start building accessible features without feeling overwhelmed

Whether you are new developer, or a veteran interested in getting into the world of accessibility, this guide is for you!

What is accessibility and why should you care?

Let’s clarify some of the basic misconceptions.

Accessibility != Only screen readers

Most beginners think accessibility means that it is a support system for blind users.

Agreed, screen readers are a major part, but accessibility also includes:

• Low vision users
• Colour blind users
• Users with motor disabilities
• Users with dyslexia or cognitive challenges
• Users who rely only on keyboard navigation
• Users working in bright, sunlit environments
• Use
• rs on small screens or touch devices

Basically, accessibility isn’t just about disabilities, it’s about real-world usage.

Business and legal requirements

Depending on your region, accessibility compliance may be required by law (WCAG, EN 301 549, ADA, etc.).

SAP itself follows these standards as part of its UX(user experience) strategy. But even if your project isn’t legally mandated:

Accessible apps reach more users, reduce support tickets, and improve perceived quality.

SAP’s philosophy: Accessible by default

UI5 controls come with built-in:

• ARIA attributes
• Keyboard navigation
• Focus handling
• Theming and contrast handling

BUT, the moment we override them with:

• Custom CSS
• Custom HTML
• Custom JS(Java Script) focus logic
• Non-standard layouts

…we break accessibility without even noticing it.

Most Common Accessibility Issues (and How to Fix Them)

Even if you use SAP UI5 controls correctly, there are a few pitfalls that most beginners hit. I definitely learnt things the hard way. Let’s run through them one by one and see why it happens, why it matters and how do you fix it in UI5.

Colour, Contrast and Theming

Why contrast matters

Low vision users (and those on bright screens) depend heavily on contrast. If your text blends into your background, even slightly, a huge portion of users can’t read it.

SAP follows WCAG(Web Content Accessibility Guidelines) contrast standards by default. However, accessibility issues often arise when custom CSS is introduced.

Custom CSS overrides the themes default colours. This means that the moment a user switches from, let’s say, SAP Morning Horizon to SAP Evening Horizon, or some High Contrast theme, your nice looking custom blue, grey, or white will instantly break contrast rules.

The Fix -> Use SAP Named Colours

SAP UI5 provides semantic colour variables that automatically adapt to themes. Let’s look at the correct way to incorporate this.

Wrong Way:

.cusCountSizeNewFeature {
    color: #2424fc !important;  /* this is a nice looking blue in light mode */
}

Correct way:

.cusCountSizeNewFeature {
    color: var(--sapInformativeColor) !important; /* adapts across themes */
}

Why this is powerful?

• Theme switching becomes seamless
• WCAG contrast ratios are preserved
• You stay aligned with the Fiori design ecosystem

Responsiveness

This is not just a design or a layout problem. It can affect anybody and everybody because many users:

• Zoom their screens
• Use large fonts
• Work on mobile
• Use split screen mode
• Use tablet input or touch screens

If your UI doesn’t adapt, your users could lose access to content.

Common Responsiveness Issues

1. Text Truncation
   Short labels become unreadable. For example, “Transaction” could become “Transa…” or “Customer Name” could be “Custo…”
   If the Truncated text contains meaning, it becomes inaccessible.
   Fix:
   Avoid truncation as much as possible.
   Use a tooltip on truncated text
   Prefer responsive UI5 controls over fixed widths
2. Overflow Text
   Long values break layouts or overlap with other elements. The fix is simple. Wherever possible, use the wrapping property. For example:

<Text text="{path: 'desc'}" wrapping="true"/>​

• Unresponsive Font Sizes
  Some developers like to set pixel-based font sizes. This breaks zooming and accessibility. The fix for this is to use rem or theme variables.
• Touch responsiveness
  If buttons or icons are too small, they become impossible to tap. SAP recommends a 44px minimum tap target. Avoid placing tiny icons close to each other without padding. UI5 automatically handles this of you use Fiori controls instead of custom HTML.

Alternate texts, Tooltips and Descriptive Labels

Images, buttons and icons must describe what they are or do, especially for screen reader users.

• Alt texts for images

<Image src="cat/logo.png" alt="A cute cat"/>​

If the image is only decorative

<Image src="kitty/divider.png" decorative="true"/>​

If this property is set to true, the alt text is ignored.

• Accessible names for Buttons
  If we declare a button as given below

<Button icon="sap-icon://delete"/>​

This will fail accessibility, since the screen reader reads it as “Button”. To ensure correctness, we define the text and tooltips.

<Button icon="sap-icon://delete" text="Delete" tooltip="Delete item"/>​

• Tooltips for truncated text
  In case we have long texts, or we are truncating text intentionally, add tooltips.

<Text text="{Name}" maxLines="1" tooltip="{Name}" />​

• Use ARIA helpers
  For custom layouts

<Input ariaLabelledBy="labelId"/>​

Navigation, Scrolling and Table Design

Keyboard navigation for any UI is a must. A fully accessible app must be usable with:

• Tab
• Shift + tab
• Enter
• Space
• Arrow Keys

Users with motor disabilities rely heavily on this. If you build custom elements without roles or focus handling, this will break.

Keyboard traps

Sometimes, users can get stuck in a nested scrolling trap.

Page -> Panel -> ScrollContainer -> Table

Here, the user tabs into a ScrollContainer and gets stuck. This is why we should avoid unnecessary scroll containers.

Horizontal Scrolling

Horizontal Scrolling is an accessibility nightmare. It forces users to:

• Drag horizontally
• Loses track of headers
• Miss important fields
• Struggle with screen readers

This is a problem most seen in tables with large column counts. To solve this issue, one of many steps can be taken. You can use:

• sap.m.Table – responsive
• sap.m.Column – provides pop ins which are responsive. You can control what columns to be shown on smaller screen sizes.
• Setting the growing property to true – this ensures the user isn’t overwhelmed with too much information

Table design – Best practices

• Always provide meaningful column headers
• Avoid short forms in headers
• Avoid multilevel frozen columns
• DO NOT force horizontal scroll unless absolutely necessary
• Prefer using Lists or Grid Lists for card like layouts
• Use meaningful “no data” text.

Tools to Test Accessibility

Like how cleanliness starts at home, testing should start on your local system. Doing this a few times automatically makes you mindful of the potential problems you can face before you even begin your development.

Keyboard Navigation

Before you use any fancy tool for testing, do this: Put your mouse away and try to navigate your app using only the keyboard.

While you do this, here are some questions you should ask:

• Can I reach every interactive element?
• Does the focus shift logically?
• Can I open and close dialogs without touching the mouse?
• Do I get stuck in any keyboard traps?
• Is focus visible at all times?

You can try this exercise with various screen resolutions and zoom levels

SAP Fiori Keyboard shortcuts

SAP Fiori has its own keyboard shortcuts for tables, lists and other controls. Make sure your app doesn’t break them. A list of all available shortcuts can be found here: Link.

Contrast Checkers

Even if you use SAP Names colours, it is better to test for contrast manually, especially if you introduce any custom styles. I personally use the Colour Contrast Analyser tool.

Things to check

• Text vs background
• Icons vs background
• Focus borders
• Disabled states
• Theming (light/dark/high contrast)

If these are readable across various themes, you are good to go!

Screen Readers

You don’t need to be a screen reader expert. Just know how to turn one on and check the basic flow.

As a windows user, my go to screen reader is JAWS. It is known for its high accuracy and is very common in corporate accessibility audits. If your app works with JAWS, it means that you are on the right track.

If you are Mac user, you can use VoiceOver. This is a built-in screen reader for macs and is good for quick tests.

What to test?

• Are form labels read correctly?
• Are buttons announced with purpose (“Delete item”, not “Button”)?
• Are images read with correct alt text?
• Does the screen reader announce when a dialog opens?
• Can you navigate tables row by row?

If any of these are failing, or if the announcements are confusing or not in order, then your UI needs improvement.

Browser Accessibility Inspection Tools

Since most Fiori applications recommend Chrome to be used as the preferred browser, let’s look at what it has.

Chrome DevTools

The accessibility tab in chrome is super useful for developers. In this tab, you can inspect:

• Accessible name
• Role
• ARIA attributes
• States
• Contrast issues
• Keyboard behaviour
• Responsiveness is different screen sizes

Lighthouse Accessibility Audit

Lighthouse accessibility is an automated tool by Google that checks a web page against a set of rules to provide an accessibility score and a report on potential issues. You can add the extension to your browser. Once it is added, click on the Lighthouse icon and select “Generate Report”. Some of the things it checks are:

• Contrast issues
• Tap target sizes
• Missing labels
• ARIA role issues
• HTML semantics
• Broken keyboard tap order

Lighthouse is a great starting point, but definitely not a substitute for manual testing. An accessibility score of 90+ is a good score.

From whatever we have seen till now, accessibility might sound complicated, but once you start practicing it, you realize it’s mostly just… common sense.

Use proper UI5 controls.

Don’t fight the theme with custom CSS to make your app jazzy.

Make sure colours actually contrast.

Label things like how you would label the boxes on your kitchen shelf. This helps anyone who is looking (even screen readers) know what things are.

And for the love of UX, check if your app works without a mouse.

That’s it.

If your UI works in light mode, dark more, with a keyboard, and with a screen reader announcing things correctly, you’re already miles ahead.

So as the “Hitchhiker’s Guide To The Galaxy” would say – DON’T PANIC.

Go have fun and build cool stuff.

Make it usable.

Make it friendly.

Happy testing, and finally, welcome to the accessibility club 🙂