This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Comments from James: 5.2. Conflicts between native markup semantics and WAI-ARIA http://www.w3.org/WAI/PF/aria-implementation/#notify_state_changes """ When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic. When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic, it can be particularly problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the host language feature are both provided but their values are not kept in sync, it is uncertain which one is correct. """ Does not account for conflict on attrs with similar but non-identical semantic conflicts such as <input type=checkbox checked aria-checked=mixed> -------------------------------------------------------------- 5.2. Conflicts between native markup semantics and WAI-ARIA http://www.w3.org/WAI/PF/aria-implementation/#notify_state_changes """ When a WAI-ARIA role is provided, use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. """ I worry this opens up an opportunity for the HTML5 group to forbid ARIA attrs on certain elements where it should not be forbidden. The UAIG should clarify that this is only for non-UI include elements such as script or style includes, and potentially <input type="hidden"> We should admit wording that will prevent a host language from forbidding ARIA attrs on elements that render UI.
Another related comment from James: 5.4. Role mapping http://www.w3.org/WAI/PF/aria-implementation/#mapping_role """ When a matching role is found, user agents MUST use it to override any implicit role inferred from the host language markup in performing this mapping, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. """ Again, I worry this opens up an opportunity for the HTML5 group to forbid ARIA attrs on certain elements where it should not be forbidden. The UAIG should clarify that this is only for non-UI include elements such as script or style includes, and potentially <input type="hidden"> We should admit wording that will prevent a host language from forbidding ARIA attrs on elements that render UI.
(In reply to comment #0) > Comments from James: > > 5.2. Conflicts between native markup semantics and WAI-ARIA > http://www.w3.org/WAI/PF/aria-implementation/#notify_state_changes > """ > When a host language declares a WAI-ARIA attribute to be in direct semantic > conflict with a native attribute for a given element, ignore the WAI-ARIA > attribute and instead use the host language attribute with the same implicit > semantic. When WAI-ARIA states and properties correspond to host language > features that have the same implicit WAI-ARIA semantic, it can be particularly > problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the host > language feature are both provided but their values are not kept in sync, it is > uncertain which one is correct. > """ > > Does not account for conflict on attrs with similar but non-identical semantic > conflicts such as <input type=checkbox checked aria-checked=mixed> I think we should add text to clarify this. Can James propose some text? > > -------------------------------------------------------------- > > 5.2. Conflicts between native markup semantics and WAI-ARIA > http://www.w3.org/WAI/PF/aria-implementation/#notify_state_changes > > """ > When a WAI-ARIA role is provided, use the semantic of the WAI-ARIA role for > processing, not the native semantic, unless the role requires WAI-ARIA states > and properties whose attributes are explicitly forbidden on the native element > by the host language. > """ > > I worry this opens up an opportunity for the HTML5 group to forbid ARIA attrs > on certain elements where it should not be forbidden. The UAIG should clarify > that this is only for non-UI include elements such as script or style includes, > and potentially <input type="hidden"> We should admit wording that will > prevent a host language from forbidding ARIA attrs on elements that render UI. I echo this concern.
Ditto for comment 1.
Andi to start e-mail thread with Michael and James. We do have an agreement with the HTML 5 WG that they can forbid certain WAI-ARIA attributes on HTML elements.
Resolved with James. No changes required.