Beyond the Basics: Semantic HTML for Accessibility and SEO

When we build motion graphics portfolios or demo reels, it's tempting to treat HTML as a mere container for our visual work. We drop video embeds into generic divs, wrap navigation in a div with class='menu', and call it done. But the markup choices we make have long-term consequences—for the people who use assistive technologies, for search engines trying to understand our content, and for our own maintenance burden as sites grow. This guide is for motion graphics teams who already know basic HTML and want to understand why semantic elements matter beyond the textbook definitions, and how to apply them in real projects without getting lost in theory.

Why Semantic HTML Matters for Motion Graphics Sites

Motion graphics sites are often media-heavy, with video players, animated thumbnails, and interactive demos. When we build these with generic divs, we create a flat, meaningless structure. A screen reader user navigating a portfolio might hear 'div, div, div'—nothing that tells them where the navigation is, where the main content starts, or how to skip to the reel. Search engines, too, rely on HTML structure to infer page hierarchy and relevance. A page that uses <nav>, <main>, and <article> sends clear signals that a page built with <div id='nav'> lacks.

The core mechanism is simple: semantic elements carry inherent meaning. <nav> means 'this is a navigation block.' <figure> with <figcaption> means 'this media has a caption.' When we use these elements, we offload interpretation to browsers, assistive technologies, and crawlers—they don't need to guess. For motion graphics, where visual context is everything, semantic HTML becomes the textual backbone that makes our work accessible to people who cannot see the screen, and understandable to bots that cannot watch the video.

But there's a catch: semantic HTML is not a checklist you can tick once. It requires ongoing judgment. A <section> used incorrectly can confuse as much as a <div>. Teams often find that the first attempt at semantic markup introduces more problems than it solves—over-nesting, misplaced landmarks, or heading levels that jump from h1 to h4 without warning. The goal is not to replace every div with a semantic tag, but to build a structure that serves both human and machine readers.

For motion graphics specifically, the stakes are higher because our primary content—video—is inherently inaccessible without text alternatives. Semantic HTML provides the hooks for captions, transcripts, and audio descriptions. Without proper markup, even the best accessibility features can be invisible to assistive technology. A caption track inside a <video> element is useless if the page structure doesn't tell a screen reader that the video is the main content.

Three Approaches to Structuring Your Markup

Teams typically fall into one of three camps when approaching semantic HTML. Understanding the trade-offs helps you choose what fits your project timeline, team skill level, and long-term maintenance plan.

Approach 1: Div-Heavy with ARIA Roles

This is the most common starting point. You build with <div> and <span>, then add ARIA attributes like role='navigation' or role='main' to convey meaning. The advantage is speed—you don't need to restructure existing templates or learn new elements. The downside is fragility. ARIA roles can be forgotten, misapplied, or overridden by browser updates. A <div role='button'> does not behave like a native <button>—it won't respond to keyboard events unless you add JavaScript. For motion graphics sites with complex interactions (timeline scrubbing, playback controls), this approach often introduces more bugs than it prevents.

Approach 2: Strict Semantic Elements

Here you commit to using native HTML5 elements as much as possible: <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>. This approach is more maintainable and accessible out of the box—screen readers and browsers understand these elements natively. The challenge is that not every layout maps cleanly to a semantic element. For example, a grid of project thumbnails could be an <article> list, a <section>, or a <figure> collection. Choosing wrong can create confusion. Teams also need to handle CSS reset and browser support for older elements like <main> (which is now well-supported but was once problematic).

Approach 3: Hybrid with Progressive Enhancement

Many experienced teams use a hybrid: start with a semantic skeleton (landmarks, headings, lists) and use <div> for purely presentational grouping. For example, the page structure uses <header>, <nav>, <main>, and <footer>, but inside a project card, you might use <div class='card'> because the card itself is not a distinct section of the document outline. This approach balances accessibility and development speed. The trade-off is that it requires clear team guidelines—without them, the hybrid can drift into the div-heavy approach over time.

For most motion graphics sites, the hybrid approach is the most practical. It gives you the structural clarity of semantic elements for key landmarks while avoiding over-engineering in areas where the document outline doesn't benefit from extra nesting.

How to Evaluate Your Current Markup

Before rewriting your entire site, you need criteria to decide what to change and in what order. We recommend evaluating four dimensions: document outline, landmark coverage, interactive element semantics, and media accessibility hooks.

Document Outline

Run your page through an HTML outline checker. Does the heading hierarchy make sense? A common problem on motion graphics sites is using <h1> for the site title and <h2> for every project name, then <h3> for sub-sections—but sometimes a project page might need <h2> for the project title and <h3> for 'Credits' and 'Process.' If headings skip levels (h1 to h3) or are used purely for styling, the outline fails.

Landmark Coverage

Does your page have at least <nav>, <main>, and <footer> landmarks? For a portfolio, you might also need <aside> for a sidebar of related work. Landmarks allow screen reader users to jump directly to the content they want—essential for a site with multiple reels and case studies.

Interactive Element Semantics

Check all buttons, links, and controls. Are they native <button> or <a> elements, or are they <div> with JavaScript? Native elements provide keyboard interaction, focus management, and accessibility tree information for free. Custom controls for video playback (play, pause, scrub) should use <button> with appropriate ARIA labels if the visual design is custom.

Media Accessibility Hooks

For each video or animation, is there a <figure> with <figcaption>? Are there text alternatives—captions, transcripts, or descriptions—linked or embedded? Semantic HTML alone doesn't create accessibility, but it provides the structure that makes those features discoverable.

Score each page against these criteria. Pages with multiple failures (e.g., no landmarks, broken heading hierarchy, custom buttons) should be prioritized for rewrite. Pages that are mostly correct but have a few <div> where <nav> would fit can be fixed incrementally.

Trade-Offs in Semantic HTML Decisions

Every semantic choice involves trade-offs. Understanding them helps you avoid dogmatic decisions that hurt user experience or development velocity.

Heading Hierarchy vs. Visual Design

Designers often want a specific visual hierarchy that doesn't match the semantic outline. For example, a project title might be visually smaller than the section heading above it, but semantically it should be an <h2>. The trade-off: you can use CSS to style headings independently of their level, but that requires discipline to ensure the visual design doesn't mislead users who rely on headings for navigation. One team I read about solved this by creating a utility class that resets heading sizes, allowing them to use the correct semantic level while matching the design comp.

Landmark Overuse

Adding <section> or <article> to every block can create a cluttered document outline. Screen readers allow users to navigate by landmark, but too many landmarks become noise. A good rule of thumb: use <section> only when the content has a natural heading and forms a distinct part of the document. For a grid of thumbnails, a single <section> with an <h2> for 'Projects' is better than wrapping each thumbnail in its own <section>.

ARIA vs. Native HTML

ARIA should be a last resort, not a first choice. Native HTML elements have built-in keyboard interaction, focus management, and accessibility tree mappings. Adding role='tablist' to a set of <div> elements requires you to implement keyboard navigation, focus management, and ARIA states manually—work that a native <tab> element would handle. The trade-off is that native elements sometimes have limited styling flexibility. For motion graphics sites, where visual polish is paramount, you may need to choose between custom-styled native elements (which can be done with CSS) or fully custom ARIA widgets (which require more development and testing).

Video Caption Placement

Should captions be embedded in the video file, provided via WebVTT track, or rendered as HTML overlays? Each approach has trade-offs. Embedded captions are simplest for the developer but cannot be styled or searched. WebVTT tracks are standard and accessible but require browser support. HTML overlays give full design control but need JavaScript to sync with playback. For a motion graphics portfolio, HTML overlays might be overkill—WebVTT is usually sufficient and more maintainable.

Implementing Semantic HTML in Your Workflow

Once you've decided to improve your markup, the implementation path matters. A full rewrite is rarely necessary; incremental improvements yield better results with less risk.

Step 1: Audit and Prioritize

Run an automated accessibility checker (like axe or WAVE) on your top 5 pages. Note the issues related to semantics: missing landmarks, heading level errors, non-semantic buttons. Prioritize pages that get the most traffic or are entry points (homepage, featured project pages).

Step 2: Fix Landmarks First

Add <nav>, <main>, and <footer> to every page. These are low-risk changes that immediately improve navigation for assistive technology users. If your site uses a template, update the template once.

Step 3: Correct Heading Hierarchy

Review each page's heading structure. Ensure there is exactly one <h1> (usually the page title or site name), and that subsequent headings follow a logical order without skipping levels. This may require renaming CSS classes to decouple visual style from semantic level.

Step 4: Replace Custom Interactive Elements

Identify any <div> or <span> that acts as a button, link, or tab. Replace with native <button> or <a>, then restyle with CSS. Test keyboard interaction—native buttons are focusable and activatable with Enter/Space by default.

Step 5: Add Semantic Media Containers

Wrap each video or animation in <figure> with a <figcaption>. If the video has a transcript, link to it from the caption or from a <details> element nearby. This provides context for users who cannot see the video.

Step 6: Test with Real Assistive Technology

Use a screen reader (like NVDA or VoiceOver) to navigate your site. Listen to how the page is announced. Does the screen reader announce 'navigation landmark' when you enter the menu? Does it read headings in order? This hands-on test reveals issues that automated tools miss.

Throughout this process, keep a changelog. Note which elements you changed and why. This documentation helps future team members understand the decisions and avoid reverting semantic improvements during redesigns.

Risks of Ignoring Semantic HTML

Choosing not to invest in semantic HTML carries real risks—not just for users with disabilities, but for your site's long-term health and discoverability.

Accessibility Lawsuits and Compliance

While we are not lawyers, it is general information that accessibility lawsuits have increased in many jurisdictions. A site that fails basic semantic structure (no landmarks, broken headings, non-semantic buttons) is more likely to be non-compliant with standards like WCAG 2.1. For a professional motion graphics studio, an inaccessible portfolio can damage reputation and limit client opportunities, especially when bidding for government or education contracts that require accessibility.

SEO Degradation

Search engines use HTML structure to understand page content. A page with no <nav> or <main> gives crawlers less context about which parts of the page are important. While semantic HTML alone won't boost rankings dramatically, it is a foundation that other SEO efforts (structured data, content quality) build upon. In competitive niches like motion graphics, every signal matters.

Maintenance Nightmares

Non-semantic markup tends to accumulate over time. A div-based navigation might work fine initially, but as the site grows, developers add nested divs for styling, JavaScript hooks, and analytics. Eventually, the navigation becomes a tangled mess of divs with multiple classes and IDs. Semantic elements like <nav> provide a clear, single-purpose container that resists this bloat.

Excluding Users

The most direct risk is excluding people. A motion graphics artist's work should be seen by as many people as possible. If your site is inaccessible to screen reader users, people with motor disabilities who cannot use a mouse, or users who rely on keyboard navigation, you are turning away potential clients, collaborators, and fans. Semantic HTML is one of the simplest ways to reduce those barriers.

Teams often underestimate how many users benefit from semantic structure. It's not just screen reader users—people with temporary impairments (like a broken arm), older users, and users on mobile devices all benefit from clear, keyboard-accessible navigation and well-structured content.

Frequently Asked Questions

Do I need to use semantic HTML on every page?

Yes, but the depth can vary. A simple contact page might only need landmarks and a heading hierarchy. A project case study with video, credits, and process steps benefits from more granular semantic elements like <article>, <section>, and <figure>. Focus on the pages that carry the most weight for your site's purpose.

Will semantic HTML break my CSS?

It can, if your CSS relies on element selectors like div.nav instead of classes. Using semantic elements often requires updating selectors to target classes or the new elements directly. The fix is straightforward: use class-based selectors (e.g., .nav instead of div.nav) and apply them to the semantic element. This is a good practice anyway, as it decouples styling from element type.

What about older browsers that don't support HTML5 elements?

All modern browsers support HTML5 elements. For very old browsers (IE 8 and below), you can use a simple JavaScript shim (like html5shiv) to make them styleable. However, the number of users on such browsers is negligible for most motion graphics sites. The accessibility benefits far outweigh the edge-case compatibility cost.

Can I use ARIA instead of semantic HTML?

ARIA can supplement semantic HTML, but it should not replace it. Native semantic elements provide behavior that ARIA cannot fully replicate—like keyboard interaction for buttons or the document outline for headings. Use ARIA to add extra information (e.g., aria-label on a <nav> to distinguish multiple navigation landmarks) rather than to create semantics from scratch.

How do I handle video captions semantically?

Use the <track> element inside <video> for captions. Provide a link to the full transcript near the video, ideally within a <figure> that also contains the video. For animated GIFs or CSS animations, include a text description in the surrounding content or as an alt attribute if using <img>.

Practical Recommendations for Your Next Project

After reading this guide, you might feel overwhelmed by the number of potential changes. That's normal. The key is to start small and build momentum. Here are three specific actions you can take this week:

1. Audit one page. Pick your most-visited project page. Run it through an HTML outline checker and an accessibility tool. Write down three semantic issues you find. Fix them—even if it's just adding a <nav> landmark and correcting the heading hierarchy.

2. Create a template checklist. For your next new page or redesign, include semantic HTML requirements in your project checklist. Items like 'landmarks present,' 'headings in order,' and 'buttons are native' should be checked before launch.

3. Test with a screen reader. Spend 15 minutes navigating your site with VoiceOver (macOS) or NVDA (Windows). Listen for how your content is announced. You'll likely discover issues that no automated tool caught—and you'll gain empathy for users who rely on these tools every day.

Semantic HTML is not a one-time fix; it's a practice that grows with your site. The motion graphics community values craft and precision in visual work—applying that same care to the underlying code makes your work accessible to everyone, now and in the future.