Procurement asked which assistive technologies your website supports. The answer is not a list.

# Procurement asked which assistive technologies your website supports. The answer is not a list.

The procurement questionnaire came back to your team with one line on it: list the assistive technologies your website supports. Somebody forwarded it to whoever owns your website, and that person has spent the morning looking for a list to copy. There is not one, and what you do next is the whole question.

Assistive technology is not installed on your website. It runs on the reader's machine, and what it can do when it arrives there was settled when your markup was written. The answer procurement can actually use is a standard, a level and a date — WCAG 2.0 Level AA is the version Ontario names — plus what you have measured and when you measured it.

Send a device list instead and it becomes the sentence that gets read back to you eighteen months later, on the morning somebody cannot finish your application form using a switch.

Assistive technology runs on your reader's machine, and nothing you install changes what it does there

W3C puts the definition inside the standard, and the definition is doing work. Assistive technology is "hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents" (opens in a new window) — WCAG 2.1, checked 12 September 2026.

A user agent is the browser. So the screen reader sits beside Chrome, or inside the operating system, takes whatever the browser exposes, and turns it into speech or braille. Magnification, switch access, voice control and eye tracking sit in the same position, and most of them are on the machine before anybody visits you: VoiceOver ships with macOS and iOS, Narrator and Voice Access with Windows, TalkBack with Android.

There is no field in your analytics that reports any of this, and a supplier offering to tell you is inferring it.

Every one of those programs is asking your page the same question

They differ at the output end. One speaks, one enlarges, one drives a braille display, one moves a highlight between controls on a timer. At the input end they are identical: each one is asking what this thing is, what it does, what state it is in, and what comes next.

WCAG has a phrase for that — programmatically determined — and it is worth noticing which criteria it lands in.

All quoted from WCAG 2.1 (opens in a new window), 12 September 2026. Every one of them is Level A. Not the ambitious tier — the floor.

W3C puts the reason in one sentence: "the components must work together in order for the web to be accessible" (opens in a new window) (updated 14 March 2024). Your content is one of those components. The assistive technology is another, and it is not yours.

One defect takes several of them down at once, which is why a device list is the wrong shopping list

Take the most ordinary failure there is: a div with a click handler on it, styled to look like a button.

• A screen reader announces the words inside it and nothing about what it is, because there is no role to report — 4.1.2.
• Tab never reaches it, because a div is not focusable — 2.1.1.
• Switch access has nothing to land on, for the same reason. Switch scanning moves between focusable things, and this is not one.
• Voice control has no name to match, so saying "click Submit" does nothing.

One defect. Four technologies, three of which nobody was thinking about. And the fix is not four pieces of work — it is the same one line, which is why auditing by device would have been the expensive way to find it.

[GATE A — BLOCKED, specific 1 of 3] The occasion from Mike: one real control on a real estate where a single defect took out several technologies at once, what it was, how it was found, and what closing it actually involved. Method only if the estate is the employer's. Do not invent.

The next one down the list is a form input whose label is a styled paragraph sitting above it rather than a label bound to the field. To your eye the form is labelled. To everything above, that field has no name — and the error message raised against it after a failed submission has nothing to attach to.

[GATE A — BLOCKED, specific 2 of 3] Something a client, a colleague or a committee member actually said on first hearing their own form read aloud, or on first watching a keyboard pass. Permission status to be resolved in the same conversation: named, anonymous, or method-only.

The short list of things that genuinely are per-technology, and Ontario excludes two of them

Not everything reduces to markup, and the residue is worth naming.

Captions and audio description are content somebody has to produce, not defects somebody has to fix, and Ontario draws the line precisely. O. Reg. 191/11, section 14 (opens in a new window) requires designated public sector organizations and large organizations to conform to WCAG 2.0 Level AA by January 1, 2021, "other than, i. success criteria 1.2.4 Captions (Live), and ii. success criteria 1.2.5 Audio Descriptions (Pre-recorded)." A large organization there is one "with 50 or more employees in Ontario." Consolidation currency date September 9, 2026.

Read the exclusion carefully, because it is narrower than people assume. Live captions are out. Pre-recorded audio description is out. Captions on pre-recorded video are 1.2.2, they are Level A, and they are not excluded by anything. The recorded town hall on your website is inside the requirement.

Documents are the other genuine residue. A PDF is not your site's markup and carries its own tagging; a screen reader or a braille display reads a tagged PDF and can do nothing whatsoever with a scan of a printed page. And at the far end, a hearing aid paired to somebody's phone needs absolutely nothing from you. Not every technology on the catalogue is your problem, and saying so is more useful than implying they all are.

One number, since it will be quoted at you eventually. The World Health Organization counts "more than 2.5 billion people" (opens in a new window) needing one or more assistive products (fact sheet updated 2 January 2024) — wheelchairs and spectacles alongside screen readers. It is not a statistic about your website, and anybody using it as one is selling you something.

What to send back when procurement asks for the list

Four lines, and they are checkable, which a device list is not.

1. The standard and level. Named, not described. Ontario names WCAG 2.0 Level AA in the IASR; most buyers outside Ontario will name 2.1 AA, and the regulation has not moved.
2. The date it was last measured, and by what. Automated scanning plus a manual keyboard pass is a different sentence from automated scanning alone, and that difference is what procurement is testing you on.
3. The known exceptions, listed. My own statement says the site is partially conformant, that no third-party audit has been run, and that screen reader and zoom testing are not all done — and it carries a date, because an undated statement is a mood.
4. What you tested with, if you tested with anything. Naming the screen reader and browser pairing you actually used is worth more than naming ten you did not touch.

[GATE A — BLOCKED, specific 3 of 3] Mike's own pairing decision on client work: which screen reader and browser combination he tests against, why that one, and — the part that carries the section — what he deliberately does not test and tells clients he does not test. This cannot come from koval.dev's own statement, which records screen reader testing as not yet done.

If the questionnaire will not take a standard and insists on the device list anyway, write the list and staple the standard to it. But know what you have handed over. The list is unverifiable in both directions, by them and by you; the date is the only part of it anybody can check later.

What makes this uncomfortable is that it cuts the work smaller and harder at the same time. Smaller, because you are not buying compatibility with a catalogue of devices — you are closing one set of defects that all of them trip over. Harder, because none of that set is visible to you while you are sitting in front of your own website with a mouse in your hand.

I run AODA accessibility audits for Ontario organizations, including the keyboard and screen-reader pass that the scanners cannot do, with every finding recorded against its success criterion. What the audit covers, and what it costs.