Theming and accessibility

SDK-rendered components take their look from theme tokens your app passes at initialisation, and campaigns can override colours. This page lists the tokens and their defaults, shows which token each component uses, and describes what the components do for accessibility and what your app and campaigns still need to do. It applies only to SDK-rendered components; host-rendered decisions use your own views and your own accessibility work.

Theme tokens

You pass a theme once, when you initialise the SDK. Every token is optional; anything you leave out uses the default.

Token	Default	Used for
Regular font	The system font	Body text
Bold font	A bold version of the regular font	Titles, labels and buttons
`primary`	`#054B3A`	Banner background, progress bar fill, offer badge text, message icon
`onPrimary`	`#FFFFFF`	Banner text
`accent`	`#6FCF97`	Banner eyebrow, progress bar fill once met, offer badge and border, message icon background
`surface`	`#FFFFFF`	Progress, offer and message backgrounds
`text`	`#1A1C1A`	Text on surface-based components, the progress card outline and bar track
`mutedText`	`#6B706C`	Footnotes and offer body text
Corner radius	14 (density-independent units)	Card corners, clamped to 0 to 32

The defaults are Grona’s own colours. Set at least primary, onPrimary, accent and your fonts so the components match your app.

How components use the theme

Component	Background	Text	Accent
Banner	`primary`	`onPrimary`	`accent` for the eyebrow; the button is an inverted pill in the text and background colours
Progress	`surface`	`text`, with `mutedText` for the footnote	Bar fill `primary` while below the threshold, `accent` once met
Offer	`surface` tinted with `accent`	`text`, with `mutedText` for the body	`accent` for the badge and border
Message	`surface` tinted lightly with `text`	`text`	`accent` behind the icon

Per-campaign colours

A banner, progress or offer campaign can set style with background, text and accent, each as #RRGGBB. Each colour the campaign sets replaces the matching theme token for that component only; anything it leaves out falls back to your theme. A malformed colour makes the campaign inactive. A message has no style and always uses your theme.

Use per-campaign colours sparingly, for example a seasonal banner. Most campaigns read better in your app’s own colours.

Dark mode

The theme holds fixed colours, set once at initialisation, so components do not switch with the system’s dark appearance on their own in this version. If your app supports a dark theme, choose token values that read on the screens where your placements sit, and keep per-campaign colours to ones that work in both appearances.

Accessibility

This section describes what the components do on Android and iOS in this version. Where the platforms differ, the item says so. The platform pages give the details: Android and iOS.

What the components do

Readable contrast. Before drawing, the SDK checks each text colour against its background. If titles, body text or button labels would fall below a contrast ratio of 4.5:1 (WCAG AA), it switches them to white or near-black, whichever reads better. Eyebrows and progress footnotes use a 3:1 threshold. This applies to your theme tokens and to per-campaign colours.
Font scaling. Text follows the shopper’s system font size: scalable units on Android, Dynamic Type on iOS.
Line limits. Each text field has a line limit (for example three lines for a banner title and four for body text) and ends with an ellipsis when it runs over. At very large font sizes, long copy is cut off.
Touch targets. The banner’s call-to-action button has a minimum touch target of 48 dp on Android, drawn as a 40 dp pill, and of 44 by 44 pt on iOS.
Tapjacking protection. On Android, buttons ignore taps that pass through another app’s overlay.
Decorative visuals are hidden from screen readers. Icons, the banner image and the progress bar graphic are not announced. Screen readers read the text and the button.
Reduced motion. The reveal and collapse animations and the progress bar fill are skipped when the shopper has turned system animations off on Android (8.0 and later) or turned on Reduce Motion on iOS.
Right-to-left layouts. Components use start and end alignment, and the progress bar fills from the start edge, so they mirror in right-to-left locales.

The SDK sets no custom accessibility labels (content descriptions on Android) on components, and draws no dismiss control on them.

What your campaigns and app should do

Put the meaning in the text. Because images, icons and the bar are not announced, the title, text and button label must carry the whole message. For a progress bar, say how much is left in text (for example “Add {gap} more for free delivery”), not only in the bar.
Keep copy short. Write titles that fit in two lines at default size, so they still fit at large font sizes.
Label buttons with the outcome. “Add all for {total}” reads better to a screen reader than “Tap here”.
Check contrast in both appearances. The automatic correction can replace a brand colour with white or near-black; pick tokens that already pass so the correction never needs to run.
Test with a screen reader and the largest font size on the screens that carry placements, using a preview link to pin each campaign.