Page MenuHomePhabricator

There should not be multiple h1 tags on mobile page HTML: Restructure mobile web header for SEO and accessibility
Closed, ResolvedPublic3 Estimated Story Points

Description

Outcome from 2018 SEO project with Go Fish Digital:

Having more than h1 tag on a page can negatively impact search engine rankings, as it makes it difficult for crawlers to understand what the title of a page is. Since HTML5 it is permitted to have more than a single h1 tag, but it's not a good practice for search engine optimisation. On desktop we correctly only have one h1 tag which contains the title of the page, but on mobile we also have a second h1 tag containing the Wikipedia header image:

<h1>
    <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>&beta;</sup>
</h1>

This h1 tag should be removed, and replaced with something else that's appropriate for the context.

Acceptance criteria

Given we are using "nav" for our main menu. Let's continue adopting HTML5 semantic elements

QA steps

Visit https://en.wikipedia.beta.wmflabs.org/wiki/Transcluded_page and navigate various pages via Special:Random. Checking that the heading bar and content are displaying as normal. Make sure to visit pages as anonymous as well as logged in to catch any potential regressions.

Use real mobile phones to test this.
It would also be advisable to test with a few legacy browsers e.g. Opera Mini, UC browser.

Note: While we're unlikely to see any issues here at all (or notice any changes) possible things that could go wrong:

  • The header disappears on a certain browser
  • Site name/logo is stretched/huge
  • Clicking site logo/title doesn't take you to main page
  • article content is not visible

Event Timeline

Deskana created this task.Jul 6 2018, 10:12 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 6 2018, 10:12 AM
Deskana triaged this task as Medium priority.Jul 6 2018, 10:12 AM
Deskana moved this task from Tag to 2018 SEO project outcomes on the SEO board.
Deskana added projects: Mobile, MobileFrontend.
Krenair added a subscriber: Krenair.Jul 6 2018, 5:41 PM
Krenair edited projects, added MinervaNeue; removed MobileFrontend.Jul 6 2018, 6:02 PM

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

Jdlrobson added subscribers: Krinkle, Jdlrobson.

"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.

Jdlrobson renamed this task from Remove erroneous h1 tag from mobile page HTML to There should not be multiple h1 tags on mobile page HTML.Jul 6 2018, 7:33 PM
Jdlrobson moved this task from Incoming to Needs Prioritization on the Readers-Web-Backlog board.

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

Krinkle added a comment.EditedJul 6 2018, 10:02 PM

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

(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 :)

Jdlrobson updated the task description. (Show Details)EditedJul 9 2018, 10:28 PM

@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 renamed this task from There should not be multiple h1 tags on mobile page HTML to There should not be multiple h1 tags on mobile page HTML: Restructure mobile web header for SEO and accessibility.Jul 9 2018, 10:29 PM
Jdlrobson added a project: Accessibility.

@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.

Jdlrobson updated the task description. (Show Details)Jul 10 2018, 4:57 PM
ovasileva set the point value for this task to 3.Jul 10 2018, 5:00 PM
Jdlrobson moved this task from Needs triage to Triaged on the Mobile board.Jul 10 2018, 9:03 PM

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.

cscott added a subscriber: cscott.Jul 19 2018, 12:46 PM

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

Niedzielski moved this task from To Do to Doing on the Readers-Web-Kanbanana-Board-Old board.

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

Niedzielski removed Niedzielski as the assignee of this task.Aug 8 2018, 7:40 PM
Niedzielski added a subscriber: Niedzielski.
Jdlrobson moved this task from Triaged to MinervaNeue on the Mobile board.Aug 9 2018, 8:59 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

Added QA steps. Please test this one on the beta cluster since we are mostly concerned with how caching works.

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?
Jdlrobson updated the task description. (Show Details)Aug 14 2018, 9:05 PM
Jdlrobson updated the task description. (Show Details)

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

ABorbaWMF added a subscriber: ABorbaWMF.

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

phuedx removed Ryasmeen as the assignee of this task.Aug 16 2018, 10:37 AM
phuedx added a subscriber: Ryasmeen.
ovasileva closed this task as Resolved.Aug 17 2018, 9:53 AM
ovasileva claimed this task.
ovasileva added a subscriber: ovasileva.

Looks good! Resolving.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptAug 17 2018, 9:53 AM

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.