DEV Community: Amira Chaabane

How Don Norman's framework applies to sustainable UX and digital product design

Amira Chaabane — Thu, 26 Mar 2026 07:20:35 +0000

Don Norman coined the term "User Experience."

Then he spent his later career arguing that designers have been solving the wrong problems.

In Design for a Better World (2023), he lays out a framework called Circular Design. Here's the core of it:

The world runs on a linear model:
Take raw materials → Make products → Discard as waste.

Waste happens at every stage. Not just at the end.
Half of all waste is produced before a product is even manufactured: in mining, refining, and transportation alone.

The materials we design with take 20 to 500 years to biodegrade.
More than 1 million species are now threatened with extinction.
84% of global energy still comes from fossil fuels.

These are not environmental stats. These are design consequences.

Norman defines three types of planned obsolescence:
→ Breakdown: components fused so repair is impossible
→ Progress: new standards that make old products incompatible
→ Fashion: cosmetic changes that make the old feel outdated

And three principles of circular design to counter them:
→ Treat waste and pollution as design flaws
→ Design products to last, to be repaired, to be reused
→ Design so end-of-life materials regenerate, not degrade

These principles apply to digital products:

An app that drops OS support to push upgrades ?
That's planned obsolescence through progress.

A redesign that forces users to relearn everything ?
That's the digital equivalent of a glued-together coffee cup.

Features that pile up until the only fix is a full rebuild ?
That's take-make-waste applied to software.

It is too late to stop the damage, but it is not too late to slow it down and reverse its progress.

Full article covering the complete framework, the recycling myth, and how circular design applies to UX.

Your analytics script is the heaviest thing most visitors download

Amira Chaabane — Thu, 12 Mar 2026 06:25:50 +0000

Every time someone visits your website, their browser silently downloads a piece of JavaScript code called a tracking script. This is a small program that runs in the background, watches what the visitor does, which pages they view, where they came from, how long they stay and sends that information back to an analytics service like Google Analytics.

The visitor never sees it. They never click on it. But their browser downloads and executes it on every single page, every single visit.

Google Analytics loads roughly 45 KB of this tracking code onto every page of your website. Multiply that by your monthly traffic and the numbers stop being trivial.

This article breaks down the environmental cost of analytics tracking scripts, compares Google Analytics to the lightweight open-source alternatives that have emerged in recent years, and makes the case that switching is one of the easiest Green IT wins available to any website owner.

What your analytics script actually costs

Before we talk about the cost, it helps to understand what actually happens when a visitor lands on a page that runs Google Analytics.

When a visitor's browser loads your page, it encounters a <script> tag in your HTML that points to Google Tag Manager: a JavaScript file hosted on Google's servers at googletagmanager.com.

The browser downloads this file (~28 KB). Once executed, this script immediately fetches a second file: the Google Analytics tag from google-analytics.com (~17 KB).

Once both scripts are loaded and running, they begin collecting data:

page URL
referrer
screen size
browser
device
location
scroll depth
engagement time

…and more.

This data is then sent back to Google's servers as a series of HTTP requests. This happens on every page the visitor navigates to.

That’s roughly:

45 KB of JavaScript downloaded
two external server connections
tracking data sent back

for every page view.

Each of these steps has an energy cost.

The files must be:

transferred over the network (routers, CDNs, cell towers)
downloaded to the visitor's device
parsed and executed by the browser
followed by additional data sent back to external servers

All of this consumes electricity and computing resources.

Note

DNS lookup is how the browser translates a domain name (like googletagmanager.com) into an IP address it can connect to.

TCP connection is the handshake between the browser and the server that establishes a reliable communication channel.

TLS handshake is the encryption negotiation that happens for HTTPS connections.

Because Google Analytics uses two external domains:

googletagmanager.com
google-analytics.com

the browser performs the full:DNS → TCP → TLS

sequence twice, before a single byte of analytics data has even been collected.

For a site with 100,000 monthly page views, that's roughly 4.5 GB of analytics JavaScript transferred per month.

For a site with 1 million page views, it's 45 GB.

And that's just the tracking script.

It does not include the analytics data payloads sent back to Google's servers.

Note

These numbers assume the standard Google Tag Manager + GA4 integration, which is how most sites implement Google Analytics.

There are lighter implementations (minimal analytics scripts, self-hosted gtag), but the vast majority of websites use the default setup.

The lightweight alternatives

A new generation of analytics tools has appeared.

They share a common philosophy:

collect only what you need
use the smallest possible tracking script
respect user privacy by design

Well-known ones include:

Umami
Plausible
Fathom
Cabin
Simple Analytics

Several of these are fully open source.

What they have in common (from a Green IT perspective)

Script size

Umami: < 2 KB
Plausible: < 1 KB
Cabin: ~1.2 KB
Google Analytics (via GTM): ~45 KB

That’s roughly a 20× to 45× difference in JavaScript payload on every page view.

No third-party requests

Most lightweight alternatives either:

self-host their script
serve it from a single domain

Google Analytics requires connections to multiple Google-owned domains.

No cookies

These tools don’t use cookies, which means no cookie consent banners.

Consent banners themselves load additional:

JavaScript
CSS
modal overlays

Removing the need for them reduces page weight further.

Smaller data payloads

Lightweight analytics collect fewer data points:

page views
referrers
device type
country

Google Analytics collects hundreds of data points, including:

scroll depth
engagement time
user demographics
session data

More data means more bytes sent back to servers.

Pro Tip

Plausible calculated that replacing Google Analytics on a site with 100,000 monthly visitors saves approximately:

7 GB of data transfer per month
84 GB per year

At an estimated 0.2 kWh per GB, that’s roughly:

16.8 kWh saved annually from a single script change.

The privacy argument

This article focuses on Green IT, but privacy is closely related.

Google Analytics:

collects personal data
uses cookies
integrates with Google’s advertising ecosystem

This requires cookie consent banners under regulations such as:

GDPR (EU)
CCPA (California)

Lightweight alternatives:

collect no personal data
use no cookies
require no consent banners

They are GDPR-compliant by design.

What Devly uses

Umami, self-hosted on a VPS at OVHcloud.

Umami is open source and OVHcloud has committed to powering its data centers with 100% renewable energy by 2025, with 77% already achieved.

They have also:

signed a solar power purchase agreement with EDF Renewables
implemented proprietary liquid cooling systems
reported a PUE between 1.1 and 1.3
signed the Climate Neutral Data Centre Pact

Self-hosting matters for Green IT.

When you self-host analytics:

you control the infrastructure
you choose the hosting provider
you know where the data center is located
you can verify its energy sourcing

Note

If self-hosting isn’t an option, good managed alternatives include:

Plausible (open source, hosted on renewable-energy-powered Hetzner servers)
Cabin (100% renewable hosting with built-in carbon tracking)

The counter-argument: when Google Analytics is justified

Google Analytics exists because it solves real problems.

For example:

detailed conversion attribution
e-commerce funnel analysis
Google Ads integration
advanced audience segmentation
remarketing

Lightweight tools don’t fully replicate these capabilities.

But most websites don’t need them.

Typical sites like:

blogs
documentation sites
portfolios
small business websites
SaaS marketing pages

mostly need:

page views
referrers
top pages
basic events

For these use cases, Google Analytics is dramatically over-engineered.

How to switch

Migrating is simpler than most people expect.

Typical process:

Add the analytics <script> tag to your <head>
Verify data appears in the dashboard
Remove the Google Analytics script
Remove the cookie consent banner (if analytics was the only reason)

Pro Tip

Before removing Google Analytics, export any historical data you want to keep.

Some tools, such as Plausible Analytics, offer a Google Analytics import feature that allows you to migrate historical statistics into their dashboard.

Analytics tracking scripts are only one piece of a website’s environmental footprint but they are a uniquely wasteful one because many sites load far more analytics infrastructure than they actually need.

For more: Devly digital

A starting guide to web accessibility

Amira Chaabane — Fri, 06 Mar 2026 04:39:54 +0000

What is web accessibility really?

Web accessibility means that every person can use your website, regardless of ability, disability, device, or situation. That includes someone using a screen reader, someone navigating with only a keyboard, someone with low vision, or someone in bright sunlight trying to read their phone.

It's not an extra feature you bolt on at the end. It's a fundamental part of how the web was designed to work in the first place. The inventor of the World Wide Web, Tim Berners-Lee, said it best:

The power of the Web is in its universality. Access by everyone, regardless of disability, is an essential aspect.

Accessibility is often shortened to "a11y" in the developer community, the "11" represents the 11 letters between the "a" and the "y". You'll see this everywhere.

Who needs accessible websites?

Most developers think of accessibility as helping "people with disabilities." But it's far broader than that.

A person who is blind and uses a screen reader to navigate the web.
A person with a motor impairment who cannot use a mouse and relies entirely on a keyboard.
A person with low vision who needs to zoom in to 400% to read content.
A person with a cognitive disability who needs clear, simple language and structure.
An elderly person whose vision or motor control has declined with age.
A person in a bright environment where low-contrast text becomes unreadable.
A person on a slow mobile connection where heavy pages take forever to load.
A person temporarily injured — a broken arm means no mouse for weeks.

Accessibility features benefit everyone. Curb cuts on sidewalks were designed for wheelchair users but are also used daily by people with strollers, luggage, and bicycles. The web works the same way.

Understanding WCAG

WCAG stands for Web Content Accessibility Guidelines. It's the international standard for web accessibility, maintained by the World Wide Web Consortium (W3C). When someone says "accessible website," they almost always mean WCAG compliant.

WCAG is organized into three levels of conformance:

Level A: The minimum. Covers the most critical barriers that completely block access for some users.
Level AA: The recommended standard. Most legal requirements around the world require at least AA compliance. This is your target.
Level AAA: The gold standard. Nice to achieve where possible, but not required for most websites.

Many countries and regions have laws requiring websites to meet WCAG AA. In the EU, the European Accessibility Act applies. In the US, the Americans with Disabilities Act (ADA) has been interpreted to cover websites. Building accessibly isn't just good practice. In many cases, it's a legal requirement.

The 4 pillars of accessibility

WCAG organizes all its guidelines around four core principles. Everything you'll ever do for accessibility traces back to one of these:

Perceivable: Users must be able to perceive all information. If something is only communicated through color, or only through sound, some users will miss it entirely.
Operable: Users must be able to operate the interface. If something can only be activated with a mouse click, keyboard users are locked out.
Understandable: The content and interface must be understandable. Confusing navigation, inconsistent behavior, or unclear language creates barriers.
Robust: The content must be robust enough to be reliably interpreted by a wide variety of assistive technologies, both current and future.

Semantic HTML: the foundation

This is the single most important thing you can do for accessibility. Semantic HTML means using the right HTML elements for their intended purpose, instead of using generic elements like divs for everything.

<!-- Bad: No meaning, screen readers see nothing useful -->
<div class="header">
  <div class="nav">
    <div class="nav-link">Home</div>
    <div class="nav-link">About</div>
  </div>
</div>
<div class="main">
  <div class="title">Welcome</div>
  <div class="content">This is my website.</div>
</div>

<!-- Good: Every element tells assistive tech what it is -->
<header>
  <nav>
    <a href="/">Home</a>
    <a href="/about">About</a>
  </nav>
</header>
<main>
  <h1>Welcome</h1>
  <p>This is my website.</p>
</main>

Screen readers announce the role of elements to users. With semantic HTML, a user hears "navigation, list, 2 items" instead of just silence. This gives them a mental map of your page without ever seeing it.

Here are the key semantic elements you should know:

The top section of a page or article, usually containing branding and navigation.
A block of navigation links.
The main content of the page. Only one per page.
A self-contained piece of content, like a blog post.
A thematic grouping of content
Content that is tangentially related to the main content, like a sidebar.
The bottom section of a page or article.
h1 through h6 Headings that create a hierarchy. Never skip levels.
For actions. Never use a div or span for a clickable action.
For navigation. Never use a button for navigating to a URL.

Never use a div with an onClick handler as a button, and never use a to navigate to a different page. Screen readers announce these differently, and keyboard users expect specific behavior from each. Using them wrong breaks the experience entirely

Keyboard navigation

Every single interactive element on your website must be reachable and usable with only a keyboard. Many users; whether due to motor disabilities, power users, or assistive technology; rely entirely on the keyboard.

<!-- Bad: Only works with a mouse click -->
<div class="btn" onclick="submitForm()">Submit</div>

<!-- Good: Keyboard accessible, correct semantics -->
<button type="submit">Submit</button>

The key rules:

All interactive elements must be focusable: buttons, links, inputs, and custom components.
Focus must follow a logical order: top to bottom, left to right.
Focus must always be visible: the user must see which element is currently focused.
No keyboard traps: the user must never get stuck somewhere they can't escape with the keyboard.

/* Bad: Removing focus styles entirely */
button:focus {
  outline: none;
}

/* Good: Custom but visible focus indicator */
button:focus-visible {
  outline: 2px solid #5de8e2;
  outline-offset: 2px;
}

Never remove focus styles with outline: none without providing an alternative. This makes your website completely unusable for keyboard-only users. If you don't like the default browser outline, style it, don't remove it.

Images and alt text

Every image on your website needs an alt attribute. This is one of the most basic and most commonly violated accessibility rules.

Alt text serves two purposes: it describes the image to screen readers, and it displays as fallback text if the image fails to load.

<!-- Bad: No alt text at all -->
<img src="chart.png">

<!-- Bad: Meaningless alt text -->
<img src="chart.png" alt="image">
<img src="chart.png" alt="IMG_4732.png">

<!-- Good: Descriptive alt text -->
<img src="chart.png" alt="Bar chart showing website carbon emissions dropping 60% after optimization">

<!-- Good: Decorative images use empty alt -->
<img src="decorative-divider.png" alt="">

Color contrast

Color contrast is the difference in brightness between text and its background. If the contrast is too low, text becomes hard or impossible to read, especially for people with low vision, color blindness, or anyone in a bright environment.

WCAG AA requires:

Normal text (under 18px or 14px bold): A contrast ratio of at least 4.5:1.
Large text (18px+ or 14px+ bold): A contrast ratio of at least 3:1.
UI components and icons: A contrast ratio of at least 3:1 against adjacent colors

/* Bad: Low contrast — fails WCAG AA */
.text {
  color: #777777; /* gray text */
  background-color: #ffffff; /* white background */
}
/* Contrast ratio: 4.48:1 — just below the 4.5:1 requirement */

/* Good: Sufficient contrast — passes WCAG AA */
.text {
  color: #595959;
  background-color: #ffffff;
}
/* Contrast ratio: 7.0:1 — well above the requirement */

Never rely on color alone to convey information. For example, don't show errors in red text only. Add an icon, a label, or a pattern so that colorblind users can also understand the message.

Forms and inputs

Forms are one of the most common accessibility failure points on the web. A form that looks fine visually can be completely broken for assistive technology users.

Every input needs a proper label. Every error needs to be clearly communicated. Every required field needs to be marked.

<!-- Bad: No label, no error handling -->
<input type="email" placeholder="Enter your email">

<!-- Good: Proper label, error handling, required marking -->
<div>
  <label for="email">
    Email address
    <span aria-label="required">*</span>
  </label>
  <input
    type="email"
    id="email"
    name="email"
    required
    aria-required="true"
    aria-describedby="email-error"
  >
  <p id="email-error" role="alert" aria-live="polite">
    Please enter a valid email address.
  </p>
</div>

ARIA: when and why

ARIA stands for Accessible Rich Internet Applications. It's a set of attributes you can add to HTML to give assistive technologies extra information about your content.

But here's the critical rule: use native HTML first. ARIA is a last resort.

<!-- Bad: Using ARIA when native HTML already works -->
<div role="button" tabindex="0" aria-pressed="false">
  Submit
</div>

<!-- Good: Native HTML does this automatically -->
<button type="submit">Submit</button>

<!-- Good: ARIA used correctly — native HTML can't do this -->
<div
  role="dialog"
  aria-modal="true"
  aria-label="Confirm deletion"
>
  <p>Are you sure you want to delete this item?</p>
  <button>Cancel</button>
  <button>Delete</button>
</div>

A good rule of thumb: if a native HTML element already does what you need, use it. ARIA is for cases where native HTML falls short: like custom modals, tooltips, live regions, and complex widgets that have no HTML equivalent.

Testing your work

You cannot rely on visual inspection alone to find accessibility issues. You need a combination of automated tools and manual testing.

Automated tools: They catch roughly 30-40% of issues. Use them as a starting point, not a guarantee.
Keyboard testing: Unplug your mouse. Navigate your entire site using only Tab, Enter, Space, and arrow keys. Can you reach everything? Can you use everything?
Screen reader testing: Install a free screen reader and try using your site. NVDA (Windows) and VoiceOver (Mac/iOS) are both free and widely used.
Color contrast checkers: Tools like the WebAIM Contrast Checker let you input two colors and see if they meet WCAG ratios.
Real user feedback: If possible, ask people who use assistive technologies to test your site. Their feedback is irreplaceable.

Automated tools are helpful but limited. They cannot detect issues like confusing navigation, unclear language, or illogical reading order. Always combine automated testing with manual review.

Resources to keep learning

W3C WCAG 2.1 Guidelines: w3.org/WAI/WCAG21/Understanding The official standard. Read the "Understanding" version, it's much more approachable than the raw spec.
WebAIM: webaim.org One of the best free resources. Guides, tools, and checklists all in one place.
MDN Web Docs (Accessibility): developer.mozilla.org/en-US/docs/Web/Accessibility Solid technical reference for HTML, ARIA, and accessibility best practices.
axe DevTools: axe devtools The most popular browser extension for automated accessibility testing.
Google Lighthouse: developers.google.com/web/tools/lighthouse Built into Chrome DevTools. Gives you an accessibility score and actionable recommendations.
WebAIM Contrast Checker: webaim.org/resources/contrastchecker Instantly check if two colors meet WCAG contrast requirements.

The Skip Navigation feature makes your website more accessible

Amira Chaabane — Mon, 02 Mar 2026 07:38:04 +0000

Only 13.7% of the top million websites have a skip navigation link. Of those that do, 10% are broken. This is a feature that takes about 20 minutes to implement, costs nothing to maintain, and directly improves the experience for every keyboard user who visits your site.

So what skip navigation actually does and why it matters beyond compliance checkboxes ?

What skip navigation actually solves

Picture a typical website. There's a logo, a main navigation with 8–15 links, maybe a search bar, maybe a language switcher or a dark mode toggle. A sighted mouse user glances past all of it and clicks directly on the content they want. The whole process takes less than a second.

Now picture navigating that same page with only a keyboard. Every one of those elements: logo, nav links, search input, toggles, requires a Tab keypress to move past. On a site with 20 interactive elements before the main content, that's 20 Tab presses. On every single page. For someone using a switch device by tapping their head, or operating a mouth stick to press keys, those 20 actions aren't a minor inconvenience. They're a physical barrier.

(image caption: A mouth stick: an assistive device gripped between the teeth to press keys and interact with a computer, used by people with limited or no use of their hands.)

A skip navigation link solves this by placing an anchor link as the very first focusable element on the page. When activated, it jumps the user directly to the main content. One Tab, one Enter, done.

Note: WCAG Success Criterion 2.4.1 (Bypass Blocks) requires that websites provide a mechanism to skip repeated content blocks. This is a Level A requirement, the most basic tier of accessibility compliance. It's referenced in the ADA (US) and the European Accessibility Act. It is not optional for any public-facing website that needs to meet accessibility standards.

Why this isn't just a compliance box

The practical argument for skip links goes beyond legal requirements.

Screen reader users hear every element announced sequentially. Without a bypass mechanism, they hear the same navigation announced on every page they visit. Keyboard-only users, whether due to motor impairments, temporary injuries, or simply preference, must physically tab through every repeated element. Users with cognitive or attention differences benefit from reduced noise between them and the content they came for.

And it's not a niche audience. WebAIM's 2025 analysis of the top million home pages found an average of 51 accessibility errors per page. The web is not built for these users by default, which means every correct implementation counts.

How it works

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Page Title</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>

  <!-- Skip link: first element inside <body> -->
  <a href="#main-content" class="skip-link">
    Skip to content
  </a>

  <header>
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
      <a href="/blog">Blog</a>
      <a href="/contact">Contact</a>
    </nav>
  </header>

  <!-- Target: the main content area -->
  <main id="main-content" tabindex="-1">
    <h1>Page Heading</h1>
    <p>Your actual content starts here.</p>
  </main>

  <footer>
    <p>&copy; 2025</p>
  </footer>

</body>
</html>

Three things make this work: the skip link is the first focusable element in the DOM (it can be after the logo also), it points to an id on the main content container, and the target has tabindex="-1" so it can receive focus programmatically.

The tabindex="-1" part is critical. Without it, the element isn't focusable, the browser will scroll to it when the link is activated, but focus won't actually move there. The next Tab press would jump back to wherever focus was before (usually somewhere in the header), completely defeating the purpose.

Note: Use the semantic element as your target, not a random . This serves double duty: it's the skip link target and an ARIA landmark that screen readers can navigate to independently using their built-in landmark navigation.

The link is hidden off-screen by default and slides into view when it receives keyboard focus. When the user Tabs away, it slides back out. Mouse users never see it unless they're also using the keyboard.

.skip-link {
  position: absolute;
  top: -100%;
  left: 16px;
  z-index: 9999;
  padding: 12px 24px;
  background-color: #0a0e17;
  color: #ffffff;
  font-size: 1rem;
  font-weight: 600;
  text-decoration: none;
  border-radius: 0 0 8px 8px;
  transition: top 0.2s ease-in-out;
}

.skip-link:focus {
  top: 0;
  outline: 2px solid #ffffff;
  outline-offset: 2px;
}

Common mistakes and how to avoid them

The pattern above is simple, but there are several ways to break it. The WebAIM Million 2025 study found that 10% of existing skip links were non-functional. The following mistakes are among the most common causes of broken or ineffective skip links.

Hiding with display: none or visibility: hidden

This is the most widespread error. An element with display: none is removed from both the layout and the tab order, it cannot receive keyboard focus at all. That means you can't pair it with a :focus rule to make it appear when the user Tabs to it, because the user can never Tab to it in the first place. visibility: hidden has the same practical effect: the element takes up layout space but is removed from the tab order and invisible to assistive technology.

It is technically possible to use JavaScript to toggle display: none on and off in response to some external trigger (a keypress event, a :focus-within on a parent wrapper, etc.). But this adds unnecessary complexity for a problem that CSS positioning solves cleanly without scripting.

The same problem applies to subtler hiding techniques: setting the link to 0px width or height, making it fully transparent, or matching its color to the background. Automated testing tools flag all of these as failures.

Fix: Hide the link with CSS positioning (top: -100% or left: -9999px) so it stays in the DOM and the tab order. Bring it back into view on :focus. No JavaScript needed.

The target element isn't focusable

If the skip link points to an id on a

or without tabindex="-1", activating the link scrolls the page to that element, but focus doesn't move there. The user sees the content scroll into view, presses Tab, and focus jumps back to the header. From their perspective, the skip link did nothing.

Fix: Always add tabindex="-1" to the target element. This makes it programmatically focusable without adding it to the natural tab order.

Buried under a sticky header:

Sites often have a fixed or sticky header with position: fixed and a high z-index. When the skip link appears on focus, it renders behind the header, present in the DOM, technically visible in the layout, but completely obscured on screen. This one is particularly frustrating because the skip link works perfectly in terms of functionality (focus moves, keyboard interaction works), but sighted keyboard users can't see it.

Fix: Give the skip link a z-index value higher than your header. If your header uses z-index: 100, the skip link needs at least z-index: 101. The example CSS above uses 9999 to avoid this issue entirely.

When you might not need one

Skip links are strongly recommended, but there are contexts where they add less value. A page with very minimal navigation: a landing page with two links in the header, doesn't force keyboard users through a burdensome number of Tab stops. Adding a skip link is still good practice, but the impact is smaller.

Single-purpose pages with no repeated navigation (a login form for example) may not have content blocks to skip in the first place.

Skip navigation is one of the simplest accessibility features to implement. It's a single component, a few lines of CSS, and a tabIndex attribute. The fact that 86% of the top million websites still don't have one isn't a technical problem, it's an awareness problem.

If you're reading this and your site doesn't have a skip link yet: add one. It will take you less time than reading this article did.

DEV Community: Amira Chaabane

How Don Norman's framework applies to sustainable UX and digital product design

Your analytics script is the heaviest thing most visitors download

What your analytics script actually costs

Note

Note

The lightweight alternatives

What they have in common (from a Green IT perspective)

Script size

No third-party requests

No cookies

Smaller data payloads

Pro Tip

The privacy argument

What Devly uses

Note

The counter-argument: when Google Analytics is justified

How to switch

Pro Tip

A starting guide to web accessibility

What is web accessibility really?

Who needs accessible websites?

Understanding WCAG

The 4 pillars of accessibility

Semantic HTML: the foundation

Keyboard navigation

Images and alt text

Color contrast

Forms and inputs

ARIA: when and why

Testing your work

Resources to keep learning

The Skip Navigation feature makes your website more accessible

What skip navigation actually solves

Why this isn't just a compliance box

How it works

Common mistakes and how to avoid them

When you might not need one

Further reading