Glossary · Accessibility term

Programmatically determined

Programmatically determined is WCAG's term for information software can read out of the code rather than infer from how the page looks. It is a defined term, and there is more inside it than the usual paraphrase. Three conditions are packed in there. The data has to come from you, the author, rather than be guessed at by something clever. More than one kind of software has to be able to extract it, not just the one screen reader you happened to test with. And the point of extracting it is presenting the same information in another form, which is what makes this an accessibility requirement rather than a machine-readability one. A heading that looks like a heading because it is large and bold is determined visually. A heading marked up as an h2 is determined programmatically, because the element says what it is and anything reading the page can act on that. There is a second, far less quoted half of the same idea. Programmatically set is the write direction, and it is what lets voice control or a screen reader's own controls change a value rather than only announce it.

In practice

The bar is commonly available software, which is stricter than it sounds. A custom data attribute only your own script understands is beautifully structured and not programmatically determined, because nothing anybody actually uses can read it. That is also the root of the accessibility-supported problem, since a specification-correct pattern no assistive technology implements has not made anything determinable in practice.

One route out of the requirement gets forgotten. The rule about structure and relationships asks that they be programmatically determined or available in text. So telling readers in words that required fields are marked with an asterisk is a conforming answer rather than a dodge. It is rarely the better answer, and it is in the binding wording.

Assistive technology is broader than a screen reader, which changes what this term is for. The standard's own list names screen magnifiers, text-to-speech software, speech recognition, alternative keyboards and alternative pointing devices alongside screen readers. Somebody using voice control can see your page perfectly well, and they still need the accessible name to contain the visible label, because they say the words they can see.

Why it matters

The whole standard is built around this one gap. Scope is set by what a person perceives, since a user interface component is defined as whatever somebody perceives as a single control, and conformance is satisfied by what the code says. So a div that everybody looks at and calls a button is a control, and the code has to agree. That is why so much accessibility work looks like translating something obvious into something explicit, and why nobody notices it is missing until somebody stops looking at the screen. Say it in the code.

The distinction that matters

A red asterisk tells somebody looking at the form that a field is required. The required attribute, or aria-required where the native one does not apply, tells software the same thing, and the native HTML attribute is the better answer wherever you can use one. Either way the point is the same. Two people are reading the same field and only one of them is reading it with their eyes.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan