Accessibility statement

Our target

We aim to meet WCAG 2.2 Level AA, the standard most U.S. accessibility law and guidance points to. This is a target we build toward, not a certification we hold — no independent accessibility audit or assistive-technology user testing has been performed on this site. We are not going to claim “fully accessible” without that audit, because an unverified claim like that is itself a real legal and ethical problem, not just marketing overreach.

What we’ve actually built

Every item below points at the real file it lives in, so you can check it yourself:

• A working skip link. The first focusable element on every page jumps straight to the main content, visibly styled when focused (src/app/layout.tsx).
• A visible, sitewide focus indicator. Every interactive element gets a crisp 2px outline plus a soft halo on keyboard focus — including a separate high-contrast variant for our dark-background sections, so focus stays visible against both the light and dark parts of the site (src/app/globals.css, the :focus-visible and .dark-band :focus-visible rules).
• Reduced-motion support throughout. The stylesheet checks prefers-reduced-motion at more than a dozen separate points — turning off or softening scroll-driven reveals, hover-lift transforms, and smooth scrolling for anyone who has asked their system for less motion (src/app/globals.css). No content or function ever depends on an animation actually playing.
• Semantic landmarks and labeled navigation. A single header/nav/main /footer structure runs sitewide, with the primary and mobile navigation regions each carrying their own aria-label (src/app/layout.tsx, src/components/Header.tsx, src/components/Footer.tsx).
• Breadcrumb navigation with a labeled nav landmark and aria-current="page" on the current page, matched by real BreadcrumbList structured data rather than a visual-only trail (src/components/Linking.tsx).
• An accessible pattern for scrollable data tables. Wide comparison tables (card comparisons, lender data) sit inside a region with tabIndex={0}, role="region", and a descriptive aria-label, so keyboard users can scroll the table with arrow keys and screen-reader users get an accessible name for it — plus a visually-hidden <caption> describing what’s being compared (src/components/products/StudentCardTable.tsx, src/components/products/BuyerBewarePanel.tsx).
• Real form labels and inline error handling. Every input in our calculators and the debt tracker has an associated <label>, and validation errors are linked to their field with aria-invalid and aria-describedby rather than shown as color alone (src/components/products/DebtTracker.tsx, src/components/products/PaymentCalculator.tsx).
• Live-region status announcements. Actions in our interactive tools — saving a debt, marking one paid off, running a calculator — update a visually-hidden aria-live="polite" region, so screen-reader users hear confirmation without their focus jumping anywhere (used across DebtTracker.tsx, PaymentCalculator.tsx, and our lender and card-finder tools).
• Decorative elements are hidden from assistive technology. The logo mark uses alt="" with aria-hidden="true" (src/components/LogoMark.tsx), and the small glyphs on our warning/caution/note callouts (◷, ⚖, ⚲) are marked aria-hidden="true" so a screen reader announces the text label next to them instead of an unreadable symbol (src/components/Blocks.tsx).
• Color is never the only signal. Our warning, legal-consequence, and informational callouts each pair a distinct border color with its own text label and icon — never a bare color change alone.
• An internal, code-based contrast check. During our last visual redesign we ran a programmatic audit of the text/background color pairs used sitewide against WCAG 1.4.3 and corrected the ones that fell short. This was an internal engineering check, not an independent or certified audit, and it does not cover every possible combination a reader might encounter.

Known limitations — stated honestly

We would rather list these than let you find them first:

• No independent audit or assistive-technology user testing. Everything above was implemented against WCAG technique documentation and checked internally by the people who built it — not verified by an accessibility specialist, and not tested by people who use screen readers, switch access, or magnification day to day.
• Interactive tools haven’t had dedicated screen-reader testing. The calculators, debt tracker, card finder, and comparison tables follow semantic HTML and ARIA patterns we believe are correct, but none has been walked through end-to-end with JAWS, NVDA, or VoiceOver by someone who relies on one.
• Long-form article content isn’t exhaustively swept. We publish content as Markdown/MDX across hundreds of pages; we have not individually checked every article for a perfect heading hierarchy, and an occasional heading-level skip is possible in older content.
• Third-party content is outside our control. Outbound links to government and legal-aid sites, and Google’s own analytics scripts where analytics is enabled, are not something we can guarantee the accessibility of — see Privacy Policy for what analytics does and doesn’t do.
• Optional motion still exists. Reduced-motion is respected everywhere (see above), but for readers who haven’t set that system preference, a handful of subtle scroll-driven animations remain. They are decorative only and never required to read or use anything on the site.

Report a barrier

If something on this site is hard or impossible to use with a keyboard, screen reader, or other assistive technology, tell us — “accessibility problems with the site” is already a listed reason to write on our contact page. Please include the page URL, what you were trying to do, and the browser or assistive technology you were using, if you can. That level of detail is the difference between us guessing and us actually fixing it.

Our commitment

We aim to acknowledge accessibility reports within a few business days and to fix a confirmed barrier as quickly as we reasonably can, prioritizing anything that blocks you from reading content or completing a tool over cosmetic issues. This is a commitment we intend to keep, not a formal service-level agreement.

Outside of writing to us directly, website accessibility complaints under the Americans with Disabilities Act can also be filed with the U.S. Department of Justice’s ADA complaint process.