Accessibility Information is inaccurate

erTell us what’s happening:
Describe your issue in detail here.

This article/lesson is teaching a bad a11y practice. h1 elements do not belong in the header region since they are usually the first targeted element by screen reader users. Once I jump to the h1, I am expecting there to be page content ready to go when I start navigating normally element by element down the page. Putting the h1 in the header defeats the purpose of the h1 and the landmark since only repeated elements and object belong in the header, such as logos, navigation regions, search boxes, etc. The h1 will change with each page change, and navigating down from it should move me immediately into the page content, not contend with anything else in the header region.

Skip to content links generally aim for either the main region id or the h1 id, and if I land on an h2 in the main content, I feel like I’ve missed something and try navigating backwards to find the h1.

Please revise the practices being taught here and ensure that coders and designers don’t put their h1s incorrectly into header regions.

  **Your code so far**



<!-- h1 elements do not belong here! -->

  <h1>Training with Camper Cat</h1>


<!-- h1 elements belong right here! -->

  <section id="stealth">
    <h2>Stealth &amp; Agility Training</h2>
    <article><h3>Climb foliage quickly using a minimum spanning tree approach</h3></article>
    <article><h3>No training is NP-complete without parkour</h3></article>
  <section id="combat">
    <h2>Combat Training</h2>
    <article><h3>Dispatch multiple enemies with multithreaded tactics</h3></article>
    <article><h3>Goodbye world: 5 proven ways to knock out an opponent</h3></article>
  <section id="weapons">
    <h2>Weapons Training</h2>
    <article><h3>Swords: the best tool to literally divide and conquer</h3></article>
    <article><h3>Breadth-first or depth-first in multi-weapon training?</h3></article>
  **Your browser information:**

User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15

Challenge: Make Screen Reader Navigation Easier with the header Landmark

Link to the challenge:

1 Like

Hello @Marconiusiii,

I am not agree with what you are saying even I didn’t understand all. <h1> just means title very important. It is better to have only one per page. The content of each tags is free. <header>, <footer>, <article> etc, can contain absolutely everything. It depends the project you are working on etc, especially when you want to create something original. <header> is just a block tag, at the same level that a <div> except that it means something. You can repeat a <h1> such as you can repeat a logo, talking about what you mentioned. You can have the logo + a <h1> combine together. The <h1> can simply be your name in the case you do a personal website. That the <h1> be inside the <header>, inside the <main> or whatever change nothing at the code. You still have the content who is following. For the SEO, the content of a <header> and the elements inside are important, and it seems perfectly logic to have a <h1> tag inside it. If there is well something that is repeated into a website is the title and name of it. You are not gonna give a <h2> for the name of your page because it doesn’t make any sense.

freeCodeCamp proposes a part about accessibility, also you can check that link if you want to learn more about all of this:

It sounds like @Marconiusiii is someone who actually uses a screenreader, so I’m going to assume that they are speaking from a position of expertise. I have created an Issue in GitHub based on what you’ve said Marconiusiii. If you would like to add further remarks or subscribe to updates, you can find it here: Report of incorrect a11y guidance for "Make Screen Reader Navigation Easier with the header Landmark" · Issue #45091 · freeCodeCamp/freeCodeCamp · GitHub

While technically not a WCAG violation to have the h1 heading in the header element, I do agree with @Marconiusiii that it is a best practice to have it at the beginning of the main element. The h1 heading is generally the page title and should immediately proceed the beginning of the main page content, which is in the main element, so it usually makes sense to put the h1 heading at the beginning of main.

But if you do put the h1 in the header element then it should probably be the very last thing in the header. As @Marconiusiii pointed out, when you navigate to the h1 heading you expect the content that immediately follows to be the beginning of the main content, not menus, logos, search bars, or anything else that is routinely stuck in the header element.

On a side note, if you do have content in the header element that needs a heading then you can use an h2 element. The h1 heading does not need to be the first heading on the page (though it should be near the top of the page).

Thank you, for taking the time to open this.

@bbsmooth Is this something that can be accomplished with tabIndex? That is, assert the h1 in the header to be last in the selectable group?

You wouldn’t want to use tabIndex=0 for this, that should only be used for interactive elements (and most of the time they will already have an implicit tabIndex=0 so there are really only a few use cases where it needs to be explicitly used).

Screen reader users have several ways to navigate content that do not involve using the Tab key, and navigating by headers is one of the most common. The order of content for screen reader users is determined solely by the order of that content in the DOM. Thus, the <h1> should literally be the last element in the <header>.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.