Applies to all technologies that support an accessibility API.
When standard controls from accessible technologies are used, they usually are programmed in a way that uses and supports the accessibility API. However, when custom controls are created, it is up to the control's author to ensure that the control is correctly exposed to users via the platform's accessibility API. If this is not done, then assistive technologies will not be able to understand what the control is or how to operate it or may not even know of its existence.
For technologies that support it, WAI-ARIA can be used to expose a custom control's role, name, value, states, and properties via the accessibility API for the technology.
Along with ensuring custom controls are properly exposed to users via the platform's accessibility API, there are many other considerations that need to be made so the control is accessible to as many people as possible. Keyboard functionality, target size, and color contrast requirements are only a few of the additional considerations that need to be accounted for, all of which go beyond what 4.1.2 Name, Role, Value, and this technique cover.
A music player is designed with custom controls that look like musical notes that are stretched for volume, tone etc. The programmer does not make the new control support the Accessibility API. As a result - the controls cannot be identified or controlled from AT.