Web Accessibility: Design for Everyone

Eylül ÖzkayaApril 11, 20266 min read

Web Accessibility: Design for Everyone

Web Accessibility: Design for Everyone

Tim Berners-Lee, the founder of the web, said: "The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect."

That statement is from 1997. Nearly 30 years have passed and most websites still can't be used by everyone.

Accessibility isn't a luxury — it's a fundamental right. And it affects far more people than you think.


Who Does Accessibility Affect?

According to the World Health Organization, approximately 16% of the world's population lives with some form of disability.

But accessibility isn't limited to permanent disability conditions:

  • Permanent: Visual impairment, hearing impairment, motor disability
  • Temporary: Broken arm, post-eye surgery, migraine
  • Situational: Looking at a screen in sunlight, holding a baby, watching video in a noisy environment

All of us benefit from accessibility features at some point in our lives. Elevators aren't just for wheelchair users — everyone with heavy luggage uses them.

Web accessibility is the same way.


WCAG: What Is the Standard?

Web Content Accessibility Guidelines (WCAG) are the international accessibility standard set by the W3C. The current version is WCAG 2.2.

Conformance Levels

  • A: Minimum level. Without this, the site is completely inaccessible to some users.
  • AA: Recommended level. Most legal requirements target this.
  • AAA: Highest level. May not be practical for every situation but valuable as a goal.

Our target is AA level in every project. This is a realistic and effective goal.

POUR Principles

WCAG is built on four fundamental principles:

Perceivable: Content must be presented in a way users can perceive. Visual information shouldn't only be visual — alternative formats should exist.

Operable: Interface components must be usable. Not only with a mouse, but also with a keyboard. Not only with touch, but also with assistive technologies.

Understandable: Content and interface must be understandable. Language should be clear, behavior should be predictable.

Robust: Content must be reliably interpreted by different technologies and assistive tools.


Practical Applications

Theory is nice but what gets done in practice? Here are the fundamental rules that should be applied in every web project.

Color Contrast

There must be sufficient contrast between text and background. WCAG AA requirements:

  • Normal text (16px and below): Minimum 4.5:1 contrast ratio
  • Large text (18px+ bold or 24px+): Minimum 3:1 contrast ratio

Light gray text on a white background might look elegant — but it's unreadable. Design aesthetics should never override readability.

Check tool: Your browser's DevTools contrast checker or online contrast checker tools.

Alt Text

Every meaningful image should have alt text.

Good alt text:

<img src="team.jpg" alt="Novexing team having a design meeting in the office">

Bad alt text:

<img src="team.jpg" alt="image">
<img src="team.jpg" alt="team.jpg">
<img src="team.jpg" alt="">  <!-- Should not be empty if not decorative -->

Rule: Alt text describes what the image shows, not the file name. For decorative images (background patterns, separator lines), empty alt text (alt="") is used.

Keyboard Navigation

All interactive elements must be accessible via keyboard:

  • Tab: Move to next element
  • Shift + Tab: Return to previous element
  • Enter / Space: Press button, click link
  • Escape: Close modal, close dropdown

The test method is simple: set your mouse aside and try to use your site with only the keyboard. If you get stuck somewhere, your users are getting stuck too.

Semantic HTML

HTML tags carry meaning. Using this meaning correctly is the foundation of accessibility.

<!-- Bad: Divs everywhere -->
<div class="header">
  <div class="nav">
    <div class="link" onclick="navigate()">About Us</div>
  </div>
</div>

<!-- Good: Semantic tags -->
<header>
  <nav>
    <a href="/about">About Us</a>
  </nav>
</header>

Screen readers read the <nav> tag as "navigation." They read the <div> tag as nothing.

Essential semantic tags: <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <button>, <a>, <h1>-<h6>.

ARIA Labels

ARIA (Accessible Rich Internet Applications) adds accessibility information where HTML falls short.

Rule: ARIA should be a last resort. First use the correct HTML tag. If HTML isn't sufficient, then add ARIA.

<!-- No ARIA needed — correct HTML is sufficient -->
<button>Open Menu</button>

<!-- ARIA needed — custom component -->
<div role="tablist">
  <button role="tab" aria-selected="true">Tab 1</button>
  <button role="tab" aria-selected="false">Tab 2</button>
</div>

Commonly used ARIA attributes:

  • aria-label: Non-visual label
  • aria-expanded: Dropdown menu state
  • aria-hidden: Hide from screen readers
  • aria-live: Dynamic content notification

Focus Management

Users navigating with a keyboard should see which element is active.

/* Bad: Removing focus indicator */
*:focus { outline: none; }

/* Good: Custom focus style */
:focus-visible {
  outline: 3px solid #E5442C;
  outline-offset: 2px;
}

Using :focus-visible is important — it doesn't show on mouse clicks, but shows on keyboard navigation.

Form Accessibility

Forms are the areas that contain the most accessibility errors.

<!-- Every input should have a label -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" required>

<!-- Error messages should be programmatically linked -->
<input type="email" id="email" aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email</span>

Rules:

  • Every input must have a <label> tag
  • Placeholder should not be used instead of label
  • Error messages should be clear and helpful
  • Required fields should be indicated (required + visual indicator)

Accessibility and SEO Relationship

Accessibility and SEO overlap in many areas. Improving one also improves the other.

Semantic HTML = Better Indexing

Search engines also try to understand page structure like screen readers. Tags like <h1>, <h2>, <nav>, <main> clarify the page structure.

Alt Text = Image Search

Google Images uses alt text to index images. Good alt text brings traffic from image search.

Heading Hierarchy = Content Structure

<h1> to <h2> to <h3> hierarchy determines page structure for both screen readers and search engines. Skipping headings (jumping from h1 to h3) is problematic for both.

Fast and Light Pages = Good for Everyone

Performance optimization is critical for both accessibility and SEO. Slow pages lose low-bandwidth users as well as search engines.


Testing

You can't claim to be "compliant" without testing accessibility.

Automated Scanning

Automated tools catch approximately 30-40% of issues. Good for a start but not sufficient on its own.

  • Browser DevTools: Chrome and Firefox's built-in accessibility audit
  • Lighthouse: Google's performance and accessibility scanning tool
  • axe DevTools: Detailed accessibility analysis

Manual Testing

Finds issues that automated tools can't catch.

  • Keyboard test: Try using the site with only the keyboard
  • Zoom test: Enlarge the page to 200% — is everything still usable?
  • Color test: Convert the page to grayscale — is information still understandable?

Screen Reader Testing

The best way to understand the real user experience.

  • VoiceOver: Built into macOS and iOS
  • NVDA: Free screen reader for Windows
  • TalkBack: Built into Android

On your first try, attempt to use your site with a screen reader. You'll likely be surprised — you'll realize many things are inaccessible.


Where to Start?

Making an existing site fully accessible can seem like a big job. But you don't have to do everything at once.

Priority Order

  1. Contrast fixes — Fastest impact, easiest implementation
  2. Add alt text — Meaningful descriptions for every image
  3. Keyboard navigation — Logical tab order
  4. Semantic HTML — Correct tags instead of divs
  5. Form accessibility — Labels, error messages, required field notifications
  6. ARIA — Final touches for custom components

Each step makes a difference on its own. Aim for progress, not perfection.


Conclusion

Accessibility isn't an "extra feature." It's an integral part of quality web development.

An accessible site performs better in SEO, reaches a wider audience, is more usable, and reduces legal risks.

A website that leaves everyone out is a website that's incomplete for everyone. Design's job isn't to look beautiful — it's to work for everyone.

Share
About the author
Eylül Özkaya
Eylül ÖzkayaCo-Founder & Creative Director

Expert in UI/UX design, atomic design systems, corporate identity, and illustration. Leads the creative vision of Novexing.