Accessibility Statement
Last updated: May 31, 2026
Document owner: VP Product and Accessibility Program Lead
Policy steward: Design Systems and Frontend Engineering
Review cadence: Quarterly and after major UI release milestones
Effective date: 2026-05-31
Conformance target: WCAG 2.1 Level AA
Primary contact: ethicpages+contact@invictosoft.com (subject: Accessibility)
Accessibility commitment
EthicPages is committed to building and operating a platform that is inclusive, perceivable, operable, understandable, and robust for as many users as possible. Accessibility is not treated as a post-release checklist item; it is a product quality requirement integrated into design, implementation, QA, and support workflows.
We design our website and product experiences to align with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA and to support usage across a broad range of assistive technologies and interaction preferences. Our accessibility program is informed by user feedback, engineering audits, and continuous improvements in semantic HTML, keyboard support, form usability, color contrast, focus management, and error communication.
This statement applies to EthicPages-owned properties and interfaces, including authenticated SaaS areas, public marketing pages, and hosted experience controls operated directly by EthicPages. Customer-authored content may vary by customer input and configuration. For data and security context, see our Privacy Policy, Security Overview, and Responsible Disclosure Policy.
Conformance status
EthicPages targets WCAG 2.1 AA conformance and evaluates conformance through a combination of automated scanning, manual keyboard testing, screen reader checks, and component-level design review.
| Area | Current status | Notes |
|---|---|---|
| Core application navigation | Partially conformant | Primary navigation, landmarks, and skip links implemented; periodic regressions monitored |
| Authentication and account flows | Partially conformant | Keyboard and labels validated; remediation in progress for edge-case error announcement timing |
| Billing and subscription management | Partially conformant | Focus order and button semantics align with standards; some third-party embedded controls require extra testing |
| Public marketing pages | Partially conformant | Heading hierarchy and semantic regions mostly compliant; some decorative media needs improved alternatives |
| Document editing and preview experiences | Partially conformant | Major workflows support keyboard and screen readers; complex markdown preview interactions continue to be refined |
Conformance is an ongoing process. "Partially conformant" means certain parts of the content do not yet fully conform to all WCAG 2.1 AA success criteria, and documented remediation work is active.
Standards and principles we follow
Our accessibility implementation is guided by four foundational principles:
- Perceivable: Information and UI components are presented in ways users can perceive.
- Operable: Interface components are usable by keyboard, pointer, touch, and assistive technologies.
- Understandable: Content and operations are clear, predictable, and resilient to input errors.
- Robust: Markup and interaction patterns support current and emerging assistive technologies.
Internal accessibility control map
| Control area | Examples of implementation commitments |
|---|---|
| Semantics and landmarks | Use of native elements, structured headings, main landmarks, and ARIA only when needed |
| Keyboard access | Logical tab order, visible focus states, no keyboard traps, and predictable modal behavior |
| Forms and validation | Programmatic labels, field descriptions, clear validation messages, and announcement of errors |
| Color and contrast | Contrast ratios aligned to WCAG thresholds; non-color cues for critical states |
| Motion and timing | Reduced motion support and avoidance of time-limited barriers where possible |
| Content structure | Plain language defaults, descriptive links, and consistent control naming |
Accessibility development lifecycle
Accessibility work is integrated throughout the software development lifecycle rather than deferred to final QA stages.
| Phase | Accessibility requirement | Owner |
|---|---|---|
| Discovery | Capture accessibility acceptance criteria and impacted assistive pathways | Product + Design |
| Design | Validate structure, color contrast, interaction states, and error communication | Design Systems |
| Implementation | Use shared accessible primitives and semantic-first coding patterns | Frontend Engineering |
| Quality assurance | Automated checks plus manual keyboard and screen reader scenarios | QA + Engineering |
| Release | Accessibility regression review for high-risk changes | Release Manager |
| Post-release | Track issues, triage feedback, and prioritize remediation by impact | Accessibility Program Lead |
Assistive technology support
EthicPages tests and supports major assistive technologies in common browser environments, while recognizing that compatibility can vary due to browser, operating system, and AT version differences.
| Assistive technology class | Typical supported usage |
|---|---|
| Screen readers | Navigation of page landmarks, headings, forms, and interactive controls |
| Keyboard-only navigation | Full operation of core workflows without mouse input |
| Magnification and zoom | Usability at common zoom levels with responsive reflow expectations |
| Speech input tools | Basic command targeting where controls are clearly labeled |
| High contrast / custom styles | Support for stronger contrast and visible focus indicators |
Browsers and environments we prioritize
| Environment category | Support approach |
|---|---|
| Modern evergreen browsers | Primary compatibility target for release validation |
| Current desktop operating systems | Routine manual checks for keyboard and screen reader flows |
| Mobile web environments | Validation of touch targets, responsive reflow, and form behavior |
We recommend users keep browsers and assistive technologies up to date for best results.
Known limitations
Despite ongoing improvements, some areas currently have known limitations. We document these publicly to support transparent expectations and accountable remediation.
| Known limitation | User impact | Planned action |
|---|---|---|
| Complex markdown preview announcements may be delayed | Screen reader users may not receive immediate context changes in rare edit states | Improve ARIA live-region timing and reduce noisy state changes |
| Some chart-like data summaries depend on visual formatting | Users relying on non-visual navigation may need additional tabular context | Expand text alternatives and structured summaries |
| Occasional focus return inconsistency after modal close in edge flows | Keyboard users may land at a non-ideal return target | Standardize modal focus restoration utility across components |
| Third-party embedded widgets may not fully meet AA expectations | Inherited limitations in vendor-managed iframes or controls | Work with vendors and provide alternate support workflows |
Known limitations are prioritized based on severity, usage frequency, and impact on task completion.
Feedback and support process
We want to hear from users who encounter accessibility barriers. Reports are used both to address individual issues and to improve systemic quality.
| Feedback channel | What to include | Expected response |
|---|---|---|
| Email: ethicpages+contact@invictosoft.com | Page/feature, browser, assistive tech, reproduction steps, and impact | Acknowledgment within 3 business days |
| Support ticket (customers) | Workspace context and affected workflow | Initial triage within 1 business day for production blockers |
| Security-adjacent accessibility issue | If issue has security implications, reference Responsible Disclosure | Security + accessibility joint review |
We welcome feedback in plain language. You do not need to provide technical terminology for us to investigate effectively.
Remediation timeline and prioritization
EthicPages follows a severity-based remediation model designed to quickly address blockers while maintaining durable fixes.
| Priority class | Definition | Target remediation timeline |
|---|---|---|
| P0 Critical blocker | Prevents completion of a core workflow for users with disabilities and lacks reasonable workaround | 7 calendar days for mitigation; permanent fix ASAP |
| P1 High impact | Significant friction in primary workflows with partial workaround | 30 calendar days |
| P2 Moderate impact | Noticeable usability issue in secondary flows | 60-90 calendar days |
| P3 Improvement | Cosmetic, minor, or low-frequency issue | Planned backlog release cycles |
Timelines may be adjusted for dependencies on third-party providers, but we aim to ship practical mitigations quickly when full fixes require longer lead time.
Governance and accountability
Accessibility governance combines product, design, engineering, and support ownership.
| Role | Responsibility |
|---|---|
| Accessibility Program Lead | Program oversight, KPI tracking, and quarterly reporting |
| Design Systems Team | Accessible primitives, component patterns, and design audits |
| Frontend Engineering | Implementation quality and regression prevention |
| QA | Scenario-based verification and compatibility testing |
| Support | Intake quality, customer communication, and issue escalation |
Accessibility metrics are reviewed alongside quality and trust metrics to ensure visibility at leadership levels.
Continuous improvement roadmap
Our roadmap for accessibility maturity includes:
- Expanding component-level regression tests for keyboard and focus behavior.
- Increasing manual screen reader test coverage on high-traffic workflows.
- Strengthening accessible defaults in design tokens and shared UI primitives.
- Improving documentation for customer-authored content accessibility.
- Enhancing plain-language guidance and error message quality.
We treat accessibility improvements as a recurring product investment that improves usability for all users, not only for users who explicitly identify accessibility needs.
Customer-authored and third-party content
EthicPages provides tools that help customers create content, but customers remain responsible for the accessibility of the text, structure, media, and external assets they publish. We provide guidance and defaults where feasible; however, customer-entered content and third-party embeds can introduce accessibility differences outside direct platform control.
Where applicable, we provide alternatives, warnings, or recommended fixes to help customers reduce barriers. For contracts, procurement, or legal commitments related to accessibility obligations, please contact ethicpages+contact@invictosoft.com.
Related legal and policy documents
- Privacy Policy
- Security Overview
- Responsible Disclosure Policy
- Vendor Code of Conduct
- Modern Slavery Statement
- ESG Commitments
- Terms of Service
Requesting alternate formats
If you need critical information in an alternate format, contact ethicpages+contact@invictosoft.com with:
- The URL or document title.
- The preferred format (for example, plain text or structured table extract).
- Any timing constraints tied to procurement, compliance, or legal deadlines.
We will make reasonable efforts to provide an equivalent alternative in a practical timeframe.
Statement updates
We revise this statement as our product and accessibility program evolve. Material changes to commitments or conformance posture will be reflected in the "Last updated" field and incorporated into our legal document index.
EthicPages believes accessibility is a shared product responsibility and a long-term trust commitment. We remain accountable for measurable progress, transparent communication, and respectful collaboration with users who report barriers.