Website Accessibility: WCAG Basics for Business Owners

Accessibility is often framed as a specialist topic, but most of it is ordinary quality work. The Web Content Accessibility Guidelines organize the subject into four principles: content must be perceivable, interface elements must be operable, language and behavior must be understandable, and the result must work with the assistive technology people actually use. Those four ideas cover the majority of barriers found on business websites.

Perceivable starts with contrast and alternatives. Body text needs a contrast ratio of at least 4.5 to 1 against its background, and larger text needs at least 3 to 1. Images that carry meaning need text alternatives; decorative images need empty ones so screen readers skip them. Video needs captions, and any information conveyed by colour alone needs a second cue, such as an icon or label.

Operable means the site works without a mouse. Every interactive element should be reachable and usable by keyboard, with a visible focus indicator that is not suppressed for aesthetic reasons. Menus and modals must not trap focus. There should be a way to skip repeated navigation, and tap targets should be large enough to use on a phone. Avoid time limits that cannot be extended, respect reduced-motion preferences for animation, and never autoplay media that cannot be paused.

Understandable covers language and predictability. Headings should describe their sections, links should say where they go rather than 'click here', and navigation should stay in the same order across pages. Forms should label every field visibly, identify errors in text, explain how to correct them, and avoid surprising behavior like changing context when a field receives focus.

Readable content is part of the standard, not a separate editorial concern. Short sentences, common words, clear headings, and descriptive page titles help everyone, and they matter more for readers with cognitive disabilities or limited language proficiency. Text should remain usable when zoomed to two hundred percent, and layouts should not force horizontal scrolling. If a page cannot be understood at first read, no amount of technical compliance will make it genuinely accessible.

Robust is about clean foundations. Use native HTML elements for their intended purposes instead of rebuilding buttons and inputs from generic containers. Add ARIA attributes only when native semantics fall short, because incorrect ARIA is worse than none. Test with a screen reader at least once per project to hear the page the way a real user will encounter it.

Third-party content is often overlooked. Chat widgets, embedded maps, payment frames, and review carousels carry their own accessibility behavior, and an audit that stops at your own code will miss them. Ask vendors for their accessibility documentation, test the widget by keyboard, and keep a fallback such as a phone number or plain contact form for anything critical. Content editors need guidance too, since most accessibility regressions enter through new pages and images, not through releases.

Forms are where accessibility problems cluster most densely. Labels must be programmatically associated with their inputs, required fields should be indicated in text as well as colour, and error summaries should link to the fields they describe. Group related controls such as radio buttons with a fieldset and legend. These changes usually improve completion rates for everyone, not just assistive technology users.

An audit mixes automated and manual methods. Automated tools can catch missing alt text, low contrast, and structural issues quickly, but they cannot judge whether a text alternative is meaningful or whether a flow makes sense. A useful audit combines tooling with keyboard-only navigation, screen reader checks, and testing at different zoom levels. Expect the report to prioritize issues rather than simply list them. A findings list without severity is just a longer to-do list.

Legal exposure varies by country and sector, and it is easy to overstate or dismiss it. Public sector and publicly funded organizations in many jurisdictions have explicit requirements, and private businesses increasingly face complaints when barriers are obvious. The practical response is not fear but focus: fix the issues that block people from using core journeys, then work through the rest in planned increments.

Prioritize by impact. Contrast on body text, keyboard access to navigation and forms, meaningful alt text for key images, and correctly labeled inputs address most real-world barriers. Then move to deeper items such as complex widget patterns, dynamic content announcements, and document accessibility. Record what is fixed and what remains, so progress is visible and priority conflicts are resolved with evidence.

Accessibility regresses unless it is built into routine work. Add an accessibility section to design reviews, include states and labels in component definitions, check contrast before approving palettes, and test key journeys before each release. Training helps, but process is what makes the difference. Assign the checklist to a role rather than to someone's spare time. A site that is accessible at launch and inaccessible a year later is not an accident; it is a missing habit.