Skip to main content
Accessibility Field Guide

Headings and Page Structure

A practical Field Guide page about using headings to make screens easier to scan, navigate, and review.

A notebook, clipboard, pen, and folders arranged on a wooden desk.
Photo: Notebook and clipboard with papers placed on desk with folders and pens via Pexels — https://www.pexels.com/photo/notebook-and-clipboard-with-papers-placed-on-desk-with-folders-and-pens-5668469/
View full screen Download image

Headings are not just bigger text.

They are part of how a page explains itself.

A good heading structure helps people understand where they are, what each section is about, and how the screen is organized. It also gives people another way to move through the page without reading every word from top to bottom.

That matters because people do not all scan a page the same way.

Some people skim visually. Some use a screen reader heading list. Some zoom in and only see part of the page at a time. Some are trying to complete a task quickly and need the page to make sense without a lot of extra effort.

When headings are clear and structured, the page has a path.

When headings are missing, vague, or only styled to look right, people have to work harder to understand the screen.

The common project moment

A screen looks organized in a design file.

There is a big title at the top. There are bold labels. There are cards, panels, sidebars, helper sections, and maybe a few repeated blocks.

Visually, the layout seems clear because spacing, font size, and color are doing a lot of work.

But the actual structure may tell a different story:

  • the page has no real h1
  • every section title is just bold paragraph text
  • headings skip from h1 to h4 because the smaller style looked right
  • multiple areas use the same vague heading, such as Details
  • card titles look like headings but are not marked up as headings
  • a modal or panel opens without a clear heading
  • a long form has labels but no section structure
  • the visual order and heading order do not match

That gap can be hard to notice in a screenshot.

It shows up when someone tries to navigate the screen, review the markup, use assistive technology, or understand the page without seeing the whole layout at once.

What headings do

Headings give content a usable outline.

They answer practical questions:

  • What is this page or screen about?
  • What are the main sections?
  • Where does one section end and the next begin?
  • Which details belong under which topic?
  • Can someone skip to the part they need?

A heading is not there only to make text stand out.

It helps the page communicate structure.

For example, a benefits application screen might have one page title and several clear sections:

  • Apply for benefits
  • Applicant information
  • Household members
  • Income information
  • Documents to upload
  • Review and submit

Those headings help more than the visual design.

They give the page a map.

Start with one clear page heading

Most pages should have one clear main heading.

In HTML, that is usually the h1.

The h1 should name the page, screen, task, or record clearly enough that someone knows where they landed.

Better page headings are specific:

  • Apply for benefits
  • Review readiness checklist
  • Upload supporting documents
  • Payment confirmation
  • Vendor accessibility questions

Vague page headings create extra work:

  • Form
  • Details
  • Dashboard
  • Information
  • Step 2

Those may be understandable to the team building the screen, but they often make the page harder for users and reviewers to understand.

If the page title only makes sense when someone already knows the workflow, it may need more context.

Use heading levels to show relationships

Heading levels should describe the relationship between sections.

They should not be chosen only because of how they look.

A simple structure might look like this:

<h1>Apply for benefits</h1>
<h2>Applicant information</h2>
<h2>Household members</h2>
<h2>Income information</h2>
<h3>Employment income</h3>
<h3>Other income</h3>
<h2>Review and submit</h2>

The h2 headings are major sections under the page title.

The h3 headings are smaller sections inside Income information.

That structure gives the page an outline people can follow.

It is usually a problem when heading levels are picked to match a visual size instead:

<h1>Apply for benefits</h1>
<h4>Applicant information</h4>
<h4>Household members</h4>
<h2>Income information</h2>

The visual design might still look fine, but the structure is harder to understand.

If a heading needs to look smaller, style it with CSS. Do not change the heading level only to get the visual size.

Do not make everything a heading

Headings are useful because they mark real sections.

If every label, card title, helper note, and short phrase becomes a heading, the outline gets noisy.

A heading should usually introduce content that belongs under it.

For example, this can be useful:

  • Contact information
  • Mailing address
  • Phone and email

But this may be too much if each item is only a single field label or short line of helper text:

  • First name
  • Last name
  • Middle initial
  • Optional
  • Help

The question is not “Can this text be visually larger?”

The question is:

Does this text introduce a meaningful section someone may want to find or skip to?

If not, it may be better as a label, paragraph, list item, or normal text.

Make section names specific enough to help

A heading should help someone decide whether the section is relevant.

Repeated or vague headings make that harder.

For example, a page with several sections named Details may look clean visually, but it does not give much help in a heading list.

Better headings name the thing they are about:

  • Applicant details
  • Case details
  • Payment details
  • Document details

The same issue appears in cards and repeated blocks.

If every card section is called More information, the user has to open or read each one to understand what it means.

Clear headings reduce that guessing.

Keep visual structure and code structure aligned

A common accessibility issue happens when the screen has a visual structure but the code does not.

A large bold line looks like a heading, but it is coded as a paragraph.

A card title looks like a section label, but it is only a generic div.

A modal has a visual title, but the dialog is not connected to that title.

A long form has visual groupings, but the markup does not communicate those groups.

This creates a mismatch between what some users see and what other users can navigate.

The goal is not to make the code fancy.

The goal is to make sure the page structure people can see is also available programmatically.

Forms and workflows need structure too

Headings are especially useful in long forms and multi-step workflows.

A form with thirty fields can feel overwhelming if it is just one long stack.

Clear sections help people understand the path:

  • who the form is about
  • what information is needed
  • which documents are required
  • where review and submission happen
  • what changed after an error or validation message appears

This also helps internal review.

A BA, designer, developer, or tester can talk about a specific part of the screen without guessing what it is called.

“Applicant information” is easier to discuss than “the group of fields near the top after the intro text.”

Questions teams can ask

During design and content

  • What is the main page or screen heading?
  • Can someone understand the page by skimming the headings?
  • Do the section names match the task language users would expect?
  • Are repeated sections named clearly enough to tell them apart?
  • Are card titles, modal titles, and panel titles doing real section work?
  • Is anything being made large or bold when it should actually be a heading?

During development

  • Does the page have one clear h1?
  • Do heading levels describe the structure instead of the visual size?
  • Are headings coded as real headings when they introduce sections?
  • Are labels, helper text, and ordinary copy kept out of the heading outline when they are not real sections?
  • Does the DOM order match the visual reading order?
  • Are dialogs, panels, and dynamic sections connected to clear titles when needed?

During QA

  • Can you navigate the page by headings and understand the outline?
  • Does the heading list contain useful section names?
  • Are any important visual headings missing from the heading list?
  • Are there skipped or strange heading levels that make the structure confusing?
  • Are there repeated vague headings such as Details, Information, or More?
  • Does the structure still make sense at mobile sizes or high zoom?

Common trail hazards

  • No clear h1 for the page or screen.
  • A page title that is too vague to orient the user.
  • Text styled to look like a heading but not coded as a heading.
  • Heading levels chosen for font size instead of structure.
  • Skipped heading levels that make the outline harder to follow.
  • Too many headings, making the page outline noisy.
  • Repeated headings such as Details, Information, or More without enough context.
  • Card titles, modal titles, or panel titles that look important visually but are not exposed as structure.
  • Long forms with no section headings.
  • Visual order and programmatic order that do not match.

Small habit

Before a screen moves too far into development, read only the headings.

Ask:

If someone used this outline as their map, would the page make sense?

If the answer is no, the screen may need clearer structure.

That does not always mean adding more headings.

Sometimes it means naming sections better. Sometimes it means using the right heading level. Sometimes it means turning visual styling into real structure. Sometimes it means removing headings that are not doing useful work.

The goal is simple: make the path through the page easier to understand.

Use these as trail markers, not as the whole conversation:

What to do next