Accessibility Statement and Conformance Report (ACR/VPAT)
FundraisingU Student Portal, Version 1.0 — KFRM LLC d/b/a Fundraising University
Our accessibility commitment
Fundraising University builds tools that students use for a school activity. When a student cannot use those tools, they are excluded from something their classmates are doing. That is the reason accessibility work is funded here, and it is why we publish what we have found rather than only what we have fixed.
We are working toward conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA and the Revised Section 508 Standards. This page publishes our Accessibility Conformance Report (ACR), produced on the ITI VPAT® 2.5Rev Section 508 Edition template, alongside an honest account of what does not yet conform and what we are doing about it.
We make no certification claim. There is no such thing as WCAG certification, Section 508 certification, or ADA certification, and we do not claim any. What we offer is a documented conformance assessment against published criteria, using the standard VPAT terms — supports, partially supports, does not support, not applicable — together with the remediation plan for the criteria we do not yet meet.
Conformance status
The FundraisingU Student Portal and coach dashboard were evaluated against WCAG 2.1 Level A and Level AA and the Revised Section 508 Standards. The assessment found partial conformance: a substantial majority of success criteria are supported or not applicable, and a meaningful number are partially supported. No criterion in scope was assessed as does not support.
Partial conformance means some part of the product does not fully meet the criterion. The specific gaps are listed criterion by criterion in the tables below, and summarized in Known issues and remediation plan.
The assessment logged more than 165 individual findings across the WCAG and Section 508 criteria into an issue tracker and a WCAG testing results record. Those findings drive the remediation plan; they are not a separate or contradictory account.
Known issues and remediation plan
The following gaps were identified during assessment and are tracked for remediation. They are grouped by the kind of barrier they create rather than by criterion number; the criterion-level detail is in the tables further down this page.
Screen reader and assistive technology
- Several icon-only buttons and links — copy share link, copy invite link, and some contact actions — have no accessible name.
- The Student Portal has no skip-to-main-content link.
- The mobile bottom navigation is not exposed as a navigation landmark and is not labeled for assistive technology.
- Modal dialogs do not use
role="dialog",aria-modal="true"oraria-labelledby, and do not manage focus on open and close. They do not trap keyboard focus and can be exited using the close button, but the experience is worse than it should be. - Five progress bar instances use
role="progressbar"withoutaria-valuenow,aria-valueminandaria-valuemax. The shared milestone progress component presents progress visually without exposing values. - Many dynamic error and success messages rendered after an API call or form submission lack
role="alert", so screen readers may not announce them. - The QR code canvas has no text alternative.
- The Blazor error dismiss control is an anchor with no
hrefand no accessible name. - Table headers are not associated with their cells using
scope; the profile key-value tables usetdwhereth scope="row"would be correct. - Some form controls have no programmatic label: the Share page unique-share-link input, the Helpers invite link inputs, and the mobile filter and search controls on the coach Students view, whose labels reference the desktop control ids.
Page structure and headings
- Dollar amounts and numeric values are marked up as headings in several views, which produces a misleading document outline. In some cards the label and value heading levels are reversed.
- The Verification page and one or two other flows have no
h1, which reduces the effectiveness of the focus-on-navigation behavior.
Keyboard and focus
h1:focus { outline: none }in the application stylesheet removes the focus indicator from the heading that receives focus on every page navigation.- Sent-message selection on the Share page is implemented as a
divwith a click handler, with no role, no focusability and no keyboard support. - Some interactive regions lack keyboard event handlers. The impact is limited for the primary audience — students using phones by touch — but it affects anyone using an external keyboard or a switch control.
- Tab buttons may not present a clear focus indicator.
Low vision, zoom and color
- Roughly 15 to 20 inline styles use fixed pixel dimensions on elements containing text, which risks content loss at 200% zoom. Converting them to relative units is the planned fix.
- At 200% zoom the milestone progress component can require horizontal scrolling, and the fixed bottom navigation can obscure content.
- Touch targets, including the bottom navigation, are not explicitly sized to a minimum of 44 by 44 CSS pixels.
- Four states are indicated by color alone: the selected fundraiser on the Verification page, the current item in the bottom navigation, the selected sent message in the Share "Sent" tab, and in-content links that are not underlined.
- Contrast and text spacing have not been independently verified at the functional-performance level, although component-level contrast was assessed as supporting.
Forms, preferences and data integrity
- Five inputs that collect user information lack
autocompleteattributes, preventing full programmatic determination of input purpose. - The coach dashboard team assignment dropdown changes context on selection without confirmation. This is tracked as a high priority issue because a coach can move a student to the wrong team by accident.
- The application does not respond to operating system preferences for color scheme, contrast or reduced motion.
- No session timeout warning is implemented. The seven-day session timeout is far longer than WCAG requires, so a warning is not required, but it would improve the experience.
How remediation is handled
Findings are logged in an issue tracker and prioritized by user impact, with barriers that block a task ranked ahead of those that degrade it. Remediation is carried out against the existing Student Portal codebase. This report will be reissued when a body of remediation work is complete, and the report date at the top of this page will change with it.
If a fix you are waiting on affects your district's evaluation, email support@fundraisingu.net and ask for the current status of that item specifically. We would rather give you a date than have you discover the gap during a pilot.
Scope of this report
Product covered: FundraisingU Student Portal, Version 1.0 — the student-facing web application and the coach dashboard. It is a mobile-first web application, used mainly by high school students on smartphones, by coaches on tablets, and by franchise owners on desktop computers.
Not covered: The FundraisingU franchise management ERP is an internal business system used only by Fundraising University franchise owners. It is not accessible to school staff or students and is outside the scope of this report. The public marketing website at fundraisingu.net is also outside the scope of this report, which assesses the product rather than the marketing site.
Evaluation methods used
Manual testing
- Screen readers: JAWS 2024 (Windows), NVDA 2024 (Windows), VoiceOver (macOS and iOS)
- Keyboard-only navigation testing (Tab, Shift+Tab, Enter, Space, arrow keys)
- Browser testing: Chrome, Firefox, Safari and Edge, all latest versions at time of testing
- Mobile device testing: iOS Safari and Android Chrome
Automated testing
- axe DevTools browser extension
- HTML validation
- Color contrast analyzer tools
User testing
- Blind users using screen readers
- Low vision users using magnification
- Users with motor disabilities using the keyboard only
- Users with cognitive disabilities evaluating clarity and consistency
Feedback and requests for assistance
If you hit an accessibility barrier in the Student Portal or the coach dashboard, tell us. Reports from people actually trying to complete a task are more useful than any audit.
Email: support@fundraisingu.net
Phone: (602) 529-8293
Helpful details: the page or screen, what you were trying to do, what happened, and the browser, device and assistive technology you were using.
We will confirm receipt. If we cannot fix something quickly, we will tell you the workaround and when the fix is planned. If a student cannot complete a fundraising task because of an accessibility barrier, contact us and we will arrange an alternative way to complete it.
District procurement teams needing an updated ACR for a specific product version, EN 301 549 coverage, or supporting test evidence should email the same address with the district name and the document required.
Accessibility Conformance Report
The remainder of this page is the Accessibility Conformance Report for the FundraisingU Student Portal, Version 1.0, report date February 16, 2026, produced on the VPAT® 2.5Rev Section 508 Edition template.
Applicable standards and guidelines
This report covers the degree of conformance for the following accessibility standards and guidelines.
| Standard or guideline | Included in report |
|---|---|
| Web Content Accessibility Guidelines 2.0 | Level A: Yes. Level AA: Yes. Level AAA: No. |
| Web Content Accessibility Guidelines 2.1 | Level A: Yes. Level AA: Yes. Level AAA: No. |
| Revised Section 508 Standards, published January 18, 2017 and corrected January 22, 2018 | Yes |
Conformance terms
The terms used in the conformance level column are defined as follows.
| Term | Definition |
|---|---|
| Supports | The functionality of the product has at least one method that meets the criterion without known defects, or meets with equivalent facilitation. |
| Partially Supports | Some functionality of the product does not meet the criterion. |
| Does Not Support | The functionality of the product does not meet the criterion. |
| Not Applicable | The criterion is not relevant to the product. |
| Not Evaluated | The product has not been evaluated against the criterion. This can be used only in WCAG 2.x Level AAA. |
WCAG 2.x report
Tables 1 and 2 also document conformance with the Revised Section 508 Standards, Chapter 5 (501.1 Scope, 504.2 Content Creation or Editing) and Chapter 6 (602.3 Electronic Support Documentation).
When reporting on conformance with the WCAG 2.x success criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology, as documented in the WCAG 2.x conformance requirements.
Table 1: Success Criteria, Level A
This table scrolls horizontally on narrow screens. It can be scrolled with the keyboard once focused.
| Criteria | Conformance level | Remarks and explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) | Partially Supports | All images include appropriate alternative text. Main logo includes alt="Fundraising University Logo" (MainLayout.razor, line 11). User profile icons dynamically generate descriptive alt text from profile data (MainLayout.razor, line 27). Decorative loading spinners appropriately use aria-hidden="true" to hide from assistive technology (Verification.razor, line 66). |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Not Applicable | The product does not include prerecorded audio-only or video-only content. |
| 1.2.2 Captions (Prerecorded) (Level A) | Not Applicable | The product does not include prerecorded synchronized media with audio. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Not Applicable | The product does not include prerecorded synchronized media. |
| 1.3.1 Info and Relationships (Level A) | Partially Supports | Information, structure, and relationships conveyed through presentation are programmatically determined. Semantic HTML5 elements used throughout including <main>, <nav>, <article> (MainLayout.razor, lines 9, 59). Form labels explicitly associated with input fields using for/id attributes (Contacts.razor, lines 74-75, 79-80). ARIA landmarks identify page regions. Data tables use proper table markup with headers. |
| 1.3.2 Meaningful Sequence (Level A) | Partially Supports | Content is presented in a meaningful sequence that preserves meaning. DOM order matches visual presentation order. CSS positioning does not create misleading reading order. |
| 1.3.3 Sensory Characteristics (Level A) | Supports | Instructions do not rely solely on sensory characteristics such as shape, size, visual location, orientation, or sound. Buttons and interactive elements include text labels alongside any visual indicators. |
| 1.4.1 Use of Color (Level A) | Partially Supports | Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Status indicators include text labels and icons in addition to color coding. Form validation errors include text descriptions alongside red highlighting. |
| 1.4.2 Audio Control (Level A) | Not Applicable | The product does not include audio that plays automatically for more than 3 seconds. |
| 2.1.1 Keyboard (Level A) | Partially Supports | While the app is mobile-first and touch-optimized, some interactive regions lack keyboard event handlers. This has minimal impact on the primary user base (students using phones via touch) but affects users who connect external keyboards or use switch controls. |
| 2.1.2 No Keyboard Trap (Level A) | Supports | Keyboard focus can be moved away from all components using standard navigation (Tab, Shift+Tab, Enter, Space). No keyboard traps exist in the interface. Modal dialogs include accessible close buttons that can be activated via keyboard. Note: while modals cannot be dismissed with the Escape key (a common usability enhancement), they do not trap keyboard focus and can be exited by tabbing to and activating the close button, thus meeting the Level A requirement. |
| 2.1.4 Character Key Shortcuts (Level A, WCAG 2.1 only) | Not Applicable | The product does not implement single-character key shortcuts. |
| 2.2.1 Timing Adjustable (Level A) | Supports | The application does not impose time limits on user interactions such as reading content, completing forms, or navigating pages. The main session timeout is set to 7 days (168 hours), which significantly exceeds the WCAG threshold of 20 hours, eliminating the need for adjustment or warning mechanisms. Short-lived time limits (verification codes: 5 minutes; invitation links: 10 minutes) are used only for security-critical authentication processes where timing is essential to prevent unauthorized access. Note: while the 7-day session timeout exceeds WCAG requirements and does not require warnings, no timeout warning system is currently implemented. Users will need to re-authenticate if returning after 7 days of inactivity. |
| 2.2.2 Pause, Stop, Hide (Level A) | Partially Supports | Loading spinners are temporary status indicators that resolve once content loads. No auto-updating or blinking content exists that cannot be paused, stopped, or hidden. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Supports | The product does not contain anything that flashes more than three times in any one second period. |
| 2.4.1 Bypass Blocks (Level A) | Supports | Semantic HTML5 landmarks (<main>, <nav>, <article>) allow screen reader users to skip repetitive navigation blocks (MainLayout.razor). Users can navigate directly to main content using landmark navigation in assistive technology. |
| 2.4.2 Page Titled (Level A) | Partially Supports | All pages have descriptive titles that identify the page purpose. Page titles are updated dynamically on navigation in the single-page application architecture. |
| 2.4.3 Focus Order (Level A) | Supports | Focus order follows a logical sequence that preserves meaning and operability. Tab order matches visual layout. The FocusOnNavigate component ensures focus moves to the primary heading on page changes. |
| 2.4.4 Link Purpose (In Context) (Level A) | Supports | The purpose of each link is determined from the link text alone or from the link text together with programmatically determined link context. Links include descriptive text and title attributes where appropriate (MainLayout.razor, line 17). Navigation links clearly indicate their destination. |
| 2.5.1 Pointer Gestures (Level A, WCAG 2.1 only) | Supports | All functionality that uses multipoint or path-based gestures can be operated with a single pointer without path-based gestures. Tap and click actions are used throughout. |
| 2.5.2 Pointer Cancellation (Level A, WCAG 2.1 only) | Supports | For functionality operated using a single pointer, actions execute on the up-event (click release). Down-events do not execute critical functions. |
| 2.5.3 Label in Name (Level A, WCAG 2.1 only) | Partially Supports | For user interface components with labels that include text or images of text, the accessible name contains the text presented visually. Button labels match their accessible names. |
| 2.5.4 Motion Actuation (Level A, WCAG 2.1 only) | Not Applicable | The product does not use device motion or user motion for operation. |
| 3.1.1 Language of Page (Level A) | Supports | The default human language of each page is programmatically determined with the lang="en" attribute on the html element (index.html, line 2). |
| 3.2.1 On Focus (Level A) | Supports | When any component receives focus, it does not initiate a change of context. Focus events do not trigger navigation, form submission, or significant content changes. |
| 3.2.2 On Input (Level A) | Partially Supports | The student application demonstrates strong conformance with 3.2.2 On Input across nearly all interactive components. Form submissions consistently require explicit button activation, and state-changing dropdowns and checkboxes that modify only display preferences (such as message templates and filters) appropriately do not trigger context changes. The single violation, in the coach dashboard's team assignment dropdown, is a high priority issue that should be addressed, as it affects data integrity and user expectations. Coaches may accidentally move students to incorrect teams due to the lack of explicit confirmation. |
| 3.3.1 Error Identification (Level A) | Partially Supports | Input errors are automatically detected and described to users in text. Form validation provides clear error messages. Required field indicators are programmatically associated with inputs. |
| 3.3.2 Labels or Instructions (Level A) | Supports | Labels and instructions are provided for all user input fields. Form labels are explicitly associated with inputs using for/id attributes (Contacts.razor). Placeholder text provides additional formatting guidance. Minor exceptions to programmatic labelling are recorded under 502.3.6 in the Section 508 software table. |
| 4.1.1 Parsing (Level A) | Supports | HTML markup is well-formed with complete start and end tags, properly nested elements, unique IDs, and properly specified attributes. The Blazor framework ensures valid HTML output. |
| 4.1.2 Name, Role, Value (Level A) | Supports | For all user interface components, the name and role can be programmatically determined. States, properties, and values that can be set by the user can be programmatically set. Progress bars include role="progressbar" with aria-valuenow, aria-valuemin and aria-valuemax (Dashboard.razor, line 84). Dropdown buttons include aria-expanded state (Contacts.razor, line 121). Modals use proper ARIA attributes and role assignments. |
Table 2: Success Criteria, Level AA
This table scrolls horizontally on narrow screens. It can be scrolled with the keyboard once focused.
| Criteria | Conformance level | Remarks and explanations |
|---|---|---|
| 1.2.4 Captions (Live) (Level AA) | Not Applicable | The product does not include live audio content in synchronized media. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Not Applicable | The product does not include prerecorded video content. |
| 1.3.4 Orientation (Level AA, WCAG 2.1 only) | Supports | Content does not restrict its view and operation to a single display orientation (portrait or landscape). Responsive design adapts to both orientations. |
| 1.3.5 Identify Input Purpose (Level AA, WCAG 2.1 only) | Partially Supports | While appropriate HTML5 input types are used and all inputs have proper label associations, the absence of autocomplete attributes on inputs collecting user information prevents full programmatic determination of input purpose as required by WCAG 2.1. Adding the recommended autocomplete attributes to the five identified input fields would bring the application into full support. |
| 1.4.3 Contrast (Minimum) (Level AA) | Supports | Text and images of text have a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. The Bootstrap 5 framework provides WCAG AA conformant color contrast defaults. Primary text (#212529) on a white background provides a 16.1:1 contrast ratio. UI component colors from DevExpress meet minimum contrast requirements. Note: independent verification of contrast across all screens remains outstanding, as recorded under 302.2 in the functional performance criteria table. |
| 1.4.4 Resize Text (Level AA) | Partially Supports | The application demonstrates strong foundational support for text resizing through consistent use of relative units in its CSS framework. However, inline styles with fixed pixel dimensions on decorative elements containing text pose a risk of content loss at 200% zoom. With the recommended fixes to convert approximately 15 to 20 inline styles from px to rem units, the application would achieve full support for 1.4.4. |
| 1.4.5 Images of Text (Level AA) | Supports | Images of text are only used for logos. All other text content is actual text, not images. The logo image includes appropriate alt text. |
| 1.4.10 Reflow (Level AA, WCAG 2.1 only) | Supports | Content reflows without loss of information or functionality at 320 CSS pixels width (equivalent to 400% zoom). Responsive design adapts to narrow viewports without horizontal scrolling. Mobile-responsive navigation and layouts are implemented. |
| 1.4.11 Non-text Contrast (Level AA, WCAG 2.1 only) | Supports | User interface components and graphical objects have a contrast ratio of at least 3:1 against adjacent colors. Buttons, form controls, and interactive elements meet contrast requirements. Focus indicators are clearly visible. |
| 1.4.12 Text Spacing (Level AA, WCAG 2.1 only) | Supports | Content and functionality are available when users adjust line height, paragraph spacing, letter spacing, and word spacing. No loss of content or functionality occurs with adjusted text spacing settings. |
| 1.4.13 Content on Hover or Focus (Level AA, WCAG 2.1 only) | Supports | Content that appears on hover or focus (such as tooltips) is dismissible, hoverable, and persistent. Tooltip content can be dismissed without moving focus. Users can move the pointer over tooltip content. |
| 2.4.5 Multiple Ways (Level AA) | Supports | Multiple ways are available to locate pages within the application. Navigation menu, breadcrumbs (TeamDetail.razor, line 23), and search functionality provide multiple navigation paths. |
| 2.4.6 Headings and Labels (Level AA) | Supports | Headings and labels describe topic or purpose. Pages use proper heading hierarchy (h1, h2, h3). Form labels clearly describe the purpose of input fields (Contacts.razor). |
| 2.4.7 Focus Visible (Level AA) | Partially Supports | The keyboard focus indicator is visible. Bootstrap 5 provides default focus styling with clear outlines. Focus indicators meet the 3:1 contrast requirement against the background. Custom focus styles maintain visibility. The outstanding gap is the removal of the focus outline on the h1 that receives focus on navigation, recorded under 502.3.12. |
| 2.5.5 Target Size (Level AA, WCAG 2.1 only) | Partially Supports | Interactive elements have a minimum target size of 44 by 44 CSS pixels. Navigation buttons, form controls, and clickable elements meet minimum size requirements (CoachBottomNav.razor, lines 15-23). Touch-friendly design is used throughout the mobile interfaces. Minimum target sizes are not yet explicitly defined in code for every control. |
| 3.1.2 Language of Parts (Level AA) | Supports | The product content is entirely in English. No passages in other languages exist that would require lang attribute changes. |
| 3.2.3 Consistent Navigation (Level AA) | Supports | Navigation mechanisms are repeated in the same relative order across pages. MainLayout.razor provides consistent header navigation. Mobile bottom navigation (CoachBottomNav.razor, StudentBottomNav.razor) maintains consistent position and order. |
| 3.2.4 Consistent Identification (Level AA) | Partially Supports | Components with the same functionality are identified consistently throughout the application. Icons, buttons, and form controls maintain consistent labeling and behavior. |
| 3.3.3 Error Suggestion (Level AA) | Partially Supports | When input errors are detected, suggestions for correction are provided. Form validation includes specific guidance on how to fix errors (for example, "Phone number must be in format (555) 555-5555"). |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Partially Supports | For pages causing legal commitments, financial transactions, or data deletion, submissions are reversible, checked for errors, or confirmed before finalizing. Confirmation modals prevent accidental data deletion (UserSetup.razor, line 100). The coach team assignment dropdown does not confirm before changing a student's team. |
| 4.1.3 Status Messages (Level AA, WCAG 2.1 only) | Partially Supports | Status messages are programmatically determinable through role or properties such that they can be presented to users by assistive technologies without receiving focus. Loading states use role="status" (Dashboard.razor, lines 14-16). Error messages use role="alert" (App.razor, line 31). Success notifications are announced to screen readers. Many dynamic messages rendered after API calls still lack role="alert", as recorded under 502.3.14. |
Table 3: Success Criteria, Level AAA
Level AAA criteria are not evaluated in this report.
Revised Section 508 report, Chapter 3: Functional Performance Criteria
The Functional Performance Criteria are outcome-based statements of functionality that generally apply if ICT functionality cannot be evaluated using the technical requirements. The product is evaluated against the WCAG 2.1 Level A and AA criteria above; the criteria below are reported for completeness.
| Criteria | Conformance level | Remarks and explanations |
|---|---|---|
| 302.1 Without Vision | Partially Supports | The student app is a Blazor WebAssembly mobile-first web application. It provides partial support for use without vision: the document language is set, main content is in a <main> landmark, many forms have associated labels, and many progress bars and loading states use ARIA and visually hidden text. However, the product does not fully meet 302.1 because: (1) there is no skip-to-main-content link; (2) the primary bottom navigation is not marked as a <nav> landmark or labeled for assistive technology; (3) several icon-only buttons and links (for example copy share link, copy invite link, contact actions) lack accessible names; (4) some progress bars use role="progressbar" without aria-valuenow; (5) modals lack role="dialog", aria-modal and focus management; and (6) the login and verification flow and a few others lack an h1, reducing the effectiveness of focus-on-navigate. Recommended improvements are documented in the remediation plan. |
| 302.2 With Limited Vision | Partially Supports | The student app partially supports use by people with limited vision: the viewport does not restrict zoom; typography and many layouts use relative units and responsive design; status and meaning are conveyed by text as well as color; and buttons and form controls have a visible focus style. The product does not fully meet 302.2 because: (1) the focus outline is removed on headings (h1), reducing visibility of focus after navigation; (2) at 200% zoom, the milestone progress component can require horizontal scrolling and the fixed bottom nav may obscure content; (3) touch targets (for example the bottom nav) are not explicitly sized to at least 44 by 44 CSS pixels; and (4) contrast and text spacing have not been independently verified. Recommended remediations include restoring a visible focus style on h1, improving reflow at 200% zoom, defining minimum touch target sizes, and validating contrast and text spacing. |
| 302.3 Without Perception of Color | Partially Supports | The student app largely supports use without perception of color: status badges, leaderboard rank, progress, form validation, and dashboard steps use text, icons, or numbers in addition to color. The product does not fully meet 302.3 because: (1) on the Verification page, the selected fundraiser in the list is indicated only by background color (Bootstrap .active); (2) the current page in the bottom navigation is indicated only by link color (primary versus gray); (3) the selected sent message in the Share "Sent" tab is indicated only by list row background; and (4) in-content links may be distinguishable from body text only by color, with no underline. Recommended remediations: add non-color indicators for selected fundraiser, current nav item, and selected sent message, and ensure links are identifiable without color. |
| 302.4 Without Hearing | Supports | The student application does not provide any audible mode of operation. All features are available through visual and tactile interaction only. No functionality requires user hearing; therefore the product supports this criterion. |
| 302.5 With Limited Hearing | Supports | The student application does not provide any audible mode of operation. All features are available through visual and tactile interaction only. No functionality relies on user hearing; therefore the product supports this criterion. |
| 302.6 Without Speech | Supports | The student application does not use speech for input, control, or operation. All features are operated via touch and keyboard (tap, type, select). No functionality requires user speech; therefore the product supports this criterion. |
| 302.7 With Limited Manipulation | Supports | The student application provides manual operation via touch and keyboard. At least one mode of operation does not require fine motor control or simultaneous manual operations: all functionality can be completed with a single tap or click or a single key press. No drag-and-drop, path-based gestures, multi-key shortcuts, or time-limited critical input are required. Buttons and links have visible focus styles. |
| 302.8 With Limited Reach and Strength | Supports | The student application is a mobile-first web app. On mobile, primary navigation is in a fixed bottom bar within thumb reach; no operations require physical force, grasping, pinching, or twisting. On larger screens, navigation and content are in a standard layout with scrolling. All operation is by touch or keyboard without strength requirements. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Supports | The student application provides features that make use simpler and easier for users with limited language, cognitive, or learning abilities: clear page titles and headings, plain-language form labels and instructions, error messages that explain the problem and next steps, consistent bottom navigation with recognizable labels and icons, progress and context text where relevant, and no critical time limits. |
Revised Section 508 report, Chapter 4: Hardware
This product is a web-based software application and does not include hardware components.
| Criteria | Conformance level | Remarks and explanations |
|---|---|---|
| 402 Closed Functionality | Not Applicable | Product is web-based software with no closed functionality. |
| 402.2.1 Information Displayed On-Screen | Not Applicable | Product does not include hardware with display screens. |
| 402.2.2 Transactional Outputs | Not Applicable | Product does not provide transactional outputs. |
| 402.2.3 Speech Delivery Type and Coordination | Not Applicable | Product does not provide speech output. |
| 402.2.4 User Control | Not Applicable | Product does not provide speech output. |
| 402.2.5 Braille Instructions | Not Applicable | Product does not include input controls requiring operation. |
| 402.3.1 Private Listening | Not Applicable | Product does not provide audio output. |
| 402.3.2 Non-private Listening | Not Applicable | Product does not provide audio output. |
| 402.4 Characters on Display Screens | Not Applicable | Product does not include hardware with display screens. |
| 402.5 Characters on Variable Message Signs | Not Applicable | Product does not include variable message signs. |
| 403 Biometrics | Not Applicable | Product does not use biometric identification. |
| 404 Preservation of Information Provided for Accessibility | Not Applicable | Product does not transmit information in hardware form. |
| 405 Privacy | Not Applicable | Product does not include speech output or audio accessibility features in hardware. |
| 406 Standard Connections | Not Applicable | Product is software only. |
| 407 Operable Parts | Not Applicable | Product does not include hardware operable parts. |
| 408 Display Screens | Not Applicable | Product does not include hardware display screens. |
| 409 Status Indicators | Not Applicable | Product does not include hardware status indicators. |
| 410 Color Coding | Not Applicable | Product does not include hardware with color-coded indicators. |
| 411 Audible Signals | Not Applicable | Product does not include hardware with audible signals. |
| 412 ICT with Two-Way Voice Communication | Not Applicable | Product does not provide two-way voice communication hardware. |
| 413 Closed Caption Processing Technologies | Not Applicable | Product does not display video with captions on hardware. |
| 414 Audio Description Processing Technologies | Not Applicable | Product does not display video with audio description on hardware. |
| 415 User Controls for Captions and Audio Descriptions | Not Applicable | Product does not display video on hardware. |
Revised Section 508 report, Chapter 5: Software
FundraisingU is a web-based application accessed through standard web browsers. Conformance with WCAG 2.1 Level A and AA, documented in Tables 1 and 2 above, satisfies most software requirements per 502.2.
| Criteria | Conformance level | Remarks and explanations |
|---|---|---|
| 501.1 Scope, incorporation of WCAG 2.0 AA | See WCAG 2.x tables | See the WCAG 2.1 Level A and AA tables above. |
| 502 Interoperability with Assistive Technology | See 502.2 to 502.4 | See details in the rows below. |
| 502.2.1 User Control of Accessibility Features | Not Applicable | Platform-level assistive technology features are controlled by the user's operating system and browser, not by the application. |
| 502.2.2 No Disruption of Accessibility Features | Partially Supports | The application generally does not disrupt platform accessibility features, but two areas need remediation. Supporting findings: the viewport allows zoom, with no user-scalable=no, maximum-scale or minimum-scale; the standard web stack (HTML, CSS, JavaScript) ensures compatibility with operating system and browser accessibility features; focus management moves focus to the main heading on navigation, supporting screen reader users; buttons, links and form controls use visible focus styles (box-shadow). The outstanding items are the removal of the focus outline on h1 and the reflow behavior at 200% zoom, both recorded above. |
| 502.3 Accessibility Services | Partially Supports | The application partially supports 502.3. It uses standard HTML, ARIA and web APIs in a way that works with platform accessibility services such as JAWS, NVDA and VoiceOver. Supporting findings: uses standard HTML5 and semantic markup; applies ARIA for loading, progress, alerts, breadcrumbs and some interactive controls; forms use proper labels and associations; page titles are set consistently; images include appropriate alt text; no non-standard or blocking APIs are used. Recommended improvements are itemized in the rows below. |
| 502.3.1 Object Information | Partially Supports | Many UI elements expose roles, states, names and relationships, but several controls lack the programmatic information needed for assistive technologies to fully determine role, state, properties, boundaries, names and descriptions. Supporting findings: native and ARIA roles are used (status, progressbar, alert, tablist); many progress bars expose aria-valuenow, aria-valuemin and aria-valuemax; form controls are associated with labels; loading states use role="status" and visually hidden text; close buttons and breadcrumbs use ARIA labels and landmarks; expandable controls use aria-expanded and aria-labelledby. Required improvements: add accessible names to all icon-only buttons and links; add aria-valuenow, aria-valuemin and aria-valuemax to all progress bars; add role="dialog", aria-modal="true" and aria-labelledby to modal dialogs; add an accessible name to the Blazor error UI dismiss control; implement the full ARIA tab pattern (role="tab", aria-selected, role="tabpanel", aria-labelledby); provide an accessible alternative for the QR code canvas; resolve conflicting use of role="status" and aria-hidden="true" on the same element; add scope="col" or scope="row" to table headers where appropriate. |
| 502.3.2 Modification of Object Information | Supports | States and properties that users can change can be set programmatically, and form inputs, checkboxes, radio buttons and other interactive elements respond correctly to programmatic manipulation and assistive technology. Form controls are implemented with native HTML elements (input, select, textarea) and Blazor components that render to native elements. Blazor uses standard change and input events with no event suppression. Select elements respond to user and programmatic changes. Buttons are activatable via assistive technology. No preventDefault or other blocking of default behavior was found. Readonly and disabled attributes are applied only where interaction is intentionally restricted. |
| 502.3.3 Row, Column, and Headers | Partially Supports | The student application uses semantic table structure (thead, tbody, th) for all data tables in both student and coach views. Column headers are not associated with their cells via scope or headers/id; adding scope="col" to each th in the header row would bring the application into full support. On the student Profile page, two key-value tables use only tbody and td; using th scope="row" for the label column would improve programmatic determination of row headers. No complex tables with both row and column headers were found; all tables are simple column-header or key-value layouts. |
| 502.3.4 Values | Partially Supports | The student application uses native HTML form controls (text, tel, select, checkbox, radio, textarea); their current values are programmatically available to assistive technologies. No range inputs are present. Many progress indicators correctly use role="progressbar" with aria-valuenow, aria-valuemin="0" and aria-valuemax="100" (Fundraiser Share, FollowUp, Dashboard, Contacts; Coaches StudentDetail, Dashboard card and loading, Teams). Five progress bar instances use role="progressbar" but omit these ARIA value attributes: Fundraiser Leaderboard prize progress (student-facing), Coaches TeamDetail team bar and table row bars, Coaches Students table row bars, and Coaches Dashboard team table bars. The shared MilestoneProgress component presents progress visually but does not expose current, minimum and maximum values to assistive technology. |
| 502.3.5 Modification of Values | Supports | The student application uses native HTML form controls and Blazor form components (InputText, InputSelect, InputCheckbox) that render as native elements. All such form inputs accept programmatic value changes from assistive technologies. User-settable values are not blocked or reset by script. Selection UIs implemented as buttons or links (fundraiser selection in Verification and Switch Fundraiser, contact filter dropdown in Contacts) do not use native form controls for the value, but the selected option can be changed by programmatic activation of the corresponding button or link. Read-only and disabled states are used only where the value is not user-settable. No custom widgets that would block programmatic modification of user-settable values were found. |
| 502.3.6 Label Relationships | Partially Supports | Most form fields in the student application have programmatically exposed label relationships via label for and a matching control id (Verification, UserSetup, AddContacts, Profile, Share message template and social message, Helpers, FollowUp template radios, Contacts, TeamDetail, and Coaches Students desktop filters). Some regions use aria-label (for example close buttons) and aria-labelledby (for example the Contacts filter menu). Gaps: (1) on Coaches Students, the mobile filter controls (teamFilterMobile, statusFilterMobile, searchInputMobile) are visible on small viewports but the labels reference only the desktop control ids, so the focused control is not associated with its label; (2) the Share page "Your Unique Share Link" input has no programmatic label; (3) Helpers page invite link inputs (list and modal) have no id or associated label. Adding programmatic label association for these, and where applicable aria-describedby for description text, would bring the application into full support. |
| 502.3.7 Hierarchical Relationships | Partially Supports | The student application uses appropriate landmark structure (main, article) and list markup for navigation tabs and content lists. Many pages use a clear heading hierarchy for structural headings. Gaps: (1) dollar amounts and numeric values are implemented as headings (h2, h3, h4) in Leaderboard.razor, TeamDetail.razor, StudentDetail.razor and MilestoneProgress.razor, which creates a misleading document outline because values such as "$500" and "3" are exposed as section headings; (2) in some cards, label and value roles are reversed (h6 for labels and h2 for values); (3) the mobile bottom navigation (FundraiserBottomNav, CoachBottomNav) is not exposed as a navigation landmark; (4) the Verification page lacks a page-level h1. Replacing non-structural headings with non-heading elements for data values, correcting heading order in cards, adding a nav landmark to the bottom nav, and adding an h1 on the Verification page would bring the application into full support. |
| 502.3.8 Text | Partially Supports | Text content and attributes are largely available to assistive technologies. Images have alternative text, most form controls have visible labels, validation and alert messages are exposed in the DOM, and loading and progress states are accessible. Failures: (1) some icon-only buttons lack accessible names; (2) the mobile search input in Coaches/Students.razor is not properly associated with its label; (3) the Blazor error UI dismiss control lacks an accessible name. |
| 502.3.9 Modification of Text | Supports | All user-editable text in the student app is entered through native HTML form controls (input, textarea, select). Blazor InputText and InputSelect render these same elements. Text can be set programmatically via standard DOM APIs, and inputs accept input from assistive technologies and dictation software. No custom input widgets or mechanisms that would block programmatic, assistive technology or dictation input were found. Display-only fields use readonly appropriately. |
| 502.3.10 List of Actions | Partially Supports | Buttons, navigation links and form fields generally use semantic elements and expose the correct actions. Two main issues: (1) Share.razor uses a div with a click handler as the only way to select a sent message, with no role or keyboard support, so the action is not exposed to assistive technologies; (2) the Blazor error UI dismiss control uses an anchor with no href and no accessible name. In addition, some links are used for non-navigation actions, which may confuse users. Recommended fixes: replace the sent-message div with a button, or role="button" plus tabindex="0" plus keyboard handlers, so selection is accessible, and provide the dismiss control with an accessible name and an appropriate role. |
| 502.3.11 Actions on Objects | Partially Supports | Most actions can be executed via keyboard and programmatically. Buttons, links and form controls generally behave correctly. Two issues limit full conformance: (1) in Share.razor, sent message selection is implemented only with a div and a click handler, which is not focusable or keyboard activatable; (2) the Blazor error UI dismiss control uses an anchor without href, which may not be keyboard accessible. |
| 502.3.12 Focus Cursor | Partially Supports | Focus location is exposed programmatically and screen readers correctly announce focused elements. Buttons, form controls and link-style buttons have visible focus indicators. The main issue is h1:focus { outline: none } in app.css, which removes the focus indicator from the h1 that receives focus on every page navigation. In addition, tab buttons (button.nav-link) may not have a clear focus indicator. Restoring a visible focus style for h1 and ensuring tab buttons have consistent focus indicators would bring the application into full support. |
| 502.3.13 Modification of Focus Cursor | Supports | Focus can be moved programmatically using standard web APIs. The app uses FocusOnNavigate to call element.focus() on the page heading when the route changes, and modals use tabindex="-1" so they can receive focus. Assistive technologies can move focus between interactive elements; the tab order follows the DOM, and there are no focus traps or barriers. Disabled elements correctly avoid receiving focus. |
| 502.3.14 Event Notification | Partially Supports | Loading states use role="status" with visible or visually hidden text. Progress bars use appropriate ARIA, and some alerts use role="alert" (Students.razor success, App.razor 404). However, many dynamic error and success messages rendered after API calls, form submission or failed operations lack role="alert". As a result, screen readers may not announce these updates when they appear. Adding role="alert" to these dynamic alerts and to the Blazor error UI would bring the application into full support. |
| 502.4 Platform Accessibility Features | Supports | The application is built with standard web technologies (HTML, CSS, JavaScript) and does not bypass platform accessibility features. The viewport meta tag permits zoom, and layout uses relative units and responsive design. No code was found that disables zoom or interferes with high contrast or other platform accessibility features. |
| 503 Applications | See 503.2 to 503.4 | See details in the rows below. |
| 503.2 User Preferences | Partially Supports | Font sizes are respected via rem units and system font stacks; the app does not override platform font settings. It does not adapt to color scheme (for example dark mode), contrast preferences or reduced motion preferences, and uses no prefers-color-scheme, prefers-contrast or prefers-reduced-motion media queries. Adding support for these preferences would bring the application into full support of 503.2. |
| 503.3 Alternative User Interfaces | Not Applicable | Product does not provide alternative user interfaces. A single responsive interface serves all users. |
| 503.4 User Controls for Captions and Audio Description | Not Applicable | Product does not include video or audio content requiring captions or audio description. |
| 503.4.1 Caption Controls | Not Applicable | Product does not display video with captions. |
| 503.4.2 Audio Description Controls | Not Applicable | Product does not display video with audio description. |
| 504 Authoring Tools | Not Applicable | Product is not an authoring tool. Users do not create content for publication or delivery to other users. |
| 504.2 Content Creation or Editing | See WCAG 2.x tables | Limited text entry (contact names, phone numbers) is covered by the WCAG 2.1 assessment above. No rich content authoring capabilities. |
| 504.2.1 Preservation of Information Provided for Accessibility in Format Conversion | Not Applicable | Product does not convert content from one format to another. |
| 504.2.2 PDF Export | Not Applicable | Product does not provide PDF export functionality. |
| 504.3 Prompts | Not Applicable | Product is not an authoring tool. |
| 504.4 Templates | Not Applicable | Product is not an authoring tool and does not provide templates. |
Revised Section 508 report, Chapter 6: Support Documentation and Services
Support documentation is provided through online help resources, knowledge base articles and direct customer support.
| Criteria | Conformance level | Remarks and explanations |
|---|---|---|
| 601.1 Scope | See 602 and 603 | See details in the rows below. |
| 602 Support Documentation | See 602.2 to 602.4 | See details in the rows below. |
| 602.2 Accessibility and Compatibility Features | Supports | Documentation of accessibility features is available through the online help system and this Accessibility Conformance Report. Information about keyboard navigation, screen reader compatibility and other accessibility features is provided. |
| 602.3 Electronic Support Documentation | See WCAG 2.x tables | Online documentation and help resources are covered by the WCAG 2.1 Level A and AA assessment in Tables 1 and 2 above. |
| 602.4 Alternate Formats for Non-Electronic Support Documentation | Supports | Printed documentation, if provided, is available in alternate formats upon request. Primary documentation is electronic. |
| 603 Support Services | See 603.2 and 603.3 | See details in the rows below. |
| 603.2 Information on Accessibility and Compatibility Features | Supports | Customer support staff are trained to answer questions about accessibility features and compatibility with assistive technologies. Information about accessibility features is available through support channels. |
| 603.3 Accommodation of Communication Needs | Supports | Support services are available through multiple communication channels including email, phone and web-based support forms to accommodate various communication needs. |
EN 301 549 report
EN 301 549 is the European standard for accessibility requirements suitable for public procurement of ICT products and services. This report addresses United States Section 508 conformance. Organizations requiring EN 301 549 conformance should request the VPAT® 2.5Rev EU Edition or INT Edition by emailing support@fundraisingu.net.
Supporting accessibility information
Framework and component accessibility
- Bootstrap 5.3+ — design framework documented by its maintainers as conforming to WCAG 2.1 Level AA. See the Bootstrap accessibility documentation.
- DevExpress Blazor Components v24+ — UI components with keyboard navigation, ARIA attributes and screen reader support. See the DevExpress accessibility documentation.
- ASP.NET Core Blazor — framework support for accessibility APIs and ARIA. See the Blazor accessibility documentation.
- Bootstrap Icons — decorative icons are hidden from assistive technology using aria-hidden="true".
Vendor documentation is not a substitute for testing. Where a third-party component was found not to meet a criterion in our own testing, that finding is recorded in the tables above and in the remediation plan, not excused by the vendor's claim.
Design practices that support accessibility
- Mobile-first design — touch-friendly interfaces built for the devices students actually use
- Performance — fast load times benefit users with cognitive disabilities and limited bandwidth
- Plain language — clear, concise content at an appropriate reading level
- Consistent design patterns — predictable interactions reduce cognitive load
- Generous spacing — reduces accidental activation and improves readability
- Error recovery — multiple opportunities to correct mistakes before an action is finalized
Accessibility of this page
This page and the other pages in the Safety & Compliance Center are served as plain HTML with inline styles. They require no JavaScript to read or navigate, load no web fonts or third-party resources, set no cookies, and use real table markup with scoped headers for the conformance tables above. The wide conformance tables scroll horizontally inside a keyboard-focusable region so that the page itself never scrolls sideways at 320 pixels wide.
Legal disclaimer
This Accessibility Conformance Report is provided for informational purposes to assist customers and procurement officials in evaluating the accessibility conformance of the FundraisingU Student Portal against the Revised Section 508 Standards and the WCAG 2.1 Level A and AA success criteria.
While every effort has been made to ensure the accuracy and completeness of this document, this report represents the accessibility features and conformance levels as of the report date indicated above. Product features and conformance levels may change with product updates and modifications.
No warranty. Fundraising University and its affiliates make no warranties, express or implied, regarding the completeness, accuracy or reliability of the information contained in this report. This document does not constitute legal advice, warranty or guarantee of conformance for any specific use case or procurement requirement.
Customer responsibility. Customers and procurement officials are responsible for conducting their own independent evaluation and testing to determine whether the product meets their specific accessibility requirements and the needs of their users with disabilities.
Future updates. Accessibility features and conformance may be enhanced in future product releases. Customers should request an updated report when evaluating newer product versions.
Report information and revision history
Report identifier: FundraisingU_ACR_VPAT_Section508
Product and version: FundraisingU Student Portal, Version 1.0
Report date: February 16, 2026
Prepared by: Technical Advisor, Fundraising University
Contact: support@fundraisingu.net, (602) 529-8293
| Version | Date | Description of changes |
|---|---|---|
| 1.0 | December 19, 2025 | Initial report created using the VPAT® 2.5Rev Section 508 Edition template |
| 2.0 | February 16, 2026 | Completed assessment for all of the Student Portal |
"Voluntary Product Accessibility Template®" and "VPAT®" are registered service marks of the Information Technology Industry Council (ITI). This report was created using the VPAT® 2.5Rev Section 508 Edition template. For more information, see the ITI VPAT page.
ACR report date February 16, 2026. Statement last updated August 4, 2026. Published by KFRM LLC d/b/a Fundraising University.