Looks like this is from includes/skins/minerva.mustache in the MinervaNeue skin.

"Since HTML5 it is permitted to have more than a single h1 tag, but it's not a good practice for search engine optimisation."
How big a deal is this? I was under the impression that this advice is outdated - Google themselves said that this wasn't a problem - https://www.youtube.com/watch?v=WsgrSxCmMbM

Note, although here h1 is maybe not so necessary it's more important on https://www.mediawiki.org/wiki/MediaWiki where there is no icon and that it is possible and wikitext can plant h1s in a page - https://en.wikipedia.beta.wmflabs.org/wiki/Multiple_h1s - which is probably more of a concern.

(Removing word " erroneous" as this was an intentional non-erroneous choice given h1s are commonly used to reflect a site title.)

Yeah... this particular bit of SEO advice seems rather dated. Its not unusual for such advice to bounce around many years, because following it (usually) doesn't cause problems, and other (unrelated) changes customers make around the same time may improve things – thus leading one to falsely believe it "helped". I'm glad Google has put out this Google Webmasters series that, among other things, unequivocally states that heading levels aren't a problem.

It probably does not matter whether you have many H1s followed by H2s, or many H2s followed by H3s. That's just an overall shift up or down, that behaves the same from an accessibility point of view (and for search engines). In the case of wikitext, they'll visually look bigger, but otherwise its a harmless editorial decision (or mistake) that doesn't affect search or accessibility.

While search engines may be unaffected, good structure does matter for UX and accessibility trees.

Structure

What presumably does matter is for the overall tree to be well-balanced. Which means we don't want the site name and article title to be competing for user's attention in the accessibility tree. I see two clear choices emerge from that desired outcome:

1. Separate the site header from the content, by having the header be its own semantic area, scoping headings locally (instead of part of the document-wide structure).
2. Or; Make the site logo not an <h1>, marking up the logo as native content instead with <a><img/></a>. (Given there is no benefit from it being an H-1: it only results in more work to undo with CSS and semantic attributes.)

Option 1 would basically mean putting the site-wide branding in an element with role="banner" and the content in role="main" (equivalent to <header> and <main>, behaves the same to Assistive Technology). Once that is done, heading levels are treated as relative to within their semantic area, thus an <h1> logo would no longer be seen as the top-level heading of the main content.

The Vector and MonoBook skins actually follow both options already (for wider support with older AT that don't recognise semantic roles).

Vector AT
Minerva AT

This is just a quick glance using Chrome's AT inspector. Actual screen readers may be better (or worse), but it seems worth investigating to see what can be improved. We may want to create a new task for that, though.

Further reading:
https://csswizardry.com/2010/10/your-logo-is-an-image-not-a-h1/
https://wehavezeal.com/blog/web-development/2016/01/12/should-i-use-the-h1-tag-for-my-website-logo
https://www.fastcompany.com/3016894/should-your-tag-be-your-logo

In T198947#4404366, @Jdlrobson wrote:

(Removing word " erroneous" as this was an intentional non-erroneous choice given h1s are commonly used to reflect a site title.)

Apologies. The way it was described to me by the SEO consultants made me think it was a mistake. No offence was intended.

Don't worry no offence. Just wanted to clear that up :)

@Krinkle do you think the proposal in acceptance criteria makes sense? is there any advantage in having a hidden h1 e.g

<a href="/">
  <span><img src="/static/images/mobile/copyright/wikipedia-wordmark-en.png" alt="Wikipedia" srcset="/static/images/mobile/copyright/wikipedia-wordmark-en.svg 1x" height="18" width="116"></span>
  <sup>β</sup>
</a>
<h1 style="display:none;">Wikipedia</h1>

@Jdlrobson No, I don't think the hidden H-1 would have any benefit. It would be hidden and ignored for all relevant parties, including search.

Hidden by display: none provides nothing. From my expertise in recent years, search engine crawlers ignore hidden elements (or even go beyond and tag it as spam and assistive technology completely hides it to their users. Even dynamically shown elements might run into both issues depending on crawler or AT.

Google isn't using our mobile content for indexing anyway. They are using the Parsoid-format HTML directly from RESTbase AFAIK.

In T198947#4438071, @cscott wrote:

Google isn't using our mobile content for indexing anyway. They are using the Parsoid-format HTML directly from RESTbase AFAIK.

(For context, @cscott has commented more extensively about this over at T198970#4438029 ff.)

Change 451402 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/MinervaNeue@master] Hygiene: replace header and content divs

https://gerrit.wikimedia.org/r/451402

Change 451402 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Hygiene: replace header and content divs

https://gerrit.wikimedia.org/r/451402

@Jdlrobson passing this over to QA but would be great if you can add some more detail, specifically:

• is the idea to test this on mobile?
• what types of regressions should QA be looking for?

@alexhollender updated QA. Hoping this is a little clearer.

Tested using some real and some simulated devices (for coverage and screenshots). Did not see any regressions.

Per T198947#4404746, the original report led me to discover an issue in a related problem space (Accessibility/Screen readers). The task was implicitly repurposed for that.