Legal
Accessibility
A lot of the people running a nonprofit's books are volunteers, treasurers, and directors doing it after hours — some using a screen reader, a keyboard instead of a mouse, or a larger text size. We want NP Ledger to work for them, and we treat that as part of getting the product right, not an extra.
Last updated: July 7, 2026
This statement explains the standard we build to, what we do to hold ourselves to it, where we know we still fall short, and how to reach us if something gets in your way. If you hit a barrier, tell us at support@70ware.com — a real person reads it, and we treat access problems as bugs.
The standard we build to
Our target is the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — the same bar most public bodies and enterprise buyers use. WCAG 2.2 AA builds on 2.1 AA and adds criteria like minimum target sizes, visible focus that isn't hidden behind other content, and not making people re-enter information they already gave.
We aim for that standard across the app and our public pages. We don't claim we meet every criterion on every screen at every moment — an application this size changes weekly, and honest is more useful to you than absolute. Where we know a screen falls short, we say so below and we're working on it.
What we do to hold that line
Accessibility is easy to promise and easy to let slip. So we wired checks into the build itself, not just a once-a-year review:
- Automated audits on every change. Our test suite renders the app in a real browser and runs the axe-core accessibility engine against the major pages, checking for WCAG 2.2 A and AA issues. A serious or critical finding fails the build, so a regression can't ship quietly.
- A gate on every page we render. A second check scans each screen the test suite produces for form fields with no label and icon-only buttons with no name — the kinds of gaps that are invisible in a code review but block a screen-reader user. A new one can't land without being caught.
- Keyboard and screen-reader patterns. Menus, dialogs, and the command palette are built to be reached and operated with a keyboard, with focus handling and labels that assistive technology can announce.
In our opinion this catches the common, repeatable problems well. It is automated tooling and our own review, though — not yet an independent third-party audit. Automated checks can't judge everything a person would, so we lean on the report-a-barrier path below to catch what they miss.
Where we know we fall short
Being straight about the gaps: some multi-step flows (like the import and tagging wizards) and detail screens that need specific data to open aren't yet covered by the automated audit end to end, and some third-party embedded pieces — such as a bank-connection widget or a payment form — follow their provider's accessibility, not ours. We're extending coverage over time. If one of these is where you're stuck, tell us and we'll prioritize it and find you a way through in the meantime.
Report a barrier — and get help
If any part of NP Ledger is hard or impossible to use with your setup, email support@70ware.com. It helps if you can tell us the page, what you were trying to do, and the browser or assistive technology you use — but send it however you can, and we'll follow up. We aim to reply within a few business days, and if something is blocking you from getting your books done, we'll help you get it done while we fix the underlying issue.
Conformance report (VPAT) on request
If your organization — a government office, a grantmaker with a Section 508 flow-down, or a buyer with a procurement checklist — needs a formal accessibility conformance report, we keep a VPAT describing how NP Ledger measures against WCAG 2.2 AA. It's a self-assessment, current as of the date above, and we'll share the latest copy on request. Email support@70ware.com and ask for the VPAT.