Accessibility
Accessibility.
We target WCAG 2.2 AA. If you find something that doesn't work for you, tell us and we'll fix it.
Standards.
aiessaydetector.ai is built to conform to WCAG 2.2 Level AA. We test with keyboard-only navigation, with VoiceOver, NVDA, and JAWS, and with the Lighthouse and axe-core automated scanners on every production deploy.
Known issues.
- Sentence-level highlighting in the detector uses color as one of its signals. We also mark high-probability sentences with an underline and a screen-reader label ("flagged as likely AI-generated, confidence 0.82") so the color is redundant.
- The humanizer's pre/post slider is keyboard accessible but does not yet expose the percentage change to screen readers in real time. Fix tracked; expected April 2026.
Feedback.
If something doesn't work for you, please email hello@aiessaydetector.ai with the URL, the browser and assistive-technology version, and a description. We respond within one business day and will treat accessibility regressions as P1 bugs.
Alternative formats.
Detector results are available in plain-text and CSV export for signed-in users. If you need a report in another accessible format (large print, Braille-ready PDF), email us and we'll produce it.
Keyboard Navigation Implementation and Testing Methodology
All interactive elements on aiessaydetector.ai are accessible through keyboard navigation without requiring a mouse or pointing device. Users can navigate the interface using standard keyboard controls including Tab, Shift+Tab, Enter, Space, and arrow keys. The implementation follows WCAG 2.2 Success Criterion 2.1.1 (Keyboard) and 2.1.3 (Keyboard - No Exception), ensuring that focus indicators are clearly visible with a minimum contrast ratio of 3:1 against adjacent colors as specified in Success Criterion 2.4.7 (Focus Visible). Custom focus styles have been implemented using CSS outline properties to provide visual feedback that exceeds the minimum requirements, with a 2-pixel solid border and additional padding to ensure visibility across different viewport sizes.
Testing procedures for keyboard accessibility occur during each development sprint and prior to production deployments. The testing protocol includes sequential navigation through all interactive components, verification of focus order logical consistency, and validation that no keyboard traps exist within modal dialogs, dropdown menus, or dynamic content regions. Screen magnification software testing at 200% zoom has been conducted to verify that focus indicators remain visible and that the focus order remains intuitive when the viewport is constrained. Documentation of keyboard shortcuts is provided in an accessible format on this page, and all shortcuts use modifier keys to prevent conflicts with assistive technology hotkeys.
Screen Reader Compatibility and Semantic HTML Structure
The platform has been tested with NVDA 2023.3, JAWS 2024, and VoiceOver on macOS Sonoma and iOS 17 to ensure compatibility with the most widely used screen reader technologies. Semantic HTML5 elements including <nav>, <main>, <article>, <section>, and <aside> provide structural landmarks that enable screen reader users to navigate efficiently through page regions. ARIA labels have been applied judiciously to interactive elements where visible labels are insufficient, following the first rule of ARIA usage that native HTML semantics should be preferred whenever possible. All form inputs include properly associated <label> elements, and error messages are announced to screen readers using aria-live='polite' regions to provide real-time feedback without interrupting the user's current task.
Dynamic content updates, such as the AI detection analysis results, are programmatically announced to assistive technology users through ARIA live regions with appropriate politeness settings. The analysis interface uses role='status' for non-critical updates and role='alert' for time-sensitive information that requires immediate user attention. Alternative text for informational graphics follows WCAG 2.2 Success Criterion 1.1.1 (Non-text Content), providing concise descriptions that convey equivalent information to visual presentations. Testing with screen readers in browse mode and forms mode has confirmed that all functionality can be accessed and understood through auditory feedback alone, with particular attention paid to ensuring that data tables include proper header associations using scope attributes and <th> elements.
Recent Accessibility Improvements and Ongoing Compliance Monitoring
Between January and March 2024, the development team implemented several targeted improvements to address accessibility barriers identified through user feedback and automated testing. Color contrast ratios for all text elements were audited and adjusted to meet WCAG 2.2 Level AA requirements, with body text achieving a minimum contrast ratio of 4.5:1 and large text (18pt or 14pt bold) maintaining at least 3:1 contrast against background colors. The file upload interface was redesigned to provide multiple interaction methods, including drag-and-drop functionality with equivalent keyboard-accessible buttons and clear visual feedback for upload progress. Error messages were enhanced to include both color-coded indicators and iconography to ensure that information is not conveyed through color alone, satisfying Success Criterion 1.4.1 (Use of Color).
Automated accessibility testing is integrated into the continuous integration pipeline using tools including axe-core 4.8 and Pa11y-CI 3.1, with builds failing when Level A or AA violations are detected. Manual testing is conducted quarterly by an external accessibility consultant who performs comprehensive evaluations using assistive technology and provides detailed remediation recommendations. The most recent audit in February 2024 identified zero Level A violations and three Level AA issues related to skip link positioning, all of which were resolved within two weeks. A public feedback mechanism allows users to report accessibility barriers directly through a dedicated contact form, with all reports acknowledged within 48 hours and prioritized according to severity in the product roadmap.