Use current accessibility guidance
W3C recommends using WCAG 2.2 when developing or updating accessibility policies. WCAG 2.2 extends earlier versions and adds criteria covering areas such as focus visibility, target size, dragging movements, redundant entry and accessible authentication.
Canadian requirements vary by jurisdiction and type of organization, so this guide is not a substitute for legal advice. Accessibility Standards Canada publishes standards and technical guidance, while provinces may have their own rules.
Start with semantic HTML
Headings should describe the page structure. Forms need associated labels. Buttons should be buttons when they trigger actions. Links should have meaningful destinations. Landmarks such as main content and navigation help assistive technology understand the page.
Keyboard and focus testing
Try the site without a mouse. The focus indicator should remain visible, menus should be operable, dialogs should not trap users unexpectedly and interactive elements should appear in a sensible order.
Contrast, reflow and target size
Text needs adequate contrast. Content should reflow at smaller widths without forcing two-dimensional scrolling for ordinary reading. Touch targets should be large enough to use reliably.
Forms need more than placeholders
Placeholders disappear while typing and should not replace labels. Required fields, errors and instructions should be communicated clearly, and error recovery should not depend on colour alone.
Accessibility starts with structure
Semantic HTML provides a useful foundation because headings, landmarks, lists, buttons, links and form controls already carry meaning that assistive technologies can use. Replacing these with generic containers and custom click handlers creates extra work and often introduces problems that could have been avoided.
Use one clear main landmark, a sensible heading hierarchy, descriptive page titles, visible focus states and controls that can be reached and operated with a keyboard. Form fields should have labels, error messages should be understandable, and interactive components should not depend on hover alone.
Design for more than perfect conditions
Readable contrast, resizable text, sufficient spacing and responsive layouts also help people using small screens, older devices, high zoom levels or difficult lighting. Accessibility work frequently improves ordinary usability because it forces the design to be clearer about hierarchy and interaction.
Audit the components that repeat everywhere
A navigation menu, dropdown, form pattern or card component can appear across dozens of pages. Fixing accessibility at the component level has a much larger effect than correcting isolated pages one at a time. This is why design systems should include keyboard behaviour, focus, labels and responsive states alongside colours and spacing.
Projects such as Burnaby-Lawyers.com and CoquitlamLimo.ca are useful live examples for reviewing readable page structure, navigation and mobile presentation. They should still be tested independently rather than assumed compliant because they look clean.
Do not treat automated scores as the final answer
Automated testing can catch missing labels, contrast failures, landmark problems and some ARIA issues, but it cannot fully judge whether content is understandable, keyboard order is sensible or an interaction makes sense to a real user. Combine automated tools with keyboard testing, zoom testing and manual review.