Business and Service Websites: Designing Accessible Article Categories for Cross-team Maintenance

When multiple teams update a business or service website, maintaining consistent and accessible article categories is crucial. This article addresses the specific challenge of structuring content so that assistive technologies and human users can navigate efficiently. We will explore how to use heading levels correctly, label menus semantically, and ensure descriptive titles for better orientation.

Assuming a shared blog section with mixed contributors

Assume a mid-sized service company where the marketing, support, and engineering teams all publish into one shared blog. The marketing editor writes customer stories, support contributes troubleshooting notes, and engineering posts release explanations. The shared article category set is the piece under discussion here, not the publishing workflow.

For this scenario, imagine three candidate category schemes on the table. One is deliberately plain: "Guides," "Updates," and "Stories." It is easy to scan and simple to translate into accessible navigation, but the marketing editor worries that customer stories and release explanations will crowd each other under "Stories." A second scheme is more granular: "How-to Guides," "Product Updates," "Customer Stories," "Troubleshooting," and "Engineering Notes." It maps cleanly to who writes what, yet the support lead points out that a troubleshooting note and a how-to guide often cover the same task, so contributors would need a rule for choosing between them. A third option groups by reader intent: "Get Started," "Fix a Problem," "See What's New," and "Hear from Customers." This reads well for visitors, but the engineering team is unsure where a release explanation belongs when it also fixes a known issue.

A second open question is naming and ordering. The marketing editor proposes numbering the categories so the order stays stable as new ones appear, while the support lead prefers alphabetical order so contributors can find a category without memorizing a sequence. Neither choice is settled, and the accessibility implications differ: a fixed order may need a visible explanation, while alphabetical order may bury the most-used category.

A third is ownership. Someone has to decide when a new category is warranted rather than stretching an existing one, and nobody in this scenario has been named for that role. The engineering lead has drafted a short note proposing that any new category needs a named owner and a one-line description, but it is only a draft sitting in a shared document.

These are illustrative examples, not a real taxonomy or a record of past publishing. They simply show the kinds of choices that a mixed-contributor blog forces into the open before any maintenance routine can be written.

Using hierarchical headings to define category boundaries

The W3C WAI headings tutorial states that page headings communicate content organization and can support in-page navigation by browsers, plug-ins, and assistive technologies. It ranks headings from h1 as most important to h6 as least, and explains that headings of equal or higher rank start a new section while lower-rank headings start subsections of the higher-ranked section; skipping ranks should be avoided where possible, though it is acceptable when closing subsections.¹

For fixed page sections such as sidebars, the tutorial says heading ranks should not change based on the content area, because consistency across pages matters more there. It also notes that aria-labelledby can associate headings with page regions, with visible headings making those regions easier for all users to identify.¹

You can take one shared draft category page and rewrite only its heading levels to see how boundaries become easier to follow. Begin with a flat set of category names, then assign each a level: the overall collection as an h1 element, broad groupings such as “Guides” or “Updates” as h2 elements, and narrower subtypes beneath them as h3 elements. Read the result without the surrounding design and note where a reader can tell that a new grouping has begun.

Consider testing two versions of the same sample text: one where every category is an h2, and one where related categories sit under a shared h2 with h3 children. In the second version, a support troubleshooting note and a release explanation can each appear under a distinct subgroup, so a reader scanning headings sees why they are separate. You might record which version makes the difference between “Stories” and “Updates” clearer without relying on color or position.

Keep the wording of each heading tied to what its articles actually share. If a proposed subgroup contains only one article, you can leave it at the broader level for now and note the reason. The choice of how deep to nest remains yours; the aim is a heading outline another team member can follow when adding or moving an article.

Labeling navigation menus for clear identification

Labels should be short but descriptive so users can distinguish between multiple menus on a page. The source says to provide the label with a heading, an aria-label attribute, or an aria-labelledby attribute, and it points to the labeling regions tutorial for those techniques. Its example uses a nav element labelled by a visually hidden second-level heading that reads “Main Menu.”²

Take your current category menu and write each label as if it were the only clue a reader gets before clicking. Begin with the labels you already publish, and replace any internal shorthand with the words readers use for the same content. For example, “Release Notes” might become “Product Updates,” and “KB Articles” might become “Help and Troubleshooting,” because both rewritten labels say what the reader will find rather than which team produced it. You can decide case by case whether the plainer wording is worth the change.

You might also compare two label sets side by side before settling on one. In one column, place the names your teams currently use; in the other, write a reader-facing alternative and note why it reads more clearly. Keep both columns visible when the group discusses the menu, so a label is not quietly renamed without a shared reason. If two labels still sound interchangeable, you can merge them or sharpen one with a more specific word drawn from the articles it contains.

Providing unique and informative page titles

For each page, give a short title that describes the page content and distinguishes it from other pages. The title is often the same as the page's main heading, and the unique, most relevant information should come first—for example, the page name before the organization name. For pages that form part of a multi-step process, include the current step in the page title. This guidance corresponds to WCAG 2.4.2, Page Titled.³

Take one existing category landing page and check whether its page title would still make sense if a reader saw it alone in a browser tab or a list of search results. You can start with the page you already have rather than writing a new one. Read the title once, then ask whether it names the category's actual subject and distinguishes it from sibling categories. A title like "Articles" tells a reader little; "Troubleshooting Notes for Service Customers" says what the collection contains and who it is for.

You might revise a candidate title in two passes. First, write the plain version, then add only the detail that separates it from the nearest other category. For example, if your draft reads "Customer Stories," consider whether "Customer Stories: How Service Teams Solved Problems" gives a reader a more accurate expectation without becoming a slogan. The added wording should describe the articles, not promise an outcome.

Choose between two candidate titles by setting them beside the category's three most recent article titles. If the page title repeats words that already appear in every article title, it may be too generic; if it introduces a subject none of the articles cover, it may be misleading. You can note which candidate better predicts the mix, then keep the other as a fallback for discussion with the team that owns those articles.

Organizing content sections with programmatically identifiable headers

For the shared category set, the source technique asks that each section have a heading that identifies it. In HTML, heading elements h1 through h6 can serve this role, letting user agents identify section headings automatically. The technique also says authors should nest headings properly, such as an h1 followed by an h2, and an h2 followed by another h2 or an h3. Its example uses an h1 for the page title, h2 elements for major sections, and h3 elements for sub-sections.⁴

Take one shared draft category page and look only at its section headings, not the articles beneath them. You can mark each heading as h2, h3, or h4 to see whether the nesting matches how the categories actually relate. If “Troubleshooting” and “Release Notes” both sit as h2 elements under one broader h1 element, ask whether readers would expect them as siblings or as children of something like “Product Help.”

You might then rewrite the same page two ways before choosing. In the first, keep every category at h2; in the second, group support and engineering notes under a shared h2 with h3 children. Read both aloud and note which one makes the boundary between customer stories and technical updates clearer. Neither version is automatically correct; pick the one your mixed audience can follow without extra explanation.

When a heading feels ambiguous, you can revise its wording in two passes: write the plain label first, then add only the detail that distinguishes it from the nearest category. Choose between candidates by placing them beside the three most recent article titles in that section. If a heading repeats what the article titles already say, you might shorten it rather than add more words.

Ensuring descriptive labels help users orient themselves

Under Success Criterion 2.4.6, headings and labels must describe topic or purpose so users can understand what content is present and how it is organized. The W3C guidance notes they need not be lengthy—a word or even a single character may suffice if it gives an appropriate cue—but their accuracy and clarity matter. Descriptive labels help users identify specific components within the content. The same source separates concerns: this criterion does not require that heading or label content be correctly marked up, which falls under 1.3.1, and does not require headings or labels be provided at all. Clear titles especially help readers with slow reading or limited short-term memory predict what each section contains.⁵

Take a small sample of labels from each contributor and write each one as though it were the only clue a reader sees before clicking. You can start with three: a marketing customer story, a support troubleshooting note, and an engineering release explanation. For each, draft a plain reader-facing label, then note which neighboring category a reader might confuse it with. If “Updates” could cover both a release explanation and a support fix, the label may be too broad; consider whether “Release notes” or “Fixes and workarounds” separates them without overexplaining.

You might compare two wording candidates for the same category before choosing. Candid one could be “Getting started”; candidate two might be “Setup guides for new customers.” The second is longer but tells a reader what kind of article sits beneath it. Keep whichever candidate survives a quick read beside the category’s three most recent article titles, and discard wording that repeats what those titles already say.

You can also revise one ambiguous heading in two passes: write the plain label first, then add only the detail that distinguishes it from its nearest neighbor. These are author demonstrations, not tested results, so treat the final choice as a draft you can revisit when contributors add new material.

Frequently asked questions

How can I rewrite a shared draft category page's heading levels to make its boundaries easier to follow?

You can take one shared draft category page and rewrite only its heading levels to see how boundaries become easier to follow. Begin with a flat set of category names, then assign each a level: the overall collection as an h1 element, broad groupings such as “Guides” or “Updates” as h2 elements, and narrower subtypes beneath them as h3 elements.

How can I check whether my page title would still make sense if a reader saw it alone in a browser tab or search results?

Take one existing category landing page and check whether its page title would still make sense if a reader saw it alone in a browser tab or a list of search results. You can start with the page you already have rather than writing a new one.

How can I revise an ambiguous heading in two passes?

You can also revise one ambiguous heading in two passes: write the plain label first, then add only the detail that distinguishes it from its nearest neighbor.