Presentational children

Some roles are leaves whatever you put inside them. ARIA lists the ones whose children are presentational: button, checkbox, radio, switch, tab, option, menuitem, progressbar, slider, meter, img, math, separator and their kin. Everything nested inside such an element loses its own role in the accessibility tree, and its text is swept up into the accessible name of the ancestor instead. A button holding an icon, a bold count and a two item list is one node with one name, not six nodes a reader can walk through.

This is a feature, and it is the reason a composed control works at all. The button you shipped is a box with a picture and two lines of copy in it; the announcement is “Archive 3 messages Frees 40 MB, button”, in document order, with no interruption. Without the rule a reader would step into the button, meet a graphic, a chunk of text and a list, and have to reassemble the control from its parts.

Where it bites is when you nest semantics you expected to survive. A <h3> inside a button is not a heading to anyone using headings to navigate. A list inside an option is not a list. A nested <button> inside a tab is not reachable as a control at all, since the flattening removes the inner widget’s role, and the browser’s own nested interactive warnings exist because of exactly this. The markup validates, the visual design works, and the structure you believe you authored is silently discarded.

So treat the rule as a hint about where the boundary of a control belongs. If the content inside really is structure a reader should be able to navigate, the container is not a button, and the first rule of ARIA points at the same answer from the other direction: build the thing whose semantics you actually want. If the content is decoration and copy, flattening is already doing the right thing, and your only job is to check that the swept up string reads as a sentence rather than as a pile of fragments.