This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The experimental HTML5 conformance checker throws an error when more than one space separated value is used within a role attribute. However, the Role Attribute Draft [1] defines "The role attribute takes as its value one or more whitespace separated TERMorCURIEorAbsURIs as defined in [RDFA-CORE]" The HTML5 spec fails to specify yet that one or more values is allowed, but it seems to be the base for conformance checker implementations. Therefore I suggest to include the sentence above, unless it doesn't need to be specified redundantly and it is a failure on the W3C validator to implement the Role Attribute specification properly. Use cases for multiple roles: 1. It would be appropriate for a horizontal main navigation to have role="navigation menubar" 2. On flickr, headings can be edited when they receive focus. It's a heading that should be included in the taborder via tabindex="0", but as soon as it received focus it becomes a text input field. Therefore <h1 role="heading textbox"> would make perfect sense as the element has the potential to be both: Schrödinger's Heading. [1] http://www.w3.org/TR/2010/WD-role-attribute-20100916/#s_role_module_attributes
(In reply to comment #0) > However, the Role Attribute Draft [1] defines That's irrelevant. HTML5 has a role attribute on its own without defining it by reference to the Role Attribute Draft. > The HTML5 spec fails to specify yet that one or more values is allowed, but it > seems to be the base for conformance checker implementations. Actually, the conformance checker implementation predates ARIA integration in the HTML5 spec and was based on discussing the prospects of ARIA extensibility with a browser implementor familiar with the matter.
> 1. It would be appropriate for a horizontal main navigation to have > role="navigation menubar" This is not compatible with the forward-compatible processing model for role. At least when I was previously briefed on ARIA extensibility plans, the plan was that the UA would always honor one role per element and would honor the first role it recognizes. Thus, using two roles from ARIA 1.0 is bogus. Once ARIA.next is around, it would make sense to use two tokens the first one of which is from ARIA.next and the second one is the best approximation from ARIA 1.0. Since ARIA.next isn't here yet, the validator supports only one token in the role attribute.
(In reply to comment #2) > Since ARIA.next isn't here yet, the validator supports only one token in the > role attribute. So for the time being the validator doesn't support it, that's OK for me. Now that this has been clarified, it's more relevant that the bug is filed for the HTML5 spec, not for the validator: The spec is so far underspecified regarding the format that a role attribute can take. The definition of a role in HTML5 should be consistent with other W3C specs, in particular with ARIA and the Role Attribute spec. Also HTML5 should be future proof, and when you confirm that ARIA.next plans to use multiple roles, allowing multiple space-separated role values is essential. Therefore I suggest to adopt the definition from Role Attribute.
(In reply to comment #1) > (In reply to comment #0) > > However, the Role Attribute Draft [1] defines > That's irrelevant. HTML5 has a role attribute on its own without defining it by > reference to the Role Attribute Draft. if this is correct where is the role attribute defined in the html5 spec? if found 69 instances of the word "role" in http://dev.w3.org/html5/spec/Overview.html 67 of them in the aria section of the spec, none of them in reference to a HTML5 role attribute.
Does the WAI-ARIA draft define the format for the role attribute?
(In reply to comment #5) > Does the WAI-ARIA draft define the format for the role attribute? The Role Attribute draft defines the format as above, see link in comment #0.
(In reply to comment #5) > Does the WAI-ARIA draft define the format for the role attribute? ARIA defines the characteristics of the attribute http://www.w3.org/TR/wai-aria/host_languages#host_general_role ...but says the host language "will provide" it. (In reply to comment #4) > if this is correct where is the role attribute defined in the html5 spec? http://www.whatwg.org/specs/web-apps/current-work/#global-attributes says: "To enable assistive technology products to expose a more fine-grained interface than is otherwise possible with HTML elements and attributes, a set of annotations for assistive technology products can be specified (the ARIA role and aria-* attributes)." I guess for avoidance of doubt, the HTML5 spec should be edited to make it unambiguous that the paragraph I quoted means to "provide" the attributes whose characteristics are defined in http://www.w3.org/TR/wai-aria/host_languages#host_general_role and http://www.w3.org/TR/wai-aria/host_languages#host_general_attrs (In reply to comment #6) > The Role Attribute draft defines the format as above, see link in comment #0. No, that's the old XHTML2 WG role attribute that allows URIs and CURIEs. That's not the ARIA-only role attribute that HTML5 is integrating with. ARIA was specifically modified to no longer normatively refer to the Role Attribute/Module draft, since the Role Attribute/Module draft doesn't represent consensus among ARIA implementors or reflect implementation reality. (AFAIK, implementations don't support CURIE resolution in role.) It's really unfortunate that work on http://www.w3.org/TR/2010/WD-role-attribute-20100916/ hasn't been terminated by publishing it as a tombstone Note, since the document now generates confusion about such as comment 0 suggesting that the document were normative over HTML5 conformance checkers.
(In reply to comment #7) > (In reply to comment #5) ... > (In reply to comment #6) > > The Role Attribute draft defines the format as above, see link in comment #0. > > No, that's the old XHTML2 WG role [...] WAI-ARIA says : "The attribute value MUST allow a token list as the value; > It's really unfortunate that work on > http://www.w3.org/TR/2010/WD-role-attribute-20100916/ hasn't been terminated WAI-ARIA's @role attribute builds on that draft: http://www.w3.org/TR/wai-aria/usage#usage_intro
(In reply to comment #7) > (In reply to comment #5) > > Does the WAI-ARIA draft define the format for the role attribute? > ARIA defines the characteristics of the attribute > http://www.w3.org/TR/wai-aria/host_languages#host_general_role > ...but says the host language "will provide" it. > (In reply to comment #4) > > if this is correct where is the role attribute defined in the html5 spec? > http://www.whatwg.org/specs/web-apps/current-work/#global-attributes says: "To > enable assistive technology products to expose a more fine-grained interface > than is otherwise possible with HTML elements and attributes, a set of > annotations for assistive technology products can be specified (the ARIA role > and aria-* attributes)." > I guess for avoidance of doubt, the HTML5 spec should be edited to make it > unambiguous that the paragraph I quoted means to "provide" the attributes whose > characteristics are defined in > http://www.w3.org/TR/wai-aria/host_languages#host_general_role > and > http://www.w3.org/TR/wai-aria/host_languages#host_general_attrs > (In reply to comment #6) > > The Role Attribute draft defines the format as above, see link in comment #0. > No, that's the old XHTML2 WG role attribute that allows URIs and CURIEs. That's > not the ARIA-only role attribute that HTML5 is integrating with. ARIA was > specifically modified to no longer normatively refer to the Role > Attribute/Module draft, since the Role Attribute/Module draft doesn't represent > consensus among ARIA implementors or reflect implementation reality. (AFAIK, > implementations don't support CURIE resolution in role.) > It's really unfortunate that work on > http://www.w3.org/TR/2010/WD-role-attribute-20100916/ hasn't been terminated by > publishing it as a tombstone Note, since the document now generates confusion > about such as comment 0 suggesting that the document were normative over HTML5 > conformance checkers. so the current editors draft of the ARIA spec states: "An implementing host language will provide an attribute with the following characteristics: The attribute name MUST be role; The attribute value MUST allow a token list as the value; The appearance of the name literal of any concrete WAI-ARIA role as one of these substrings MUST NOT in and of itself make the attribute value illegal in the host-language syntax; and The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element. User Agent processing for roles is defined in the WAI-ARIA User Agent Implementation Guide [ARIA-IMPLEMENTATION]." Which reads to me as if HTML5 MUST allow role="navigation menubar" as conforming.
(In reply to comment #9) > Which reads to me as if HTML5 MUST allow role="navigation menubar" as > conforming. That depends on what "in and of itself" means. If you read it broadly enough, it could be read as banning the whole concept of making violations of strong semantics non-conforming. I think a bug needs to be filed on ARIA to make ARIA itself clearer and to make it permissible for host languages to make the non-conforming to override the roles on some elements. Furthermore, it's non-sensical to make role="navigation menubar" conforming when the processing model is "The first name literal of a non-abstract WAI-ARIA role in the list of tokens in the role attribute defines the role according to which the user agent MUST process the element." This means that the token "navigation" MUST be used to process the element. In that case, it makes no sense to allow the token "menubar" that according to the processing model doesn't take an effect. If "menubar" doesn't take an effect, what can it be but an authoring error? What would make sense is that ARIA.next defines a role fancymenubar and then *once ARIA.next is available* role="fancymenubar menubar" becomes conforming for authors to use so that ARIA.next-compliant UAs expose fancymenubar and old UAs fall back to exposing menubar. Now, if ARIA wants to allow both a landmark role and a non-landmark role on one element to take effect simultaneously, ARIA needs to revise its processing model. As I understand Gecko's behavior, Gecko honors the first role it recognized but also exposes all role tokens via IAccessible2, so AT that uses IAccessible2 can (and do?) subvert the processing model specified in ARIA. :-( I guess this already makes non-landmark plus landmark "work" in violation of the ARIA processing model if the AT violates the ARIA processing model and picks up landmark from IAccessible2 while also honoring the non-landmark role. Personally, I think it be the clearest to honor the first role the the UA recognizes and not to allow landmarks and non-landmarks on one element, though I can see why one might want to honor both the first recognized landmark and the first recognized non-landmark.
(In reply to comment #10) > Furthermore, it's non-sensical to make role="navigation menubar" conforming > when the processing model is "The first name literal of a non-abstract WAI-ARIA > role in the list of tokens in the role attribute defines the role according to > which the user agent MUST > process the element." It MUST use that role. It must also ignore abstract roles. And the WAI ARIA implementation spec makes clear that AT _may_ also use additional roles to refine their presentation: http://www.w3.org/TR/2010/WD-wai-aria-implementation-20100916/#mapping_role ]] The entire role string MUST be exposed as a text string if the API supports it. This allows assistive technologies to do their own additional processing of roles. Microsoft Active Accessibility: not supported IAccessible2: expose as an object attribute pair (role=string) User Interface Automation: expose as AriaRole property. The AriaRole property can also support secondary roles using a space as a separator. Accessibility Toolkit: expose as an object attribute pair (role=string) Apple: expose as AXRoleDescription property (AXRoleDescription=string) See the Role Mapping Table below for details. [[
(In reply to comment #1) T>hat's irrelevant. HTML5 has a role attribute on its own without defining it by >reference to the Role Attribute Draft. i would not call this: "To enable assistive technology products to expose a more fine-grained interface than is otherwise possible with HTML elements and attributes, a set of annotations for assistive technology products can be specified (the ARIA role and aria-* attributes)." http://dev.w3.org/html5/spec/elements.html#global-attributes defining the role attribute, it gives NO information about how browsers are to implement it for a start.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This is out of scope for HTML, since HTML defers entirely to the ARIA spec for the definition of role="" and its conformance criteria for authors and user agents.
This is an override of the WAI-ARIA Implementation guide that is normative and is inconsistent with what we agreed on from the HTML working group: http://www.w3.org/WAI/PF/aria-implementation/#mapping_role Henri was involved in these discussions in fact. The implementation guide is quite clear on how the role attribute is mapped. In future version of WAI-ARIA we want to be able to expand on the fact that a role can take mulitiple values. While, like any specification, this would require us to work with user agent manufacturers. We do not want to be unnecessarily restricted by HTML on this point. The ARIA specification clearly states how the role attribute is processed and HTML must not restrict its implementation. So, in essence the validator must allow multiple roles to be passed and user agents must defer to the ARIA implementation guide to ensure proper processing of the role attribute. So, I would agree with Ian's comments that HTML 5 should defer to ARIA on this one and the validator be corrected. Should ARIA.next decide to change the processing of the role value passed it must clearly define how to process them. However, it should not be a validation error if multiple values are passed. Since the specification defers to ARIA on the use of role I see no issue with the HTML 5 specification here. The validator implementation is however incorrect. It must allow for multiple role values.
(In reply to comment #14) > Since the specification defers to ARIA on the use of role I see no issue with > the HTML 5 specification here. The validator implementation is however > incorrect. It must allow for multiple role values. Why would you want to make two ARIA 1.0 non-landmark roles in one ARIA attribute not a validation error? If the first one is always honored, surely the second is always an authoring error.
revisit in 5.1