The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Semantic HTML makes a page’s structure and purpose clearer to browsers and assistive technologies. In her DEV Community post, Faith describes auditing her portfolio and fixing generic page containers, missing image alternatives, unassociated form labels, and a skipped heading level. Those changes improved the markup; her reported perfect Lighthouse accessibility score is one audit result, not proof that the portfolio—or any site—is fully accessible.
What semantic HTML communicates
Semantic HTML uses elements that describe the role of their content instead of relying on generic containers such as <div> for every region. A <nav> identifies navigation, while <main> identifies the page’s main content. This gives browsers and assistive technologies meaningful structure to expose to users.
W3C WAI explains that semantic page structure helps people navigate and orient themselves. Its H101 technique notes that landmarks can help assistive-technology users move to regions such as navigation or main content. As W3C puts it, “Landmarks provide an easy way for users of assistive technology understand the programmatic structure of a page and skip over content they’re not interested in.” Not every semantic element creates a landmark in every context, and W3C techniques are examples rather than mandatory methods for meeting WCAG.
Faith’s audit found generic wrappers where more meaningful structure could clarify the portfolio’s regions. Replacing a generic wrapper with an element such as <header> or <nav> is useful when that element accurately describes the content and its placement. The goal is meaningful structure, not swapping tags merely to use more semantic elements.
#1 Best Overall
W3C WAI’s Page Structure Tutorial explains how page structure supports navigation and orientation.
How Faith applied semantics in her portfolio
Choose image alternatives for their purpose
Faith found placeholder images without descriptive alt text and added text describing a profile picture. The right alternative depends on an image’s purpose and context: an informative image needs a useful text equivalent, while a decorative image may not need a description. A generic label such as “image” does not tell a user what information the image conveys.
Associate each form label with its control
Faith connected form fields to their labels using matching for and id attributes. For an explicit association, the label’s for value must match the control’s id:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute<label for="email">Email address</label>
<input id="email" name="email" type="email">W3C WAI’s Forms Tutorial says: “A label and a form control should be associated with each other either implicitly or explicitly.” An implicit association can place a control inside its label; the explicit pattern above connects them by matching attributes. In either case, the label should identify the control’s purpose. See W3C WAI’s guidance on labeling controls.
Keep headings in a useful hierarchy
Faith discovered that a page moved from an <h1> directly to an <h3>, then repaired the sequence. Headings marked up as headings let readers navigate the document’s sections. W3C recommends nesting headings by rank and avoiding skipped ranks where possible, so the hierarchy reflects the content’s organization. A skipped numerical level does not, by itself, automatically establish a WCAG failure; the structure should be evaluated in context. W3C WAI’s headings guidance covers heading structure.
What an accessibility score can—and cannot—tell you
Faith reports that she used Chrome DevTools Lighthouse and WAVE and achieved a perfect Lighthouse accessibility score after making fixes. That is her reported outcome for her portfolio, not an independently reproduced result or evidence that every access barrier was removed.
Rank #4
Automated tools can flag issues they are designed to detect, but they do not replace appropriate manual review. W3C WAI distinguishes automated checks from manual evaluation when discussing how to select accessibility evaluation tools. A score is therefore one input: it cannot, on its own, establish whether every page, interaction, image, or form works for every user. W3C’s tool-selection guidance explains the role and limits of evaluation tools.
A practical way to apply the lessons
- Identify the page’s regions. Use elements such as
<header>,<nav>, and<main>where they accurately describe the structure and context. - Review images in context. Decide whether each image conveys information or is decorative, then provide an appropriate alternative when needed.
- Check every form control. Confirm it has a label that identifies its purpose and that the label is associated with the correct control.
- Review heading order. Mark section titles as headings and nest them by rank to communicate the document’s organization.
- Combine automated and manual evaluation. Use tools to find detectable issues, then review the experience beyond what an automated score can establish.
These checks turn Faith’s portfolio audit into reusable habits: make structure meaningful, connect controls to their labels, and evaluate the result without treating a single score as a complete verdict.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
