Accessibility
Elements must only use allowed ARIA attributes
The behavior and purpose of controls on your web page are important to screen readers and other assistive technologies. HTML controls like buttons and radio groups come with this information already embedded. If you create custom controls, however, you must provide the information with ARIA roles and attributes.
As part of ARIA, elements are defined in terms of semantics. These semantics can be classified as roles (defining the type of element) and states and properties supported by the role. Unless the element already has appropriate ARIA semantics (via the use of an appropriate HTML element), authors must assign an ARIA role and state and property during its life cycle. When ARIA semantics are implemented, only the accessibility API of a browser receives additional information; the DOM of a page remains unchanged.
Why it is important
The accessibility of a web page can be compromised when ARIA attributes are used in roles where they are not allowed. The use of an invalid role-attribute combination will, at best, have no effect on the application's accessibility, but at worst, it can disable accessibility for entire sections of the application.
The use of ARIA attributes on HTML elements that do not conform to WAI-ARIA 1.1 conflicts with the semantics of the elements, causing assistive technology products to report nonsensical user interface (UI) information that does not represent the document's actual UI.
Fixing the problem
In ARIA, attributes are explicitly defined for every role and for every attribute, as well as where each attribute can be used for each role. The documentation for each role and/or attribute will give you more detailed information about each attribute.
Refer to ARIA in HTML - Document conformance requirements for use of ARIA attributes in HTML for additional information about which ARIA attributes may or may not be used by HTML elements.