FundWisr™ Accessibility Statement
1. Commitment to Accessibility
FundWisr™ is committed to providing a digital experience that is accessible to people with disabilities.
FundWisr is designed to support nonprofit organizations, social enterprises, businesses, consultants, board members, staff, volunteers, and other users with a wide range of abilities, technologies, and access needs.
Impctrs Management Group, LLC is working to make FundWisr websites, applications, documents, communications, support services, and customer workflows perceivable, operable, understandable, and robust.
Accessibility is treated as an ongoing product, content, service, procurement, and quality responsibility, not as a one-time certification.
2. Accessibility Standard
FundWisr's target is substantial conformance with:
Web Content Accessibility Guidelines (WCAG) 2.2, Level AA
WCAG is developed by the World Wide Web Consortium's Web Accessibility Initiative and provides recommendations for making web content more accessible to people with disabilities.
FundWisr may also consider:
- applicable Americans with Disabilities Act requirements;
- Section 508 and related federal accessibility practices where relevant to customers or contracts;
- accessible document standards;
- platform-specific mobile accessibility guidance;
- applicable state, local, contractual, procurement, and international requirements.
A statement of target conformance does not mean that every page, feature, document, integration, or third-party component is currently free from accessibility barriers.
FundWisr must not claim "fully ADA compliant," "100% accessible," "certified accessible," or similar absolute language unless the specific claim is accurate, supported, current, and appropriately scoped.
3. Accessibility Features
FundWisr is designed to support features such as:
- keyboard navigation;
- visible keyboard focus;
- logical heading structure;
- descriptive page titles;
- properly associated form labels;
- accessible form instructions and errors;
- sufficient color contrast;
- text resizing and browser zoom;
- screen-reader compatibility;
- meaningful alternative text;
- captions and transcripts for prerecorded media;
- accessible tables;
- accessible dialogs and notifications;
- understandable link and button labels;
- reduced-motion preferences;
- non-color indicators;
- responsive layouts;
- status announcements for assistive technologies;
- accessible authentication;
- accessible legal notices and consent controls;
- accessible reports and document exports where supported.
Actual availability may vary by feature, file format, browser, device, assistive technology, and third-party integration.
4. Recommended Technology
FundWisr should be usable with current versions of commonly used:
- desktop and mobile browsers;
- screen readers;
- screen magnification software;
- voice-input software;
- keyboard-only navigation;
- switch-control technologies;
- browser zoom and text-resizing tools;
- operating-system accessibility settings.
Users should not be required to use one specific assistive technology to access core FundWisr services.
When reporting an issue, users may optionally identify their browser, device, assistive technology, and the page or feature involved. FundWisr must not require a user to disclose a diagnosis or medical information to request help.
5. Known Limitations
Audit basis: two internal reviews, neither of them a certified third-party WCAG audit.
The first, conducted 2026-08-08, checked image alternative text, form and search field labeling, interactive-element accessible names, heading hierarchy, keyboard focus visibility, and color contrast against WCAG 2.1 AA thresholds across the marketing site, legal pages, and the core application.
The second, conducted 2026-08-26, reviewed overlay dialogs, dropdown menus, and page landmarks. It found and remediated three failures the first review had missed:
- Dialogs were not announced and could not be closed from a keyboard. Thirty-nine drawers and modals were built as plain containers with no dialog role, so assistive technology was never told one had opened, and keyboard focus continued into the page behind them. Twenty-three of the thirty-nine had no Escape handler, which meant a keyboard user who opened one could not close it. This was a failure of WCAG 2.1.2 (No Keyboard Trap), Level A. All thirty-two current dialogs now declare a role and a name, move focus in on open, confine Tab within the dialog, close on Escape, and return focus on close.
- Thirty close buttons and four row menus had no text alternative, presenting to assistive technology as an unlabeled button or as a punctuation character. WCAG 4.1.2, Level A. All now carry accessible names, and menu triggers report whether the menu is open.
- The skip link pointed at nothing on the public site. Forty pages rendered a main landmark with no matching identifier, so the first control a keyboard user reached did nothing before scripting loaded and never moved the caret afterwards. WCAG 2.4.1, Level A. Every page and shell now carries the target, and the accessibility settings are reachable from inside the application and from every portal rather than only from the marketing footer.
A follow-up on 2026-08-26 addressed status messages, the remaining Level AA item the second review had identified:
- The result of an action was shown but not announced. Errors, confirmations and notices appeared on screen as styled text with no programmatic status role, so somebody using a screen reader received no indication that a save had failed, a record had been archived, or a filter had returned nothing. Seven live regions existed across the product against more than two hundred and fifty such messages. WCAG 4.1.3 (Status Messages), Level AA. All of them now announce through a persistent live region, using an assertive role for failures and a polite one for confirmations.
A second follow-up on 2026-08-26 corrected the text-size control:
- The text-size setting did not resize any text. The accessibility panel offers 90% to 200% and works by setting a font size on the page's root element. Every one of the roughly 8,000 text sizes in the product was an absolute pixel value, which does not respond to that setting. Measured directly: selecting 200% moved the root from 16 to 32 pixels and left every heading and paragraph exactly as it was. The same fault meant the product ignored a larger default font size set in the reader's own browser. All text sizes are now relative, the control resizes the interface as described, and the layout reflows without horizontal scrolling at every offered size.
Neither review, nor either follow-up, included testing with a screen reader by a person who relies on one day to day. A full third-party audit remains a recommended next step and is not yet scheduled.
For each known limitation, disclose:
- affected page, feature, file, or integration;
- the barrier users may experience;
- affected interaction or assistive technology;
- temporary alternative;
- remediation status;
- estimated review or remediation milestone where appropriate.
Required format
| Area | Known limitation | Temporary alternative | Status |
|---|---|---|---|
--color-faint and --color-taupe design tokens on the ivory surface (used for captions, eyebrows, and metadata labels) | Measured 4.05:1 and 3.82:1 respectively against ivory, below the 4.5:1 WCAG AA minimum for normal-size text; --color-taupe also measures 4.33:1 against paper. All three clear the 3:1 minimum for large-scale text. Against the canvas and paper surfaces --color-faint now measures 4.78:1 and 4.58:1 and passes | Affected text is supplementary labeling, never the only way to reach a page's primary content or complete a required action | Re-measured 2026-08-26. The earlier figure recorded here (approximately 3.0:1) is superseded: the token was darkened after 2026-08-08 and now passes on two of the three light surfaces. The residual combinations above are a brand-palette decision awaiting the owner's review, not an engineering blocker |
| Repeated identical failure messages | Where a form reports the same error twice in a row and the handler does not clear the message between attempts, the second failure is shown but not re-announced. This affects a minority of handlers; the majority clear the message before retrying, which causes the repeat to be announced normally | The message remains visible on screen throughout, and the field-level validation state does not change between attempts | Identified 2026-08-26 during the status-message remediation. A caller-side convention rather than a defect in the announcement itself |
| WCAG 2.2-specific success criteria | The stated target in Section 2 is WCAG 2.2 Level AA. Both internal reviews were conducted against WCAG 2.1 Level AA thresholds. The criteria added in 2.2, including Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication (3.3.8), have not been separately reviewed. Target Size Minimum (2.5.8) was checked and interactive targets meet the 24 by 24 threshold | Not applicable; this is a gap in review coverage rather than a known barrier | Identified 2026-08-26. To be included in the third-party audit when scheduled |
| Full-app screen-reader walkthrough (JAWS, NVDA, VoiceOver) | Not yet performed. Both internal reviews checked accessible names, labels, roles, and heading structure programmatically, but nothing has been verified end-to-end by a person using a screen reader | Every checked interactive element does expose a programmatic accessible name | Scheduled as part of a future third-party audit, not yet dated |
Do not state that there are "no known limitations" unless a current audit supports that statement.
Potential areas requiring special review include:
- AI chat and streaming responses;
- charts and dashboards;
- drag-and-drop interfaces;
- diagnostic progress indicators;
- document editors;
- data tables;
- file uploads;
- signature tools;
- calendar controls;
- PDF exports;
- DOCX exports;
- third-party payment pages;
- embedded support tools;
- interactive maps or property tools;
- third-party authentication;
- videos and webinars;
- dynamically generated reports.
6. Third-Party Content and Integrations
Some FundWisr features may use third-party services, embedded content, payment tools, authentication providers, document-rendering tools, chat tools, videos, or other integrations.
FundWisr evaluates accessibility when selecting and configuring material providers, but it may not control every aspect of third-party technology.
When a third-party barrier affects access to a FundWisr service, FundWisr should:
- document the barrier;
- provide an alternative method where reasonably possible;
- communicate with the provider;
- prioritize replacement or remediation when the barrier materially affects access;
- avoid shifting the full burden to the user.
A general third-party disclaimer must not be used as a substitute for providing reasonable access to core FundWisr services.
7. Alternative Formats and Reasonable Assistance
Users may request reasonable assistance or an alternative format for FundWisr content or services.
Depending on the request and the nature of the material, alternatives may include:
- accessible HTML;
- tagged PDF;
- accessible Word document;
- plain-text version;
- CSV or structured data;
- captioned video;
- transcript;
- audio description;
- larger text;
- high-contrast version;
- keyboard-accessible workflow;
- assistance completing a form;
- assistance accessing a report;
- an alternative method for completing a transaction;
- human support for a blocked workflow.
FundWisr will evaluate requests individually and will not require a person to accept an alternative that does not provide meaningful access to the relevant service.
FundWisr must not charge a disability-related fee for an accessibility accommodation.
8. Contact FundWisr About Accessibility
To report an accessibility barrier, request assistance, or ask for an alternative format, contact:
FundWisr Accessibility Team
Impctrs Management Group, LLC
Email: accessibility@fundwisr.ai
Telephone or relay-compatible contact: 888-429-5094
Mailing address: 830 N John Young Parkway, Kissimmee, FL 34741
Accessibility request form: https://www.fundwisr.ai/contact?topic=Accessibility%20request
Please provide, when possible:
- the page, feature, document, or communication involved;
- a description of the barrier;
- the format or assistance requested;
- your preferred contact method;
- any relevant browser, device, or assistive technology details you choose to share.
Do not send passwords, payment-card information, Social Security numbers, unnecessary health information, or confidential client documents through the accessibility form.
9. Response Commitment
FundWisr should acknowledge accessibility requests promptly.
Recommended service targets:
- automatic confirmation immediately;
- human acknowledgment within five business days;
- initial assessment within ten business days;
- urgent access barriers affecting account security, payment, active deadlines, or core service access prioritized as soon as practicable, ahead of the standard windows above;
- progress updates when resolution requires additional time.
These are service targets, not guarantees. The final public wording must reflect FundWisr's actual staffing and operational capacity.
If FundWisr cannot immediately remove a barrier, it should provide a meaningful temporary alternative when reasonably possible.
10. Feedback and No Retaliation
FundWisr welcomes accessibility feedback.
A user will not lose access, receive a lower score, be charged more, or be treated adversely because they:
- use assistive technology;
- report an accessibility barrier;
- request an alternative format;
- request an accommodation;
- decline to disclose disability details;
- challenge the adequacy of an accessibility response.
Accessibility complaints must not be used for marketing segmentation, AI training, diagnostic scoring, risk scoring, funding matching, or unrelated profiling.
11. Changes to This Statement
FundWisr may update this Accessibility Statement as:
- the platform changes;
- audits identify new barriers;
- barriers are remediated;
- standards change;
- legal obligations change;
- third-party integrations change.
The Statement must display:
- effective date;
- last updated date;
- version;
- material-change summary where appropriate.
12. Entity Statement
FundWisr™ is operated by Impctrs Management Group, LLC under license from Mzrik Innovations, LLC. © 2026 Mzrik Innovations, LLC. All rights reserved. FundWisr™ and its proprietary frameworks, scoring systems, methodologies, platform content, software, and related intellectual property are owned by Mzrik Innovations, LLC. Technology developed by AI Arkitech, LLC.