Ontario Access Check

Public sample

Sample Fix Plan

This is a sample Fix Plan built from the repository’s controlled fixture. It is not a named customer report.

The fixture uses reserved fixture.invalid URLs. Findings below are copied from saved fixture evidence. This is not a certification, legal opinion, or complete accessibility audit.

At a glance

Executive action summary

The seeded issues affect keyboard navigation, control identification, form understanding, page orientation, and perception of content.

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

Three most important fixes

  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. Custom menu opens only from pointer hover — Keyboard users cannot open the Services menu. Seen on both the phone and desktop layouts.
  3. Shared header icon button has no accessible name — Screen reader users may encounter an unnamed header control and cannot determine its action. Seen on both the phone and desktop layouts.

Fastest useful improvements

  • Add accessible names to the shared header buttons.
  • Repair the skip-link target.
  • Declare the widgets page language and descriptive title.

Repeated shared components

  • The unnamed icon button repeats in the shared header across four templates.

Shared header icon button has no accessible name

Impact Screen reader users may encounter an unnamed header control and cannot determine its action.

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

Across four templates, the same shared-header icon button exposes an empty accessible name under one stable component signature.

What a screen reader would hear: Name: (none). Role: (none). Expanded: not set. Help text: none associated.

Layouts Seen on both the phone and desktop layouts.

Technical record

Finding ID
F-001
Status
Confirmed — deterministic evidence supports this issue
Priority
P2. A deterministic 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 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.

Interpret carefully

What this sample cannot establish

  • This controlled 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.