A useful website accessibility checklist asks one practical question: can people with different ways of seeing, hearing, moving, reading, and navigating complete the important tasks on this site? For a business website, those tasks usually include understanding the offer, comparing services, reading evidence, contacting the team, submitting a form, and receiving a clear confirmation.
Start with the highest-value journeys, test them with a keyboard and on a small screen, then review structure, labels, contrast, media, forms, and feedback. Accessibility is not a decorative score added after launch. It is a quality discipline that makes the same business journey more dependable for more people.
This guide is written for website owners and marketing teams. It is not a legal compliance opinion and it cannot replace testing with disabled users. It gives you a practical operating checklist based on the Web Content Accessibility Guidelines, W3C authoring guidance, and common interaction patterns.
Begin with real visitor tasks
Do not start by opening a long checklist and inspecting random components. First write down the three to five tasks that matter most to your visitors and your business. A service company may choose: understand a service, compare proof, request an audit, contact the team, and read the submission confirmation. An online store may choose: find a product, understand its options, add it to the cart, pay, and read the order confirmation.
Run every later check against those journeys. This keeps the review connected to outcomes. A technically neat footer does not compensate for a contact form that cannot be completed with a keyboard. A perfect colour palette does not help if a screen reader user cannot identify the error that blocked submission.
If the journey itself is confusing, review the website design and development service and the agency's working process before treating accessibility as an isolated patch.
Check keyboard access from start to finish
Put the mouse aside and use Tab, Shift plus Tab, Enter, Space, and the arrow keys where a component requires them. You should be able to reach every interactive control in a logical order, understand which control has focus, operate it, and move away without getting trapped.
- Provide a visible focus indicator that remains easy to see against the surrounding colour.
- Make sure menus, accordions, tabs, dialogs, carousels, filters, and form controls work without a mouse.
- Place focus inside an opened dialog and return it to the triggering control when the dialog closes.
- Do not create keyboard shortcuts that surprise users or conflict with assistive technology.
- Add a useful skip link so repeated navigation can be bypassed.
The W3C ARIA Authoring Practices keyboard guidance is helpful when you build custom interactive components. Native HTML controls are usually the safer starting point because browsers already understand much of their expected behaviour.
Give every page a meaningful structure
A page should make sense before its visual styling is applied. Use one clear H1, then arrange H2 and H3 headings in a logical hierarchy. Headings should describe the section that follows, not simply create large text. Use real lists for grouped items, real tables for data, and landmarks such as header, navigation, main, and footer for major regions.
Give the page a descriptive title and make link text understandable out of context. Repeated links called “learn more” force the reader to reconstruct meaning from nearby copy. “View website design services” is more useful because it names the destination.
Also check that the reading order in the source matches the visual order. Complex grid layouts can look correct while sending keyboard or screen reader users through content in an unexpected sequence.
Make text readable when it changes size
Visitors may zoom, increase text size, use a narrow viewport, or apply personal display settings. Test at 200 percent browser zoom and at a small mobile width. Important content and controls should remain available without overlapping, clipping, or forcing unnecessary horizontal scrolling.
- Use a comfortable base font size and line height.
- Keep paragraph widths readable rather than stretching copy across the full screen.
- Do not place essential text inside an image.
- Allow components to grow when text wraps to a second or third line.
- Check that buttons do not truncate translated or enlarged labels.
For a broader review of page clarity, compare the result with the examples in the Vedam Vision portfolio and the practical guidance in the Vedam Vision blog.
Use contrast and colour with care
Text, icons, form boundaries, and focus indicators need enough contrast against their backgrounds. WCAG 2.2 provides specific contrast requirements, but the business review should go beyond sampling a single colour pair. Check normal, hover, active, disabled, error, success, and focus states. A button may pass in its default state and become unreadable when hovered.
Never use colour as the only signal. Add a text label, symbol, pattern, or structural cue. For example, an error field should not be identified only by a red border. Pair it with a short message that explains what went wrong and how to fix it.
Label controls and forms clearly
Every input needs a programmatically associated label. Placeholder text is not a replacement because it disappears while someone types and may have weak contrast. Group related options with a fieldset and legend where appropriate. Tell people which fields are required before submission and use instructions that are specific enough to prevent avoidable errors.
Then test the complete form, not only the empty state:
- Move through fields using only the keyboard.
- Submit with one required field empty.
- Confirm that focus or a clear summary leads to the error.
- Correct the value and submit again.
- Verify that the success message is announced and explains what happens next.
For the highest-value lead journey, test the free website audit form and the contact page in production. A form that works only in a visual preview is not finished.
Write useful alternatives for images and media
Informative images need alternative text that communicates their purpose in the current context. Decorative images should normally have an empty alternative so assistive technology can ignore them. Charts and process diagrams may need a concise alternative plus a longer explanation in nearby text.
For video, provide captions for spoken content and meaningful sounds. Add a transcript when it helps people review the information in another format. Avoid autoplay with sound. If moving content starts automatically, provide controls that are easy to find and operate.
Do not repeat the same information in the filename, caption, and alternative text. Write each element for its job. The alternative identifies the image's contribution, while the caption can add context for everyone.
Protect users from motion, time limits, and interruptions
Animations, auto-rotating carousels, flashing content, and unexpected popups can make a page difficult or unsafe to use. Respect reduced-motion preferences and provide pause controls when content changes automatically. Keep important information available long enough to read.
Review chat buttons, cookie notices, sticky contact bars, and promotional overlays together. Each may look harmless in isolation, but their combined layers can cover content, trap focus, or make the final call to action unreachable on mobile. The solution is often fewer competing elements, not a higher stacking value.
Make touch targets and mobile layouts forgiving
People using a phone may have limited dexterity, temporary injury, a small screen, or a moving environment. Controls should have sufficient size and spacing, and their visible label should match the action they perform. Web.dev's accessible tap-target guidance explains why small or crowded controls cause errors.
Test the menu, forms, filters, chat launcher, close buttons, and footer links with one thumb. Rotate the device, increase text size, and repeat the main journey. Mobile accessibility is part of the same responsive quality system covered in the services overview, not a separate version of the site.
Use status messages that assistive technology can detect
When a form saves, a filter updates results, an item is added, or an error appears, the change should be communicated without forcing the user to hunt for it. Use appropriate live regions or status semantics carefully. Too many announcements become noise, while no announcement leaves the user unsure whether anything happened.
Write plain messages such as “Your request was sent. We will reply by email” instead of a vague “Success.” If a process will take time, state that clearly. Accessibility improves trust when the system consistently explains its current state.
Review documents and third-party tools
Your website journey may depend on embedded calendars, payment tools, maps, videos, chat systems, downloadable PDFs, or external forms. Include them in the review. A page can pass its internal checks while a required third-party step remains unusable.
Ask vendors for current accessibility documentation, but verify the actual implementation. If an essential tool has a barrier you cannot fix immediately, provide an equivalent route such as email, phone, or a simple internal form. Document the limitation, owner, and target date instead of hiding it.
Use a layered testing method
No single tool can prove that a website is accessible. Automated testing is useful for repeatable signals such as missing alternatives, structural errors, and some contrast problems. Manual keyboard testing reveals focus, order, operation, and trapping issues. Screen reader testing helps verify names, roles, states, and announcements. Zoom and mobile testing reveal reflow and overlap problems. Testing with disabled users reveals barriers that the project team did not anticipate.
Use this release sequence:
- Review the page structure and accessible names in development.
- Run automated checks and resolve confirmed issues.
- Complete every priority journey with only a keyboard.
- Test representative pages with a screen reader and browser zoom.
- Check small screens, touch interaction, orientation, and overlays.
- Repeat critical checks after deployment on the live URL.
Store the result in a simple issue log with the page, barrier, affected task, severity, owner, evidence, and verification status. The case-study library can help teams think in complete journeys rather than disconnected interface details.
Prioritise barriers by user and business impact
Fix blockers before cosmetic imperfections. A contact form that cannot be submitted, a menu that cannot be opened by keyboard, a dialog that traps focus, or a checkout error that is never announced deserves immediate attention. Next address barriers that make a task slow, confusing, or error-prone. Lower-severity cleanup can follow in the normal design system backlog.
Also fix the source component, not only the page where the issue was reported. If every service page uses the same inaccessible accordion, update the shared component and verify all affected pages. This turns accessibility work into durable system improvement.
Know what this checklist cannot prove
A checklist cannot certify legal compliance, represent every disability, or guarantee that future content will remain accessible. Standards also require interpretation in context. A technically valid label can still be confusing. A contrast ratio can pass while the overall visual hierarchy remains difficult to understand.
Treat this guide as a repeatable quality baseline. Combine it with WCAG 2.2, appropriate legal advice for your markets, testing by qualified practitioners, and feedback from disabled users. Recheck templates whenever navigation, forms, chat tools, or the design system changes.
Turn the checklist into an operating habit
Add accessibility acceptance criteria to briefs, component reviews, content publishing, and release checks. Give one person responsibility for closing each issue, but make every contributor responsible for preventing new barriers. Designers should define states and contrast. Developers should preserve semantics and keyboard behaviour. Writers should create descriptive links, headings, and alternatives. Website owners should fund testing and remediation.
If you want a structured starting point, request a free audit or use the contact page to describe the journey that matters most. The useful first conversation is not “Can you make the score green?” It is “Can every intended visitor understand and complete this task?”
