Accessibility at Donateazy

Built so everyone can use it.

Donateazy is committed to digital accessibility for every NGO administrator, donor, and beneficiary. Here is what we conform to, what works today, and how to flag what doesn't.

Target WCAG 2.1 Level AA Last reviewed 20 May 2026
Conformance statement

Donateazy partially conforms to WCAG 2.1 Level AA.

"Partially conforms" means most parts of the platform meet the standard, with known exceptions noted below. We test new releases against this bar, and we treat any AA failure on a critical donor or compliance flow as a P1 bug.

01Our Commitment

NGOs serve everyone, so the tools they rely on must too. Donateazy is built so that an NGO finance lead using a screen reader, a donor on a low-bandwidth Android device, and a board member zooming the browser to 200 percent can all complete their task.

Accessibility is a baseline, not a feature. We do not charge for it, and we do not gate it behind a plan.

02Standards We Follow

  • WCAG 2.1 Level AA (Web Content Accessibility Guidelines, World Wide Web Consortium) is our primary conformance target.
  • EN 301 549 (European accessibility standard for ICT) for the underlying success criteria.
  • Section 46 of the Rights of Persons with Disabilities Act, 2016 (India) and the related Guidelines for Indian Government Websites (GIGW 3.0) inform our public-page design.

Where DPDPA 2023 consent flows interact with assistive technology, we apply the spirit of WCAG 2.2 even where 2.1 is silent.

03What Works Today

  • Keyboard navigation: every interactive control on the marketing site, the NGO dashboard, and the donor checkout is reachable using Tab, Shift+Tab, Enter, and Space.
  • Visible focus: a saffron focus ring is rendered on every focusable element. We do not suppress the browser focus indicator.
  • Colour contrast: body text against ivory backgrounds meets the WCAG AA 4.5:1 ratio. Primary calls-to-action (saffron on ink, ivory on ink) exceed 7:1.
  • Semantic structure: headings follow a single H1 per page with logical H2 / H3 nesting. Landmarks (header, main, nav, footer) are used consistently.
  • Forms: every form field has an associated label, error messages are announced via aria-live, and required fields are marked with both visual and programmatic cues.
  • Resize: the layout reflows cleanly at 320px viewport width and at 200 percent browser zoom without horizontal scroll on body content.
  • Reduced motion: all marquee and fade-in animations honour prefers-reduced-motion: reduce.

04Assistive Technology We Test With

The platform is tested in each release cycle against the following combinations:

Screen reader Browser Status
NVDA (latest)Firefox, Chrome on WindowsSupported
JAWS (latest)Chrome on WindowsSupported
VoiceOverSafari on macOS, iOSSupported
TalkBackChrome on AndroidSupported
NarratorEdge on Windows 11Best-effort

The platform is also usable with Dragon NaturallySpeaking and switch controls on iOS and Android.

05Known Limitations

We are honest about gaps. These are the areas that do not yet meet our AA target:

  • Receipt PDFs: 80G receipt PDFs are generated as styled HTML to PDF. The tag tree is not yet PDF/UA compliant. A screen reader can read the receipt text, but the heading and table semantics in the PDF tag tree are limited. Tracking as a P2 fix.
  • Older charts: a small number of donor-trend charts in the legacy analytics view do not yet have text alternatives that fully describe trend direction and magnitude. The same data is always available as a downloadable CSV from a control adjacent to the chart.
  • Third-party widgets: the Razorpay payment widget is rendered inside an iframe controlled by Razorpay. We have raised accessibility issues with Razorpay and link to their accessibility statement from our checkout page.

If you encounter a barrier that is not listed here, please report it. We treat every report as a real issue, not an edge case.

06How We Test

  • Automated: axe-core runs against every pull request that touches a Blade template or component. A build cannot merge if it introduces a new WCAG AA violation on a tracked page.
  • Manual: the donor checkout, NGO onboarding wizard, and 10BD export flow are walked through end-to-end with a screen reader once per release.
  • External audit: we commission a third-party WCAG 2.1 AA audit annually. The most recent audit report summary is available on request from accessibility@donateazy.com.

07Report a Barrier

If you cannot complete a task on Donateazy because of an accessibility barrier, please tell us. We commit to:

  • Acknowledging your report within 2 working days.
  • Providing an interim workaround within 5 working days where the issue blocks a compliance or donation flow.
  • Tracking a permanent fix on the public roadmap, with status updates to you until it ships.
Contact the accessibility team

Email accessibility@donateazy.com with the URL of the page, the assistive technology you were using, and a short description of what failed. A screenshot or screen recording helps but is not required.

08Roadmap

  • Q3 FY26-27: PDF/UA tagging for all generated 80G receipts.
  • Q4 FY26-27: high-contrast theme toggle and text-resize control persisted per user profile.
  • FY27-28: WCAG 2.2 AA conformance review across the full surface area, including the dashboard and field PWA.
Accessibility office
Donateazy
Bengaluru, Karnataka, India
accessibility@donateazy.com →
Chat with us