Accessibility

The French text governs. This page is the English translation of Accessibilité FR. The French version is the one that governs; this translation is provided for understanding. Where the two diverge, the French text prevails.

This page states how OrgGuardian's accessibility is measured, what the measurement gives, and what it does not cover. This is not a declaration of conformity. The reservations are named further down, and we regard them as blocking for a declaration — that is the conclusion of our own audit, not a precaution added after the fact.

This page was corrected on 22 August 2026, and in both directions. Re-measured against the installed version, the probe found 37 contrast failures where we had been publishing zero since 13 August — and the same run showed that our own probe had been crying wolf about a reservation we were publishing. Both corrections are set out below. We would rather publish a measurement that contradicts us than a comfortable figure we know to be false.

What is measured, and how?

The standard applied is WCAG 2.1, levels A and AA. The measurement is instrumented and replayable: it walks the application deployed in a real org, screen by screen, and computes each contrast ratio on the colour composited up to the first opaque background found by walking back up the ancestors — not on the value declared in the stylesheet.

Run of 22 August 2026, against version 0.1.0.16 installed in a real org. A measurement belongs to the day and the version it was taken on; this one replaces the 13 August run rather than correcting it, and will be replaced in its turn.

• 39 screens measured out of 39. The screens are enumerated from the tabs the package installs, and not from the navigation on display: an audit that visits only the easily reachable screens overstates conformity.
• 55,551 elements walked.

What does the measurement give?

1.4.3 — text contrast

37 failures, which reduce to six colour/background pairs — not thirty-seven distinct places. The most frequent, twenty-seven times, is the “Critical” red: #dc2626 on #f4f7fc, ratio 4.497 against a threshold of 4.5. It fails by three thousandths. No eye would have caught it and no review would have flagged it; only a ratio measurement finds it. All six pairs are fixed in the code — the smallest correction that clears the threshold, so the palette does not move — but the fix is not yet in the installed package: it will be verified against a real org at the next version, not by calculation alone.

1.1.1 — images with no text alternative

0.

1.3.1 — skipped heading levels

0.

2.4.3 — positive tabindex

0. Tab order follows document order.

1.4.10 — reflow at 345 px

Conformant: the document does not overflow horizontally.

4.1.2 — focusable elements with no accessible name

0. This figure was first announced as 3, then measured at 15 — and all fifteen were false positives of our own probe. It read the accessible name through textContent, which does not traverse a shadow root; the cells of a lightning-datatable render their content inside nested shadow roots. The probe read an empty string and concluded “no name”, while the cell was displaying its text perfectly well. Probe fixed, extraction bounded by depth and node count: 15 before, 0 after, against the unchanged org.

Why do we not declare conformity?

An audit that does not declare its blind spots cannot be relied upon. Here are ours.

1. 942 text nodes sit on a background that cannot be measured (13 August run) — gradients from the Salesforce design system, which the instrument cannot reduce to a single colour. They are declared not measured, never assumed conformant. This is the heaviest reservation: a far from negligible share of the text has not been verified, and a check by eye or with a pixel tool is still owed.
2. The 37 contrast failures are fixed in the code, not yet in the installed package. Until the next version has been measured against a real org, this reservation stands: a calculated fix is not a verified fix.
3. 409 touch targets under 24 px (13 August run). This criterion belongs to WCAG 2.2 and is not required in 2.1. We report it because it will be.

And this site itself?

The page you are reading and the other pages of this site are measured separately from the product, against the published site rather than local files. Run of 22 August 2026: 20 pages × 4 widths (320, 390, 768 and 1,440 px, i.e. 80 renders), 14,300 text nodes, 0 AA contrast failures, 0 horizontal overflow. Also: 0 broken heading levels, complete keyboard navigation, and prefers-reduced-motion respected. The screenshot carousel stays readable without JavaScript.

This particular run cost the instrument a fix, and that is the part worth stating. The sweep read the color property only: it did not composite opacity. A language badge set at opacity: .7 came out at 3.61:1 on white — an AA failure it could not see. That is the third time the same blind spot has been paid for on this tool, after background gradients and reveal states: a rendered colour is not a declared colour. The badge is fixed, so is the instrument, and the 80 renders above were taken afterwards.

Run of 26 August 2026: what the 22 August run no longer says. The site had 28 pages that day; it has 44 today. The figures above therefore belong to the 22 August site and to it alone — they do not cover the sixteen pages published since, and “complete keyboard navigation” has not been re-measured on them. What follows is what was measured on 26 August, and nothing more.

A WCAG defect found and fixed on 26 August, on 14 of the 44 pages. The trial request form carries a bot trap: a field nobody sees and only an automated agent fills in. It was hidden off-screen and removed from the tab order, but it remained programmatically focusable — focusable content placed under aria-hidden="true", which a WCAG check counts as a defect. The inert attribute has been added to all fourteen copies of the form. Verification: 42 published URLs × 4 widths, i.e. 168 renders, and 0 non-inert focusable element under aria-hidden across the lot; a full tab cycle on the home page yields 63 stops and the field appears in none of them. The trap still works: the field is still displayed as far as CSS is concerned and is still posted with the form, which the server continues to require. A ratchet in the test suite now refuses the loss of the attribute on any one of the fourteen pages — an attribute copied by hand fourteen times gets lost at the fifteenth edit.

A second WCAG defect found and fixed on 26 August, on the 11 English pages. The title band of the inner pages is a dark slab: the link in the “The French text governs” note, which points each English page at its French version, was still painted in the link blue meant for paper — #2563EB on #0B1220, i.e. 3.62:1 against a 4.5 threshold (WCAG 1.4.3). The cause is a CSS specificity tie: the dark-band rule and the paper rule carried exactly the same weight, and the one lower in the file won. The link now uses the instrument's cyan, 10.36:1. Verification run: 44 pages, 371 text nodes in the dark band, 0 failures after the fix against 11 before, the lowest remaining pair being 7.19:1. This run covers the dark band only: the rest of the pages is not re-measured here, for the reason stated just below.

A fourth blind spot in the instrument, named on 26 August and not yet fixed. The probe looks for the first opaque background by walking up the ancestors. When an element carries both an opaque background colour and a decorative translucent gradient, the probe resolves the gradient against the parent's background and skips the element's own colour — the one actually painted underneath. On this site's dark bands it therefore composes white text over the light paper of the <body> and reports 1.13:1 where the eye reads white on #0B1220. The mechanism is demonstrated and the consequence is massive: 3,508 alleged failures across the 42 URLs, with no way for the instrument to tell which of them would be real. No site contrast run is therefore published for 26 August: the probe must be repaired first, then the measurement retaken. This is the fourth time the same kind of blind spot has been paid for on this tool, after background gradients, appearance states and opacity — which is exactly why it is written here rather than left unsaid.

Run of 27 August 2026: the probe is repaired, contrast is measured again. The paragraph above stated that no contrast run would be published while the instrument composed backgrounds the wrong way round. It now composes opacity and walks up to ancestor backgrounds, and refuses to score what it cannot compute rather than counting it as a pass. Across 44 pages × 7 widths (320, 390, 620, 900, 960, 1,024 and 1,440 px, i.e. 308 renders): 58,884 contrast readings considered and 0 AA failures among those that could be judged.

The blind spot in this run, and it is wide: 13,461 readings — 23% — were not judged. These are the ones whose ancestor carries a background image: the effective background of text sitting on it follows from no declared value, and an instrument that invented a colour there would return a number rather than a measurement. A further 2,828 (5%) were judged against an approximated background and are flagged as such by the tool. We would rather publish that 23% than absorb it into a “0 failures” that would look cleaner than it is.

Horizontal overflow: 0, verified independently of the harness, across 12 widths from 320 to 1,920 px (320, 328, 360, 390, 620, 768, 900, 960, 976, 1,024, 1,440, 1,920) and all 44 pages. The fine step is not decorative: two narrow bands — [320–331] and [951–990] — overflowed without any of the widths then measured falling inside them. They are fixed, and the two witness widths have entered the tool so that a recurrence shows.

This run covers a layout rebuilt the same day. The body of article pages was aligned on a shared left edge: prose occupied 632 px of an 1,136 px track, leaving 504 px of empty space to its right on every paragraph. It now shares an axis rather than an edge (252 px each side at 1,440 px). The defect had been reported by eye four times while five successive measurements declared it green; for that reason the tool gained a sixth measurement, which rejects a block left off-centre in its track.

Reporting a defect

If you run into an accessibility barrier, in the product or on this site, write to contact@orgguardian.com. Describe the screen, the assistive technology used and what happened: that is what makes a report reproducible, and therefore fixable.

Back to home