An accessible business website lets people perceive its information, operate its controls, understand its instructions, and use it with compatible browsers and assistive technologies. For a contractor or Canadian small business, that includes the practical journeys that produce an enquiry: understanding a service, reading project evidence, calling, completing a quote form, using a calendar, and finding an alternate way to get help.

Accessibility is not a one-time scanner score or a widget installed after launch. It is a set of requirements for design, content, code, third-party tools, testing, procurement, and maintenance.

This checklist uses WCAG 2.2 Level AA as a useful current project target. It does not determine whether a specific law applies to a particular organization. Canadian requirements vary by jurisdiction, sector, organization type, size, content date, and other facts. Confirm the applicable rules and obtain qualified legal guidance where compliance decisions matter.

Begin with two written questions:

  1. Which legal, contractual, procurement, or policy requirements apply to this organization?
  2. Which technical accessibility standard will the website team use as its acceptance target?

Do not assume that “small business in Canada” produces one answer.

The Accessible Canada Act is a federal law aimed at removing and preventing barriers in areas under federal jurisdiction. Government guidance is directed to federally regulated public and private organizations, and regulations include requirements concerning accessibility plans, feedback processes, and progress reports. Provincial and territorial requirements may apply to other organizations.

Ontario provides a clear example of why the facts matter. Its official guidance says that, as of January 1, 2021, public websites controlled by designated public-sector organizations and businesses or non-profits with 50 or more employees must meet specified WCAG 2.0 Level AA requirements for covered content, subject to stated exceptions and details. Ontario also has broader information, communication, policy, training, and reporting requirements that cannot be reduced to a website checklist.

Record:

  • the provinces and territories where the organization operates;
  • whether it falls under federal regulation;
  • public-sector, private-sector, and non-profit status;
  • employee count and how the applicable rule calculates it;
  • contractual accessibility requirements from clients or procurement;
  • which public websites, applications, documents, and internal systems are in scope;
  • relevant publication and refresh dates;
  • the standard and conformance level named by each requirement; and
  • who is authorized to interpret obligations.

Use the legal baseline as a floor, not a reason to design new work against an older standard. W3C encourages use of the latest WCAG version. WCAG 2.2 is organized around four principles—perceivable, operable, understandable, and robust—with testable success criteria at Levels A, AA, and AAA. A team can target WCAG 2.2 AA for current development while documenting any different statutory wording that applies.

Inventory the customer journeys and content types

An accessibility review should cover representative templates and real tasks, not only the homepage.

Map the main journeys:

  • understand what the company does;
  • confirm the service area;
  • compare services or plans;
  • read a resource or case study;
  • navigate menus and breadcrumbs;
  • call, email, or use another contact route;
  • complete and correct a form;
  • use scheduling, chat, maps, or payment tools;
  • open a document or watch a video; and
  • recover when a third-party feature fails.

Then inventory the underlying content types:

  • headings, paragraphs, lists, tables, and links;
  • navigation, dialogs, accordions, tabs, and carousels;
  • buttons, forms, validation, and confirmation messages;
  • logos, icons, photographs, diagrams, and charts;
  • audio, video, captions, transcripts, and descriptions;
  • PDFs and other downloadable documents;
  • maps, review widgets, calendars, chat, and CRM embeds; and
  • authentication, payment, or customer portals.

Choose a representative test set that includes the most complex version of each component and every critical conversion path. A passing homepage does not prove that the quote form, calendar, or uploaded PDF is usable.

Build semantic structure before adding ARIA

Native HTML communicates roles and relationships to browsers and assistive technologies. Use it correctly before reaching for custom scripts or ARIA attributes.

  • [ ] Set the correct page language and identify meaningful language changes.
  • [ ] Use landmarks such as header, navigation, main, and footer appropriately.
  • [ ] Give each page one descriptive H1 and maintain a logical heading hierarchy.
  • [ ] Use real buttons for actions and real links for navigation.
  • [ ] Use lists for lists and tables for genuinely tabular data.
  • [ ] Give each page a unique, descriptive title.
  • [ ] Make link text meaningful in context.
  • [ ] Expose status, error, and confirmation messages programmatically.
  • [ ] Give custom controls an accessible name, role, state, and keyboard behaviour.

Do not add redundant ARIA to elements that already expose the correct semantics. A styled div with click handling is not automatically a button. If a native element can perform the task, it usually brings more reliable keyboard and assistive-technology behaviour.

Make every action work from a keyboard

Test without a mouse. Use Tab and Shift+Tab to move through interactive elements, Enter or Space where appropriate to activate them, arrow keys where a recognized component pattern requires them, and Escape to dismiss temporary layers when expected.

  • [ ] Every interactive control receives keyboard focus.
  • [ ] Focus order follows the visual and task sequence.
  • [ ] Focus is always visible against the surrounding colours.
  • [ ] No component traps focus unintentionally.
  • [ ] Opening a dialog moves focus to a sensible location.
  • [ ] Closing a dialog returns focus to the triggering control.
  • [ ] Skip links let users bypass repeated navigation.
  • [ ] Sticky bars and overlays do not cover the focused element.
  • [ ] Hover-only content is also available through focus or another persistent method.
  • [ ] Keyboard shortcuts do not conflict with assistive technology or typing.

Test at mobile widths and high zoom. Responsive layouts can rearrange visual elements without changing the DOM order, producing a focus sequence that no longer makes sense.

Keep text and controls perceivable

Colour, spacing, zoom, and reflow affect whether content can be read and operated.

  • [ ] Text and meaningful interface components meet the chosen contrast requirements.
  • [ ] Information is not communicated by colour alone.
  • [ ] Links are distinguishable from surrounding text.
  • [ ] Text can resize without clipping, overlap, or loss of functionality.
  • [ ] Pages reflow at narrow widths without requiring two-dimensional scrolling except where the content genuinely needs it.
  • [ ] Controls have a usable target size and sufficient spacing.
  • [ ] Focus indicators are not hidden by outlines being globally disabled.
  • [ ] Motion respects reduced-motion preferences where appropriate.
  • [ ] Flashing content is avoided.
  • [ ] Instructions do not rely only on shape, colour, location, or sound.

Check real states, not just the design system swatches. Placeholder text, disabled controls, validation errors, visited links, image overlays, and text placed over photography are frequent failure points.

Design forms around recovery, not just submission

Contractor quote forms and booking paths are business-critical. They also combine labels, instructions, validation, consent, status messages, and third-party handoffs.

  • [ ] Associate a persistent label with every input.
  • [ ] Explain required fields before or at the field.
  • [ ] Use instructions that do not disappear when the user types.
  • [ ] Group related choices with a fieldset and legend where appropriate.
  • [ ] Use input purposes and autocomplete tokens accurately.
  • [ ] Identify errors in text and connect them to the relevant field.
  • [ ] Move focus to, or summarize, errors in a predictable way after submission.
  • [ ] Suggest a correction when one is known.
  • [ ] Preserve valid entries after an error.
  • [ ] Provide review or correction steps for consequential submissions where required.
  • [ ] Announce successful submission without relying only on colour or a visual animation.
  • [ ] Offer a clear non-form contact route.

Avoid CAPTCHA where possible. When abuse protection is necessary, assess whether the method creates a visual, auditory, cognitive, or keyboard barrier and provide an accessible alternative.

Test the complete production chain: website form, consent controls, CRM receipt, confirmation screen, email or text confirmation, and the path back after an error. A technically labelled input does not make an inaccessible embedded calendar acceptable.

Give images the right text alternative

Alternative text depends on purpose, not file content alone.

  • Informative image: describe the information needed in context.
  • Functional image: describe the action or destination.
  • Decorative image: use an empty text alternative so it can be ignored.
  • Complex chart or diagram: provide the key conclusion and a nearby detailed text equivalent.
  • Image of text: replace it with real text unless the visual presentation is essential.

For contractor project galleries, avoid stuffing service and city keywords into every alt attribute. Describe what the image contributes to the page. If the photo is evidence, its caption may need the approved project context, while the alt text should remain concise and useful.

Icons inside labelled buttons may be decorative. An icon-only button needs an accessible name that describes its action. Do not rely on a tooltip that appears only on hover.

Plan audio and video accessibility before recording

W3C's media guidance distinguishes captions, transcripts, and description because they solve different access needs.

  • [ ] Provide accurate captions for speech and meaningful non-speech audio where required.
  • [ ] Provide a transcript for audio information and as a useful companion to video.
  • [ ] Describe essential visual information for people who cannot see it.
  • [ ] Use a media player that supports keyboard and assistive-technology operation.
  • [ ] Avoid autoplay with sound.
  • [ ] Give users control over playback.
  • [ ] Check that captions remain readable over changing backgrounds.
  • [ ] Include speaker identification and relevant sound cues.

Plan the script so important visual information is spoken naturally. That can reduce the amount of separate description required and improve the main presentation. Automatically generated captions need human review; a caption file existing is not evidence that names, technical terms, punctuation, or timing are accurate.

Treat documents and third-party tools as part of the website

A crawlable HTML page is often easier to use and maintain than a PDF, but some businesses need downloadable estimates, guides, forms, or policies. Those files require their own heading structure, reading order, link text, table semantics, form labels, language, title, and alternative text.

Do not upload a scanned page and assume browser OCR makes it accessible. Provide an accessible HTML alternative where practical and test the document with appropriate tools.

For third-party features, record:

| Component | Accessibility evidence | Failure fallback | Owner | | --- | --- | --- | --- | | Booking calendar | Keyboard, labels, errors, zoom, screen-reader checks | Phone or accessible request form | Operations | | Map | Accessible location and service-area text | Address or coverage list | Content | | Chat widget | Focus, name, announcements, close behaviour | Contact page | Marketing | | Payment or portal | Vendor conformance evidence plus task testing | Supported alternate process | Operations |

A vendor badge or conformance statement is useful input, not final acceptance. Test the exact configured version in the real page. Establish how accessibility defects are reported, escalated, and replaced if the vendor does not fix them.

Combine automated, manual, and user testing

W3C notes that evaluation tools can save time but cannot check everything and can produce inaccurate results. A credible release gate uses several methods.

Automated checks

Run an accessibility testing tool on representative pages and components. Automated tests can identify issues such as missing accessible names, some contrast failures, invalid relationships, and certain structural problems. Keep results tied to the tested URL, build, viewport, and date.

Manual checks

  • Complete every critical journey using only a keyboard.
  • Test zoom, text resize, and narrow reflow.
  • Inspect headings, landmarks, names, roles, states, and live messages.
  • Review alternative text against image purpose.
  • Verify colour is not the only signal.
  • Check captions, transcripts, and descriptions.
  • Confirm errors can be found, understood, and corrected.

Assistive-technology checks

Test representative journeys with combinations that reflect the supported environment, such as a screen reader with a commonly used browser. Do not claim universal compatibility from one device or one tester.

Testing with people with disabilities

Include people with disabilities in research and usability testing where possible, compensate them appropriately, and do not use their participation as a substitute for meeting technical requirements. Real use can reveal barriers that checklists miss.

Record defects by user impact, affected journey, standard reference, reproduction steps, owner, fix, retest evidence, and residual limitation.

Create an accessible publishing workflow

The website can regress after launch even when its templates begin in good condition.

Give content editors practical controls and training:

  • require a heading outline rather than formatting text to look like a heading;
  • require purposeful alternative text decisions for images;
  • prevent empty link labels and vague repeated links;
  • provide accessible table patterns;
  • include caption and transcript fields for media;
  • publish accessible document templates;
  • preserve visible focus and component semantics in theme controls; and
  • schedule review for time-sensitive instructions and third-party embeds.

Nexxen's preferred acceptance pattern is to connect each requirement to evidence. For example, a rendered-page test can confirm one H1 and crawlable links, while manual keyboard, zoom, form-error, media, and assistive-technology checks cover behaviours that a server-rendering test cannot prove. This distinction prevents a green automated test from being described as full WCAG conformance.

Use a launch and maintenance checklist

Before launch:

  • [ ] Legal and contractual scope has an identified owner.
  • [ ] The project target and WCAG version are documented.
  • [ ] Critical journeys and representative templates are inventoried.
  • [ ] Semantic structure and keyboard operation pass.
  • [ ] Focus, contrast, zoom, reflow, and target-size checks pass.
  • [ ] Forms support labels, instructions, errors, recovery, and confirmation.
  • [ ] Images, media, and documents have appropriate alternatives.
  • [ ] Third-party components pass task testing or have usable fallbacks.
  • [ ] Automated, manual, and assistive-technology evidence is recorded.
  • [ ] Known limitations have owners, dates, and interim alternatives.
  • [ ] Editors know how to publish accessible updates.
  • [ ] Users have an accessible way to report a barrier.

After launch:

  • retest after design-system, navigation, form, and vendor changes;
  • include accessibility checks in new-page and campaign approvals;
  • review feedback and support requests for recurring barriers;
  • test new browsers, devices, and assistive-technology combinations proportionately;
  • monitor documents and media added outside the main CMS;
  • keep the public accessibility information accurate; and
  • review the applicable legal and technical standards for changes.

An accessibility statement or feedback notice must reflect the real organization, scope, contact route, known limitations, and applicable requirements. Do not copy another company's legal wording or claim conformance without sufficient evidence.

Make accessibility part of website quality

Accessibility belongs beside performance, security, privacy, SEO, and conversion—not after them. The contractor website design checklist covers the broader architecture and lead journey. The Core Web Vitals guide addresses loading, responsiveness, and visual stability, which are related quality concerns but do not prove accessibility.

For implementation help, website development in Canada should define accessible components, content rules, third-party acceptance criteria, testing evidence, and maintenance ownership before launch.

The useful outcome is not a perfect score. It is a website where fewer people encounter preventable barriers, critical tasks remain usable, defects have accountable owners, and accessibility continues after the initial build.