Your semantics tree is your test API and your accessibility API at once
A testTag is invisible to a screen reader. A contentDescription is not.
accessibility
6 posts
Focus is the input model you don't test until someone plugs in a keyboard
Compose's focus system handles keyboard, D-pad and accessibility navigation. The APIs are small, but modifier order matters, and a form with no focus handling is unusable on any device without a touchscreen.
Automated checks find the missing labels. They can't tell you the label is wrong.
Compose's accessibility checks catch touch targets, contrast and missing labels automatically. The failures they cannot detect — wrong labels, bad order, gesture-only actions — need a person, and knowing the split makes both cheaper.
Reading order is layout order, until your layout stops matching your meaning
Screen readers traverse in layout order, which breaks when a floating action button, a sticky header or a two-column layout puts visual priority somewhere else. Traversal groups and indices reorder without moving anything.
One card, four announcements — merging is the fix
A composite component produces one semantics node per child by default, so a card becomes four swipes. mergeDescendants, clearAndSetSemantics and invisibleToUser control the shape of the tree.
Compose builds a second tree, and it's the one your users hear
Every Compose UI produces a semantics tree alongside the layout tree. It's what screen readers read, what tests query, and what autofill inspects — so getting it right serves three audiences at once.