Region or group — let the count decide

# Region or group — let the count decide Having decided a scrollable code block needs a role and a name, the obvious move was to match its siblings. `scroll-area/root` and `table/container` both use `role="region"`. So: `region`. That was wrong, and the way to find out was to count. ## What the pages actually contain ```txt /components/code 13 code blocks, 1 with a title, 2 with a language /index 4 code blocks, 0 with a title, 0 with a language ``` A `region` is a landmark. It appears in the landmark list that screen-reader users navigate by. Ten of the thirteen blocks on one page would have been landmarks named "Code" — the same name, ten times, in the list meant to help you skip around the page. That is not a smaller version of a good outcome. It is a worse outcome than having no landmark at all. ## The axis that actually matters The siblings are regions for a reason that does not generalise: a data table or a scroll panel is **one prominent thing**, deliberately placed, and its name is a required prop the consumer must supply. A code block **names itself** and a documentation page renders one per fence. Same runtime, same tab stop, opposite frequency — and frequency is the axis that picks `region` from `group`. `group` names the tab stop and stays out of the landmark list. "The other two are regions" is consistency of implementation, not consistency of situation. ## Two passes, one answer A second reviewer reached `group` independently, before seeing the count, on the required-prop-versus-self-naming argument. Two routes to the same call is a better signal than either one alone — and it is the kind of check worth setting up deliberately when a decision has no test that can fail.