Fixing Accessibility

What It Is

Fixing accessibility means improving HTML, keyboard behavior, focus handling, labels, descriptions, and visual communication so all users can operate the interface.

Most accessibility fixes start with correct semantic HTML, then add keyboard support, focus behavior, and assistive technology support where needed.

Fixing Accessibility = Correct HTML + Keyboard support + Focus management + Clear labels

---

Core Fixing Principle

Accessibility problems usually happen when the UI looks correct visually but does not communicate meaning or behavior to browsers and assistive technologies.

The most effective approach is:

Start with semantic HTML
Add correct keyboard behavior
Manage focus properly
Use ARIA only when needed
Validate with tools and manual testing

Tools are useful for finding issues, but the foundation should come from correct markup and behavior.

---

Non-Semantic Clickable Elements

A common issue is using div or span for interactive actions.

Problem:

<div onclick="submitForm()">Submit</div>

This element has multiple accessibility problems:

• it is not keyboard focusable by default
• it does not respond to Enter or Space
• it is not announced correctly by screen readers
• it does not have native button behavior

Fix:

<button onclick="submitForm()">Submit</button>

A native button automatically provides:

• proper semantics
• keyboard accessibility
• focus handling
• screen reader support

If a custom element is unavoidable, add role, focusability, and keyboard behavior.

<div tabindex="0" role="button">Submit</div>

element.addEventListener("keydown", (e) => {
  if (e.key === "Enter" || e.key === " ") {
    submitForm();
  }
});

Prefer the native button whenever possible.

---

Tab Order and Navigation

Tab order should follow the logical reading order of the page.

Keyboard users move through interactive elements using Tab, so the DOM structure should match the visual structure.

Problem:

<div>Footer</div>
<div>Main Content</div>
<div>Header</div>

This creates confusing keyboard navigation because the DOM order does not match the expected page order.

Fix:

<header>Header</header>

<main>Main Content</main>

<footer>Footer</footer>

Important tabindex rules:

• tabindex="0" makes an element focusable in normal flow
• tabindex="-1" allows programmatic focus but removes it from tab order
• avoid tabindex="1", tabindex="2", etc. because positive values break natural navigation

<button>Save</button>

<div tabindex="0" role="button">Custom Action</div>

<h1 tabindex="-1">Dashboard</h1>

---

Focus Visibility

Keyboard users rely on focus indicators to know where they are on the page.

Removing the focus outline without a replacement makes navigation confusing.

Problem:

:focus {
  outline: none;
}

This removes the only visible focus indicator.

Fix:

:focus {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

A good focus style should be:

• clearly visible
• high contrast
• available on all interactive elements
• consistent across the UI

No visible focus = keyboard users lose their position

---

Forms and Labels

Forms are one of the most common sources of accessibility issues.

Placeholders are not a replacement for labels.

Problem:

<input placeholder="Enter email" />

A placeholder may disappear when the user types, and screen readers may not reliably treat it as a proper label.

Fix:

<label for="email">Email</label> <input id="email" type="email" />

This ensures:

• screen readers announce the field correctly
• users understand the purpose of the input
• the label remains visible and meaningful

---

Form Errors and Validation

Error messages must be connected to the related input.

If the error is only visually placed near the input, assistive technology may not announce it properly.

Problem:

<input id="email" /> <span>Email is required</span>

The error is visible, but it is not programmatically connected to the input.

Fix:

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

<input id="email" aria-describedby="email-error" />

<span id="email-error" role="alert"> Email is required </span>

This helps screen readers:

• announce the error
• connect the error message to the field
• notify the user when validation changes

---

Images

Images need text alternatives when they provide meaning.

Without alt, screen reader users may not understand what the image represents.

Problem:

<img src="profile.png" />

Fix:

<img src="profile.png" alt="User profile picture" />

For decorative images, use empty alt text.

<img src="background.png" alt="" />

This prevents screen readers from announcing unnecessary decorative content.

---

Links

Link text should clearly describe its destination or purpose.

Vague links are difficult for screen reader users because links may be read out of context.

Problem:

<a href="/course">Click here</a>

This does not explain what the link does.

Fix:

<a href="/course">View course details</a>

Good link text improves:

• screen reader usability
• clarity
• navigation confidence

Bad link = Click here
Good link = View course details

---

Color and Visual Communication

Do not rely only on color to communicate meaning.

Users with color vision deficiencies may not understand the message if color is the only signal.

Problem:

<p style="color: red;">Error</p>

This depends only on red color.

Fix:

<p>Error: Invalid input</p>

Use color as a supporting signal, not the only signal.

Better communication can include:

• text
• icons
• labels
• patterns
• helper messages

Color can support meaning, but should not be the only meaning.

---

Modals and Focus Management

Modals often break accessibility when focus is not handled correctly.

Expected behavior:

• focus should move into the modal when it opens
• tab navigation should stay inside the modal
• Escape should close the modal when supported
• focus should return to the trigger element when closed

modal.focus();

closeButton.addEventListener("click", () => {
  triggerButton.focus();
});

If focus is not managed:

• keyboard users may interact with background content
• screen reader users may lose context
• users may not understand that a modal opened

A modal should behave like a temporary focused area until it is closed.

---

Missing Semantics

Generic elements do not communicate meaning clearly to assistive technologies.

Problem:

<div class="nav">Menu</div>

This visually looks like navigation but does not tell assistive technologies that it is navigation.

Fix:

<nav>Menu</nav>

Semantic elements provide built-in meaning.

Examples:

Use Case	Semantic Element
Page header	header
Navigation	nav
Main content	main
Page section	section
Article content	article
Footer	footer
Action	button

Semantic HTML reduces the need for ARIA and makes accessibility easier from the start.

---

Debugging Workflow

Accessibility issues should be tested systematically, not guessed.

A practical debugging workflow:

Navigate using only keyboard
Check focus order and focus visibility
Inspect roles and labels in DevTools
Run Lighthouse accessibility audit
Run Axe DevTools scan
Test with a screen reader
Zoom to 200-400%
Verify layout stability and readability

This workflow helps catch both automated issues and real usability problems.

---

Common Issues Table

Issue	Problem	Fix
Clickable div	Not keyboard accessible	Use button
Bad tab order	Keyboard flow is confusing	Match DOM order with visual order
Hidden focus	User cannot see current position	Add visible focus style
Missing label	Screen reader cannot identify input	Use label with for and id
Disconnected error	Error is visible but not announced	Use aria-describedby and role="alert"
Missing alt text	Image has no meaning for screen readers	Add meaningful alt
Vague link	Link purpose is unclear	Use descriptive link text
Color-only message	Meaning may be missed	Add text or icon with color
Broken modal focus	User loses context	Move, trap, and return focus
Missing semantics	Assistive tools cannot understand structure	Use semantic HTML

---

Basic Checklist

Use native semantic elements first
Replace clickable divs with buttons
Make custom controls keyboard accessible
Keep DOM order logical
Avoid positive tabindex
Keep visible focus indicators
Use labels for all form inputs
Connect errors to inputs
Add meaningful alt text to images
Use descriptive link text
Do not rely only on color
Manage modal focus correctly
Use semantic landmarks like nav and main
Run Lighthouse and Axe
Test with keyboard, screen reader, and zoom

---

Interview Style Answer

Fixing accessibility means correcting the parts of a UI that prevent users or assistive technologies from understanding and operating it. The most common fixes include replacing non-semantic clickable elements with native buttons, keeping DOM order aligned with visual order, preserving visible focus indicators, adding proper form labels, connecting validation errors with inputs, adding alt text to meaningful images, writing descriptive links, avoiding color-only communication, managing modal focus correctly, and using semantic landmarks like nav, main, and footer. A good debugging workflow includes keyboard-only testing, checking focus visibility, inspecting roles and labels in DevTools, running Lighthouse and Axe, testing with a screen reader, and verifying the page at high zoom.

---

One-Line Summary

Fixing Accessibility = Use semantic HTML, keyboard support, clear labels, visible focus, and proper testing to remove usability barriers.

---

Final Mental Model

Start with HTML semantics
Then fix keyboard behavior
Then manage focus
Then add labels and descriptions
Then validate with tools and real testing