Accessibility Statement | The Art of CTO

Last Updated: September 13, 2026

This statement applies to the website theartofcto.com, its interactive tools, the Command Center, and our mobile application. It is published by [TO CONFIRM: registered legal entity name] ("The Art of CTO").

1. Conformance status

The Art of CTO is partially conformant with WCAG 2.2 Level AA. "Partially conformant" means some parts of the content do not fully conform to the standard. Our own review in September 2026 identified failures against five Level A and Level AA success criteria — 1.3.1, 2.4.3, 2.4.6, 3.3.2 and 4.1.2 — affecting roughly 1,300 individual controls, dialogs and table headers. Those failures are listed in Section 3 below, with counts, with the criteria they fail, and with the method that produced each count.

We are stating this plainly because we sell a WCAG assessment tool. Claiming a conformance level we have not reached would be the exact failure that tool exists to catch.

The target standard is WCAG 2.2 Level AA, which is also the standard referenced by EN 301 549 for the purposes of the European Accessibility Act (Directive (EU) 2019/882).

2. What already works

So that the list in Section 3 is read in proportion, the following are in place across the Platform:

Semantic HTML structure with landmark regions and a single H1 per page
Server-side rendering, so content is present without JavaScript for the reading experience
Both themes now meet AA contrast on every semantic colour token — see “Fixed since the last version” in Section 3
Keyboard-operable primary navigation, plus a command menu on Cmd+K / Ctrl+K
Text that reflows and remains readable at 200% zoom and on small viewports
All 433 form controls on the interactive tools carry a programmatic label, held by a scan that sees every one of them
The cookie consent banner is announced as a dialog, receives focus when it appears, and is the second stop in the tab order rather than the eighty-first
Automated accessibility checks run against key pages in both light and dark mode — pa11y against WCAG 2 AA on the live site and axe-core in our end-to-end suite. Scanning only the default theme is how the consent-banner failure stayed invisible for as long as it did. (Our Lighthouse run still sees only the default theme.)

3. Known barriers

These are the accessibility problems we know about and have not yet fixed. The counts come from a scan of our own source code, not from an estimate; where a fix lands, this list shrinks. Two of the counts below went down at the last re-measure because the previous figures were wrong, not because anything was fixed — each of those says so explicitly, since a number that falls on a page like this deserves more scrutiny than one that rises.

Form fields without programmatic labels

WCAG 2.2 SC 1.3.1 Info and Relationships, SC 3.3.2 Labels or Instructions, SC 4.1.2 Name, Role, Value

We count 804 form controls with no programmatic label. They rely on placeholder text, or on visual text sitting near the control, rather than on an associated label element or an aria-label. A screen reader announces them as unlabelled, and placeholder text disappears as soon as you start typing. This is the largest single barrier on the Platform. 626 of the 804 are in the parts of the Platform this statement covers: 234 in the Command Center, 329 in shared components used across it, and 63 on other pages of the site. The remaining 178 are in our staff-only admin console, which is not a public surface and is listed here only so the total is not quietly trimmed to look better. The 433 controls on the interactive tools under /tools are no longer part of this count — see "Fixed since the last version".

Where: The Command Center, the dashboard and account surfaces, shared components across the site, and the internal admin console.

Buttons labelled only by a symbol

WCAG 2.2 SC 4.1.2 Name, Role, Value, SC 2.4.6 Headings and Labels

We count 27 buttons across 18 files whose entire visible content is a single symbol character — ×, ✕, ↑, ↓, −, + or an emoji — with no aria-label, no title and no visually hidden text. A screen reader reads the character rather than the action, so a close control announces as "multiplication sign, button" and a reorder control as "up arrow, button". The related and worse case — a button containing only icon markup, which announces as "button" with nothing at all — no longer occurs anywhere we can find. An earlier version of this statement put the combined figure at 53. We cannot reproduce that number with any scan that separates the two cases, so we are publishing what we can reproduce: 27 symbol-labelled, 0 unlabelled.

Where: Close, reorder and delete controls in the editors: board presentations, the ArchiMate and tech-radar editors, SplitCause dialogs, and several Command Center panels.

Dialogs still rendered by hand

WCAG 2.2 SC 4.1.2 Name, Role, Value, SC 2.4.3 Focus Order

Our automated guard (npm run check:dialogs) finds 28 files still building a modal overlay out of plain container elements instead of the shared dialog component, plus one it cannot detect because that dialog's backdrop is invisible. Four of the 28 are annotated as not really dialogs — two transient celebration overlays, a mobile sidebar backdrop, and the command menu, which manages its own focus — leaving 24, or 25 counting the undetectable one. In those, focus is not trapped while the dialog is open and is not returned to the control that opened it, so keyboard and screen-reader users can tab out into the page behind and lose their place when it closes. The earlier version of this statement said 76 dialogs and that none of them trapped or restored focus. That is no longer true: components/Modal.tsx does both, and 76 files now render through it or one of the form wrappers built on it.

Where: Nine tool pages, the SplitCause dialogs, the Wardley map builder, the tech radar editor, the outage detail view, and the data import/export dialogs.

Data tables without header associations

WCAG 2.2 SC 1.3.1 Info and Relationships

We count 437 table header cells across 60 files that carry no scope attribute and no explicit header/cell association — 146 across 29 files in the public Platform, and 291 across 31 files in the staff-only admin console. In a simple table a screen reader can often infer the relationship, but in the wider tables we use — comparison matrices, entity registers, cost breakdowns — it cannot reliably, so cell values are announced without the column or row they belong to.

Where: Tables across the tools, the policy pages on this site, the Command Center, and the internal admin console.

Fixed since the last version

Listed rather than quietly deleted, so that anyone who read the earlier version of this statement can see what changed and check it.

Text contrast in light mode

Fixed September 2026, and completed on 13 September 2026. The first version of this statement reported tertiary text at 2.43:1, muted text at 1.41:1, the orange accent at 2.23:1, success green at 2.18:1, warning amber at 2.06:1, error red at 3.60:1 and info blue at 3.52:1 against the light background. Every one of those tokens was re-derived. Re-measured against the light page background: tertiary text 5.15:1, muted text 5.00:1 (4.55:1 at its worst, on a raised surface), success 6.24:1, warning 6.01:1, error 5.38:1, info 6.42:1. The brand orange is unchanged as a fill, border and icon colour, where it passes non-text contrast; used as text on a light ground it now resolves to a darker tone measuring 5.60:1 on the page background and 5.85:1 on white. The status colours were deliberately taken above the 4.5:1 minimum so that the common tinted-badge pattern still clears it. Dark mode was re-checked at the same time and did not regress. One caveat we would rather state than leave implied: this covers our semantic colour tokens, and 255 uses of raw Tailwind palette colours remain in 63 files, held under a ratchet that lets the number fall but never rise.

The cookie consent banner (the last light-mode contrast failure)

Fixed 13 September 2026. Until this date the consent banner painted its Privacy Policy link and its "Manage Preferences" and "Reject All" buttons with the brand orange hardcoded in inline styles. On the light background that measures 2.33:1 where 4.5:1 is required, so the one surface on the site that asks for a legal decision failed contrast on every page in light mode. It also had no dialog role and no accessible name, it never received focus, and on the homepage its controls were the 81st of 93 stops in the tab order — so a keyboard user had to cross the entire page to answer it. Its preferences pane additionally shipped three checkboxes with no accessible name at all. Re-measured with axe-core after the fix: zero violations in both themes, accent text at 5.85:1 in light and 5.98:1 in dark, the banner announced as a dialog named by its own heading, focus moved into it when it appears, and its controls now at tab stop 2. It deliberately does not trap focus: consent is a decision you are entitled to defer while you read the page underneath.

Form labels on the interactive tools

Fixed September 2026. The 270 unlabelled controls previously reported across the tool pages are now zero, across all 433 controls in that surface, and the result is held by two committed guards rather than by good intentions: a source scan that sees every control (__tests__/architecture/tool-form-labels.test.ts) and an axe sweep of twelve tool pages. The scan also rejects an empty aria-label, which is the obvious way a check like that gets quietly defeated.

A single accessible dialog primitive

Landed September 2026, not yet finished. components/Modal.tsx now provides role="dialog", an accessible name, a focus trap, Escape-to-close and focus restored to the control that opened it; 76 files render through it or through the form wrappers built on it, and a guard in our build (npm run check:dialogs) fails on a newly hand-rolled one. 24 hand-rolled dialogs have not been converted yet and are listed as an open barrier above.

Two accessibility scanners that could not see the defect they existed to catch

Fixed 13 September 2026. Our axe-based end-to-end sweep excluded any element whose class contained "consent" or "cookie", so it deleted the consent banner from the page before measuring it. Our pa11y scan against the live site never selected a theme, so it only ever rendered dark mode, where the failing colour passes. Those two blind spots overlapped exactly, which is why a failure affecting every page in light mode went unreported by both. The exclusions are gone, pa11y now scans every page in light mode as well as dark, and the consent banner has its own axe assertions in both themes.

Not yet assessed. Some parts of the Platform have not been assessed in detail against WCAG 2.2 AA and may contain further barriers: the graphical tools (Wardley maps, the system design canvas, the ArchiMate workspace and the causal graph editor), generated PDF exports, and the mobile application. We do not claim conformance for these, and we would rather say so than imply a coverage we have not achieved.

Third-party content. Some functionality is provided by third parties — the Auth0 hosted sign-in pages, the Stripe checkout and billing portal, and embedded media. We do not control the accessibility of those interfaces, though we do take it into account when selecting providers.

4. Remediation plan

The work below is sequenced but not yet scheduled: we have not committed to completion dates and we are not going to publish ones we invented. The order reflects how much of the Platform each item unblocks. When dates are set, they will appear here and the "Last Updated" date at the top of this page will change with them.

Form labels: associate a label or accessible name with the remaining 804 unlabelled controls, starting with the 234 in the Command Center and the 329 in the shared components it is built from. This is first because an unlabelled form is the difference between a tool being slow to use and being unusable. The same work is already complete on the 433 controls in the tool surface, so the approach is proven rather than theoretical.
Dialog semantics and focus management: move the remaining 24 hand-rolled overlays onto the shared dialog primitive that 76 files already use. The primitive exists and the build refuses new hand-rolled dialogs, so this is conversion work rather than design work.
Button names: give the 27 symbol-only buttons an aria-label or visually hidden text.
Table header associations: add scope attributes to the 437 header cells that lack them.
Regression guard: extend our automated checks so unlabelled controls, symbol-only buttons and unscoped headers fail the build outside the tool surface too, so the counts above cannot climb back up while we work through them.
Independent audit: we have not commissioned a third-party accessibility audit and have none booked. If we commission one, its findings and date will be published here.

If a barrier above is blocking you right now, tell us at support@theartofcto.com — a specific report moves an item up this list faster than the list does on its own.

5. Assessment approach

This statement is based on a self-evaluation carried out in September 2026 and re-measured on 13 September 2026, combining automated testing (pa11y against WCAG 2 AA on the live site, Lighthouse accessibility audits, and axe-core checks in our end-to-end suite — pa11y and axe now run in light mode as well as dark; Lighthouse still only sees the default dark theme) with a source scan of every form control, button, dialog and table header in the codebase, and manual review of keyboard operation, screen-reader output and colour contrast. It has not been reviewed or verified by an independent third party.

6. Compatibility and technical specifications

The Platform is designed to work with recent versions of Chrome, Firefox, Safari and Edge, in combination with the screen reader shipped with the operating system. It relies on HTML, WAI-ARIA, CSS and JavaScript; where JavaScript is unavailable, content pages still render but interactive tools do not function.

7. Feedback and contact

If you hit a barrier on this site, or you need something on it in a different format, please tell us. Reports of specific barriers are the fastest route to getting them fixed, and we treat them as bugs rather than suggestions.

Email: support@theartofcto.com — please include the page address and what happened
We acknowledge accessibility reports within 2 business days and give you a substantive response, including a remediation timeline, within 10 business days
If we cannot make specific content accessible, we will provide the information in an alternative format on request

8. Enforcement

If you are not satisfied with our response:

European Union: you may contact the market surveillance or enforcement authority designated under the European Accessibility Act in your Member State.
United Kingdom: you may raise a complaint under the Equality Act 2010 through the Equality Advisory and Support Service.
Australia: you may lodge a complaint with the Australian Human Rights Commission under the Disability Discrimination Act 1992.