DEV Community

Cover image for Frontend Accessibility: Building Web Interfaces Everyone Can Use
Abanoub Kerols
Abanoub Kerols

Posted on

Frontend Accessibility: Building Web Interfaces Everyone Can Use

#a11y #webdev #frontend


Accessibility is not a feature that you add at the end of a project.

It is a fundamental part of frontend development.

A website can look beautiful, have excellent performance, and work perfectly for most users — while still being extremely difficult or even impossible to use for people with disabilities.

This is where Web Accessibility (a11y) comes in.

Accessibility means designing and developing websites and applications that can be used by as many people as possible, including people who:

  • Use screen readers
  • Navigate using only a keyboard
  • Have visual impairments
  • Have hearing impairments
  • Have motor disabilities
  • Have cognitive or learning disabilities
  • Have temporary disabilities
  • Use mobile devices or slow connections
  • Interact with websites in unusual environments

In this article, we'll explore frontend accessibility from the fundamentals to practical implementation.

Table of Contents

  1. What Is Web Accessibility?
  2. Why Accessibility Matters
  3. Understanding A11y
  4. The Four Principles of WCAG
  5. Semantic HTML
  6. Headings and Document Structure
  7. Accessible Links
  8. Accessible Buttons
  9. Keyboard Accessibility
  10. Focus Management
  11. Forms and Labels
  12. Error Messages
  13. Images and Alternative Text
  14. Color and Contrast
  15. Don't Use Color Alone
  16. Accessible Modals
  17. ARIA
  18. When NOT to Use ARIA
  19. Screen Readers
  20. Accessible Navigation
  21. Tables
  22. Dynamic Content
  23. Live Regions
  24. Reduced Motion
  25. Responsive Accessibility
  26. Common Accessibility Mistakes
  27. Testing Accessibility
  28. Automated Testing
  29. Manual Testing
  30. Accessibility Checklist
  31. Accessibility in Modern Frontend Frameworks
  32. Final Thoughts

1. What Is Web Accessibility?

Web accessibility is the practice of making websites and web applications usable by people with different abilities.

Consider this button:

<div class="button">
  Submit
</div>
Enter fullscreen mode Exit fullscreen mode

It looks like a button.

But semantically, it isn't a button.

A screen reader may not identify it as an interactive control, and a keyboard user may not be able to focus or activate it.

Now compare it with:

<button type="submit">
  Submit
</button>
Enter fullscreen mode Exit fullscreen mode

The second version automatically provides important browser behavior:

  • Keyboard interaction
  • Focusability
  • Button semantics
  • Screen reader information
  • Form integration

This is one of the most important ideas in accessibility:

Use native HTML elements whenever possible.

2. Why Accessibility Matters

Accessibility is not only about disabilities.

Imagine you're using your laptop with a broken mouse.

You now depend on the keyboard.

Or you're outside in bright sunlight.

Your screen becomes difficult to read.

Or you're holding your baby with one hand.

Your ability to interact with the interface is temporarily limited.

Accessibility helps in all of these situations.

It also improves:

  • Usability
  • Maintainability
  • Semantic structure
  • SEO
  • Keyboard navigation
  • Screen-reader compatibility
  • Overall user experience

Accessibility is therefore not just a compliance requirement.

It's good frontend engineering.

3. Understanding A11y

You may see the term:

a11y

Why?

The word:

Accessibility
Enter fullscreen mode Exit fullscreen mode

starts with:

A
Enter fullscreen mode Exit fullscreen mode

and ends with:

y
Enter fullscreen mode Exit fullscreen mode

There are 11 characters between them.

Therefore:

A + 11 + y = a11y
Enter fullscreen mode Exit fullscreen mode

You'll frequently see developers use a11y as shorthand for accessibility.

4. The Four Principles of WCAG

The Web Content Accessibility Guidelines (WCAG) organize accessibility around four fundamental principles.

A website should be:

1. Perceivable

Users must be able to perceive the information.

Examples:

  • Text alternatives for images
  • Captions for videos
  • Sufficient color contrast

2. Operable

Users must be able to interact with the interface.

Examples:

  • Keyboard navigation
  • Accessible buttons
  • Visible focus indicators
  • Enough time to complete interactions

3. Understandable

Users should be able to understand the content and interface.

Examples:

  • Clear labels
  • Consistent navigation
  • Useful error messages
  • Predictable behavior

4. Robust

Content should work with different browsers, assistive technologies, and user agents.

This is where semantic HTML becomes extremely important.

5. Semantic HTML

Semantic HTML means choosing HTML elements according to their meaning.

Bad:

<div onclick="submitForm()">
  Submit
</div>
Enter fullscreen mode Exit fullscreen mode

Better:

<button onclick="submitForm()">
  Submit
</button>
Enter fullscreen mode Exit fullscreen mode

Bad:

<div class="navigation">
Enter fullscreen mode Exit fullscreen mode

Better:

<nav>
Enter fullscreen mode Exit fullscreen mode

Bad:

<div class="article">
Enter fullscreen mode Exit fullscreen mode

Better:

<article>
Enter fullscreen mode Exit fullscreen mode

Semantic HTML gives browsers and assistive technologies useful information about the structure of your application.

Common semantic elements include:

<header>
<nav>
<main>
<section>
<article>
<aside>
<footer>
<button>
<form>
<label>
<table>
Enter fullscreen mode Exit fullscreen mode

Before reaching for ARIA, ask:

Can native HTML solve this problem?

Very often, the answer is yes.

6. Headings and Document Structure

Headings are not just visual styles.

They create a document hierarchy.

For example:

<h1>Frontend Accessibility</h1>

<h2>Semantic HTML</h2>

<h3>Buttons</h3>

<h3>Forms</h3>

<h2>Keyboard Accessibility</h2>

<h3>Focus Management</h3>
Enter fullscreen mode Exit fullscreen mode

A screen-reader user can navigate through headings to understand the page structure.

Avoid choosing headings simply because they look good.

Don't do this:

<h1>Small Text</h1>
Enter fullscreen mode Exit fullscreen mode

just because you want a particular font size.

Use CSS for presentation:

h1 {
  font-size: 2rem;
}
Enter fullscreen mode Exit fullscreen mode

7. Accessible Links

A link should communicate where it will take the user.

Avoid:

<a href="/products">
  Click here
</a>
Enter fullscreen mode Exit fullscreen mode

Prefer:

<a href="/products">
  View our products
</a>
Enter fullscreen mode Exit fullscreen mode

The second version provides useful context.

This becomes especially important for screen-reader users who may navigate through links independently of the surrounding text.

8. Accessible Buttons

Buttons perform actions.

Links navigate.

This distinction is important.

Use:

<button type="button">
  Open menu
</button>
Enter fullscreen mode Exit fullscreen mode

for actions.

Use:

<a href="/about">
  About us
</a>
Enter fullscreen mode Exit fullscreen mode

for navigation.

Don't use:

<div onclick="openMenu()">
  Menu
</div>
Enter fullscreen mode Exit fullscreen mode

You would have to recreate many native behaviors yourself.

9. Keyboard Accessibility

A website should be usable without a mouse.

Typical keyboard navigation uses:

Tab
Shift + Tab
Enter
Space
Arrow Keys
Escape
Enter fullscreen mode Exit fullscreen mode

For example, a user should be able to:

  1. Navigate to a button.
  2. Focus it.
  3. Activate it.
  4. Open a menu.
  5. Navigate through the menu.
  6. Close it.

Test your website by physically putting the mouse aside.

Then try:

Tab
Tab
Tab
Shift + Tab
Enter
Space
Escape
Enter fullscreen mode Exit fullscreen mode

If you become stuck, your users may become stuck too.

10. Focus Management

Keyboard users need to know where they currently are.

This is the focus state.

Never blindly remove the browser focus indicator:

*:focus {
  outline: none;
}
Enter fullscreen mode Exit fullscreen mode

This can make keyboard navigation extremely difficult.

Instead, create a visible focus style:

button:focus-visible,
a:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
}
Enter fullscreen mode Exit fullscreen mode

:focus-visible is especially useful because it allows you to style focus when it is relevant to keyboard navigation.

11. Forms and Labels

Forms are one of the most common accessibility problem areas.

Bad:

<input type="email">
Enter fullscreen mode Exit fullscreen mode

The user may not know what the field represents.

Better:

<label for="email">
  Email address
</label>

<input
  id="email"
  name="email"
  type="email"
>
Enter fullscreen mode Exit fullscreen mode

The for attribute connects the label to the input's id.

You can also nest the input:

<label>
  Email address
  <input type="email">
</label>
Enter fullscreen mode Exit fullscreen mode

Both approaches can be accessible.

12. Error Messages

Consider:

Invalid email.
Enter fullscreen mode Exit fullscreen mode

This may be visually obvious to someone who can see the page.

But assistive technology needs a meaningful relationship between the input and the error.

For example:

<label for="email">
  Email address
</label>

<input
  id="email"
  type="email"
  aria-describedby="email-error"
  aria-invalid="true"
>

<p id="email-error">
  Enter a valid email address.
</p>
Enter fullscreen mode Exit fullscreen mode

Now the input is associated with its error message.

13. Images and Alternative Text

Images need appropriate alternative text.

Informative image:

<img
  src="team.jpg"
  alt="Frontend development team working together"
>
Enter fullscreen mode Exit fullscreen mode

Decorative image:

<img
  src="decoration.svg"
  alt=""
>
Enter fullscreen mode Exit fullscreen mode

An empty alt tells assistive technology that the image is decorative.

Don't write:

alt="image"
Enter fullscreen mode Exit fullscreen mode

That doesn't provide useful information.

Instead, describe the image's purpose.

14. Color and Contrast

Color is one of the most common accessibility problems.

Consider:

color: #aaa;
background: #fff;
Enter fullscreen mode Exit fullscreen mode

This might look acceptable to some users but be difficult to read for others.

Text needs sufficient contrast against its background.

Don't rely only on your eyes.

Use accessibility testing tools to measure contrast.

Tools include:

  • Browser DevTools
  • Lighthouse
  • axe
  • WAVE
  • Contrast checkers

15. Don't Use Color Alone

Never communicate meaning using only color.

Bad:

Green = success
Red = error
Enter fullscreen mode Exit fullscreen mode

Instead:

✓ Payment successful

⚠ Payment failed
Enter fullscreen mode Exit fullscreen mode

and use text as well.

For example:

<p class="error">
  Error: Invalid email address.
</p>
Enter fullscreen mode Exit fullscreen mode

Color can reinforce the meaning, but shouldn't be the only way to understand it.

16. Accessible Modals

Modals can be particularly difficult for keyboard and screen-reader users.

A good modal should:

  1. Have an accessible name.
  2. Receive focus appropriately.
  3. Keep keyboard interaction inside the modal when necessary.
  4. Allow the user to close it.
  5. Restore focus to the triggering element after closing.

Example:

<button
  id="open-dialog"
  type="button"
>
  Delete account
</button>

<dialog aria-labelledby="dialog-title">
  <h2 id="dialog-title">
    Delete account?
  </h2>

  <p>
    This action cannot be undone.
  </p>

  <button type="button">
    Cancel
  </button>

  <button type="button">
    Delete
  </button>
</dialog>
Enter fullscreen mode Exit fullscreen mode

The native <dialog> element can simplify many accessibility concerns compared with building a modal entirely from <div> elements.

17. ARIA

ARIA stands for:

Accessible Rich Internet Applications

ARIA allows developers to provide additional accessibility information to assistive technologies.

For example:

<button
  aria-expanded="false"
  aria-controls="main-menu"
>
  Menu
</button>

<nav id="main-menu">
  ...
</nav>
Enter fullscreen mode Exit fullscreen mode

aria-expanded communicates whether the menu is currently expanded.

18. When NOT to Use ARIA

One of the most important accessibility rules is:

No ARIA is better than incorrect ARIA.

Don't replace native HTML unnecessarily.

For example:

<div role="button">
  Save
</div>
Enter fullscreen mode Exit fullscreen mode

is usually worse than:

<button>
  Save
</button>
Enter fullscreen mode Exit fullscreen mode

Why?

Because the native button already provides:

  • Keyboard behavior
  • Focus behavior
  • Semantics
  • Interaction behavior
  • Assistive technology support

ARIA adds semantics.

It does not automatically add all behavior.

If you write:

<div role="button">
  Save
</div>
Enter fullscreen mode Exit fullscreen mode

you may still need to implement:

  • Keyboard handling
  • Focus management
  • Mouse interaction
  • Space key behavior
  • Enter key behavior

So prefer native HTML.

19. Screen Readers

Screen readers convert digital content into speech or Braille.

Examples include:

  • NVDA
  • JAWS
  • VoiceOver
  • TalkBack

A screen reader doesn't simply "read the screen."

It interprets the accessibility tree exposed by the browser.

For example:

<button>
  Delete
</button>
Enter fullscreen mode Exit fullscreen mode

may be exposed approximately as:

Delete, button
Enter fullscreen mode Exit fullscreen mode

Whereas:

<div>
  Delete
</div>
Enter fullscreen mode Exit fullscreen mode

may simply be exposed as:

Delete
Enter fullscreen mode Exit fullscreen mode

The semantic difference is extremely important.

20. Accessible Navigation

Navigation should have a clear structure.

Use:

<nav aria-label="Primary navigation">
  <ul>
    <li>
      <a href="/">Home</a>
    </li>

    <li>
      <a href="/products">Products</a>
    </li>

    <li>
      <a href="/contact">Contact</a>
    </li>
  </ul>
</nav>
Enter fullscreen mode Exit fullscreen mode

If you have multiple navigation regions, labels can help distinguish them:

<nav aria-label="Primary navigation">
Enter fullscreen mode Exit fullscreen mode

and:

<nav aria-label="Footer navigation">
Enter fullscreen mode Exit fullscreen mode

21. Tables

Tables should represent tabular data.

Example:

<table>
  <caption>
    Monthly sales
  </caption>

  <thead>
    <tr>
      <th scope="col">Month</th>
      <th scope="col">Revenue</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <th scope="row">January</th>
      <td>$10,000</td>
    </tr>
  </tbody>
</table>
Enter fullscreen mode Exit fullscreen mode

The <caption> explains what the table represents.

The <th> elements identify headers.

The scope attribute clarifies relationships between headers and cells.

22. Dynamic Content

Modern frontend applications constantly update the UI.

For example:

Saving...
Saved successfully.
Enter fullscreen mode Exit fullscreen mode

A screen-reader user may not automatically know that something changed.

This is where live regions can help.

Example:

<div aria-live="polite">
  Saved successfully.
</div>
Enter fullscreen mode Exit fullscreen mode

Now assistive technology can announce changes when appropriate.

23. Live Regions

Common values include:

aria-live="polite"
Enter fullscreen mode Exit fullscreen mode

and:

aria-live="assertive"
Enter fullscreen mode Exit fullscreen mode

polite means:

Announce this when convenient.

assertive means:

Interrupt the user and announce this immediately.

Use assertive carefully.

If everything is urgent, nothing feels urgent.

24. Reduced Motion

Some users experience discomfort from animations.

CSS provides a media query for users who prefer reduced motion:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms;
    animation-iteration-count: 1;
    transition-duration: 0.01ms;
    scroll-behavior: auto;
  }
}
Enter fullscreen mode Exit fullscreen mode

This allows the interface to respect the user's system preference.

25. Responsive Accessibility

Responsive design isn't only about screen sizes.

It is also about how people interact with the interface.

For example:

  • Buttons should have sufficient touch targets.
  • Text should remain readable when zoomed.
  • Content shouldn't disappear when the viewport changes.
  • Horizontal scrolling should be minimized.
  • Forms should remain usable on small screens.

Test your application at different:

Desktop
Tablet
Mobile
200% zoom
Keyboard-only navigation
Screen reader
Enter fullscreen mode Exit fullscreen mode

26. Common Accessibility Mistakes

Here are some common mistakes frontend developers make.

Mistake 1: Using <div> for everything 

<div onclick="...">
Enter fullscreen mode Exit fullscreen mode

Use semantic HTML instead.

Mistake 2: Removing focus outlines 

outline: none;
Enter fullscreen mode Exit fullscreen mode

without providing an alternative.

Mistake 3: Images without alt text 

<img src="profile.jpg">
Enter fullscreen mode Exit fullscreen mode

Mistake 4: Inputs without labels 

<input type="text">
Enter fullscreen mode Exit fullscreen mode

Mistake 5: Using placeholder as the label

Bad:

<input placeholder="Email">
Enter fullscreen mode Exit fullscreen mode

A placeholder isn't a replacement for a proper label.

Mistake 6: Relying only on color 

Red = error
Green = success
Enter fullscreen mode Exit fullscreen mode

Mistake 7: Incorrect ARIA

Adding ARIA without understanding its semantics can make the interface worse.

Mistake 8: Testing only with a mouse

A website may appear perfect with a mouse while being unusable with a keyboard.

27. Testing Accessibility

Accessibility testing should happen throughout development.

Don't wait until the project is finished.

A useful strategy is:

Development
    ↓
Automated testing
    ↓
Keyboard testing
    ↓
Screen reader testing
    ↓
Real-user testing
Enter fullscreen mode Exit fullscreen mode

28. Automated Testing

Several tools can identify accessibility problems.

Lighthouse

Chrome DevTools includes Lighthouse.

It can detect issues such as:

  • Missing alt text
  • Poor contrast
  • Missing labels
  • Invalid ARIA
  • Accessibility problems

axe

axe is widely used for automated accessibility testing.

It can be integrated into development and testing workflows.

WAVE

WAVE provides visual feedback about accessibility issues directly on web pages.

29. Manual Testing

Automated tools are useful, but they cannot detect everything.

You should manually test:

Keyboard

Try:

Tab
Shift + Tab
Enter
Space
Escape
Arrow keys
Enter fullscreen mode Exit fullscreen mode

Zoom

Try increasing browser zoom.

Screen reader

Try using:

NVDA
VoiceOver
TalkBack
Enter fullscreen mode Exit fullscreen mode

depending on your platform.

Focus

Ask:

Can I always tell where I am?

30. Accessibility Checklist

Before shipping a frontend application, check the following.

Semantic HTML

  • [ ] Use semantic elements.
  • [ ] Use buttons for actions.
  • [ ] Use links for navigation.
  • [ ] Use proper heading hierarchy.
  • [ ] Use landmarks such as main, nav, and footer.

Keyboard

  • [ ] Everything interactive is keyboard accessible.
  • [ ] Focus is visible.
  • [ ] No keyboard traps.
  • [ ] Modals manage focus correctly.

Forms

  • [ ] Every input has a label.
  • [ ] Errors are understandable.
  • [ ] Inputs have appropriate types.
  • [ ] Validation messages are accessible.

Images

  • [ ] Informative images have meaningful alt text.
  • [ ] Decorative images use empty alt text.
  • [ ] Complex images have appropriate descriptions.

Color

  • [ ] Text has sufficient contrast.
  • [ ] Color isn't the only way information is communicated.

Dynamic Content

  • [ ] Important updates can be announced.
  • [ ] Loading states are understandable.
  • [ ] Error states are accessible.

Motion

  • [ ] Reduced-motion preferences are respected.
  • [ ] Animations don't create usability problems.

Testing

  • [ ] Lighthouse tested.
  • [ ] axe or equivalent tested.
  • [ ] Keyboard tested.
  • [ ] Screen reader tested.
  • [ ] Zoom tested.

31. Accessibility in Modern Frontend Frameworks

Accessibility principles don't disappear when you use Angular, React, Vue, or Next.js.

The framework changes how you build the application.

The accessibility fundamentals remain the same.

For example, in Angular:

<button
  type="button"
  [attr.aria-expanded]="isOpen"
  (click)="toggleMenu()"
>
  Menu
</button>
Enter fullscreen mode Exit fullscreen mode

React:

<button
  type="button"
  aria-expanded={isOpen}
  onClick={toggleMenu}
>
  Menu
</button>
Enter fullscreen mode Exit fullscreen mode

The framework syntax changes.

The accessibility concepts don't.

You still need:

  • Semantic HTML
  • Keyboard support
  • Focus management
  • Accessible forms
  • Proper labels
  • Correct ARIA
  • Accessible dynamic content

32. The Accessibility Mindset

Accessibility isn't about memorizing hundreds of ARIA attributes.

It's about changing the way you think about interfaces.

Instead of asking:

Does this look good?

also ask:

Can everyone understand it?

Instead of:

Does this work with my mouse?

ask:

Can someone use it with only a keyboard?

Instead of:

Can I see the error?

ask:

Will a screen-reader user know that an error occurred?

Instead of:

Does the animation look impressive?

ask:

Can someone who prefers reduced motion comfortably use this interface?

This mindset produces better products.

33. Accessibility Is a Development Responsibility

Accessibility shouldn't belong only to a QA engineer or accessibility specialist.

Frontend developers influence accessibility every day through decisions about:

  • HTML
  • CSS
  • JavaScript
  • Components
  • Forms
  • Navigation
  • Modals
  • State management
  • Loading states
  • Error handling
  • Responsive behavior

A small decision such as choosing:

<button>
Enter fullscreen mode Exit fullscreen mode

instead of:

<div>
Enter fullscreen mode Exit fullscreen mode

can have a significant accessibility impact.

34. Final Thoughts

Frontend accessibility is not a separate technology.

It's a way of building the web.

The most effective accessibility practices are often surprisingly simple:

Use semantic HTML.
        ↓
Make everything keyboard accessible.
        ↓
Provide visible focus.
        ↓
Label forms correctly.
        ↓
Write meaningful alternative text.
        ↓
Don't rely only on color.
        ↓
Use ARIA carefully.
        ↓
Test with real interaction methods.
Enter fullscreen mode Exit fullscreen mode

The goal isn't to create a special version of your website for people with disabilities.

The goal is to create one interface that works for as many people as possible.

Accessibility is therefore not just about compliance.

It's about respecting your users.

And as frontend developers, that's part of our job.

The Golden Rule

If you remember only one thing from this article, remember this:

Start with semantic HTML, make it keyboard accessible, and use ARIA only when native HTML isn't enough.

Good accessibility often begins with writing better HTML.

Top comments (0)