These two are confused more often than any other pair in ARIA, and the confusion produces controls that announce the wrong thing or announce it twice. aria-labelledby gives the control its NAME by pointing at other elements' text; aria-describedby adds a DESCRIPTION that is announced after the name. Getting them the wrong way round means a field called enter at least eight characters and described as password, which is exactly backwards.
aria-labelledby names, and it overrides
It takes the text content of the elements whose ids it lists and makes that the accessible name, overriding a label element and any text inside the control. That override is why it is dangerous: a button with visible text and an aria-labelledby pointing at a heading will be announced as the heading, and speech-control users then cannot activate it by saying what they see.
aria-describedby describes, and it is announced last
Use it for hint text, format requirements and error messages: the password rules under a field, the note that a date must be in the future. The description is announced after the name and the role, which is the right order for something supplementary. Multiple ids are allowed and are read in the order listed.
When to use neither
When a label element will do. A visible label associated with its input needs no ARIA at all, is announced correctly everywhere, and gives sighted users a larger click target as a side effect. On the worked example six forms carry two issues each, and in practice both are usually a missing label rather than a missing ARIA attribute.
Questions people ask about aria-describedby
Can a control have both?
Yes, and that is the normal case: a label for the name, describedby for the hint or the error.
Does describedby work for error messages?
It is the usual way to associate one, and the error text should be in the DOM and visible rather than only announced.
Why is our field announced twice?
Almost always a label element plus an aria-label or labelledby that duplicates it. Remove the ARIA.