Website accessibility basics for small sites
Practical checklist and prioritized fixes to reduce major accessibility barriers on small sites. Covers headings, alt text, keyboard navigation, forms…
Emma Collins
September 27, 2026
Updated September 27, 2026
8 min read
This guide gives small-site owners and small teams a practical, prioritized checklist to reduce major accessibility barriers and make web content more usable for more people. It is informational only and does not certify legal compliance; consult official authorities for liability questions.
Quick checklist — what to fix first
Start with items that block core access. The list below targets small sites where a single developer or editor can act. Each item links to a detailed section further down.
:focus-visible where appropriate.aria-describedby.<title>.Understand the standard — WCAG in brief
WCAG 2.2 is the W3C Recommendation that defines success criteria grouped under four principles: Perceivable, Operable, Understandable, Robust. The recommendation provides measurable success criteria and implementation techniques. See the W3C link in Resources for full details; the recommendation was published 5 October 2023.
WCAG uses conformance levels A, AA and AAA. Many public-facing small-business sites use AA as a practical target; this is a convention aimed at broader accessibility and not a legal certification. The standard itself lists specific thresholds and techniques for items such as contrast, keyboard operability and non-text alternatives.
Keep the standard as the reference when choosing priorities. Use the success criteria as tests: each criterion describes observable behavior or attributes that can be checked with an automated tool or manual verification.
Low-hanging technical fixes for small sites
This section explains practical fixes that usually require minimal development time. Each subpoint includes a simple rationale and, where useful, a short code example.
Use semantic HTML and correct headings order
Semantic elements convey meaning to browsers and assistive technologies. Use one H1 for the main topic, followed by H2 and H3 for sections and subsections. Do not skip heading levels; maintain a logical outline.
<h1>Service overview</h1>
<h2>What we offer</h2>
<h3>Accessibility features</h3>Also use landmarks like <nav>, <main> and <footer> to help navigation. Tables that present tabular data should use header cells; use lists for lists, not layout tables.
Alt text for images
Alt attributes communicate image content to people who cannot see them. For informative images, write concise descriptions focused on meaning. For complex images, provide a short alt and a longer description nearby or on a linked page. Decorative images should use an empty alt attribute to be ignored by assistive tech.
Descriptive link text
Make link text meaningful out of context. Replace phrases like “more info” or “click here” with descriptive labels such as “Download product datasheet” or “See event schedule”. This improves navigation for users who list links or use screen readers.
Form labels and error messages
Associate <label> elements with inputs using the for attribute. Attach helper text and error messages using aria-describedby so assistive technologies announce them. Provide concrete, actionable error copy that identifies the problem.
<label for="email">Email address</label>
<input id="email" name="email" type="email" aria-describedby="email-help">
<div id="email-help">We will send a confirmation to this address.</div>Keyboard access and focus order
Ensure all interactive elements can be operated by keyboard. Verify that tab order follows visual order and that focus styles remain visible. For custom controls, implement keyboard handlers and focus management to match native behavior. Add a skip-to-content link at the start of pages to help keyboard users bypass navigation blocks.
Color contrast
WCAG sets contrast thresholds for text: normal text and large text have different minimum ratios. Use a trusted contrast checker to validate color combinations. If brand colors fail contrast checks, provide high-contrast variants for text or add backgrounds to meet ratios.
Resize text and responsive layouts
Design pages so text can scale without content loss. Avoid fixed-size containers that clip content at higher zoom levels. Test with browser zoom and different viewport widths to confirm the layout adapts and functionality remains available.
Media: captions and transcripts
Prerendered video requires synchronized captions when audio conveys information. Audio content should include transcripts. For small teams, using auto-captioning followed by a manual review reduces effort while improving accuracy.
Interactive content and ARIA — when and how to use it
ARIA fills gaps where native HTML cannot express required semantics. The guiding rule: prefer native HTML controls; add ARIA only when native semantics are insufficient. Follow the ARIA Authoring Practices Guide for patterns such as menus, dialogs and tabs.
Incorrect ARIA can reduce accessibility. When ARIA is used, ensure roles and properties match expected keyboard behavior and that accessible names are provided. Test ARIA-based widgets with keyboard navigation and a screen reader.
Media and documents
Video players must expose keyboard controls and support captions. Provide transcripts for audio and include audio descriptions when visual-only information is essential to comprehension. For documents such as PDFs, prefer an accessible HTML alternative; if a PDF is necessary, ensure it is tagged and structured so assistive technologies can parse headings and lists.
How to test — tools and manual checks
Automated tools find many issues quickly but do not replace manual testing. Combine scans with keyboard-only checks and screen reader spot tests to cover gaps that automation misses.
Tools commonly used by small teams include Lighthouse (Chrome), axe / axe-core, and WAVE. Each tool highlights different issues; use a combination to get broader coverage.
A suggested workflow for a small site:
Run an automated scan with Lighthouse or axe and prioritise the critical failures.
Fix semantic and keyboard issues first: headings, labels, focus.
Perform keyboard-only navigation on key pages (home, primary content pages, contact pages).
Do a few screen reader spot checks on representative pages.
Re-run automated tools to confirm fixes and iterate.
Practical remediation for common small-site platforms
General recommendations for WordPress, static-site generators and site builders:
When to call a specialist
Engage a professional when a site includes complex custom widgets, when a formal conformance report is required, or when remediation involves structural changes beyond template fixes. When requesting a consultant, ask for the scope of pages and assistive technologies tested, a clear remediation plan with priorities, and a report referencing WCAG success criteria and verification steps.
Resources & testing checklist
Printable one-page checklist: use the Quick checklist section above to create a single-page printout for task tracking and handoff to developers or editors.
Authoritative resources consulted for this guide (consulted September 27, 2026):
Is accessibility legally required?
Requirements vary by jurisdiction. Standards such as WCAG are widely referenced by authorities and procurement rules. Check local laws and government guidance for obligations; this guide does not provide legal advice.
Do short marketing videos need captions?
Captions improve access and are required by WCAG for prerecorded media when information is conveyed by sound. For small teams, automatic captions followed by a manual correction pass is a practical approach to reduce workload while improving accuracy.
Will accessibility help SEO?
Accessibility practices such as clear semantics, descriptive headings and meaningful link text overlap with SEO best practices and often improve crawlability and user experience. Accessibility alone is not a ranking guarantee.
What we did not establish
This guide does not assert that following its steps makes a site legally compliant in any jurisdiction. It does not list enforcement dates nor certify conformance. It does not name specific plugins or themes as guaranteed accessible without day-of-publication verification of vendor claims. It does not provide a paid audit or replacement for a formal remediation plan.
How this guide was compiled
The recommendations in this guide are based on WCAG 2.2 and guidance from WAI/W3C and WebAIM, and on common small-site workflows. Primary resources used are listed above with the consultation date September 27, 2026. The guide aims to help small teams prioritise fixes and to supply a practical testing workflow and checklist suitable for incremental implementation.
Related guides
Emma Collins
Emma covers e-commerce, website builders, design and AI tools. She compares platforms on the criteria a small business actually feels: setup time, running costs and lock-in.
Updated on September 27, 2026
