Even though accessibility properties inspection tools demonstrate that the element's description is exposed, some screen readers do not read the value of the referenced element, regardless that the ARIA specification indicates that any element in the base markup can have aria-describedby.
The dfn element example does not work with some screen readers. The “Experimental Demonstrations” below are all problematic in one way or another. This problem might be addressed by overriding the reporting of the button or link role via aria-roledescription, but that technique is limited, since aria-roledescription does not have robust support yet. Minimally, it creates a situation in which the native semantics of the element do not align with the purpose of the element - the tooltip would report as a link or a button, while its purpose would be only to display a tooltip. However, using a link or a button solely as a trigger for a tooltip - where the link or button is not used for interaction but as something to attached a tooltip to - potentially fails conformance to WCAG 4.1.2 Name, Role, Value. In the case of an ARIA Tooltip Widget on an input, link, or button, the tooltip can be used to provide some extra descriptive context (see the examples under “Valid Demonstrations,” below). Because of this, the only practical use for the ARIA Authoring Practices recommended implementation of Tooltip is on an interactive element. The Tooltip design pattern has significant problems: Screen readers tend not to report aria-describedby associated element values unless two things are true: the trigger element is an interactive element and the trigger element gets keyboard focus. The ARIA Authoring Practices say a “tooltip is a popup that displays information related to an element.” It also indicates that the Tooltip Widget is “a work in progress.”
0 kommentar(er)
