From harness-claude
Guides use of semantic HTML elements (landmarks, headings, buttons, links, lists, tables, forms) to improve accessibility for assistive technology users.
How this skill is triggered — by the user, by Claude, or both
Slash command
/harness-claude:a11y-semantic-htmlThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Use semantic HTML elements to convey document structure, meaning, and navigation landmarks to assistive technology
Use semantic HTML elements to convey document structure, meaning, and navigation landmarks to assistive technology
<div> and <span> soup with meaningful elements<header>Site branding and primary navigation</header>
<nav aria-label="Main">Primary navigation links</nav>
<main>Primary page content — exactly one per page</main>
<aside>Complementary content (sidebar, related links)</aside>
<footer>Site footer, legal links, copyright</footer>
<main> per page.aria-label to distinguish multiple <nav> elements (e.g., "Main", "Footer", "Breadcrumb").<nav> inside <header> is fine, <main> inside <main> is not.<h1>-<h6>) to create a logical outline. Headings are the primary way screen reader users scan a page. Follow a strict hierarchy — do not skip levels.<h1>Product Catalog</h1>
<h2>Electronics</h2>
<h3>Laptops</h3>
<h3>Phones</h3>
<h2>Clothing</h2>
<h3>Men's</h3>
<h3>Women's</h3>
<h1> per page (the page title).<h2> to <h4> — screen readers announce heading levels.<button> for actions and <a> for navigation. Buttons trigger in-page actions (submit, toggle, open modal). Links navigate to a URL. Do not use <div onclick> for either.// Correct — button for action
<button onClick={handleSave}>Save Changes</button>
// Correct — link for navigation
<a href="/settings">Go to Settings</a>
// Wrong — div pretending to be interactive
<div onClick={handleSave} className="btn">Save Changes</div>
Use <ul>, <ol>, and <dl> for lists. Screen readers announce "list, 5 items" — giving users context about the content structure. Navigation menus should be <ul> inside <nav>.
Use <table> for tabular data, never for layout. Include <thead>, <th scope="col">, and <th scope="row"> so screen readers can associate data cells with headers.
<table>
<caption>
Quarterly Sales
</caption>
<thead>
<tr>
<th scope="col">Region</th>
<th scope="col">Q1</th>
<th scope="col">Q2</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">North</th>
<td>$1.2M</td>
<td>$1.4M</td>
</tr>
</tbody>
</table>
Use <form>, <fieldset>, and <legend> for form structure. Group related inputs with <fieldset> and provide a group label with <legend>.
Use <article> for self-contained content that makes sense independently (blog posts, comments, product cards). Use <section> for thematic grouping within a page — always pair <section> with a heading.
Use <time> for dates and durations to provide machine-readable time data.
<time datetime="2026-04-07">April 7, 2026</time>
<details> and <summary> for expandable content instead of custom JavaScript accordions. They are natively accessible with keyboard and screen reader support.<details>
<summary>Order details</summary>
<p>Order #12345 — shipped on April 5, 2026.</p>
</details>
Why semantic HTML matters: Assistive technology (screen readers, switch controls, voice navigation) relies on the HTML element type to determine how to present and interact with content. A <button> is announced as "button" and activated with Enter/Space. A <div> with an onClick is announced as "group" — the user has no idea it is interactive.
Implicit ARIA roles: Semantic elements carry implicit ARIA roles — <nav> is role="navigation", <main> is role="main", <button> is role="button". Using semantic HTML means you rarely need to add ARIA attributes manually.
Common anti-patterns:
<div class="header"> instead of <header><h3> because it looks the right size (use CSS for sizing)<a href="#" onclick={fn}> — if it does not navigate, use <button><br> for spacing instead of CSS margin/padding<b> and <i> for styling — use <strong> and <em> for semantic emphasis, CSS for visual stylingTesting: Use the browser's accessibility tree inspector (Chrome DevTools > Accessibility tab) to see how your markup is exposed to assistive technology. The rendered accessibility tree should mirror the visual hierarchy.
https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML
npx claudepluginhub intense-visions/harness-engineering --plugin harness-claudeGuides building and reviewing web page HTML structure with proper heading hierarchy, landmark regions, and semantic elements for screen reader accessibility.
Web accessibility discipline: semantic HTML first, ARIA only when needed, keyboard access always. Invoke whenever task involves any interaction with accessible web content -- writing, reviewing, refactoring, or debugging HTML/CSS/JS for WCAG compliance, ARIA usage, keyboard navigation, focus management, screen reader support, or accessible component patterns.
Builds content structure that assistive technology can parse and navigate. Covers heading hierarchy, landmarks, alt text, table/forms specs, and reading order.