11805 2011-01-19 13:35:35 +0000 Sync "Conflicts between native markup semantics and WAI-ARIA" with the spec 2011-03-31 14:11:29 +0000 1 1 1 Unclassified ARIA Core AAM 1.0 PC All RESOLVED WONTFIX P1 normal --- 1 andi.snowweaver andi.snowweaver dbolter aria-ua-impl oldest_to_newest 44471 0 andi.snowweaver 2011-01-19 13:35:35 +0000 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. 44472 1 andi.snowweaver 2011-01-19 13:49:54 +0000 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. 45774 2 dbolter 2011-02-17 15:29:18 +0000 (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. 45775 3 dbolter 2011-02-17 15:30:09 +0000 Ditto for comment 1. 45779 4 andi.snowweaver 2011-02-17 15:56:03 +0000 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. 47078 5 andi.snowweaver 2011-03-31 14:11:29 +0000 Resolved with James. No changes required.