Why is this tagged accessibility?

*** Bug 33415 has been marked as a duplicate of this bug. ***

Not sure if this is proper HTML:

<h2><span class="editsection">...</span> <span id="License"
class="mw-headline">License</span></h2>

Correct would be to add the id to the h2-tga instead:
<h2 id="License"><span class="editsection">...</span> <span
class="mw-headline">License</span></h2>

It becomes a problem when you use the CSS3 pseudo selector :target to style the
background:

*:target { background-color:#fffddf !important }

http://i.imgur.com/I7uwr.png

Removing 1.19wmf1 milestone blocker. Not a high priority for 1.19 completion

Tim, Danny and I discussed this today at the Berlin Hackathon:

• Current HTML:

<h#(wikitext attribs)>
  (edit section link)
  <span class="mw-headline" id="(anchor based on heading title)">(heading title)</span>
</h#>

• Use cases:

1. Ability to jump to the headline from the hashtag. When the skin has a large edit section link or positioned it as a block
2. Ability to style the currently hash-targetted heading with CSS ":target"
3. For screen readers and semantics, the edit section link should not be part of the <h#>.

• Conclusions:

• We can't put the ID on the <h#>, because wikitext pages can (and do!) contain html tags with an ID already (e.g. <h3 id="awesome">The Awesome Delivery of Resources</h3>). See Linker::makeHeadline

• We shouldn't put an empty <span id="..></span> (or div) before the <h#>. Although that solves the jump issue, it still doesn't allow to easily select the header from the :target selector.

• We can't put a span around the <h#>. Block element should not be in an inline element.

• We can put an unstyled <div> around (not before) the <h#>. That solves all three use cases. CSS styling is possible with ":target h# { .. };". Also we should then add the "mw-headline" class to the <h#>. Potentially it can have a class already, but an element can have multiple classes. Note that in this case the attributes have to be merged. With code class="y" title="z" class="x" the last one overrides the earlier.

• Proposal 1:

<div id="(anchor based on heading title)">
  (edit section link)
<h#(wikitext attribs) class="mw-headline">
  (heading title)
</h#>
</div>

• Proposed 2 (alternative)

<div class="mw-headline" id="(anchor based on heading title)">
  (edit section link)
<h#(wikitext attribs)>
  (heading title)
</h#>
</div>

• Proposed 3 (Figure out a way to keep track of the custom ID, or decide not to support a custom ID on headings)

  (edit section link)
<h#(wikitext attribs) id="(anchor based on title or custom)">
  (heading title)
</h#>

• Proposed 4 (Allow custom ID, but move into span for anchor purpose only)

  (edit section link)
<h#(wikitext attribs) id="(anchor based on title or custom)">
  <span id="(optional custom ID)"></span>(heading title)
</h#>

The motivating application for this request is to support a template on cs.wikibooks.org which will be styled differently depending on whether it is immediately after a heading. There is a proposal for the typical placement to be changed, but they don't want to use a different template name, rather they want to use some sort of sibling selector in site CSS to detect which placement policy is in use in a given instance.

(In reply to comment #5)

[..]

3. For screen readers and semantics, the edit section link should not be part

of the <h#>.
[..]

case 3 is also reported as bug 11555 (T13555).

I propose we implement the alternative Krinkle suggested in comment 5. Might be most disruptive, but I think it will fit our future usecases better. It's more likely we want to identify the entire block of a heading, then a specific heading elements inside the heading block.

(In reply to comment #8)

I propose we implement the alternative Krinkle suggested in comment 5. Might be
most disruptive, but I think it will fit our future usecases better. It's more
likely we want to identify the entire block of a heading, then a specific
heading elements inside the heading block.

Perhaps... though I should say. Semantically what we really want when we think of an id is not the header but the whole section it encompass. ie: If it weren't for the issues with doing so we should have a <section> element with the id on it instead.