Start with the purpose of WCAG
The Web Content Accessibility Guidelines, usually called WCAG, describe ways to make web content more usable for people with disabilities. They address barriers that can affect people who use a keyboard, a screen reader, magnification, captions or other ways of accessing a site. For a small website, the goal is practical: visitors should be able to find information and complete important tasks without avoidable obstacles.
WCAG is organized around four principles. Content should be perceivable, operable, understandable and robust enough to work with a range of technologies. Under those principles are specific, testable requirements called success criteria. Each criterion has a level: A, AA or AAA. These levels help describe the scope of accessibility requirements; they are not a score for how welcoming a site feels.
What Level A covers
Level A addresses fundamental barriers. For example, WCAG includes Level A requirements for text alternatives to meaningful non-text content, keyboard access to functionality, and captions for prerecorded video with audio. A visitor may be unable to use an image-based control if it has no accessible name, or unable to submit a form if an essential step requires a mouse.
Meeting Level A does not mean a site is fully accessible. It means the applicable Level A success criteria have been met for the pages being assessed. That distinction matters because a page can pass those criteria and still have problems covered at Level AA. Think of Level A as a necessary foundation, not a stopping point.
What Level AA adds
Level AA builds on Level A: to meet Level AA, a page must meet the applicable criteria at both levels. AA includes requirements that make common experiences easier to use, such as sufficient contrast for most text, visible keyboard focus, and headings and labels that describe their topic or purpose. These details can determine whether someone can read a navigation link, tell where they are while tabbing, or understand what a form field requests.
The exact requirements depend on the WCAG version you use. For example, WCAG 2.2 includes some criteria that earlier versions do not. Record the version and level when setting a goal or discussing an assessment, rather than saying only that a site is “WCAG compliant.” A useful statement identifies what was reviewed and against which version and level. Even then, a claim of conformance requires careful evaluation; completing a checklist or running an automated scan is not enough.
Apply the levels to real visitor tasks
Begin with the pages and journeys that matter most: the home page, navigation, service descriptions, contact information and any forms or booking steps. Try reaching each task with a keyboard alone. Can you see which link or control has focus? Can you open menus, complete fields, correct errors and submit without getting trapped? Next, review the same journey at a narrow screen width and with enlarged text.
Look at the content as well as the interface. Give meaningful images alternatives that convey their purpose; decorative images generally should not add unnecessary spoken output. Use descriptive headings in a logical order, write link text that makes sense in context, and pair form fields with clear labels. If you publish video, plan for captions where required. Contrast also deserves a deliberate check: a color combination that looks clear on one screen may be difficult to read elsewhere.
Automated tools can help flag some missing labels, contrast problems and code issues. They cannot reliably decide whether alternative text is useful, whether instructions make sense, or whether a task is genuinely manageable. Combine tool results with keyboard checks, content review and, where possible, feedback from people using different access methods.
Make accessibility part of maintenance
A small team does not have to fix everything in one pass to make progress. Keep a short issue list with the affected page, the problem, its impact and an owner. Prioritize barriers that block essential tasks, then address recurring components such as the site header, form templates and content styles. Fixing a shared pattern can improve many pages at once.
Use an agreed WCAG version and Level AA as a reference point for reviews, while remembering that accessibility is also an ongoing editorial and design practice. Check new pages before publishing, retest important tasks after template changes, and make it easy for visitors to report difficulties. The levels give your team a common language; regular attention helps turn that language into a more usable website.
