Top 5 Accessibility Issues to Fix First, in Order

A scan report rarely fails for lack of findings. It fails because it lists two hundred of them in no particular order, and the team fixes whatever is easiest, or whatever is on the home page, and stops there. This guide is about order: five problems that turn up again and again, ranked by what to fix first and why.

If you want the full list of what is most common, with figures from the 2026 WebAIM Million and code for each fix, read the most common WCAG violations and how to fix each one. This page assumes you already have findings and need a sensible sequence for them.

How to decide what comes first

Three questions put almost any finding in its place:

• Does it stop someone finishing a task, or only slow them down? A checkout that cannot be completed with a keyboard is a wall. Slightly low contrast on a footer link is friction. Walls come first.
• Is it Level A or Level AA? WCAG marks its most basic requirements as Level A. Conforming at AA means meeting both, but A failures tend to be the ones that block people outright, so they are the better first pass.
• Does it live in a template? A missing label in a shared header search form fails on every page that uses the header. Fixing the component once clears it everywhere, so template and component fixes beat page fixes.

Apply those to the five problems below and the order falls out.

1. Fix keyboard gaps on your key flows first

Custom dropdowns, modals and widgets built from div elements often cannot receive focus at all, or trap it so the person cannot move on. Either one ends the visit for anyone who navigates by keyboard, including many people who use switch devices or voice control. This breaks WCAG 2.1.1 Keyboard and, for traps, 2.1.2 No Keyboard Trap, both Level A.

Why first: it is the clearest example of a wall, and scanners only see part of it. Put the mouse away and walk your main flows (sign up, contact, checkout) with Tab, Shift+Tab, Enter, Space, Escape and the arrow keys. Every control should be reachable, usable and visibly focused.

<!-- Broken: a div cannot take focus or respond to Enter -->
<div class="btn" onclick="openMenu()">Menu</div>

<!-- Fixed: a native button does both for free -->
<button type="button" class="btn" aria-expanded="false">Menu</button>

The keyboard and focus check lists what an automated pass can catch and what still needs your hands on the keys.

2. Then give images that do something a name

Missing alt text is a Level A failure of WCAG 1.1.1 Non-text Content, but not every missing alt costs the same. An icon that is the only content of a link or button leaves that control unnamed, so a screen reader announces "link" or "button" and nothing else. A missing alt on a decorative photo is noise. Do the functional images first, then images that carry information, then mark decorative ones with an empty alt="" so they are skipped.

<!-- Broken: the only content of the link has no text -->
<a href="/cart"><img src="cart.svg"></a>

<!-- Fixed: alt names where the link goes -->
<a href="/cart"><img src="cart.svg" alt="Shopping cart"></a>

The alt text checker shows what a page serves for every image, and how to write alt text covers the wording. If there are hundreds of product images, AccessGuard's AltWizard drafts alt text with AI for a person to review before it goes live.

3. Then make link text say where it goes

"Click here" and "read more" fail people who pull up a list of links to move around a page, which screen readers offer, because every entry reads the same. WCAG 2.4.4 Link Purpose (In Context) is Level A, though it lets the surrounding sentence or list item supply context, so a "read more" under a clear heading is not always a failure.

<!-- Broken: says nothing out of context -->
<a href="/pricing">Click here</a> to see our plans.

<!-- Fixed: the link text is the destination -->
See <a href="/pricing">our pricing plans</a>.

If a design needs short visible text, an aria-label can add context, but start it with the visible words ("Read more about pricing", not "Pricing details") so speech input users can still say what they see. That is WCAG 2.5.3 Label in Name. The link text check covers both cases.

4. Then remove ARIA that lies

ARIA changes what assistive technology announces without changing what the element does. A wrong role, an aria-hidden="true" on something focusable, or an aria-expanded that never updates tells a screen reader user something false. W3C's first rule of ARIA use is to use a native HTML element when one exists, and most fixes here are deletions.

<!-- Broken: announced as a button, but no keyboard support -->
<span role="button" onclick="save()">Save</span>

<!-- Fixed: the native element brings focus and keys with it -->
<button type="button">Save</button>

Why fourth: misused ARIA can be as bad as a keyboard gap, but it usually clusters in a few custom components, so it is quick to find once you know which ones. The ARIA checker flags invalid roles, attributes and broken references.

5. Then enlarge small targets

WCAG 2.5.8 Target Size (Minimum), new in WCAG 2.2 at Level AA, asks for pointer targets of at least 24 by 24 CSS pixels, or enough space around a smaller target, with exceptions such as links inside a sentence. Tiny targets make people with tremors or limited dexterity, and anyone on a phone, hit the wrong thing.

/* Broken: a 16px icon button with no padding */
.icon-btn { width: 16px; height: 16px; padding: 0; }

/* Fixed: padding grows the target, the icon stays the same size */
.icon-btn { min-width: 24px; min-height: 24px; padding: 4px; }

Why last of the five: it is a real barrier, but the control still works, and the fix is usually CSS in a handful of shared components. The target size checker measures each target on a page for you.

What to tell a client or a manager

An ordered plan is easier to approve than a raw report. Something like: "First we make sure every key task can be done with a keyboard, then we fix unlabelled controls, then link text, then the custom widgets, then tap target sizes. Most of it is in shared templates, so each fix covers many pages." It explains the sequence in terms of people who are blocked, not criterion numbers.

Be clear about the limits, too. An automated scan finds many of these problems, but not all of them, and it cannot confirm that a site conforms. Keyboard flows, whether alt text is accurate and whether ARIA behaves as promised all need a person.

Your next steps

1. Run a free accessibility scan on your most important page to get a first list of findings.
2. Sort the findings: anything that blocks a key task, then Level A, then AA.
3. Within each group, fix shared templates and components before single pages.
4. Walk the main flows with a keyboard, since a scan cannot do that for you.
5. Use the guide to the most common WCAG violations for the code behind each fix, and the accessibility audit checklist for the manual steps.