95.9% of the top one million home pages had at least one detectable WCAG failure in 2026, with an average of 56.1 errors per page. Making websites accessible starts with fixing the recurring problems that block perception, navigation, and form completion, then building a release process that stops those problems from returning.
Accessibility isn't a decorative layer added after the design is finished. It affects whether people can read your content, move through your navigation, complete a checkout, submit a lead form, or understand what went wrong after an error. For small businesses, the practical question isn't whether a site can pass a scan once. It's whether the site remains usable after an editor publishes a promotion, a plugin changes a form, or a developer adds a new component.
Why Most Websites Still Fail Accessibility in 2026
The latest WebAIM Million accessibility analysis found a detectable WCAG failure on nearly every home page it examined. The finding matters because accessibility defects are not limited to outdated or neglected sites. They appear in polished websites with established content systems, professional design teams, and regular development work.
The current target is a living standard
WCAG gives teams a shared language for content that is perceivable, operable, understandable, and resilient. WCAG 2.0 was published in 2008, WCAG 2.1 followed in 2018, and WCAG 2.2 became a W3C Recommendation on 5 October 2023, as summarized in this WCAG compliance overview. For a plain-language explanation of the requirements, see this WCAG compliance guide.
WCAG 2.2 addresses interaction patterns that older checklists often missed. Its additions include guidance for focus appearance, dragging movements, target size, consistent help, redundant entry, and accessible authentication. Correct headings and alternative text do not help if keyboard focus is hard to see or a sign-in process cannot be completed without precise pointer control.
The practical challenge is keeping those standards intact after launch. A CMS edit can introduce low-contrast text, a plugin can replace a labeled field with an unlabeled one, and a campaign landing page can ship without meaningful image alternatives. A scan after launch may identify the defect, but it does not prevent the next edit from creating another one.
Accessibility is also conversion quality
A person who cannot identify a form field cannot reliably submit a quote request. A keyboard user may abandon a menu when focus disappears. A visitor with low vision may miss a call to action because its text blends into the background. Each defect interrupts the same journeys that generate leads, purchases, appointments, and support requests.
Legal exposure also matters. Requirements under frameworks such as the ADA and the European Accessibility Act can affect organizations serving those markets. Clear structure, meaningful controls, readable contrast, and predictable feedback improve usability for many visitors, regardless of legal obligations.
Practical rule: Treat accessibility as a release-quality requirement, not a report generated after launch.
The work becomes manageable because a small group of recurring implementation patterns drives the bulk of detected failures. Small teams can fix those patterns in shared templates and components, then check them again after every CMS edit, plugin installation, and campaign release. The next step is to identify those six persistent issue types and address their sources rather than patching pages one at a time.
The Six Issues Behind 96% of Accessibility Failures
The 2026 WebAIM findings show that six issue types accounted for 96% of detected errors. Low-contrast text appeared on 83.9% of pages, missing alternative text on 53.1%, missing form labels on 51.0%, empty links on 46.3%, empty buttons on 30.6%, and missing document language on 13.5%. Those figures point to a useful implementation strategy: fix common component patterns before spending time on rare edge cases.
| Issue | WCAG 2.2 criterion | Who it affects | Standard fix |
|---|---|---|---|
| Low-contrast text | 1.4.3 Contrast Minimum | Low-vision users, users on glare-prone screens, and anyone viewing content in difficult conditions | Use text and background combinations that meet the required contrast level. Store approved combinations in design tokens. |
| Missing or ineffective image alternatives | 1.1.1 Non-text Content | Screen-reader users and people who can't perceive an image | Add concise alt text for informative images and use alt="" for decorative images. |
| Missing form labels | 3.3.2 Labels or Instructions, 1.3.1 Info and Relationships | Screen-reader users, voice-control users, and people who need clear instructions | Associate every input with a visible <label> or an appropriate programmatic label. |
| Empty links | 2.4.4 Link Purpose in Context | Screen-reader and keyboard users who navigate by link lists | Give every link an accessible name that explains its destination or action. |
| Empty buttons | 4.1.2 Name, Role, Value | Screen-reader users and keyboard users operating controls without visible text | Add visible text or an accessible name, and make sure the control performs the action described. |
| Missing document language | 3.1.1 Language of Page | Screen-reader users whose pronunciation depends on language metadata | Set the correct lang attribute on the root HTML element. |
Why these defects return
These errors are usually introduced by routine publishing work. An editor uploads a hero image without alternative text. A marketer duplicates a landing-page block and removes the visible button label to make room for an icon. A plugin injects a modal with no focus handling. A developer adds a new template but forgets the document language inherited from the main layout.
Heading structure deserves separate attention even though it isn't one of the six categories above. A page should use headings to represent its content hierarchy, not to create visual size changes. Skipping from a top-level heading to a lower-level heading can make a document outline harder to understand, while a missing main heading deprives assistive technology users of a useful orientation point. Use semantic heading elements, then style them with CSS.
The fastest remediation sequence usually follows the order in the table. Contrast, text alternatives, labels, and control names improve a large number of experiences without requiring a broad redesign. Fix the component or template that creates the defect, not only the individual page where the scanner found it.
A Prioritized Fix List for Tight Budgets
Small teams should prioritize impact per hour, not the visual length of an audit report. Start with a baseline scan using an automated accessibility checker, browser diagnostics, and a page-level review. Record the page, component, defect, owner, and verification status in one issue list. A scan is useful for finding patterns, but it can't tell you whether a checkout makes sense to a person using assistive technology.
Start with foundations
Set the document language and title in the shared layout. This is a small change with site-wide value.
<html lang="en">
<head>
<title>Residential Roofing Services | Example Company</title>
</head>
Use the language appropriate to the page. A useful title should identify the page's subject, not repeat a generic brand label across the entire site.
Contrast fixes belong in the design system, not in scattered page overrides. For normal body text, target a 4.5:1 contrast ratio, and for large text, target 3:1. Define approved colors as tokens so a new campaign inherits accessible combinations.
:root {
--color-text: #243447;
--color-surface: #ffffff;
--color-link: #0b4f8a;
}
body {
color: var(--color-text);
background: var(--color-surface);
}
a {
color: var(--color-link);
text-decoration-thickness: 0.12em;
}
Repair content and controls
Alternative text should identify the purpose of an informative image. It shouldn't describe every visual detail or repeat nearby text.
<img src="/images/team-consultation.jpg"
alt="Consultant reviewing a project plan with a client">
<img src="/images/decorative-rule.svg" alt="">
A form label must remain visible and programmatically connected to its input. Placeholder text isn't a durable substitute because it disappears during entry and may not provide a stable name.
<label for="company-email">Work email</label>
<input id="company-email"
name="email"
type="email"
autocomplete="email">
Replace icon-only controls with visible text where possible. If an icon is necessary, provide a stable accessible name and test it with a screen reader.
<a href="/contact">Request a consultation</a>
<button type="button" aria-label="Open navigation">
<svg aria-hidden="true" viewBox="0 0 24 24">...</svg>
</button>
Finally, make the heading outline reflect the content. Don't choose an <h3> because it happens to have the desired font size. Choose it because it belongs under the preceding <h2>, then style it independently.
What Accessibility Looks Like in a Real Checkout Flow
Consider a small retailer whose checkout began with a visually polished but poorly labeled form. The fields appeared in a logical order to sighted visitors, yet the inputs had no connected labels, the error message appeared above the form without being associated with the invalid field, and the submit control was represented by an unlabeled icon.
A screen reader user might hear “edit text” without knowing whether the field requested an email address, delivery address, or promotional code. A keyboard user could reach the submit control but receive no useful information about what it would do. The business could see abandoned sessions and support requests, but the underlying cause would remain hidden unless someone tested the flow with assistive technology.
The first repair adds visible labels and a named submit button:
<label for="checkout-email">Email address</label>
<input id="checkout-email"
name="email"
type="email"
autocomplete="email">
<button type="submit">Continue to delivery</button>
The announcement now contains the field's purpose, and the action communicates the next step. That improves orientation without adding visual clutter.
Make errors part of the field relationship
Inline validation should identify the problem beside the relevant field and connect the explanation with aria-describedby. The error state should also be exposed programmatically.
<label for="checkout-email">Email address</label>
<input id="checkout-email"
name="email"
type="email"
autocomplete="email"
aria-invalid="true"
aria-describedby="email-error">
<p id="email-error" role="alert">
Enter a valid email address, such as name@example.com.
</p>
The exact wording should be useful and respectful. “Invalid input” doesn't tell a customer how to recover. A good message names the field, explains the requirement, and leaves the user in a predictable place after submission.
The final pass adds autocomplete values to reduce repeated typing, preserves focus on the first invalid field, and gives the primary action a specific name. Test the complete sequence with keyboard input, a screen reader, zoom, and a narrow viewport. The lesson is practical: form accessibility is conversion work. It removes friction from a revenue action, and the strongest fixes often involve markup, focus management, and content rather than a visual redesign.
Applying Fixes Across WordPress, Shopify, and Custom Builds
The platform changes the location of the fix, not the underlying responsibility. A block theme, store theme, visual builder, or custom application can all produce accessible output when the team controls templates, components, content rules, and testing.
| Fix | WordPress | Shopify | Webflow | Custom build |
|---|---|---|---|---|
| Contrast | Change theme tokens and block styles, then review builder overrides | Update theme settings and shared CSS in the theme | Use the accessibility panel and global color styles | Enforce tokens in the component library |
| Alt text | Require media-library text for meaningful images | Add alt text in product and theme content | Add image descriptions in the asset and component settings | Make alternative text a required component prop |
| Form labels | Inspect form-plugin output and template markup | Review theme and app-generated forms | Check form blocks and published markup | Use label associations in every form component |
| Link text | Audit reusable blocks, menus, and SEO templates | Review navigation, product cards, and app links | Check collection lists and button links | Define link components with required accessible names |
WordPress
In WordPress, the durable fix usually belongs in the block pattern, theme template, or component used by editors. A page builder can produce attractive pages while stripping landmarks or encouraging heading levels based on appearance. Set editor guidance for alternative text, keep reusable blocks semantic, and inspect the published HTML rather than trusting the editing canvas.
Shopify and Webflow
Shopify teams should review both the theme and installed apps. An app can inject a modal, upsell, or quick-view panel that doesn't follow the theme's focus behavior. Test cart buttons, product options, account forms, and any application-generated interface after updates.
Webflow gives teams useful visual controls, but published output still needs keyboard and screen-reader checks. Global styles reduce contrast drift, while component-level review catches missing names and incorrect heading structures.
Custom applications
A React or Next.js build needs explicit focus management when navigation changes. After a route transition, move focus to the main heading or a suitable page container without trapping the user unexpectedly.
function PageShell({ title, children }) {
const mainRef = React.useRef(null);
React.useEffect(() => {
mainRef.current?.focus();
}, [title]);
return (
<main ref={mainRef} tabIndex="-1">
<h1>{title}</h1>
{children}
</main>
);
}
Use a skip link before the site navigation, preserve native controls where they already provide the required behavior, and treat custom ARIA as a supplement rather than a replacement for semantic HTML. Teams deciding how much to customize should use a simple rule: choose the lightest platform that lets you control templates, forms, focus, and release testing. If those controls are unavailable, a platform migration may be safer than endless patches. Guidance on choosing a CMS for website design can help frame that decision around content ownership and maintenance capacity.
Building a Testing Routine That Catches Regressions
A single audit gives you a snapshot. A testing routine gives you a chance to catch the change that caused the problem. Small teams don't need a complicated quality department, but they do need different testing layers because no single method finds every type of barrier.
Use three complementary layers
Run automated scans against changed templates and important journeys during development and deployment. These scans are good at detecting repeated markup and style patterns, especially the six high-volume defects discussed earlier. They won't judge whether the wording of an error is understandable, whether focus lands in the right place, or whether a real customer can complete the task.
Perform a short keyboard walkthrough before each release. Use only the keyboard and check:
- Entry: Can you reach the skip link, navigation, menus, forms, dialogs, and submit controls?
- Visibility: Can you always see where focus is?
- Order: Does focus move in a sensible sequence?
- Operation: Can you open, close, submit, and recover from every interactive state?
- Escape: Can you leave a modal or expanded menu without becoming trapped?
Run a screen-reader session regularly across the most important journeys, such as finding a service, submitting a lead form, adding a product, and completing checkout. A Windows screen reader and a Mac screen reader can expose different implementation problems, so use the environment your customers rely on when that information is available.
Put the checks into delivery
A pull request should trigger an automated scan against representative pages. A release checklist should require keyboard review. A recurring manual session should cover the core journeys, and a deeper audit should follow a substantial redesign or platform change.
Don't configure the pipeline to fail on every historical issue before the team has a baseline. Record existing violations, fail on newly introduced violations, and give each exception an owner and review date. This keeps the check useful instead of training developers to ignore a permanently red build.
Automated results tell you where to investigate. They don't prove that a person can complete the task.
Track defects by reusable component. If the same button problem appears on several pages, fix the button component and retest its instances. Plugin and dependency updates deserve the same discipline as code changes. A plugin update review process should include a quick accessibility check for templates, forms, modals, and navigation rather than treating the update as risk-free maintenance.
Your 30/60/90-Day Accessibility Plan and Checklist
A workable accessibility plan starts with the pages that carry the most responsibility. For a small business, that usually means the home page, service or product template, contact form, account or booking flow, and checkout or payment path. Fix those patterns first, then extend the same standards to less frequently visited content.
Days 0 to 30 focus on quick wins
Create a baseline issue list. Correct the document language, page titles, contrast tokens, image alternatives, form labels, control names, and heading structure on the priority templates. Test the pages with a keyboard and record anything that blocks movement or obscures focus.
Give editors short content rules they can use without developer support:
- Images: Add useful alternative text when an image communicates information. Mark decorative images as decorative.
- Headings: Use headings to describe structure, not to control font size.
- Links: Explain the destination or action in the link text.
- Forms: Keep labels visible and make instructions available before submission.
- Media: Provide captions or transcripts when spoken information carries meaning.
Days 31 to 60 improve the system
Move repeated fixes into the theme, component library, or design system. Add approved color combinations, a standard form field, a named button component, a skip link, and a consistent error pattern. Train anyone who publishes content, because a technically sound template can still become inaccessible through poor image descriptions, unclear links, or improvised heading choices.
Document the patterns where editors work. A short CMS note beside an image field is more useful than a policy stored in an unread folder. Record exceptions too, especially third-party forms or embedded tools that need vendor remediation or replacement.
Days 61 to 90 prevent regression
Schedule scans, add a pre-deploy checklist, and assign responsibility for reviewing new templates and campaigns. Repeat keyboard checks after major interface changes and include screen-reader verification for the journeys that produce leads, orders, bookings, or donations. Keep a small accessibility backlog so the team can address newly discovered issues instead of waiting for an annual overhaul.
Print this condensed checklist and attach it to the release process:
- Contrast: Text, controls, focus indicators, and hover states remain distinguishable.
- Alternative text: Informative images have useful descriptions, while decorative images are ignored.
- Headings: The outline reflects the content hierarchy.
- Focus: Keyboard focus is visible and never disappears behind a sticky element.
- Forms: Every field has a label, instructions are available, and errors identify recovery steps.
- Links and buttons: Every control has a clear accessible name and purpose.
- Media: Captions or transcripts support meaningful audio and video.
- CMS governance: Editors know the publishing rules, and releases include accessibility checks.
Accessibility is maintenance, not a one-time project. Small, repeatable habits outperform a large annual cleanup because they address the moment defects are introduced.
MD TECH TEAM can review accessibility barriers, improve responsive websites, and support the templates, forms, hosting, and ongoing maintenance that keep fixes in place. Visit MD TECH TEAM to discuss an accessibility-focused website review or a practical improvement plan for your small business.
