Accessibility

The target, and what it is not

The target is WCAG 2.2 Level AA. BRON does not claim conformance with it. A conformance claim covers every criterion on every screen, and no testing described below reaches that far. What this page offers instead is the narrower thing that can be supported: a target, the measures built into the code, the name of each harness and what it checks, and the date each check last ran.

The testing described here was done in house. Where a section says a machine checks something, the harness is named so the claim can be argued with. Where nothing checks something, that is said in the same plain words.

What the code enforces

These are properties of the codebase, enforced structurally, rather than intentions.

• A 24-pixel minimum height on tappable controls, enforced twice. The shared button primitive carries the floor in its base styles, so every control built from it inherits it. A second rule in the base layer of the global stylesheet applies the same floor to raw buttons, selects, disclosure summaries, and to elements carrying an interactive role such as button, checkbox, radio, switch, tab, menu item, or option. The second rule exists because the first cannot reach either of the two shapes that were actually failing: a quiet action written as a bare button with only a text class, which collapses to its line box, and a div given an interactive role, which is a real tap target no component-level guard can see. Both rules are pinned by tests, so removing one fails the suite.
• Links inside a sentence are deliberately left out of that floor. A minimum height does nothing to an inline box, so a link in prose is unchanged by the rule, which matches the exception the criterion itself makes for inline targets. One case does move, an inline-block link inside a paragraph, and it moves by under two pixels while taking its line box with it. That is why extending the floor to links needs a measurement first rather than a one-word change.
• 44 pixels is the convention for a standalone control, meaning anything that is not a link sitting inside a sentence: page and section actions, toolbar and icon buttons, list-row actions, form submits, tabs, and navigation that occupies its own line. This is a convention carried by the call site, not a floor. The shared button primitive does not reach it on its own, because its size variants stop at 40 pixels, so a standalone control asks for the larger target itself. Arbitrary pixel spellings of 44 and 24 are banned across the app by a test, because they render identically to the scale tokens and hide from every search for the convention.
• Where 44 pixels would reflow a dense table or toolbar, nothing is reflowed. The hit area is grown without changing the visual layout, using padding absorbed by a negative margin or a positioned overlay on the control. Where neither fits, the control stays at the conformant 24-pixel floor and the gap is written down rather than quietly reflowed. Changing the visual density of a table is a product decision, not something a sweep should do on its way past.
• A fixed type scale with a legibility floor. Text sizes come from a defined scale. Its two smallest steps, 10 and 11 pixels, are restricted to chips and metadata and are not permitted for body copy or for text inside an interactive control.
• Visible focus rings on interactive controls, using focus-visible, so they appear for keyboard users without following every mouse click.
• A skip link and a named main landmark on the public pages, so a keyboard or screen-reader user can bypass the navigation. The client portal exposes a named main landmark and named primary navigation, and identifies the current page, but it does not carry a skip link of its own.
• Motion tokens with one source. Easing curves and duration bands are defined once, so a call site that hand-types a curve opts itself out visibly rather than silently.
• Reduced motion means fewer and gentler, never zero. The preference is honored at the call site, deliberately rather than through a single global reset that would flatten everything. Transitions that tell a user something changed, opacity and color, are kept; position and scale changes are dropped. One case inverts: a loading spinner under reduced motion slows to a two-second turn rather than stopping, because a frozen spinner does not read as suppressed motion, it reads as a hung request. That is one unlayered rule in the global stylesheet, so it holds even on a call site that still asks for the animation to stop.

What a machine checks, and which harness

Three harnesses run here, each blind to something the others see. Naming them separately is the point; a green result from one of them says nothing about the others.

• The axe engine in a real browser. A Playwright project loads each page in the route census, waits for it to settle, and records violations rated serious or critical, horizontal page overflow, and console errors, with a screenshot per page, theme, and viewport. It is configured for the WCAG 2.0 and 2.1 A and AA rule sets.
• A 390 by 844 mobile baseline, which is the shared mobile configuration every new or materially changed page is checked against. It runs the axe pass and then measures four more things in the browser: the hit height of every rendered control against the 24-pixel floor, whether each control can actually be reached, by scrolling it into view and hit-testing its center and four corners, body and control text rendering below 12 pixels, and whether anything pinned to the bottom edge clears the published overlay inset. It covers a prioritized subset of 18 routes rather than the full census.
• A separate motion project, the one project that turns reduced motion off. Every screenshot project forces reduced motion on, for stable images, which means none of them can observe an animated state at all. The motion project clears the preference and asserts computed values instead of taking pictures: that the easing tokens resolve to the curves this app defines rather than the stock ones, that a plain transition utility inherits the app curve, that the component duration bands are what the standard asks for, that no interface transition exceeds the 300-millisecond ceiling except the documented drawer, and that a spinner under reduced motion slows rather than stops.
• Lint, on ten files. The full recommended set of JSX accessibility rules runs at error level on the public policy pages and two audited product surfaces. The rest of the app gets the six rules the framework preset enables as warnings. The list is widened as a surface is remediated; the rules are not weakened to fit a file.
• Everything else called a test here is a source-text contract test. It reads a file as a string and asserts on its contents. That is how the two tap-target floors and the motion vocabulary are held: those tests catch a guard being deleted or a convention being spelled off-scale. They render nothing and look at nothing.

What no machine here checks

This section is the reason the page exists. A suite that passes is silence about everything below, not a pass.

• Target Size, criterion 2.5.8, is not machine-checked. It arrived in WCAG 2.2, and the axe pass runs the 2.0 and 2.1 rule sets, so the engine never evaluates it. The mobile baseline measuresheight alone. It does not model target width, the spacing between adjacent targets, or every exception the criterion allows. A green run must not be read as a machine pass on 2.5.8. The 44-pixel convention is deliberately not a mechanical failure either, because failing it by machine would mislabel dense tables and toolbars whose hit areas need a person to judge.
• The other WCAG 2.2 additions are also outside the automated rule sets. That includes focus not being obscured, dragging movements having a single-pointer alternative, consistent help, redundant entry, and accessible authentication. They are reviewed by hand, which means they are reviewed as often as a person gets to them.
• No screen reader is driven by any harness here. Nothing runs VoiceOver, NVDA, or JAWS. Whether an announcement is useful, whether focus order makes sense, and whether a label means anything to the person hearing it are judgments no rule engine makes.
• Browser zoom and text resizing are not measured. Layouts are built to survive them and are checked by eye, not by an assertion.
• Contrast is checked only where it can be computed. The engine evaluates text against a solid background. Text over an image, a gradient, or a translucent layer is outside what it can decide.
• Nothing renders an iOS view and inspects it. See the next section.

The iOS app

The iOS app follows the same intent in code. Type is anchored to the system text styles so it scales when a reader turns text up, and spacing beside text scales with it where growth is what was asked for. Where a status color carries meaning, color is never left to carry it alone: the code consults the system setting for differentiating without color and adds a shape. Loading placeholders are hidden from assistive technology so a waiting screen does not read out a wall of nothing. Haptics and motion run through shared wrappers that consult the reduce-motion setting themselves, rather than relying on each call site to remember.

The honest part: there is no interface-test target, no snapshot testing, and no call to the platform accessibility audit API anywhere in the iOS sources. Nothing renders a view and looks at it. The Swift suite is unit tests and source-text contract tests, which can prove a convention is written down and cannot prove it reaches the screen. Everything in the paragraph above is a convention verified by reading code.

What we audited

The most recent recorded full run was on September 10, 2026, in a real browser at 1440 by 900 in the light theme, over a census of 85 attorney pages and 20 client pages, 105 in total. Of those, 98 loaded and were scanned and 7 timed out without loading, so nothing is claimed about the 7. Horizontal page overflow was zero pixels on all 105. The serious and critical findings from that run were 8 affected nodes across 6 pages, and they are listed in the next section by page.

Earlier, on August 21, 2026, seventeen changed surfaces were run at 390 by 844 with the same engine, with zero pixels of horizontal page overflow on all seventeen. That pass ran in a desktop Chromium build at the mobile viewport rather than in the configured mobile browser, which was not installed on the machine at the time, so it stands as a Chromium result.

On July 31, 2026, the signed-in client portal shell and the attorney Today page were reviewed at source against the keyboard, focus, landmark, status-announcement, reduced-motion, and target-size criteria above. This source-level audit does not replace testing a deployed build with a keyboard, a screen reader, a contrast tool, the reduced-motion setting, and browser zoom, and it does not cover every workflow in the product.

Known gaps

These were open when this page was last updated. They are listed with the same specificity used internally, because a statement that lists only successes tells a reader nothing about whether anyone is looking.

• Form fields without labels on two settings pages. Rated critical. The firm settings page renders two inputs with no associated label and a select with no accessible name; the templates settings page renders one unlabelled input. A screen reader cannot say what those fields are for.
• Status text below the contrast threshold in three places. Rated serious. An amber notice style places amber text on an amber wash on the AI vendor settings page, in two spots, and on the feature flag settings page, in one.
• An ARIA role missing its required children on the tabular review page. Rated critical, one node. The container declares a role whose contract obliges it to hold particular child roles, and it does not.
• An ARIA attribute on an element not permitted to own it on the attorney Today page. Rated serious, one node.
• Seven pages did not load during that run and were not scanned, among them the matter canvas. Their state is unknown rather than clean, and a later run has to establish it.
• Coverage is partial in three directions at once. The most recent recorded run is one project, one theme, one width. The dark theme and the two narrower widths have not been recorded since. The mobile baseline covers a prioritized 18 routes, not the census.
• The full accessibility lint rule set gates ten files, not the app. Turning it on across the whole codebase surfaces a large backlog of older findings, which would make the existing gate unactionable, so it is widened surface by surface as each is remediated.
• Arbitrary font sizes remain off the fixed scale. Measured on September 15, 2026: 114 occurrences across 27 files. The scale is the rule and no app-wide guard enforces it, so this residue is cleared by sweep rather than caught on the way in.
• The automated rules lag the stated target. The axe gate runs the WCAG 2.0 and 2.1 A and AA rule sets, so the criteria added in WCAG 2.2, which is the target named at the top of this page, are reviewed by hand and by nothing else.
• Automated checks find one part of the problem. They judge presence, not sense. Whether a label is meaningful, whether focus order is sensible, whether an announcement helps: those need a person, and a person has not been through every surface.
• Third-party and imported content. Court forms, opposing-party productions, scanned exhibits, and embedded third-party tools may not meet this standard, and BRON often cannot alter them. A scanned document that has been through text recognition is more usable than one that has not, and recognition makes mistakes.

Get help or report a barrier

Tell us the page, the task you were trying to carry out, your browser or device, and the assistive technology you use if you are comfortable sharing it. That is usually enough to reproduce a problem.

Signed-in users can send that through Support. If you cannot sign in, email an accessibility report to contact@bronlaw.com. That address takes reports without an account, so a barrier in the product cannot also close off the route for reporting it.

If a barrier stops a client from finishing a matter request, contact the law firm as well, so the firm can provide another way through without waiting for a software change. A firm is obliged to serve its client regardless of a limitation in this software, and should not treat a barrier here as a reason for delay.

An accessibility barrier that stops someone from finishing a task is treated here as a defect, not an enhancement request.