Accessibility at Brix

1) The standard we hold ourselves to

Brix targets WCAG 2.2 Level AA.

The reason is specific rather than aspirational. Most of our education customers are public institutions, and in April 2024 the US Department of Justice adopted WCAG 2.1 Level AA as the technical standard for state and local government web content under Title II of the ADA — which includes public schools, colleges and universities. Compliance dates were later extended to 26 April 2027 for larger entities and 26 April 2028 for smaller ones, but the technical standard did not change.

Responsibility for the third-party tools an institution uses to deliver its services stays with the institution. That is why the requirement reaches vendors like us. WCAG 2.1 AA is the floor; WCAG 2.2 AA is a superset of it, so meeting 2.2 satisfies the floor today and covers the next version an agency is likely to adopt.

2) What is covered

In scope: the Brix CMS operator web application — screens, media, playlists, schedules, layouts, approvals, reporting, users and account settings — along with sign-up, sign-in and password reset.

Also tested: this website. Every page here was scanned against the same standard in the same pass, and the defects it found were fixed.

Assessed separately: the on-screen player output, the internal staff console, and the native device applications. A digital sign is a non-interactive display and is governed by what you choose to put on it, which is a different question from whether our software is operable — we would rather split those than blur them.

3) What we measured, and what it showed

Two suites run against the CMS, and both run from a single command so the result can be reproduced before every release.

The first uses axe-core 4.11 — the same engine a third-party auditor's automated pass uses — configured for WCAG 2.0, 2.1 and 2.2 at levels A and AA. It covers 51 surfaces: every operator route, the dialogs and menus that open on top of them, the screen detail panel, the three unauthenticated pages, and four routes re-scanned at a 320 pixel viewport. Result: no serious or critical violations.

An automated engine, though, is silent on most of what WCAG 2.2 added. So a second suite tests behavior directly, in 30 checks:

• Dragging movements (2.5.7) — a test focuses the playlist reorder grip, reorders with the keyboard, and fails unless the running order actually changed. Proven, not asserted.
• Target size (2.5.8) — every button, link, field, switch, tab and menu item on 22 routes is measured against both the 24×24 threshold and the spacing exception.
• Focus visible and not obscured (2.4.7, 2.4.11) — 40 tab stops on each of three dense routes, checking at every stop that focus is visible and not painted over by a sticky bar.
• No keyboard trap (2.1.2) — a dialog holds focus while open, and Escape always releases it.
• Accessible authentication (3.3.8) — no puzzle, no CAPTCHA, and the password field genuinely accepts a paste, so a password manager works.
• Consistent help (3.2.6) and redundant entry (3.3.7).
• Reflow (1.4.10) — the page does not scroll sideways at 320 pixels, which is 400% zoom on a standard display.

All 30 pass.

4) What this pass fixed

A conformance page that lists no defects is usually a page that did not look. This pass found and closed:

• Tab strips whose aria-controls pointed at a panel that was never rendered, so a screen-reader user was offered tabs that led nowhere.
• Ten feature switches with no accessible name — each announced as "switch, on" with no subject, because the visible label beside it was decorative text rather than a real label.
• A media card that was itself a button while containing a button, in 57 places.
• Content rows given a button role, which quietly removed them from their list, so a screen reader could no longer say how many there were.
• Scrolling code blocks that could not be reached by keyboard — you could read the left edge and nothing else.
• Filled buttons that lightened on hover, dropping their white label under the contrast floor at the exact moment a pointer user is about to click.
• Rename and delete icons measuring 20×20 pixels with 22 pixels between them, failing both halves of the target-size criterion.
• On this website: an unlabelled industry selector, an unlabelled screen-count field, low-contrast pricing and guide text, and footer links distinguished from the sentence around them by color alone.

5) What we are not claiming

Three limits, stated because a conformance claim without them is not worth much.

This is a self-assessment

No independent accessibility specialist has audited Brix. Everything on this page is our own testing. If your procurement process requires third-party evaluation, tell us what standard of evidence you need and we will talk about arranging it — but we are not going to imply we already have it.

Screen-reader testing is spot-checks

We have not done a structured pass with NVDA, JAWS and VoiceOver across every workflow. Automated rules and keyboard operation are a floor, not a substitute: they can tell you an element has a name, but not whether that name makes sense when you hear it.

Customer-authored designs are the customer's

Brix includes a design editor. A customer can choose dark text on a dark background, and the CMS will show that design faithfully in preview, because a preview that silently corrected it would be lying about what goes on the screen. Those colors are not ours to fix in code.

The gap that leaves is ours: we do not yet warn an author, at design time, that their colors will be unreadable. We intend to, in the same shape as the existing workspace setting that already requires a description on every uploaded image. Until then, a customer can publish an inaccessible slide and we will not stop them, and we would rather write that here than leave it out.

6) Accessibility features in the product

Beyond meeting the standard, the CMS carries per-user settings under Settings → Accessibility that go past Level AA:

• High contrast — raises interface text to the AAA 7:1 ratio.
• Larger click targets — grows every control to the AAA 44-pixel target size.
• Reduce motion — on by default when your operating system asks for it, and available on demand when it does not.
• Underline links and readable text — comfortable line height and measure.

Workspace-wide, an administrator can require a description on every uploaded image, with a three-state model that lets a genuinely decorative image be marked as such rather than forcing a made-up description onto it — which would be a failure dressed up as compliance.

7) Tell us what we missed

If any part of Brix is difficult or impossible for you to use, we want to hear about it, whether or not it maps to a success criterion.

Email accessibility@brixsignage.com. It helps if you can tell us the page you were on, what you were trying to do, and what assistive technology you use — that is usually enough for us to reproduce it.

Procurement teams: ask at the same address for the full Accessibility Conformance Report in VPAT® 2.5 format, which rates every applicable criterion individually with remarks.

8) How current this is

This statement was last measured on 18 August 2026. The test suites behind it run before each CMS release, and this page is updated when the result changes. An accessibility claim with no date attached is not a claim, so if the date above ever looks stale to you, ask us.

WCAG® and VPAT® are registered trademarks of their respective owners.