Build Smarter: SEO, Accessibility, Performance & Best Practices for Designers and Developers

Introduction: Build Smarter Not Just Prettier

In today’s web landscape, building a beautiful site or product is only half the job. The real challenge? Making sure it’s discoverable, inclusive, and fast for everyone.

Whether you're using a no-code tool like Framer, Webflow, or Wix, or you're hand-coding your site or product from scratch, this guide will walk you through the essential practices that elevate your work from “looks good” to “works brilliantly.”

I’ll share the exact steps I took to optimize my own website from semantic structure to alt text, ARIA labels, and performance tuning all backed by real results. My site consistently scores 90%+ across SEO, accessibility, and performance audits using tools like Google Lighthouse and PageSpeed Insights.

What You’ll Learn

How to structure your site or product using semantic HTML for accessibility, SEO, and audit success

• How to write alt text and use ARIA labels that genuinely improve screen reader experiences

• How to design with mobile-first principles using stacks, flexible units (fr, vh, %), and responsive layout techniques in Framer/Webflow

• How to balance visual effects like blurs and animations with performance — especially on mobile and low-powered devices

• How to write effective page titles and meta descriptions that improve discoverability and reflect your personal brand

• How to compress and serve images and videos efficiently for faster load times and better user experience

• How to structure headings semantically (<h1> → <h2> → <h3>) while maintaining visual hierarchy

• How to make SVGs and icon links accessible using aria-hidden, hidden text, and proper labeling techniques

• How to audit your site using tools like Google Lighthouse and PageSpeed Insights, and consistently score 95%+ across SEO, accessibility, Best practices and performance

Real Results

Here’s a screenshot from PageSpeed Insights showing my site’s audit scores:

• Accessibility: 100

• SEO: 100%

• Performance: 95%

• Best Practices: 95%

These scores reflect more than just technical wins they show that your site or product is built with care, clarity, and consideration for every visitor.

Section 2: Semantic HTML Building Meaningful Structure

Before you worry about keywords or screen reader labels, your site needs a solid foundation: semantic HTML. This means using the right tags for the right purpose not just for styling, but for meaning.

Whether you're using a visual builder or writing code, semantic structure helps:

• Search engines understand your content hierarchy

• Screen readers navigate your site efficiently

• Audits (like Lighthouse) recognize your layout as accessible

Semantic HTML - Structuring for Meaning, Accessibility, and SEO

Before diving into keywords or screen reader labels, your site needs a solid foundation: semantic HTML. This means using the right tags for the right purpose - not just for styling, but for meaning. Whether you're using a visual builder or writing code, semantic structure helps search engines understand your content hierarchy, screen readers navigate efficiently, and audits like Lighthouse recognize your layout as accessible.

HTML5 provides landmark elements that define your layout:

• <header> for top-level branding or intro

• <nav> for site-wide or section-specific navigation

• <main> for the unique content of the page

• <section> for thematic grouping

• <article> for self-contained content like blog posts

• <footer> for closing info, links, or contact

To use these effectively:

• Keep <nav> and <footer> outside <main> — they’re independent landmarks, while <main> should contain only the page’s unique content. Placing <nav> or <footer> inside <main> breaks landmark logic.

  

• Use proper semantic tags as recommended in accessibility guidelines, such as using only one <main> tag per page. Avoid relying on <div> elements for layout; instead, use meaningful tags like <section> for all sections inside the main tag, such as the hero section, projects, etc. Use semantic tag like <section>, and others to group content appropriately for accessibility.

  

  
  

  If you don’t find the Accessibility tab for a component used on a page, you’ll need to go to the Component Canvas.

  

• Use headings in logical order (<h1> → <h2> → <h3>) — don’t skip levels just because a heading looks visually too large or small. Instead, maintain semantic hierarchy and style your headings with CSS to match your design. Using <h4> just because it “looks right” is misleading - it’s better to style a <h2> to appear like an <h4> while preserving structure. In my layout, headings are tagged semantically (<h2>, <h3>) and styled visually to fit the design.

  

  
  

• Some people use a visually large callout alongside a heading and mistakenly mark both as headings — but this is incorrect. Screen readers rely on semantic structure, not visual size. Even if the heading (e.g., “Recommendation”) is smaller than the callout, it should be marked as <h1>, while the callout — though visually prominent as it should be tagged as <p> in accessibility settings. This ensures the heading is read first, preserving the correct reading order and improving accessibility.

  

  
  

Section 3: Alt Text - Writing Descriptions That Actually Help

Alt text isn’t just a checkbox for accessibility audits it’s a way to make your visuals meaningful to everyone. Whether your image is a portfolio thumbnail, a UI mockup, or a decorative background, writing thoughtful alt text helps:

• Screen reader users understand what’s on the page

• Search engines index your images correctly

• Your site pass accessibility audits like Google Lighthouse and WCAG

  
  

What Makes Good Alt Text?

A great alt text is:

• Descriptive: What is the image showing?

• Contextual: Why is it there?

• Concise: Usually under 125 characters

• Keyword-aware: Includes relevant terms naturally (not stuffed)

Best Practices

• Describe the image’s purpose, not just its content Example: ✅ “IRCTC UI redesign cover image” ❌ “Screenshot” or “Thumbnail”

• Use natural phrasing ✅ “Restaurant landing page with minimal UI — above-the-fold section” ❌ “Minimal UI restaurant landing page fold part”

• Avoid redundancy Don’t say “Image of…” as screen readers already know it’s an image.

• Decorative images? Use alt="" If the image is purely visual (like a blur or background), leave the alt empty so screen readers skip it.

  
  

Common Mistakes

• Using vague labels like “Thumbnail” or “Logo”

• Misspelling key terms (e.g., “minimal” instead of “minimal”)

• Stuffing keywords unnaturally

• Skipping alt text entirely

Section 4: ARIA Label When to Use and When Not To

aria-label is a powerful tool for improving accessibility, but it should be used only when necessary. Overusing or misapplying it can confuse screen readers, override helpful content, and create redundant or broken experiences.

When to Use aria-label

• Icons or SVGs inside links or buttons with no visible text Helps screen readers announce the purpose of the element.

• Interactive elements that rely solely on visuals For example, a button with only an icon should have an aria-label.

  
  

  

• Multiple landmarks of the same type If you have more than one <nav>, <section>, or <main>, use aria-label to distinguish them (e.g., "Main navigation" vs "Footer navigation").

• Unlabeled form controls If a form input has no visible label, use aria-label to describe its purpose.

When Not to Use aria-label

• Visible text already exists If a button, link, or form field has clear visible text, screen readers will read it. Adding aria-label is unnecessary and may override that text.

• Semantic HTML is sufficient Tags like <main>, <header>, <footer>, and <nav> are recognized by screen readers. Use aria-label only if there are multiple instances.

• Form inputs are correctly labeled with <label> If a field is linked to a visible label, don’t add aria-labelas it can conflict or override the label.

• Referencing existing content with aria-labelledby Prefer aria-labelledby when pointing to another element for context as it preserves visible labels and improves clarity.

• Sections with headings If a <section> contains a heading (<h2>, <h3>, etc.), screen readers use that as the label. You don’t need to add aria-label.

  

Section 5: SVGs and Icons — Making Visual Elements Accessible

Why SVGs Need Special Attention

Unlike regular images, SVGs don’t use alt attributes. Instead, accessibility depends on how they’re embedded and labeled. If your icon is inside a link or button, it must have a clear label either visible or via ARIA.

Best Practices

• Decorative SVGs If the icon is purely visual (e.g., a background shape or flair), use css or use aria-hidden = "true":

  <svg aria-hidden="true" ...></svg>

• Meaningful SVGs (e.g., social icons) Add an aria-label to the parent <a> tag:

  <a href="..." aria-label="Visit my LinkedIn profile">
    <svg aria-hidden="true">...</svg>
  </a>

• Avoid relying on <title> inside SVGs It’s not consistently supported across screen readers.

• Use visually hidden text if needed If your builder doesn’t support ARIA labels, add a hidden <span> inside the link:

  <a href="...">
    <svg aria-hidden="true">...</svg>
    <span class="visually-hidden">Visit my LinkedIn profile</span>
  </a>

This setup also helps resolve a common accessibility audit warning:

“Links do not have a discernible name”

A frequent issue with SVG-based links. The full solution is covered in this blog post (under writing will update soon).

Section 6: Performance Tips : Blurs, Animations, and Z-Index Done Right

A fast website isn’t just good for SEO it’s essential for user experience. But modern design tools make it easy to overload your site with effects that look stunning but silently degrade performance, especially on mobile and low-powered devices.

Visual flourishes like blurs, animations, and fixed backgrounds can be deceptively heavy. High blur values (e.g., blur(60px)) are GPU-intensive, requiring real-time pixel recalculation. Looping animations force continuous repainting, especially when using transform, opacity, or filter. Fixed backgrounds increase compositing cost — and when layered with animated elements, they can compound rendering load even further.

Best Practices for Visual Performance

Modern websites need to look great and run smoothly - especially on mobile, where most users still browse first. In Framer and Webflow, it’s easy to overuse effects or rely on fixed layouts that feel slick on desktop but lag on phones. Here's how to keep things performant and responsive:

Optimize Blurs and Animations

• Use lower blur values like blur(20px) or blur(30px) to reduce GPU load.

• Pre-render decorative blurs as static PNGs instead of live CSS filters.

• Stretch animation durations (e.g., 10s, 20s) to reduce frame churn.

• Apply will-change: transform, opacity to hint GPU acceleration.

• Prefer “appear” animations for above-the-fold content over scroll-based triggers.

• Avoid excessive tickers or auto-scrolling text- they strain rendering and distract users.

Optimize Images and Media

• Use 1x images at display size to prevent unnecessary scaling and reduce memory usage.

• Compress images with tools like TinyPNG or ImageCompressor to reduce file size without visible loss.

• Choose videos over GIFs and compress them, as they compress better, are easier to control, and consume less memory.

Responsive Layouts (Mobile-First)

• Design mobile-first Start with the smallest screen and scale up most users still browse on mobile first.

• Use stacks and auto layout In Framer, Webflow, Figmasites, Wix or whatever tool you are using, also use vertical/horizontal stacks with gap spacing instead of manual positioning.

• Avoid fixed widths and pixel-perfect layouts Don’t use width: 1440px or fixed px values. Use fr, %, or minmax() for flexible grids.

• Use vh and vw units wisely Great for full-screen sections, but test across devices to avoid overflow or cutoff issues.

• Test across breakpoints Preview on mobile, tablet, and desktop and simulate low-end devices when possible.

• Avoid position: fixed for full-page elements It can cause layout issues and performance lag on mobile.

• Built layouts that hold up at 200% zoom because many newer devices now default to high zoom for better legibility. Also used the overflow property wisely to prevent clipping, hidden content, or scroll traps at high zoom levels.

Common Mistakes to Avoid

• Animating too many layers at once

• Ignoring mobile performance or skipping breakpoint testing

• Overusing fixed backgrounds with layered effects

• Using opacity: 0 to hide accessible content (use .visually-hidden instead)

Section 7: SEO Titles, Descriptions, and On-Page Best Practices

Good SEO isn’t just about keywords it’s about clarity, structure, and relevance. Here are the essentials to get right on every page:

Page Titles and Meta Descriptions

• Use a unique <title> for every page: Keep it under 60 characters and include your primary keyword naturally.

• Write compelling meta descriptions: Aim for 150–160 characters. Summarize the page clearly and include a call to action if relevant.

• Avoid duplication Don’t reuse the same title or description across multiple pages it confuses search engines and weakens ranking.

• Examples:

  Page Type	Bad Title	Problem	Good Title
  Home page	Home Sweet Home	Too personal, not professional	Mehul Varshney — Product Designer & Sr. UI/UX Specialist at Hogwarts
  Contact	Chat With Me	Casual, unclear intent	Contact Mehul Varshney — Collaborations, Freelance & Design Inquiries
  Project	Art Stuff I Made	Wrong keyword, unclear purpose	Mehul Varshney — UI/UX Projects & Case Studies
  About	Who Am I?	(philosophical, lacks identity clarity	About Mehul Varshney — My Design Philosophy, Values & Journey

Note: Page titles should reflect your personal brand and tone. While these examples follow SEO best practices, feel free to tweak yours based on how you want to present yourself - whether professional, playful, philosophical, or artistic.

On-Page Structure

Some points are already covered above but there is a overlap hence I mentioned again:

• Use one <h1> per page This should describe the main topic. Follow with <h2>, <h3>, etc. in order.

• Include keywords in headings and body text Naturally no stuffing. Example: “This minimalist restaurant UI focuses on clean navigation and mobile-first design.”

• Use semantic HTML Tags like <main>, <article>, <section>, and <nav> help search engines understand layout and content hierarchy. Example is already in first section.

• Add alt text to images Descriptive and keyword-aware, but not forced.

Technical Tips

• Use clean URLs — short, readable, and keyword-friendly.

• Right example: https://yourdomain.com/work/helping-a-platform-to-hire-helpers

• Wrong Example: https://yourdomain.com/Work/Helping%20A%20Platfo%20to%20Hire%20Helpers?ref=123&session=abc

• Set canonical tags Prevent duplicate content issues.

Final Checklist + Conclusion

You’ve made it through the essential pillars of building a site or product that’s not just beautiful — but searchable, inclusive, and high-performing. Whether you’re using a no-code builder or writing code by hand, these practices apply across the board.

Here’s a quick checklist to help you audit your own site:

Final SEO & Accessibility Checklist

Structure

• Semantic HTML tags used correctly (<main>, <nav>, <footer>, etc.)

• Headings follow a logical order (<h1> → <h2> → <h3>)

• Only one <h1> per page — clearly describes the page’s main topic

• Headings are styled visually but tagged semantically (don’t skip levels for design reasons)

Images

• Alt text is descriptive, contextual, and concise

• Decorative images use alt="" to be skipped by screen readers

• Images are compressed using tools like TinyPNG, Squoosh, or ImageCompressor

• Images are served at display size (1x) to avoid scaling and memory waste

Icons & SVGs

• SVGs marked as aria-hidden="true" if decorative

• Links with icons have aria-label or hidden text for screen readers

• Avoid relying on <title> inside SVGs — use hidden <span> or ARIA labels instead

Social Links

• Each link has a discernible name (not just an icon)

• Visually hidden labels used where needed for screen reader clarity

Videos

• YouTube embeds have visible or hidden labels

• Captions or headings provide context for screen readers

• Videos are compressed for web — use formats like MP4 with optimized bitrate

• Prefer videos over GIFs for performance and accessibility control

Performance

• Blur values and animations optimized for mobile (blur(20px) or blur(30px)) or better use .pngs of blurs exported b figma.

• will-change used for smoother transitions

• Fixed backgrounds used sparingly to reduce compositing cost

• Animation durations stretched (e.g., 10s, 20s) to reduce frame churn

• Avoid scroll-based triggers for above-the-fold content — use “appear” animations

• Test across breakpoints and simulate low-end devices for layout and speed

Conclusion: Build Smarter, Reach Everyone

Design isn’t just about how things look — it’s about how they work, how they feel, and who they include. By optimizing for accessibility, performance, and SEO, you’re not just improving metrics — you’re creating experiences that welcome everyone.

Whether you’re building in Framer, Webflow, Wordpress, FigmaSites or writing code by hand, these practices help you go beyond aesthetics. They help you build with intention.

So the next time you launch a page, ask yourself: Does it look good? Does it work well? Does it work for everyone?

If the answer is yes, you’re not just designing. You’re designing responsibly.

Found this useful? Share it with someone who’s building too and tag me if you do. Let’s raise the bar together.