The Content panel has no bearing on a PDF's accessiblity or interaction with AT.
A PDF's accessibility is established by / defined by the structure tree which lives within the Tags panel.
The structure tree (in the Tag panel) has an <h1>. What does it role map to?
ISO 32000-1 identifies that PDF's Heading elements (tags) are explicitely:
H1, H2, H3, H4, H5 and H6.
Note the uppercase "H".
Your <h1>, <h2>, etc are what's been used to denote the styling in the authoring file as a "heading".
For those authoring applications having an appropriately robust tag management process used during PDF creation the built-in Headings / Paragraph tags must be used to obtain proper role mapping that is required.
For MS Word a "Heading 1" is roled mapped to PDF's <H1> when using Acrobat's PDFMaker.
Similarly this occurs when using FrameMaker or InDesign.
A "custom" build named "h1" will role map to an appropritate PDF element/tag other than one of the PDF heading elements.
What this will be is a function of what Word style was used.
So, something based on Normal will role map to the PDF element (tag) <P>.
And, of course <P> isn't a PDF heading element (tag).
Consequently AT will (correctly) identify that there's no headings.
When the deliverable is to be an accessible PDF it is essential to understand what the role mapping of the authoring application paragarph tags / styles to PDF elements will be.
For headings use what is built-in.
If something else is used then you must establish the correct role mapping manually using Acrobat Pro.
Each individual occurance of a "<h1>" would be mannually role mapped to PDF's <H1>.
Same for each "<h2>", "<h3>", etc.
Best practice is to "get it done" in the authoring environment.
For best of class how-to when using MS Word use Karen McCall's books.
A fall back could be what is out there in Microsoft's webspace.
(Much of it provided by Karen).
For your file(s) you could remediate back in the authoring files or remediate in the PDF file(s) manually.
Be well...