Accessibility Statement

1. Our Commitment

HOOTL MedicalAssist is committed to ensuring digital accessibility for people with disabilities. We continually improve the user experience for everyone and apply the relevant accessibility standards to ensure we provide equal access to all users, including those who rely on assistive technologies such as screen readers, keyboard navigation, voice recognition software, and other adaptive tools.

We believe that every healthcare professional should be able to use our medical denial appeal management platform effectively, regardless of ability. Accessibility is not an afterthought but an integral part of our design and development process.

2. Standards We Follow

HOOTL MedicalAssist strives to conform to the following accessibility standards:

• Web Content Accessibility Guidelines (WCAG) 2.1 Level AA — Published by the World Wide Web Consortium (W3C), WCAG 2.1 provides guidelines for making web content more accessible. We target Level AA conformance, which addresses the most common barriers for users with disabilities.
• Americans with Disabilities Act (ADA) — We design our platform to be accessible in compliance with Title III of the ADA, which requires that places of public accommodation (including websites and digital platforms) be accessible to individuals with disabilities.
• Section 508 of the Rehabilitation Act — For users in federal healthcare settings, we aim to meet Section 508 requirements for electronic and information technology accessibility.

3. Accessibility Features

The following accessibility features are implemented across the HOOTL MedicalAssist platform:

3.1 Keyboard Navigation

• All interactive elements (buttons, links, form fields, modals) are reachable and operable via keyboard.
• Focus indicators are visible on all interactive elements using a consistent outline style.
• Modal dialogs implement focus trapping to prevent keyboard users from tabbing behind the modal.
• Skip-to-content links are provided on all pages to bypass repetitive navigation.
• Escape key closes modal dialogs and returns focus to the triggering element.

3.2 Screen Reader Support

• Semantic HTML elements (nav, main, article, header, footer) are used throughout for proper document structure.
• ARIA landmarks, roles, and labels are applied to dynamic content and custom widgets.
• Images include descriptive alt text; decorative images are marked with aria-hidden or empty alt attributes.
• Form fields have associated labels, and error messages are programmatically linked to their respective inputs.
• Status messages and notifications use ARIA live regions for real-time announcements.

3.3 Visual Design

• Color contrast ratios meet or exceed WCAG 2.1 AA requirements (4.5:1 for normal text, 3:1 for large text).
• Dark and light theme modes are available, allowing users to choose their preferred viewing experience.
• Text is resizable up to 200% without loss of content or functionality.
• The platform supports the forced-colors (high contrast) media query for Windows High Contrast Mode.
• Information is not conveyed by color alone; icons, text labels, and patterns supplement color coding.

3.4 Motion and Animation

• The prefers-reduced-motion media query is respected; animations and transitions are disabled for users who prefer reduced motion.
• No content flashes more than three times per second.
• Auto-playing content can be paused, stopped, or hidden.

3.5 Responsive Design

• The platform is fully responsive and usable across desktop, tablet, and mobile screen sizes.
• Content reflows properly when zoomed or when the viewport is narrowed, without horizontal scrolling at widths down to 320 CSS pixels.
• Touch targets are appropriately sized (minimum 44x44 CSS pixels) for mobile users.

4. Known Limitations

While we strive for comprehensive accessibility, the following areas have known limitations that we are actively working to resolve:

• PDF document rendering: Denial letters uploaded as PDFs are rendered using a third-party PDF viewer. While the extracted text is fully accessible, the visual PDF preview may have limited screen reader support.
• AI-generated content: Appeal letters and denial analyses generated by AI may occasionally produce content that does not fully conform to plain language guidelines. Users should review and simplify generated text as needed.
• Complex data tables: Some analytics dashboards contain complex data tables that may be difficult to navigate with screen readers. We are working to improve table markup and provide summary descriptions.
• Drag-and-drop upload: The file upload zone supports drag-and-drop as a convenience feature. An equivalent file browser input is always available as a keyboard- and screen-reader-accessible alternative.

5. Feedback and Contact

We welcome your feedback on the accessibility of HOOTL MedicalAssist. If you encounter accessibility barriers or have suggestions for improvement, please contact us:

• Email: accessibility@hootl.com
• Subject Line: Accessibility Feedback
• General Support: support@hootl.com

We aim to respond to all accessibility feedback within 5 business days. For urgent accessibility issues that prevent you from using the Platform, please include "URGENT" in your subject line and we will prioritize your request.

6. Remediation Process

When an accessibility issue is reported, we follow this process:

• Acknowledge receipt of the report within 5 business days.
• Assess the severity and impact of the issue.
• Provide an estimated timeline for remediation.
• Implement the fix and verify with appropriate testing tools and assistive technologies.
• Notify the reporter when the issue has been resolved.

If you are not satisfied with our response, you may file a complaint with the U.S. Department of Justice, Civil Rights Division, at ada.gov/file-a-complaint.

7. Assessment and Testing

HOOTL MedicalAssist assesses the accessibility of the Platform through the following methods:

• Automated testing using accessibility scanning tools during development.
• Manual keyboard navigation testing across all core workflows.
• Screen reader testing with common assistive technologies (NVDA, VoiceOver, JAWS).
• Ongoing code review to ensure new features meet accessibility standards before release.
• Periodic third-party accessibility audits.