This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Headings (h1-h6) are often used in a command-like way, but they have a strong semantic of "heading" in the HTML5 spec. Consider also allowing the following roles: button, checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, slider, spinbutton, scrollbar, tab, treeitem
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: Did Not Understand Request Change Description: no spec change Rationale: Could you give an example of <h1> being validly used in ways that these roles would be suitable for?
While I understand that HTML 5 take headings and uses them to create a table of contents, in practice authors actually takes headings and repurpose them to create widgets. Also, since headings are not tied to containers an author is not forced to to use headings in a reliable structure the accurately portrays heading levels. For example: <H4>HTML 5 Specification </H4> <H1>The HTML 5 Elements </H1> There is nothing to prevent this. And there is nothing to prevent an author from using script to override the head interaction. It supports tabindex and it supports events and script. Alternatively, if an author overrides the host language semantics and apply an aria role to the element such that it accurately portrays the authors intent such that it the element is no longer a header then that element should be removed from the table of contents generated by the use agent. So, the heading tags must be be able to be overriden unless HTML further restricts their interactivity.
Reopening since Rich added info as requested.
Could you give an example of <h1> being validly used in ways that these roles would be suitable for? The only example above is: <H4>HTML 5 Specification </H4> <H1>The HTML 5 Elements </H1> That's not a button, a checkbox, a radio button, a link, a menuitem, a listbox option, a range control, a spinbutton control, a scrollbar, a tab, or a part of a tree. It's a couple of headings, for which the appropriate role is "heading", just like the spec says. As far as I can tell, it would be non-conforming to use <h1> and company to make, say, a spinbutton, just as it is non-conforming to use role="" to say that that is what you're doing. That's the whole point of having strong native semantics. 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: See above. If there are actual examples that show how these roles could be used legitimately with these elements, please provide those examples and reopen the bug.
(In reply to comment #4) > Could you give an example of <h1> being validly used in ways that these roles > would be suitable for? yes, <summary> HTML5 has role="heading" as strong native semantics for <summary>. And yet, <summary> is an intereactive element. (PS: We probaly need a bug to track whether role="heading" is correct for <summary> The aria-html5-proposal suggest no default role. ) However, unless HTML5's strong semantics <summary role="heading"> was an error on your part, then it seems to me that you are fully able to imagine that element can serve a double purpose - as button and as heading.
(In reply to comment #5) > (In reply to comment #4) > > Could you give an example of <h1> being validly used in ways that these roles > > would be suitable for? > > yes, <summary> > > HTML5 has role="heading" as strong native semantics for <summary>. > And yet, <summary> is an intereactive element. > > (PS: We probaly need a bug to track whether role="heading" is correct for > <summary> The aria-html5-proposal suggest no default role. ) > > However, unless HTML5's strong semantics <summary role="heading"> was an error > on your part, then it seems to me that you are fully able to imagine that > element can serve a double purpose - as button and as heading. This bug is specifically about h1-h6, not about summary. Please use one or more separate bugs to report issues with <summary>.
(In reply to comment #6) > (In reply to comment #5) > This bug is specifically about h1-h6, not about summary. Please use one or more > separate bugs to report issues with <summary>. I hope e.g. Steve finds the right angle to do that. My point was to point out that Ian, in another context, considers that an element can be interactive and yet a header.Hopefully, my input could make Ian explain wy these roles _cannot_ be used legitimately with these elements. The obvous use case is when the author wants to present a document. with several headings, as a outline. I am sure ian understand the usecase, and wonder how he would solve it. Just testing VoiceOver now: it doesn't announce the heading level whenever if the h1 element has role="button". That to me seems like a drawback of declaring a h1 to have role="buttton". Perhaps using the an inner element with role="button" is a better solution? <h1><span role="button">foo</span></h1>
Since this was reopened with new information, removing TrackerRequest for now. We can re-add it after the editor's next pass on this.
While I appreciate that an HTML header has strong native semantics, the specification allows a header to: - be placed in the tab navigation order - be styled - Have children - apply script It can do all this without requiring any implicit state information like an interactive form element. If a header has such strong native semantics then why would all this additional functionality be required? In fact, an author could in fact use script in response to user to write anything it wants dynamically between the header tags. In other words it could write to it as if it were a live region or even to produce an interactive widget. Another gaping hole in the HTML spec. left over from HTML 4 is the fact that the heading level is not enforced by document structure. An author could stick an H2 anywhere in the document and follow it by an H1. This has allowed authors to use headers for styling content wherever they please. What should have been done is eliminate the HX tags altogether and created a single header tag whose level is determined by the browser DOM containment model. That would have much stronger native semantics and force the author to design their documents better. Unfortunately, the cat is out of the bag and we are stuck with it. This has plagued people with disabilities for the longest time as header navigation only works when people use it as a best practice. Since it does not have any implicit state information an author could easily override the element and apply ARIA semantics without causing a conflict in state information provided to the assistive technology. I would argue that although a header is intended semantics if used properly, yet the specification has opened the doors for an author to use it improperly. These additional interactive tools (script, CSS, etc.) allow the author to manipulate headers in a fashion that dilutes the host language semantics of a header and allows the author to turn it into something entirely different. It is for these reasons that we need to apply ARIA role semantics to headers. In the editor's example - a couple basic headers there is no reason to apply ARIA role semantics to that situation and frankly there would be nothing that would compel the author to do so. It would require additional work that is unnecessary. In this scenario: <h1><span role="button">foo</span></h1> The author is not applying a role of button to a header. It is being applied to as span within a header. However, this example: <h1 onclick='alert("<h1> onclick!")'>Click to test.</h1> shown on this web site: http://dev.opera.com/forums/topic/165324 should have had a role of button. A screen reader looking at this would immediately know the <h1> was interactive if the role was button. In no way did this act as a heading as was intended by the spec. nor was it a link.
"The editor" asked for a simple thing: an example of a page that used <h1> in a valid way where role=heading was inappropriate. Nobody has provided such an example. Therefore, "the editor" continues to question whether it is sensible to allow other roles. 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: same as before
The editor was given a response that and a link to a page where a header was turned into an element that launches an alert. <h1 onclick='alert("<h1> onclick!")'>Click to test.</h1> It is shown as an example in this page. http://dev.opera.com/forums/topic/165324 Now if it is not possible to launch an alert from a heading in HTML please state why. If the editor is incapable of doing so then I would argue that for this implementation to be processed properly by an assistive technology that <h1 role="button" onclick='alert("<h1> onclick!")'>Click to test.</h1> should be allowed to happen. You were provided what you asked for. since you can add Javascript to a heading this is perfectly legal and entirely non-intuitive from an accessibility point of view.
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: Turning an <h1> into a button is an invalid (non-conforming) use of <h1>, quite apart from anything to do with ARIA. So that is not an example of what I was asking for, which is for a *conforming* example of something where an <h1> should have a role other than "heading".
escalating this bug
The implementation I posted fails wcag 2 but is perfectly allowable in HTML. Since it is allowable in HTML it is conforming. The heading tag is not used as a heading. It would pass any HTML validation test yet it does not convey the intent of the author and a screen reader user would have difficulty understanding that the header was used to launch an alert as this is not what heading should be used for. It would also incorrectly appear in the TOC per the HTML 5 spec. when it should not. It is not the act of placing proper role of the element in HTML that should make it non-conforming. This is the JavaScript accessibility problem that has plagued Web 2.0 developers. The editor is undoing what we have fixed with ARIA re-introducing the JavaScript accessibility problem which is: Authors are allowed to repurpose HTML elements without the specification allowing the author to accurately convey the semantics of their work - in essence producing non compliant WCAG 2 content. I agree with Steve. This now needs to be escalated.
added to HTML WG Issue http://www.w3.org/html/wg/tracker/issues/129
This is part of HTML-ISSUE-129. There is some debate taking place actively. Therefore bug triage sub-team thinks this is a HTML A11Y TF priority. Adding a11ytf keyword and assigning to Steve Faulkner for ARIA mapping sub-team.
wontfix accepted as part of http://www.w3.org/html/wg/tracker/issues/129