Vayle
← Guides

Mobile and Touch Accessibility: What Ontario's AODA and WCAG Require for Phone Users (2026)

Tap targets too small, drag-only controls, text that won't reflow — mobile failures lock out customers and scanners miss them. Here's what WCAG and Ontario's IASR require, and how to check.

Illustration of a thumb tapping a phone screen with the WCAG 2.2 minimum tap-target size of 24 by 24 CSS pixels highlighted, Vayle mobile accessibility guide

Most of the people who reach your Ontario business reach you on a phone. They browse with a thumb, often one-handed, sometimes on a moving bus, sometimes with a tremor or limited fine motor control, sometimes with the text size cranked up because their vision is low. If your buttons are too small to tap reliably, if a control only works by dragging, or if your text won't reflow when zoomed, those customers can't complete a purchase — and unlike a missing-page error, nothing crashes to tell you. The visitor just leaves. These touch failures are also among the hardest for an automated scanner to catch, which is exactly why they survive to the point of a complaint.

Key facts

  • WCAG 2.5.8 Target Size (Minimum) is Level AA and new in WCAG 2.2 (Web Content Accessibility Guidelines): interactive targets must be at least 24 by 24 CSS pixels, or have 24 CSS pixels of spacing from adjacent targets, with an exception for links inside sentences (W3C, WCAG 2.2).
  • WCAG 2.5.5 Target Size (Enhanced) sets the higher bar at 44 by 44 CSS pixels, but that is Level AAA — best practice, not the AA requirement (W3C).
  • WCAG 2.5.7 Dragging Movements is Level AA and new in WCAG 2.2: any drag action (a slider, a drag-to-reorder list, a map) must offer a single-pointer alternative such as buttons (W3C, WCAG 2.2).
  • Ontario's IASR (Integrated Accessibility Standards Regulation, O. Reg. 191/11) s.14 requires organizations with 50 or more employees to meet WCAG 2.0 Level AA — a floor that predates the touch-specific 2.1 and 2.2 criteria but already includes 1.4.4 Resize Text (text resizable to 200%) (ontario.ca, O. Reg. 191/11).
  • The next ACR (Accessibility Compliance Report) deadline for Ontario organizations with 20 or more employees is December 31, 2026 (ontario.ca).
  • 5,114 ADA (Americans with Disabilities Act) digital accessibility lawsuits were filed across US federal and state courts in 2025, with mobile apps and online booking systems increasingly named among the targets (UsableNet, 2025 Year-End Accessibility Lawsuit Report).

What does Ontario's AODA require for mobile and touch accessibility?

Ontario's AODA (Accessibility for Ontarians with Disabilities Act) sets the policy; the IASR sets the technical bar. Section 14 requires organizations with 50 or more employees to make public websites and web content conform to WCAG 2.0 Level AA. There is a nuance worth getting right: the touch-specific criteria — Target Size and Dragging Movements — were added in WCAG 2.1 and 2.2, after the 2.0 floor the IASR names. So in a strict reading of Ontario law, those particular criteria are best practice rather than the legislated minimum today.

But "best practice" understates the risk for three reasons. First, WCAG 2.0 still applies on mobile — 1.4.4 Resize Text (text up to 200%) and 1.3.4 Orientation (don't lock to portrait or landscape) are in the IASR floor and are routinely broken on phones. Second, WCAG 2.2 is the current standard for any new build, so a site you ship in 2026 to a 2.0-only spec is already dated. Third, if you sell beyond Ontario, the effective bar is higher: the US Department of Justice's 2024 Title II rule and ADA case law reference WCAG 2.1 Level AA, and the European Accessibility Act applies to Ontario businesses selling into the EU — both pull the touch criteria into scope. Selling into the US already raises your effective standard above the IASR floor.

How big does a tap target have to be?

Under 2.5.8 Target Size (Minimum), a tappable control must be at least 24 by 24 CSS pixels — a CSS pixel being the standard unit your layout is measured in, independent of the device's physical screen density. If a target is smaller, it can still pass if there's at least 24 pixels of clear space around it so a thumb can't accidentally hit the neighbour. Links sitting inside a sentence are exempt, because line height constrains them.

The common offenders are small icon buttons (a tiny "×" to close, social icons crammed in a row), pagination numbers set close together, and densely stacked menu items. The enhanced target of 44 by 44 CSS pixels (2.5.5, Level AAA) is the size most mobile design guidance already recommends, so building to it satisfies the AA minimum comfortably and serves users with motor disabilities better.

The other mobile trap is gesture dependence. 2.5.7 Dragging Movements means a slider, carousel, or drag-to-reorder control must also work with a simple tap or button — a person who can't perform a sustained drag (or who uses a switch or assistive pointer) still needs a path through. The same logic underlies why an overlay widget can't fix this: a script layered on top can't rebuild a drag-only control into something a single tap can operate.

How do you check your own mobile site — and what's the risk if you don't?

You can run a first-pass check on a real phone in a few minutes:

  1. Open a key page on your phone and try to tap every button and link with your thumb — including small icons. If you mis-tap or have to zoom in to hit a control, it's too small (2.5.8).
  2. Find any slider, carousel, or drag control and confirm it also responds to a plain tap or has visible buttons (2.5.7).
  3. Zoom the page to 200% (or enlarge the system font) and confirm text grows and the layout reflows into a single column with no horizontal scrolling and nothing cut off (1.4.4, and 1.4.10 Reflow at Level AA).
  4. Walk a real task end-to-end — search, add to cart, fill the form, pay — using only touch. Your forms and checkout are where this breaks most, and where it costs you a sale. This is the same blind spot behind why a scan is not an audit: tap-target spacing and gesture alternatives need a human, not a crawler.

In Ontario, the AODA has no private right of action — individuals cannot sue under it. The enforcement path for a person is the HRTO (Human Rights Tribunal of Ontario), which hears discrimination complaints under the Ontario Human Rights Code. A customer who can't complete a mobile purchase because the controls are unusable has a plausible claim of unequal access to your goods and services. And if you sell to the US, mobile inaccessibility is among the failures cited in ADA litigation — part of the 5,114 digital accessibility lawsuits filed in 2025. As with any gap, the durable defense is documented remediation: the issues you found on mobile, the fixes you shipped, and the dates — which is also what an honest ACR should reflect by December 31, 2026.

See whether your site flags tap-target, mobile, or other accessibility issues — free Vayle Report, about 30 seconds: vayle.art. It detects overlays, surfaces real WCAG failures, and tells you exactly what legally applies to your organization in Ontario. No obligation.

Vayle is a remote-first accessibility-engineering studio serving Ontario. General information, not legal advice.

See what's quietly costing you sales

Send us your site and we'll send back 3 to 5 prioritized fixes for design, speed, conversion and accessibility. Free, within 2 business days.