Closed Bug 702594 Opened 13 years ago Closed 6 months ago

map HTML <hgroup> element to accessibility APIs

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: surkov, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

spec (http://dev.w3.org/html5/spec/sections.html#the-hgroup-element):

"The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

For the purposes of document summaries, outlines, and the like, the text of hgroup elements is defined to be the text of the highest ranked h1–h6 element descendant of the hgroup element, if there are any such elements, and the first such element if there are multiple elements with that rank. If there are no such elements, then the text of the hgroup element is the empty string."

We need to expose it to AT so they can take into account for document navigation (AT outlines).

Role: ROLE_SECTION (APIs don't provide more close role for that)
Group position: expose group position on nested hgroup elements
Relation: provide relation to keep it connected with first highest hN element (maybe describedby relation).
xml-role: I think closest one is group, maybe we should introduce hgroup for it (if we don't consider requesting new roles for that).

Thoughts?
I would not implement it for several reasons 
1. because it is at risk in the html5 specification [1].
2. as currently specced because it removes meaning for AT users (see my change proposal[2] for details.)


But I would suggest looking at implementing the outline algoritm sans hgroup. 


[1]http://dev.w3.org/html5/status/issue-status.html#ISSUE-164
[2]http://www.w3.org/html/wg/wiki/ChangeProposals/hgroup
I used to consider hgroup as section element that allows AT to navigate content faster but not as element used to hide details from AT. So say if you have several hgroups on the page then you can traverse them quickly and get an idea what the section is about. For example a book where each chapter is marked by hgroup element (maybe you could do the same by hx elements usage though).

I didn't look deeply at this issue so let's wait until you figure out whether we should take care about it. I'm ok to turn this bug into subline element support :)
Hi alex,
Their are a number of other elements that do similar to what you are describing section/article come to mind as well as h1-h6
http://dev.w3.org/html5/spec/sections.html#the-section-element
http://dev.w3.org/html5/spec/sections.html#the-article-element

The potential issue I see with having so many ways to navigate and structurally describe documents, is that AT may well not implement support and users may not these navigation aids useful even if implemented; are these all needed on top of ARIA landmarks, h1-h6 etc?
 
I think it is advisable to hold off until the dust settles. It is likely the hgroup element may be replaced or removed.

btw are you aware that JAWS implemented the HTML5 outline algorithm? But it is causing problems...
http://www.accessibleculture.org/articles/2011/10/jaws-ie-and-headings-in-html5/
(In reply to steve faulkner from comment #3)
> Hi alex,
> Their are a number of other elements that do similar to what you are
> describing section/article come to mind as well as h1-h6
> http://dev.w3.org/html5/spec/sections.html#the-section-element
> http://dev.w3.org/html5/spec/sections.html#the-article-element

> The potential issue I see with having so many ways to navigate and
> structurally describe documents, is that AT may well not implement support
> and users may not these navigation aids useful even if implemented; are
> these all needed on top of ARIA landmarks, h1-h6 etc?

Yes, I don't have perfect perception how it's supposed to be used. I think I started from the point when I filed this bug that anything from HTML5 should be prototyped.

> I think it is advisable to hold off until the dust settles. It is likely the
> hgroup element may be replaced or removed.

I'm absolutely fine with that.

> btw are you aware that JAWS implemented the HTML5 outline algorithm? But it
> is causing problems...
> http://www.accessibleculture.org/articles/2011/10/jaws-ie-and-headings-in-
> html5/

I see. That's not what I kept in mind. Changing level of headings depending on section elements hierarchy is not the way I think of hgroup element (and other section elements). But anyway let's wait. Please ping us when the dust settles.
hi alex, the dust has not settled, hgroup is marked as an at risk feature in HTML5 there are 2 competing HTML5 extension specs that cover the main use case for hgroup.
Steve, thank you for keeping updated.
Cool. Less work much happier :) Thank you for update!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
It's not dropped from the WHATWG HTML standard. Per the HTML spec its ARIA role should be "heading", with the aria-level property set to the element's outline depth.

(It's used in millions of pages already.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
The hgroup element has been made obsolete in HTML[1] as it has been discussed and considered by the HTML working group over an extended period of time and rejected due to its lack of meaningful implementations, lack of credible use cases, poor design and ill conceived accessibility mappings. 

It is now non-conforming to use, and its presence in a document results in an error when a document is checked using the W3C validator http://validator.w3.org/

"The hgroup element is obsolete. To mark up subheadings, consider either just putting the subheading into a p element after the h1-h6 element containing the main heading, or else putting the subheading directly within the h1-h6 element containing the main heading, but separated from the main heading by punctuation and/or within, for example, a span class="subheading" element with differentiated styling. To group headings and subheadings, alternative titles, or taglines, consider using the header or div elements." 

As a result authors have already begun to remove it from their markup.[2]

Its current use (and misuse) in web pages is not a reason to implement the ill conceived accessibility mappings described in the WHATWG spec.

[1] http://www.w3.org/html/wg/drafts/html/master/obsolete.html#non-conforming-features

[2] http://drupal.org/node/1959004, http://drupal.org/node/1959022, http://core.trac.wordpress.org/ticket/24114
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WONTFIX
It would be unwise for Firefox to map an element to accessibility APIs that does not validate with the W3C validators any mre. That's why I closed the bug again.
The <hgroup> element is widely used -- literally hundreds of millions of pages have the element, including e.g.:

   http://freesvgfiles.com/category/animals/
   http://dejavutheblog.com/2012/03/29/wild-girl/
   http://asetdelhi.com/content/decibel/board-members
   http://es.glee.wikia.com/wiki/Usuario:Zeebts
   http://ameblo.jp/angelstar-nefertari/entry-11407344144.html

(That's just a random sample.)

It has a clear accessibility win -- it makes headings more understandable when users are navigating the accessibility tree -- and it has a clear authoring win -- it makes it easier to mark subheadings semantically and makes styling them easier.

Why would it be unwise for Firefox to map an element to accessibility APIs that does not validate with the W3C validators? We support all kinds of features that the W3C validators know nothing about.
(In reply to Hixie (not reading bugmail) from comment #12)

> The <hgroup> element is widely used -- literally hundreds of millions of pages have the element, 

in Comment 9 

"It's used in millions of pages already." 

From publically available data sets and analysis what we do know is that in pages that do not identify themselves using the HTML5 doctype there is close to zero usage of hgroup. Of pages that do use HTML5 doctype, hgroup is found in approx 0.9% of pages.

> including e.g.:
>    http://freesvgfiles.com/category/animals/
>    http://dejavutheblog.com/2012/03/29/wild-girl/
>    http://asetdelhi.com/content/decibel/board-members
>    http://es.glee.wikia.com/wiki/Usuario:Zeebts
>    http://ameblo.jp/angelstar-nefertari/entry-11407344144.html
> 
> (That's just a random sample.)

a random sample of what?

here is a sample of hgroup usage: http://html5accessibility.com/HTML5data/hgroup.html

further info, the data set used and how the sample was derived are available: http://blog.paciellogroup.com/2012/04/html5-accessibility-chops-data-for-the-masses/


> It has a clear accessibility win -- it makes headings more understandable
> when users are navigating the accessibility tree -- 
 
From reviewing and discussing the accessibility mappings of hgroup, the defined usage and markup patterns hgroup promotes we decided there was no 'accessibility win'


> and it has a clear authoring win -- it makes it easier to mark subheadings semantically and
> makes styling them easier.

From seeking feedback, reviewing what authors had to say about hgroup, talking with authors, looking at how it has been used, what is clear that there is no  'clear authoring win'.

What is clear is that we lack consensus on the best method to provide a semantic indicator for subheadings, subtitles, alternative titles and taglines or indeed if one is needed at all.

Here are some of the alternative proposals:
http://www.w3.org/html/wg/wiki/ChangeProposals/hgroup
http://lists.w3.org/Archives/Public/public-html/2011Nov/0042.html
http://www.w3.org/html/wg/wiki/ChangeProposals/hSub2
http://www.w3.org/html/wg/wiki/ChangeProposals/dropHgroup

But we do have consensus that continued promotion of hgroup and its accessibility mappings as 'the' method is a win for no one.

Which is why we made hgroup obsolete in HTML and removed the previously defined accessibility mappings.
> a random sample of what?

Sample of pages that use <hgroup>.


> Which is why we made hgroup obsolete in HTML and removed the previously
> defined accessibility mappings.

As I mentioned above, the HTML standard still has <hgroup>.

Since pages use <hgroup>, and it's still in the standard, it seems to be poor for users that we don't support it in Firefox. There doesn't seem to be any substantial cost to supporting it since we already support it elsewhere (e.g. the parser). Not supporting it in the accessibility layer just means that pages that work for the majority of users will be less accessible than they could be.
(In reply to Hixie (not reading bugmail) from comment #14)
> > a random sample of what?
> 
> Sample of pages that use <hgroup>.
> 
> 
> > Which is why we made hgroup obsolete in HTML and removed the previously
> > defined accessibility mappings.
> 
> As I mentioned above, the HTML standard still has <hgroup>.
> 
> Since pages use <hgroup>, and it's still in the standard, it seems to be
> poor for users that we don't support it in Firefox. There doesn't seem to be
> any substantial cost to supporting it since we already support it elsewhere
> (e.g. the parser). Not supporting it in the accessibility layer just means
> that pages that work for the majority of users will be less accessible than
> they could be.

hgroup is exposed to the accessibility layer by firefox already it has a generic role via IA2 and is specifically identified tag=hgroup via an ia2 object attribute. If any user agents such as screen readers want to use this information to implement the whatwg requirements they can.

We strongly suggest that it would be poor for users to implement the whatwg requirements, and that the current implementation in Firefox allows user agents to decide about how best to represent the semantics to users.
FYI

user agent requirements for hgroup have been specified in the HTML spec 
in the section detailing user agent requirements for obsolete features [1]

It states:

"The hgroup element does not have Strong native semantics or default implicit ARIA semantics. User agents must not implement accessibility layer semantics for the hgroup element that obfuscates or modifies the semantics of its children."

The accessibility mappings for hgroup as currently implemented in Firefox conform to the HTML specification requirements.

If you have any feedback on the requirements as specified please file a bug against the HTML spec.

[1] http://www.w3.org/html/wg/drafts/html/master/obsolete.html#other-elements,-attributes-and-apis
Why would it be worse to implement the WHATWG requirements than not? What's the harm?
(In reply to Hixie (not reading bugmail) from comment #17)
> Why would it be worse to implement the WHATWG requirements than not? What's
> the harm?

what harm is being caused by not? What benefit to users does the whatwg requirements bring that is not already available? what are the use cases for the whatwg requirement? where is the data that supports the benefit of the whatwg requirement to users? Have AT implementers indicated an interest in implementing it?
> what harm is being caused by not?

Pages that use <hgroup> (I gave a random sample in comment 12, but there's millions more) are less accessible.


> What benefit to users does the whatwg requirements bring that is not already available?

It makes pages containing <hgroup> more accessible.


> what are the use cases for the whatwg requirement?

Subheadings are pretty common on the Web.


> where is the data that supports the benefit of the whatwg requirement to users?

Comment 12. Based on a scan through a subset of the Google index, there are hundreds of millions of pages that use <hgroup> today (I gave a random subset of those in comment 12).


> Have AT implementers indicated an interest in implementing it?

As I understand this bug, it's not about AT implementors, but about Firefox's default accessibility mappings.


But in any case, my question was aimed at Marco.

Marco, why would it be unwise for Firefox to map an element to accessibility APIs that does not validate with the W3C validators? We support all kinds of features that the W3C validators know nothing about. I don't understand why this bug should be WONTFIX. It has a clear accessibility win, and follows the HTML standard.
(In reply to Hixie (not reading bugmail) from comment #19)
> > what harm is being caused by not?
> 
> Pages that use <hgroup> (I gave a random sample in comment 12, but there's
> millions more) are less accessible.
 
> > What benefit to users does the whatwg requirements bring that is not already available?
> 
> It makes pages containing <hgroup> more accessible.

how so?


> > what are the use cases for the whatwg requirement?
> 
> Subheadings are pretty common on the Web.

that does not answer the question

> 
> > where is the data that supports the benefit of the whatwg requirement to users?
> 
> Comment 12. Based on a scan through a subset of the Google index, there are
> hundreds of millions of pages that use <hgroup> today (I gave a random
> subset of those in comment 12)

again, this does not support the whatwg requirements, also bandying around large numbers without providing the means to independently authenticate them is not helpful to your argument.
 
> 
> > Have AT implementers indicated an interest in implementing it?
> 
> As I understand this bug, it's not about AT implementors, but about
> Firefox's default accessibility mappings.

accessibility mappings are provided for AT implementers right?


> 
> But in any case, my question was aimed at Marco.
> 
> Marco, why would it be unwise for Firefox to map an element to accessibility
> APIs that does not validate with the W3C validators? We support all kinds of
> features that the W3C validators know nothing about. I don't understand why
> this bug should be WONTFIX. 

>It has a clear accessibility win, and follows
> the HTML standard.

You have not shown the whatwg requirements provide an accessibility win, clear or otherwise and as stated previously Firefox implements the accessibility mapping as per the HTML specification already, so it is implemented according to spec.
(In reply to steve faulkner from comment #20)
> > 
> > It makes pages containing <hgroup> more accessible.
> 
> how so?

Without it, you end up navigating headers incorrectly. For example, in this fragment:

   <hgroup> <h1>A</h1> <h2>B</h2> </hgroup> <p> Q </p>
   <h2>C</h2>                               <p> R </p>

...if you try to navigate to the previous header from C, you end up at B, rather than A. You essentially end up half-way through the actual heading.

Since apparently this was closed due to a misunderstanding (I had assumed you (Steve) understood why this was an accessibility win, and were just playing W3C politics, as opposed to just you misunderstanding why it was good for accessibility), I'm reopening the bug.
Summary: map HTML 5 hgroup element to accessibility APIs → map HTML <hgroup> element to accessibility APIs
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → NEW
(In reply to Hixie (not reading bugmail) from comment #21)
> (In reply to steve faulkner from comment #20)
> > > 
> > > It makes pages containing <hgroup> more accessible.
> > 
> > how so?
> 
> Without it, you end up navigating headers incorrectly. For example, in this
> fragment:
> 
>    <hgroup> <h1>A</h1> <h2>B</h2> </hgroup> <p> Q </p>
>    <h2>C</h2>                               <p> R </p>
> 
> ...if you try to navigate to the previous header from C, you end up at B,
> rather than A. You essentially end up half-way through the actual heading.
> 
> Since apparently this was closed due to a misunderstanding (I had assumed
> you (Steve) understood why this was an accessibility win, and were just
> playing W3C politics, as opposed to just you misunderstanding why it was
> good for accessibility), I'm reopening the bug.

I don't believe it was closed due to a misunderstanding in the first place, but it was re-opened due to a misunderstanding, as the situation described is not in anyway clearly more of an issue than the negative effects of implementing the WHATWG requirements. As stated in Comment 15 and Comment 16 the current mappings in Firefox provide the opportunity for AT implementers to decide what's best for their users in regards to how legacy hgroup code and its content is conveyed and it the implementation is conforming as per the HTML spec. So I am closing bug once again.
Status: NEW → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WONTFIX
changing to resolved fixed as the bug is "map HTML <hgroup> element to accessibility APIs" and Firefox does as per Comment 16
Resolution: WONTFIX → FIXED
Could you explain why the mappings defined in the HTML spec are bad?
(In reply to steve faulkner from comment #23)
> changing to resolved fixed as the bug is "map HTML <hgroup> element to
> accessibility APIs" and Firefox does as per Comment 16

a bugzilla note, fixed status needs a patch or other bug number which contains a patch, otherwise worksforme status is used.

But I'd rather use wontfix status since
1) As Steve noticed Gecko provides a basic mapping to accessibility APIs so that for example JAWS implements outline algorithm based on that.
2) There's no agreement on the feature and if I understand right there is no clear proposal how it should mapped to accessibility APIs (hgroup really sounds for me as aria-hidden, it seems people won't be ever agreed on it, so I'd rather spend time on something else)
(In reply to alexander :surkov from comment #25)
> (In reply to steve faulkner from comment #23)
> > changing to resolved fixed as the bug is "map HTML <hgroup> element to
> > accessibility APIs" and Firefox does as per Comment 16
> 
> a bugzilla note, fixed status needs a patch or other bug number which
> contains a patch, otherwise worksforme status is used.
> 
> But I'd rather use wontfix status since
> 1) As Steve noticed Gecko provides a basic mapping to accessibility APIs so
> that for example JAWS implements outline algorithm based on that.
> 2) There's no agreement on the feature and if I understand right there is no
> clear proposal how it should mapped to accessibility APIs (hgroup really
> sounds for me as aria-hidden, it seems people won't be ever agreed on it, so
> I'd rather spend time on something else)

OK thanks Alex, have changed back to WONTFIX as recommended
Resolution: FIXED → WONTFIX
alexander: For the record, there's a clear proposal for how it should be exposed, which is basically role=heading (see the HTML spec).

steve: Could you explain why the mappings defined in the HTML spec are bad?
(In reply to Hixie (not reading bugmail) from comment #27)
> alexander: For the record, there's a clear proposal for how it should be
> exposed, which is basically role=heading (see the HTML spec).

role=heading is always accompanied by level attribute in accessibility world. So which level should have hgroup element? Is it changed in case of nested hgroup elements? Does it affect on level of contained h1, h2 etc elements? The last question seems to be disputable, at least JAWS outline algorithm implementation had critics.
(In reply to Hixie (not reading bugmail) from comment #27)
> alexander: For the record, there's a clear proposal for how it should be
> exposed, which is basically role=heading (see the HTML spec).

I would suggest alex is well aware of the whatwg proposal as its the same one that was in the HTML specification for the last few years.

> steve: Could you explain why the mappings defined in the HTML spec are bad?

as you state [1]

"HGROUP elements are essentially equivalent to headings that contain multiple "paragraphs" (in the sense defined in the HTML specification). They should be conveyed as such to accessibility tools. This means setting the "heading" role on the HGROUP element, and treating the Hx elements in the HGROUP element the same way as paragraphs are treated normally."

which leads developers to do stuff like this [2]:


					<hgroup>
						<h1><img src="http://images.apple.com/imac/design/images/hero_title.png" width="635" height="105" alt="We've gone to extraordinary lengths. And widths."></h1>
						<h2 class="intro">Sit down in front of iMac and something incredible happens: The world around you seems to disappear, and you lose yourself in the big, beautiful display. To create an experience this immersive, we pushed every limit, rethought every detail, and advanced iMac in the most astonishing ways.</h2>
						<div class="fluidgallery-button">
							<a class="block selfclear imac-fluidgallery" href="#imac-fluidgallery" onclick="s_objectID=&quot;http://www.apple.com/imac/design/#imac-fluidgallery_1&quot;;return this.s_oc?this.s_oc(e):true">
								<div class="image">
									<img src="http://images.apple.com/imac/design/images/fluidgallery_thumb.jpg" width="65" height="36" alt="">
									<div class="play"></div>
								</div>
								<span class="link">View the gallery</span>
							</a>
						</div>
					</hgroup>

and AT users end up with a single heading that has 60+ words and a nice button to boot.

I don't see that as a good thing to hard code into Firefox.

[1] http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-129#Bug_10592:_Request_regarding_the_ARIA_role_of_heading_elements_inside_HGROUP_elements

[2] http://www.apple.com/imac/design/
(In reply to alexander :surkov from comment #28)
> (In reply to Hixie (not reading bugmail) from comment #27)
> > alexander: For the record, there's a clear proposal for how it should be
> > exposed, which is basically role=heading (see the HTML spec).
> 
> role=heading is always accompanied by level attribute in accessibility
> world. So which level should have hgroup element? Is it changed in case of
> nested hgroup elements? Does it affect on level of contained h1, h2 etc
> elements? The last question seems to be disputable, at least JAWS outline
> algorithm implementation had critics.

FYI the JAWS implementation of the outline algorithm is broken. It does not create an outline it just modifies heading levels (incorrectly), it ignores group, the last I heard was that they were going to pull it in favour of the old method they used.
(In reply to alexander :surkov from comment #28)
> 
> role=heading is always accompanied by level attribute in accessibility
> world. So which level should have hgroup element?

The spec defines this in some detail also.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Hixie (not reading bugmail) from comment #31)
> (In reply to alexander :surkov from comment #28)
> > 
> > role=heading is always accompanied by level attribute in accessibility
> > world. So which level should have hgroup element?
> 
> The spec defines this in some detail also.

your comment does not constitute a reason to re-open so closing again.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WONTFIX
Steve, that's highly rude behaviour. Please let the engineers who are actually working on this product consider the feedback they _asked_ for (comment 28) instead of closing the bug for them. This isn't the HTML working group.

alexander: The HTML standard defines how <hgroup> is mapped to ARIA. It provides that it be mapped to role=heading, and provides that the aria-level property be set to the element's outline depth, just like <h1>–<h6>. The <h1>–<h6> elements contained within <hgroup> are defined to have no role (much like <p>).

(Note that the argument in comment 29 is utterly bogus. Sure, people misuse <hgroup>, just like they misuse <div> and just like they misuse ARIA, but on balance things work fine. It's only when the data is almost uniformly bad, like with longdesc="", that it makes sense to start dropping accessibility features.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Hixie (not reading bugmail) from comment #33)
> Steve, that's highly rude behaviour. Please let the engineers who are
> actually working on this product consider the feedback they _asked_ for
> (comment 28) instead of closing the bug for them. This isn't the HTML
> working group.
> 
> alexander: The HTML standard defines how <hgroup> is mapped to ARIA. It
> provides that it be mapped to role=heading, and provides that the aria-level
> property be set to the element's outline depth, just like <h1>–<h6>. The
> <h1>–<h6> elements contained within <hgroup> are defined to have no role
> (much like <p>).
> 
> (Note that the argument in comment 29 is utterly bogus. Sure, people misuse
> <hgroup>, just like they misuse <div> and just like they misuse ARIA, but on
> balance things work fine. It's only when the data is almost uniformly bad,
> like with longdesc="", that it makes sense to start dropping accessibility
> features.)

Hi ian get off your high horse, I wontfixed the bug, as your previous arguments were rejected and you didn't provide anything new. I was given permissions to change status on the bug by the engineers who work on this. But as you want to continue to play games I will leave it up to alex to decide the continued status.
I should note that Steve is trustee person at Mozilla a11y and I believe he's in right to resolve bugs (and no doubt his bugzilla account allow him to do that).

Let me try to summarize the bug:

1a) it's part of WHATWG HTML standard (comment #9)
1b) it was dropped from W3C HTML standard (comment #10)

2a) there's millions pages that use hgroup (comment #12)
2b) probably everybody uses on its own (misuses)

3a) suggested mapping was to expose it as role heading and calculate level based on outline algorithm (comment #33)
3b) firefox has basic accessibility implementation and AT can pick it up to make their own implementation (comment #22)

Because of 1b and 2b the safest way for us to do 3b, implementing 3a could introduce more problems because of 2b so I didn't change my mind (comment #25). But since the bug gets disputable and hot then I'm fine to keep bug open.
(In reply to alexander :surkov from comment #35)
> I should note that Steve is trustee person at Mozilla a11y and I believe
> he's in right to resolve bugs (and no doubt his bugzilla account allow him
> to do that).
> 
> Let me try to summarize the bug:
> 
> 1a) it's part of WHATWG HTML standard (comment #9)
> 1b) it was dropped from W3C HTML standard (comment #10)
> 
> 2a) there's millions pages that use hgroup (comment #12)
> 2b) probably everybody uses on its own (misuses)
> 
> 3a) suggested mapping was to expose it as role heading and calculate level
> based on outline algorithm (comment #33)
> 3b) firefox has basic accessibility implementation and AT can pick it up to
> make their own implementation (comment #22)
> 
> Because of 1b and 2b the safest way for us to do 3b, implementing 3a could
> introduce more problems because of 2b so I didn't change my mind (comment
> #25). But since the bug gets disputable and hot then I'm fine to keep bug
> open.

Hi Alex, I agree with your analysis, but note while hgroup has been dropped from HTML it's implementation does have requirements are still defined:

"The hgroup element does not have strong native semantics or default implicit ARIA semantics. User agents must not implement accessibility layer semantics for the hgroup element that obfuscates or modifies the semantics of its children."

Which aligns with what Firefox has implemented.

As you know we are also adding an obsolete feature section to the HTML accessibility API spec and will detail the role and property requirements in the various APIs for hgroup there.

There has been no data or research provided to show how implementing what is defined in the whatwg spec will be of benefit to users, and there is no stated intention to implement what Ian has proposed, which points to the bug being closed as the appropriate status, but as you said its a hot button and if it appeases Ian to keep it open but idle then that is what we should do.
hgroup has not been dropped from the HTML spec we try to implement.
http://www.whatwg.org/specs/web-apps/current-work/#the-hgroup-element

But obviously it is not clear whether we should or should not implement it.
If you don't want it to be implemented, file a WhatWG HTML spec bug and ask it to be removed from the spec. I hope this issue can be resolved first at W3C and WhatWG before making decisions here.
@alex

mapping for hgroup now defined in API spec:

http://rawgithub.com/w3c/html-api-map/master/index.html#el-hgroup
Severity: normal → S3

Superseded by bug 1821156.

Status: REOPENED → RESOLVED
Closed: 11 years ago6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.