Ontario Access Check

Public sample

Abridged Sample Report

This is an abridged sample Fix Plan. It is not a named customer report. It shows how we review a homepage and each type of public task a website offers, then explain the verified problems we found.

A paid Fix Plan includes every verified problem in that scope. This public page shows two findings in full so you can see the format.

At a glance

What this sample shows

On this sample website, the homepage and a registration task were present. Contacting, donating, booking, applying, and buying were not present. The two findings below are the problems this abridged report explains in full: an unnamed header search control, and a dialog that traps keyboard focus.

Task coverage

A paid Fix Plan reviews your homepage and every type of public task your website offers. The table records what this sample website actually contained.

Task coverage for this sample website
Task type Available or not present Starting URL Safe stopping point checked Desktop checked Mobile checked Third-party boundary Representative sampling if used
Contacting Not present Not applicable Not applicable Not applicable Not applicable Not applicable Not used
Donating Not present Not applicable Not applicable Not applicable Not applicable Not applicable Not used
Registering Available https://fixture.invalid/form.html Stopped before submitting the form Yes Yes None on this sample website Not used
Booking Not present Not applicable Not applicable Not applicable Not applicable Not applicable Not used
Applying Not present Not applicable Not applicable Not applicable Not applicable Not applicable Not used
Buying Not present Not applicable Not applicable Not applicable Not applicable Not applicable Not used

The homepage at https://fixture.invalid/index.html was also reviewed on desktop and mobile.

Findings shown in this abridged report

  1. Dialog creates a keyboard trap — A keyboard user who opens the dialog cannot leave or dismiss it. Seen on both the phone and desktop layouts.
  2. Shared header icon button has no accessible name — The header search control is a button with no accessible name, so its action is not identified in the accessibility tree. Seen on both the phone and desktop layouts.

Shared header icon button has no accessible name

Impact A person using assistive technology that follows the accessibility tree may encounter a button with no name and may not know that it opens search. This is inferred from the accessibility-tree result below. A screen-reader check was not performed for this sample.

Do this Give the shared header button a concise accessible name that describes its action.

The same unnamed header search control appears on four page types in this sample.

Accessibility-tree result: Name: (none). Role: button. Expanded: not set. Help text: none associated.

Layouts Seen on both the phone and desktop layouts.

Technical record

Finding ID
F-001
Status
Confirmed
Priority
P2. An empty accessible-name computation repeats on the same shared header component across four templates, creating a serious identification barrier.
WCAG
WCAG 2.0 success criterion 4.1.2 Name, Role, Value (Level A). Ontario-required mapping target.
Root cause
The shared header button contains only an aria-hidden glyph and has no naming attribute.
Observed breadth
Four occurrences of shared-header/search-button on the home, form, widgets, and table templates.

Saved evidence

Accessible-name computation on [data-component="shared-header"] [data-oac-fixture="unlabeled-header-button"] returned an empty name on each of:

  • https://fixture.invalid/index.html
  • https://fixture.invalid/form.html
  • https://fixture.invalid/widgets.html
  • https://fixture.invalid/table.html

Reproduction

  1. Open any affected fixture template.
  2. Inspect the shared header search button in the accessibility tree.
  3. Confirm that its computed role is button and its computed accessible name is empty.

Verification

  1. Repeat the accessible-name computation on all four templates.
  2. Confirm that each header button exposes the intended action name.

Dialog creates a keyboard trap

Impact A keyboard user who opens the dialog cannot leave or dismiss it.

Do this Provide an operable keyboard close control, support Escape where appropriate, and contain focus without preventing an exit from the dialog.

After the dialog opens, Escape leaves it open and repeated Tab presses keep focus inside on the same reachable control.

Layouts Seen on both the phone and desktop layouts.

Technical record

Finding ID
F-005
Status
Confirmed — a repeatable check supports this issue
Priority
P1. A repeatable keyboard sequence traps focus in the opened dialog state.
WCAG
WCAG 2.0 success criterion 2.1.2 No Keyboard Trap (Level A). Ontario-required mapping target.
Root cause
The dialog prevents Tab and Escape, repeatedly returns focus to one control, and exposes its close control only outside the tab order.
Page and state
https://fixture.invalid/widgets.html, state dialog-open, component interactive-widgets/account-dialog.

Saved evidence

Keyboard sequence on [data-oac-fixture="keyboard-trap"]:

  1. Open the dialog
  2. Press Tab
  3. Press Escape

Recorded assertion: dialog_open true; focused selector [data-trapped-control]; keyboard_close_available false.

Reproduction

  1. Open the account notice with the keyboard.
  2. Press Tab and then Escape.
  3. Confirm focus remains on the same control and the dialog stays open.

Verification

  1. Open the repaired dialog and traverse all controls.
  2. Dismiss it with the visible keyboard-operable close control and confirm focus returns to the opener.

Technical appendix

This abridged sample is built from the repository’s controlled fixture. The fixture uses reserved fixture.invalid URLs. Findings below are copied from saved fixture evidence.

Pages and states reviewed

Five representative fixture pages or states:

  • https://fixture.invalid/index.html — controlled content-home template
  • https://fixture.invalid/form.html — controlled form template
  • https://fixture.invalid/widgets.html — controlled interactive-widgets template
  • https://fixture.invalid/table.html — controlled records-table template
  • https://fixture.invalid/clean.html — clean control used to test false-positive suppression

Fixture notes not shown as full findings

  • Add accessible names to the shared header buttons.
  • Repair the skip-link target.
  • Declare the widgets page language and descriptive title.
  • The custom Services menu opens only from pointer hover, so keyboard users cannot open it. That issue is listed here because this page is an abridged sample.

Operator terms

Seeded issues in the fixture affect keyboard navigation, control identification, form understanding, page orientation, and perception of content. The unnamed header control repeats under one stable component signature. Status wording that says deterministic evidence supports an issue belongs in this appendix, not in the customer summary.

Interpret carefully

What this sample cannot establish

  • This report covers automated and scripted tools used to collect evidence on a representative sample; these methods identify only part of the accessibility picture and can produce false or misleading results.
  • The Fix Plan is not legal advice, a VPAT, certification, or official conformance report.
  • Ontario mapping targets WCAG 2.0 Level A and AA, except live captions (1.2.4) and prerecorded audio description (1.2.5); newer-only criteria are separately labelled best practice.
  • The December 31, 2026 accessibility compliance reporting deadline is a government filing deadline for eligible organizations. This Fix Plan does not complete, replace, or guarantee that filing.