Accessibility

What we design for

• Keyboard access, logical focus order, and visible focus indicators.
• Semantic headings, landmarks, labels, names, roles, and values for assistive technology.
• Text and interface contrast at WCAG AA thresholds.
• Layouts that remain usable with larger text and browser zoom.
• Reduced-motion preferences, captions or text alternatives for meaningful media, and no action conveyed by color alone.
• Clear form instructions and errors that identify what needs attention.

Measures that are built in

These are properties of the codebase rather than aspirations.

• A fixed type scale with a legibility floor. Text sizes come from a defined scale rather than arbitrary values. The two smallest steps, 10 and 11 pixels, are restricted to chips and metadata and are not permitted for body copy or interactive controls. A sweep completed on August 21, 2026 reduced arbitrary one-off font sizes from 3,442 occurrences to 189, of which 178 are a reviewed allowlist.
• A 44-pixel target floor on navigation, primary actions, and reach controls, which is checked by an automated contract test on the audited surfaces.
• Visible focus rings on interactive controls, using focus-visible so that they appear for keyboard users without following every mouse click.
• Skip links and main landmarks on the public pages and the client portal, so a keyboard or screen-reader user can bypass navigation.
• Reduced-motion support in the global stylesheet, with individual animated elements also disabling their own motion when the preference is set.
• Automated JSX accessibility rules from the recommended jsx-a11y rule set, enforced in continuous linting on the audited files and the public policy pages.
• A shared 390 by 844 mobile baseline as a defined test configuration, so mobile layout is a gate rather than an afterthought.

What we audited

On July 31, 2026, we reviewed the signed-in client portal shell and the attorney Today page against the keyboard, focus, landmark, status-announcement, reduced-motion, and target-size criteria above. The portal exposes named primary navigation, identifies the current page, provides a main landmark, and keeps the directly audited navigation, profile, sign-out, and reach-your-team controls at least 44 CSS pixels tall. Today labels its work lanes, announces an unread or failed load instead of presenting it as an empty desk, and gives its direct links and disclosure controls visible focus and 44-pixel targets.

This source-level audit does not replace testing a deployed build with a keyboard, screen reader, contrast tool, reduced-motion setting, and 200% zoom. It also does not cover every workflow in the product; those remain in the continuing review queue.

On August 21, 2026, seventeen application surfaces were additionally run in a real browser at 390 by 844 with the axe accessibility engine, covering documents, the assistant, the editor, calendar, Today, inbox, billing, entities, workflows, the client matter view, the matter overview and canvas, audit, and trust approvals. Results: zero pixels of horizontal page overflow on all seventeen, no navigation errors, and the serious or critical findings listed in the next section. One accessibility defect found in that pass, six critical nodes where a tab strip declared a parent role incorrectly, was fixed during the pass.

Known gaps

These are open right now. They are listed with the same specificity we use internally, because a statement that lists only successes tells you nothing about whether anyone is looking.

• Unlabeled text areas on the matter canvas. Eight critical findings: text areas rendered per item with no associated label, so a screen reader cannot announce what each one is for. Long-standing rather than newly introduced.
• Scrollable regions that the keyboard cannot reach on the billing page. Two serious findings. Wide content correctly scrolls inside its own container, but two of those containers are not focusable, so a keyboard user cannot scroll them. This is the flip side of the rule that keeps the page from scrolling sideways, and the fix is to make the container focusable.
• One residual finding on the matter tab strip. The tab list contains a close button it is not permitted to own. An attempted fix was reverted because it changed nothing when measured. Clearing it requires moving the close control out of the tab strip.
• Coverage is partial. The August pass covered seventeen surfaces at one mobile viewport, not the full route census, and the desktop and dark-theme configurations were not run to completion. Surfaces outside that set have not been checked to the same standard.
• The automated rules lag the stated target. The axe gate runs the WCAG 2.0 and 2.1 A and AA rule sets. The criteria added in WCAG 2.2, which is the target named at the top of this page, are not covered by that automated gate and are reviewed by hand.
• Automated checks find only part of the problem. They do not judge whether a label is meaningful, whether focus order is sensible, or whether a screen-reader announcement is useful. Those need a person.
• 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 accessible than one that has not, but recognition is imperfect.

Get help or report a barrier

Tell us the page, the task you were trying to complete, 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 a barrier blocks a client from completing 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.

We treat an accessibility barrier that blocks someone from completing a task as a defect rather than an enhancement request.

[OWNER: publish a contact route that does not require signing in, such as a monitored email address for accessibility reports. Reporting today runs through the signed-in support form, which means the people most likely to be locked out by a barrier, including a client who cannot get through the portal sign-in, have no way to report it. No email address exists anywhere in the repository, so none is printed here. This is the most significant gap on the page.]