Accessibility is easier and more effective when it is part of the website requirement from the beginning. It affects typography, contrast, keyboard interaction, forms, content structure, media and the components editors will use after launch.
Set an explicit standard
If the organisation has a required accessibility target, state it in the brief or TOR. This gives designers, developers and testers a shared acceptance point.
Include content responsibilities
Headings, link text, alternative text, document accessibility and captions are partly content issues. A technically accessible template cannot compensate for inaccessible publishing practices.
Test interaction, not only appearance
Keyboard access, focus states, form labels, error messages and menu behavior should be checked with real interaction. Automated tools are useful but do not detect every usability problem.
Account for third-party tools
Booking widgets, payment interfaces, embedded maps and other vendor components can introduce accessibility limitations outside the theme code. These dependencies should be identified.
Protect accessibility after launch
Editors need guidance so routine updates do not undo accessible patterns. Governance matters as much as the launch audit.
What to do next
Use this as a working checklist for your organisation, then adapt it to the actual platform, risk and procurement context. If you are preparing a website project, takeover or ongoing support requirement, WebNT can review the scope with you before implementation begins.