These four attributes carry most of the state a custom component has to announce, and each one fails in a characteristic way. aria-hidden hides things that should not be hidden, aria-expanded goes stale, aria-controls points at nothing, and aria-required duplicates something HTML already did. This page is what each is for and what its failure looks like in a screen reader, written for whoever is actually changing the markup.
aria-hidden, and the focusable element behind it
aria-hidden=true removes an element and everything inside it from the accessibility tree. The classic failure is putting it on a container that still contains a focusable control: a keyboard user tabs to a button that, as far as the screen reader is concerned, does not exist. If you hide something, hide it from everyone, with the inert attribute or by removing it from the tab order too.
aria-expanded and aria-controls, and going stale
aria-expanded belongs on the control that does the expanding, not on the panel, and it has to change when the panel does. A menu button whose aria-expanded is hardcoded to false is worse than no attribute, because it announces a state that is wrong. aria-controls points at the id of the element being controlled, and it should be checked in the DOM rather than assumed: pointing at an id that no longer exists is a silent failure.
aria-required, and when HTML already did it
If the input has the required attribute, it is already announced as required. aria-required exists for custom controls that are not native inputs, and for those it is necessary. On a native input it is redundant, and redundant ARIA is the second-largest source of noise in a screen reader after unnecessary landmarks.
Questions people ask about aria-hidden
How do we test these?
Toggle the component with a screen reader running and listen. Every one of these failures is audible in about five seconds and invisible in the markup.
Is more ARIA safer?
No. Incorrect ARIA is worse than none, because it overrides what the browser would otherwise have said correctly.
Do these count as WCAG failures?
Usually under name, role, value, and under status messages where a change is not announced. They come up in audits constantly.