Quick answer
Accessibility In Web Design: WCAG Basics
Accessibility in web design means planning pages, controls, content, forms, and responsive behaviour so more people can use the site. WCAG 2.2 gives the reference framework, but a business website still needs manual review across priority templates and journeys.
Accessibility starts before code review
Accessibility in web design is easier to protect when it is planned before templates are confirmed. Page structure, content order, navigation, forms, component states, and responsive behaviour all affect whether the final website can be used by more people.
A launch team should not wait for an automated report at the end. The first review should happen when the sitemap, wireframes, content hierarchy, design system, and form flows are still flexible.
- Meaningful page titles, headings, landmarks, and content order
- Keyboard paths for menus, links, forms, cards, overlays, and calls to action
- Visible focus states that are not hidden behind sticky headers or modal layers
- Readable contrast, text sizing, spacing, and responsive reflow
- Alt text, captions, transcripts, and reduced-motion handling where needed
- Labels, instructions, errors, required states, and success states for forms
Share the current site and priority templates and we will identify the first accessibility risks to review before redesign or launch.
Get a 3-point project reviewHow WCAG 2.2 frames accessibility
WCAG 2.2 frames accessibility through four principles: perceivable, operable, understandable, and durable. Under those principles are testable success criteria at Levels A, AA, and AAA.
For most business websites, the practical design conversation often starts with Level A and AA fundamentals: structure that assistive technologies can understand, controls that work without a mouse, content that is readable, and interactions that do not create avoidable barriers.
WCAG 2.2 also makes newer interaction risks more visible, including focus not being obscured, alternatives to dragging movements, minimum target size, avoiding repeated entry, and accessible authentication patterns.
Practical checks for business websites
The useful starting point is to test priority templates and live buyer journeys, not only isolated components. A homepage, service page, pricing route, article, contact form, and checkout or enquiry flow can all fail in different ways.
Accessibility QA should combine automated scans with manual keyboard, screen reader, zoom, contrast, content, and form checks. Automation is helpful for repeatable defects, but it cannot prove the whole experience is accessible.
- Tab through the full page and confirm the order matches the visible journey
- Check every interactive element has a plain name, role, state, and focus style
- Confirm sticky headers, cookie banners, menus, and overlays do not hide focus
- Review headings, links, buttons, error messages, and labels in plain language
- Check touch targets, zoom, reflow, orientation changes, and reduced motion
- Test required fields, autocomplete, validation, confirmation, and failure states
What accessibility work does not prove
Accessibility work should not be presented as full WCAG conformance unless the scope, level, pages, technology stack, test methods, findings, exceptions, and retest status are plain.
A clean automated score is not enough. A redesigned website still needs manual review, issue tracking, content management, and future checks when new pages, forms, scripts, media, or third-party tools are added.
The safest commercial promise is practical: make accessibility visible during strategy, design, build, QA, and maintenance, then be specific about what has and has not been reviewed.
Accessibility review checklist
- Structure: meaningful headings, landmarks, page titles, and skip-link route.
- Keyboard: tab order, visible focus, no keyboard traps, and focus not hidden behind sticky UI.
- Content: descriptive links, alt text, captions or transcripts where needed, and plain error guidance.
- Forms: labels, instructions, errors, required states, autocomplete, and success or failure states.
- Responsive controls: touch target size, zoom and reflow behaviour, contrast, and motion sensitivity.
Common mistakes to avoid
- Treating automated accessibility scores as full WCAG conformance.
- Designing custom controls without keyboard and focus states.
- Checking color contrast while ignoring forms, headings, links, errors, and mobile interaction.
What 760 Studios would review first
- Priority templates and keyboard route
- Form labels, error states, and focus visibility
- What needs manual review before any conformance claim
Questions this article answers
What are the WCAG basics a business website should check first?
Start with headings, landmarks, keyboard access, visible focus, contrast, descriptive links, alt text, form labels, error messages, zoom/reflow behaviour, and whether important actions work without a mouse.
Does an automated accessibility scan prove WCAG compliance?
No. Automated scans are useful for repeatable issues, but they cannot prove the whole experience. Manual keyboard, screen reader, form, content, and responsive checks are still needed.
When should accessibility be reviewed during a redesign?
Review accessibility while sitemap, wireframes, design components, content order, and form flows are still flexible. Waiting until launch makes fixes slower and more expensive.
What should a business avoid claiming about accessibility?
Avoid full conformance claims unless the scope, pages, level, testing methods, findings, exceptions, and retest status are documented. Safer copy should name what has actually been reviewed.