Production-Quality VoiceOver and Dynamic Type for Rork Apps

Using accessibilityActions for Inline Buttons on Cards

You usually want the card itself to be one voice element, but you also want to keep small secondary actions like favorite and share inside the card. Nesting Pressable components naively just leads to VoiceOver announcing the parent and the children separately, which puts the swipe count right back where it started.

On iOS, accessibilityActions lets you bundle additional operations onto a single accessible element. With the VoiceOver rotor, the user can pick "Add to favorites" or "Share" without leaving the card, so the on-screen swipe count stays low.

const cardActions = [
  { name: 'favorite', label: isFav ? 'Remove from favorites' : 'Add to favorites' },
  { name: 'share', label: 'Share' },
];
 
<Pressable
  onPress={() => navigate('Detail', { id })}
  accessible={true}
  accessibilityRole="button"
  accessibilityLabel={`${title}, ${price.toLocaleString()} yen`}
  accessibilityActions={cardActions}
  onAccessibilityAction={(e) => {
    if (e.nativeEvent.actionName === 'favorite') toggleFavorite(id);
    if (e.nativeEvent.actionName === 'share') shareItem(id);
  }}
>
  {/* children remain accessible={false} */}
</Pressable>

Android's TalkBack only partially supports accessibilityActions, so on Android I leave a visible secondary button and label it clearly — accessibilityLabel="Add to favorites, button". When platform behavior diverges, my pragmatic answer in production is Platform.OS === 'ios' branching, accepting that I am maintaining two slightly different code paths.

A Realistic Approach to Dynamic Type

Dynamic Type can scale text up to 310 % when the user enables the Accessibility sizes under Settings → Accessibility → Display & Text Size. React Native's Text follows the OS font scale by default, but a layout that hard-codes fontSize everywhere falls apart almost immediately.

My production policy has three parts. First, font sizes live in a typography preset, never as inline magic numbers. Second, allowFontScaling stays at its default true. Third, maxFontSizeMultiplier is capped at 1.6, and on screens where the UI cannot survive that cap I switch to a different layout.

// src/theme/typography.ts
export const typography = {
  caption:  { fontSize: 12, lineHeight: 16, maxFontSizeMultiplier: 1.6 },
  body:     { fontSize: 15, lineHeight: 22, maxFontSizeMultiplier: 1.6 },
  title:    { fontSize: 20, lineHeight: 26, maxFontSizeMultiplier: 1.4 },
  display:  { fontSize: 28, lineHeight: 34, maxFontSizeMultiplier: 1.2 },
} as const;
 
<Text style={[styles.title, typography.title]}>{title}</Text>

I cap at 1.6 because iOS's "Accessibility max" pushes the scale to roughly 3.1 — beyond what most production layouts can absorb without three-line button labels or list cells that scroll off the screen. The trade-off is between respecting the user's setting and showing them a broken layout, and I lean toward not breaking it. VoiceOver itself is unaffected by maxFontSizeMultiplier, so users who rely on audio rather than visible text are not harmed by the cap.

When a screen genuinely needs to switch layouts at large scale factors, I read PixelRatio.getFontScale():

import { PixelRatio } from 'react-native';
 
const fontScale = PixelRatio.getFontScale();
const useExpandedLayout = fontScale >= 1.5;
 
return useExpandedLayout
  ? <VerticalCardLayout {...props} />
  : <HorizontalCardLayout {...props} />;

I landed on 1.5 after testing — that is roughly where horizontal cards stop fitting and need to flip to vertical. When working in Rork, sketching the vertical fallback up front makes the rework trivial later.

Respecting Reduce Motion and Reduce Transparency

Alongside VoiceOver, indie developers most often miss Reduce Motion and Reduce Transparency. The first matters for users with vestibular conditions or motion sensitivity, the second for users who need clearer contrast.

In React Native, AccessibilityInfo exposes both as boolean prefs:

import { AccessibilityInfo } from 'react-native';
import { useEffect, useState } from 'react';
 
export function useAccessibilityPrefs() {
  const [reduceMotion, setReduceMotion] = useState(false);
  const [reduceTransparency, setReduceTransparency] = useState(false);
 
  useEffect(() => {
    AccessibilityInfo.isReduceMotionEnabled().then(setReduceMotion);
    AccessibilityInfo.isReduceTransparencyEnabled().then(setReduceTransparency);
 
    const subM = AccessibilityInfo.addEventListener('reduceMotionChanged', setReduceMotion);
    const subT = AccessibilityInfo.addEventListener('reduceTransparencyChanged', setReduceTransparency);
    return () => { subM.remove(); subT.remove(); };
  }, []);
 
  return { reduceMotion, reduceTransparency };
}

I always plug this into ad-related animations. I used to play a flashy parallax intro before AdMob rewarded ads, but a handful of reviews mentioning "the ad screen makes me feel sick" pushed me to add a Reduce Motion branch that skips straight to the ad:

const { reduceMotion } = useAccessibilityPrefs();
 
function showRewardAd() {
  if (reduceMotion) {
    rewardedAd.show(); // no animation, immediate present
    return;
  }
  Animated.timing(parallaxY, { toValue: 1, duration: 350, useNativeDriver: true })
    .start(() => rewardedAd.show());
}

For Reduce Transparency, I swap translucent overlay cards for opaque solid cards. Ad labels and "Close" buttons placed on top of translucency tend to lose visibility fast, so designing solid as the production default is the safer baseline.

Focus Management for Modals and Screen Transitions

The most frustrating VoiceOver experience is not knowing where the focus lands after a screen change. React Navigation will read the new screen from the top by default, but modals and bottom-sheet UIs can strand focus in unexpected places.

When you need to declare "start reading here," AccessibilityInfo.setAccessibilityFocus does the job:

import { findNodeHandle } from 'react-native';
 
const titleRef = useRef<Text>(null);
 
useEffect(() => {
  const node = findNodeHandle(titleRef.current);
  if (node) AccessibilityInfo.setAccessibilityFocus(node);
}, []);
 
return (
  <View>
    <Text ref={titleRef} accessibilityRole="header">Settings</Text>
    {/* ... */}
  </View>
);

Returning focus to the original button after a modal closes is the part most developers forget. React Native's modal lives in a separate window-like layer, so when it dismisses, focus can jump somewhere unexpected. I hold a ref on the trigger element and restore focus in onDismiss:

const triggerRef = useRef<View>(null);
 
<Pressable
  ref={triggerRef}
  onPress={() => setModalVisible(true)}
  accessibilityLabel="Open filter settings"
>
  <Text>Filter</Text>
</Pressable>
 
<Modal
  visible={modalVisible}
  onDismiss={() => {
    const node = findNodeHandle(triggerRef.current);
    if (node) AccessibilityInfo.setAccessibilityFocus(node);
  }}
>
  {/* modal body */}
</Modal>

That single addition wipes out the "I am lost after closing a modal" experience. It is a small detail, but VoiceOver users notice these accumulated polishes immediately.

Preventing Regressions with Detox and accessibilityIdentifier

The hardest part of accessibility is keeping it healthy as you add features. You push a new card, you forget the accessibilityLabel, and nothing complains until a user does. E2E tests are the most reliable way to catch this mechanically.

For every major screen I run a minimal Detox suite that looks like this:

// e2e/home.e2e.js
describe('Home screen accessibility', () => {
  beforeEach(async () => {
    await device.launchApp({ newInstance: true });
  });
 
  it('all interactive elements have accessibility labels', async () => {
    await expect(element(by.id('home-tab'))).toBeVisible();
    // by.id matches accessibilityIdentifier on iOS, testID on RN
    await expect(element(by.id('card-list-0'))).toHaveLabel(/.+, \d+ yen/);
    await expect(element(by.id('settings-button'))).toHaveLabel('Open settings');
  });
 
  it('VoiceOver order is logical', async () => {
    const labels = await element(by.id('card-list')).getAttributes();
    expect(labels.children?.length).toBeGreaterThan(0);
  });
});

Making accessibilityIdentifier (or testID in RN) mandatory on every interactive element pays off here: a regression where a label silently goes empty is caught by toHaveLabel(/.+/). Running real-device Detox in CI is expensive for an indie budget, so I run iOS Simulator Detox in a weekly GitHub Actions cron and limit it mostly to toHaveLabel-style assertions across nearly every screen.

A Pre-Submission Checklist

Before I submit a Rork-built binary, I run through this self-checklist. Every item fits inside 30 minutes.

First, turn on VoiceOver and complete one full task with one hand from the home screen to the deepest feature. If a swipe-and-double-tap flow stalls anywhere, that point is missing an accessibilityLabel or an accessibilityActions entry.

Second, set the system font size to "Accessibility max" and open every tab. Note any clipped text, unreachable buttons, or overflowing elements. Capping at 1.6 prevents most of the worst cases.

Third, enable Reduce Motion and Reduce Transparency, then try the ad screens, paywall, and onboarding — the three places where excess motion or fuzzy overlays do the most damage to user trust.

Fourth, run the Detox toHaveLabel suite in CI so any element where the label has silently emptied is surfaced before release.

Fifth, read every accessibility warning in Google Play's Pre-launch Report and App Store Connect. If there is a red flag still standing, postpone submission by one day rather than absorb a 48-hour review delay.

I have been writing code since 1997, when an early online mentor told me that "art is a natural language that is open to everyone." That phrase still echoes through how I approach accessibility — I am, in a small way, trying to make the technology I build behave like such a language. When my children grow up, even if their sight or hearing has shifted, I want the apps I made to keep working comfortably for them. That is the state I aim for whenever I ship.

Thanks for reading.