Back to home

Accessibility

100 %
inside your org
0
outbound data by default
71
controls self-assessed out of 255 catalogued
10 min
to install

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.

22 October 2026 measurement: the installable version is not AA conformant. Two criteria fail, 1.4.10 (reflow at 320 px) and 2.5.3 (label in name). The previous run, on version 0.1.0.16, found 1.4.10 conformant; components added since — the panels of features not yet enabled, the risk-carried tile, lists shown as cards — overflow at 320 px. We publish this step back rather than keep a green line the installable version no longer holds.

What is measured, and how?

The standard applied is WCAG 2.1, levels A and AA. The measurement is instrumented and repeatable: it walks the application deployed in a real org, screen by screen, and computes every contrast ratio on the colour composited up to the first opaque background found by climbing the ancestors — not on the value declared in the stylesheet. Each reflow failure is then replayed by a second, independent navigation that finds the element and photographs it.

Run of , on version 1.0.0.7 installed in two real orgs: one in its default install state, the other a demo org with 77 features enabled. A measurement belongs to the day and the version it was taken on; this one replaces the 22 August run rather than correcting it, and will be replaced in its turn.

What does the measurement give?

Figures come in pairs: the default-state org, then the demo org.

1.4.10 — reflow at 320 px
Not conformant. 13 screens failing out of 44, then 10, from seven named defects, among them: an “Open feature activation” button that does not wrap and makes the page scroll sideways, the risk-carried tile cut off by its card, list values lost (“Last seen” shrunk to “5…”), a message that covers the next row from 1,000 px, two columns with no heading. The defects are fixed in the code, not in the installed package: this line will only change after a new measurement of the next version, in a real org.
2.5.3 — label in name
Not conformant, minor defect. 9 occurrences, the same in both orgs: the sections of the feature activation screen show “Platform 3 / 7 on” while their accessible name says “Expand section Platform (7)”. Fixed in the code, not in the installed package. The defect on the same criterion found in the previous version, on the search control, is fixed and verified.
1.4.3 — text contrast
0 failures out of 4,347 readings, then 6,517. The 37 failures of 22 August — six colour/background pairs, including the “Critical” red at 4.497 against a 4.5 threshold — are no longer found: the fix announced then is verified on the installed package.
1.4.11 — component and focus contrast
0 failures on lists, checkboxes, toggles and icon buttons; focus indicator conformant 951 times out of 951, then 1,217 out of 1,217.
1.1.1 and 4.1.2 — text alternatives and accessible names
0 images without an alternative, 0 focusable elements without a name out of 1,927, then 2,206. On 22 August our own probe wrongly counted fifteen: it read the name through textContent, which does not cross the shadow roots where lightning-datatable renders its cells. It has been fixed since.
1.3.1 — skipped heading levels
0. The skip found on the Monitoring screen of the previous version is fixed.
2.4.3 — positive tabindex
0. Tab order follows document order.

Why do we not declare conformity?

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

  1. Two AA criteria fail on the installed version (1.4.10 and 2.5.3). Until the next version is measured in a real org, a fix in the code is not a verified fix.
  2. What the measurement does not reach. Modal windows, menus and drawers: a navigation without clicks does not open them. Vertical clipping and overlap, which the probe does not measure — the overlapping messages cited above were found by eye. Three screens whose feature is off in both orgs, measured empty. Criteria 1.4.4, 1.4.12, 1.4.13 and 3.3.x, not measured.
  3. Unmeasurable backgrounds. On 13 August, 942 text nodes sat on gradients of the Salesforce design system, which the instrument cannot reduce to a single colour. The 22 October run publishes no count of them: this reservation is neither lifted nor re-measured.
  4. 556 targets smaller than 24 px, then 587. This is a raw count, not a count of failures: criterion 2.5.8 of WCAG 2.2, not required in 2.1, accepts some of these targets thanks to their spacing, and its actual failures are not yet measured. We flag it because the criterion will be required.

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 : 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 : 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