Accessible Descriptions

Accessible descriptions can help users further understand a component, by linking one ore more elements that describes the component in more detail.

Principles

1. Should best only be used on on interactive elements, like input, link or button elements, since the support on these elements is most robust.
2. But a useful use-case for aria-describedby on a non-interactive element is for dialogs or modals that pop-up. If the visible explanation text is associated to the dialog element, it will be announced to the user, when the dialog opens. ¹
3. The aria-describedby attribute is especially useful in forms, since assistive technologies are in "forms mode" which will only announce form elements. In addition many users use tabbing to navigate the form. If the description is not associated with the input element, this information can be missed. ¹
4. The descriptions should be short and concise.
5. The descriptions are always presented as flat strings of text. So semantics of lists, images or links for example get lost. So make sure it will be announced as expected.
6. Descriptive text may not always get announced by screen readers, depending on the screen reader, browser combination and version. This is why it‘s important that relevant information is not only accessible via the aria-describedby attribute but by other means as well, like visually displaying the information.
7. The most reliable way of referencing descriptions is to not reference a container element containing multiple text entries, like list items, but to instead reference each element separately. This is because some screen readers will only announce the container element, but not any descendants.

Sources 

1. TPGi: Describing aria-describedby by Scott O‘Hara © TPGi – a Vispero™ Company
1. W3C ARIA: Form Instructions by W3C WAI Tutorial Contributors is licensed under W3C Document License