Website Accessibility Basics and WCAG Principles

Website accessibility means a visitor can perceive, operate, and understand the site even when they do not use a mouse, do not see the screen well, or use assistive software. The Web Content Accessibility Guidelines (WCAG) organise the requirements. The four principles are known as POUR: perceivable, operable, understandable, and robust.

This is a practical starting set for brochure and marketing sites. It is not a conformance certificate and not a full WCAG audit. Use the current W3C WCAG recommendation when you need the normative wording.

Perceivable

People must be able to take in the content.

• Text contrast against its background should meet WCAG contrast ratios for normal and large text. Do not put grey body text on a tinted photograph.
• Information must not rely on colour alone. An error needs text, not only a red border.
• Images that convey meaning need alternative text. Decorative images should be hidden from assistive tech. Details are in website images.
• Video and audio need captions or a transcript when the spoken content matters.

Operable

People must be able to use the controls.

• Every action works from a keyboard, in a sensible order.
• Focus is visible. Do not remove the outline unless you replace it with a clearer indicator.
• Menus, dialogs, and cookie banners can be reached and dismissed without a pointer.
• Touch targets are large enough that neighbouring links are not a mis-tap. Layout changes across widths are covered in responsive breakpoints.

Understandable

• The page language is set in the HTML so pronunciation tools guess correctly.
• Headings follow the page structure. They are not chosen only to look bold.
• Labels and instructions sit with the fields. Form patterns are in website form usability.
• Navigation labels stay consistent from page to page.

Robust

Use semantic elements: buttons for actions, links for navigation, labels tied to inputs. Custom widgets need the keyboard and name behaviour that the native control would have had. Content that updates without a page load, such as a form error, should be announced in a way assistive tools can detect.

A checklist you can repeat each release

Keep the pass short enough that it happens on every template change, not only before a launch announcement.

• Page title and the main heading describe the same topic.
• Focus order follows the visual order, including the mobile menu.
• Buttons have a visible name, not only an icon.
• Form errors are text next to the field.
• Motion can be paused, and nothing flashes.

Record failures as page bugs with an owner. “We will do accessibility later” usually means the menu is rebuilt without keyboard support in the next redesign.

A practical example

A homepage hero puts white text on a bright photo. It looks sharp on the designer’s monitor and fails contrast in sunlight. The fix is a solid panel behind the text, not a thinner font. The carousel beside it can only be advanced by a hover arrow. Adding previous and next buttons that receive keyboard focus, and pausing motion, makes the same photos operable.

Key takeaways

• Start with keyboard use, visible focus, contrast, labels, and alternative text.
• Colour alone must not carry meaning.
• Native controls are easier to get right than restyled divs.
• A quick pass finds obvious blockers. It does not replace a WCAG review when you need one.

FAQ

Is accessibility only for public-sector sites?

No. Any public website has visitors who zoom, use keyboards, or run assistive tools. The legal duty depends on context. The practical benefit shows up for everyone on a phone in bright light.

Do overlays that promise compliance replace this work?

A banner that claims to fix accessibility does not repair missing labels, poor contrast, or an unusable menu. Fix the page.

Which WCAG level should we aim for?

Many teams use WCAG 2.2 Level AA as the working target. State the version you tested against, and keep a list of known gaps instead of claiming a perfect score.