Current accessibility features

What's live across the site today:

• Semantic page structure. Every page uses proper HTML landmarks — header, navigation, main, article, aside, footer — so assistive technology can jump between regions without scanning the full document.
• Descriptive link text. Links describe their destination in context. We avoid bare "click here", "more", and "read on" in isolation.
• Keyboard navigation. Every interactive element — links, buttons, dropdowns, form fields — is reachable and operable from the keyboard, and shows a visible focus outline when reached by tab.
• Form labels and live status. Form inputs are paired with persistent labels (no placeholder- only inputs). Submission outcomes and errors are announced through ARIA live regions so screen-reader users hear the result without re-reading the form.
• Editorial colour palette chosen for legibility. Body text is deep ink on warm paper rather than pure black on pure white; the accent red is reserved for emphasis and never carries meaning by itself. Status — error, success, warning — is signalled by both colour and text.
• Scalable typography. Type is sized in relative units so browser-level text zoom and reader preferences flow through cleanly. The serif headline face (Fraunces) and sans body face (Manrope) are both chosen for readability at editorial sizes, not display drama.
• Language declared. Each page declares its language at the document level so assistive technology selects the right voice and pronunciation.
• Server-rendered editorial content. Articles, charts, and data pages render their core content from the server so screen-readers and reduced-JS environments receive the same coverage as everyone else, without waiting on client-side hydration.
• Reduced reliance on icons alone. Navigation, buttons, and controls carry text labels alongside any iconography. Where an icon stands alone for space reasons, it carries an accessible name.

What we're still working on

We don't claim full WCAG 2.1 AA conformance — formal audit and screen-reader testing are scheduled before public launch. Areas we know need work: data-visualization alternatives for screen- reader users on chart pages, motion-reduction support on the few animated transitions, and refined skip-to-content navigation on long article pages. If something in this list matters for your use, please get in touch.

Tell us what's broken

If something on FinNotes didn't read well with your assistive technology — a missing label, an unreachable control, a contrast problem, an unreadable chart — please tell us. Accessibility issues are treated like editorial corrections: we triage them first and respond within one business day.

Send specifics (URL, browser + assistive technology in use, what you expected) to [email protected], or use our contact page.