Accessibility

Our commitment

Bridani is built for people in the middle of a job search, and a job search is hard enough. We want the site to work for you whether you use a screen reader, a keyboard, magnification, speech input, or nothing in particular.

We are also building for veterans and for people who have just been laid off, which means we are building for people with disabilities. Accessibility here is part of the product, not a checkbox at the end of it.

Conformance status

Bridani is partially conformant with WCAG 2.1 level AA. "Partially conformant" means most of the site meets the standard and the exceptions below do not yet.

The standard is the Web Content Accessibility Guidelines (WCAG) 2.1 at WCAG 2.1 level AA, which is the level Section 508 of the Rehabilitation Act incorporates for federal purposes.

Your preferences

What is in place today

• Every form label names its control, so a screen reader announces the field rather than a blank edit box. Checked on every build.
• The forms you use most — signing up, onboarding, confirming service, buying, and your account settings — are built from one shared field component, so every box has a label and any error is spoken as part of the field rather than only shown in red. Checked on every build.
• Every field on the site has a name — including the internal administration screens — and a build check counts them, so a new form cannot ship with an unlabeled box. Checked on every build.
• Pale status panels carry text from their own color ramp, so a warning stays readable when the dark theme leaves the panel light. Checked on every build.
• Body, helper and status text is measured against both themes — including what the dark theme substitutes for it — in every color the site paints text with, not only the ones that carry a status meaning, so a color that reads on one background cannot ship unreadable on the other. Checked on every build.
• Pages declare their language, use real landmarks (header, nav, main, footer), and put headings in order.
• Images that carry meaning have text alternatives, and decorative ones are hidden from assistive technology.
• Interactive controls are reachable and operable with a keyboard, and keep a visible focus indicator. Checked on every build.
• A button that shows only an icon carries a text alternative, so it announces what it does instead of just “button”. Checked on every build.
• Animation and scrolling across the whole site respect the reduced-motion setting your operating system already knows about — you do not have to switch anything on here for that to work.
• You can switch on higher contrast, larger text, underlined links, a stronger focus outline, or reduced motion, from the preferences on this page or from Settings. Every one of them is optional: the site meets the standard above with all of them off, and they are saved to your account so they follow you to another device. Checked on every build.
• Every page begins with a skip-to-content link, so a keyboard or screen-reader user reaches the content in one keystroke instead of tabbing through the navigation. Checked on every build.
• The accessibility rules that catch an unreachable control, an anchor with no destination or a contradictory ARIA role fail the build rather than warn. Checked on every build.
• The key pages are rendered and scanned by axe on every build — the home page, the store, the whole sign-up walkthrough, a hosted résumé, the partner tools and the signed-in pages — and a serious or critical finding fails the build instead of shipping. Checked on every build.
• Every page on the site — not a sample of them — is opened in a real browser, in both the light and the dark theme, and signed in wherever a signed-out visitor could not go, and checked against the standard above. The list of pages is read off the site itself, so a page added tomorrow is checked without anybody remembering to add it. The findings of the most recent check are the exceptions listed below. Checked on every build.

Known exceptions

These are the parts of WCAG 2.1 level AA we do not meet yet. Each one is an open item of work, not a decision. The list is what we know of, and we would rather hear about something missing from it than have you assume we know.

• 1.4.3 Contrast (Minimum)

  Some text does not stand out enough from what is behind it. Four groups of it: grey text on a pale grey panel (the language switch), the teal accent used as text rather than as a background, the faint uppercase labels above form fields and cards, and — in the dark theme — the small coloured status badges, whose text was lightened for dark mode while the pale panel behind it was not. If you cannot read one of these, the information is also written elsewhere on the page.

How we assess the site

Self-evaluation by the Bridani team, backed by two automated checks. On every build, an axe scan renders the key pages and fails the build on any serious or critical finding. Separately, a full-site scan opens every page on the site in a real browser — in both themes, and signed in wherever a signed-out visitor could not go — and checks it against WCAG 2.1 level A and AA, colour contrast included. The list of pages it opens is read off the site itself, so a new page is covered without anybody adding it to a list. The exceptions above are the findings of the most recent full-site run.

The two checks have opposite blind spots, and neither closes the other's. The per-build scan covers the key pages rather than every page and reads page structure rather than a rendered window, so it never reports a colour contrast failure. The full-site scan does measure contrast, on every page — but it is an audit run before a release rather than on every commit, so a problem introduced between runs can reach production before the next one finds it. Neither is a substitute for testing with an actual screen reader, which we do by hand and not exhaustively.

Tell us what is not working

If any part of this site blocks you, email dan@bridani.com. Tell us the page, what you were trying to do, and what you use to browse. We aim to reply within five business days.

If you already have an account, you can also raise it from Support inside the app, which keeps the conversation attached to your account.