Skip to main content
AedoBuild
Log inGet started

Accessibility Statement

Last reviewed: October 3, 2026

Our commitment

AedoBuild Inc. is committed to making www.aedobuild.com and the AedoBuild condo management platform usable by the widest possible audience, regardless of ability or technology. We treat accessibility as a product requirement, not a feature — every new page and workflow is designed with accessibility in mind, and we fix issues we find as part of normal engineering work.

Conformance target

Our target is the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. WCAG defines how to make web content more accessible to people with a wide range of disabilities including blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these; and some accommodation for learning and cognitive disabilities.

Current conformance status: partially conformant. Partially conformant means some parts of the content do not yet fully conform. Where that is the case we are actively working on fixes — see Known limitations below.

Legal standards we align with

  • Canada — AODA. We design toward the Accessibility for Ontarians with Disabilities Act (AODA) Integrated Accessibility Standards Regulation, which references WCAG 2.0 AA for private-sector websites.
  • Canada — Accessible Canada Act. For federally regulated organizations purchasing AedoBuild, we align with the Accessible Canada Act's information-and-communications standards.
  • United States — ADA. We design toward Americans with Disabilities Act Title III accessibility expectations as reflected in WCAG 2.1 AA.
  • United States — Section 508. Our product targets the Revised Section 508 standards for electronic and information technology.
  • European Union — EN 301 549 / EAA. We align with EN 301 549 (which incorporates WCAG 2.1 AA) to support compliance with the European Accessibility Act.

What we have done

  • Semantic HTML landmarks (header, nav, main, footer) on every page.
  • "Skip to main content" link available on every page for keyboard users (WCAG 2.4.1 Bypass Blocks).
  • All interactive controls — buttons, links, form fields, menu items — are reachable and operable by keyboard alone (WCAG 2.1.1 Keyboard).
  • Visible focus indicators on every interactive element (WCAG 2.4.7 Focus Visible).
  • Form fields have programmatic labels; errors are announced to assistive technology via role="alert".
  • Images that convey information carry descriptive alt text; decorative images use empty alt="" so screen readers skip them (WCAG 1.1.1 Non-text Content).
  • Color is not used as the sole means of conveying information; status icons pair with text labels.
  • Minimum text contrast of 4.5:1 for body copy, 3:1 for large text (WCAG 1.4.3 Contrast Minimum).
  • Pages are responsive and remain legible at 320 CSS pixels wide and at 200% zoom without loss of content (WCAG 1.4.10 Reflow).
  • Pinch-to-zoom is enabled on mobile — we do not block the user-scalable viewport attribute (WCAG 1.4.4 Resize Text).
  • Modals use role="dialog" with aria-modal="true", labeled by the dialog heading, and dismissible with Esc (WCAG 2.1.2 No Keyboard Trap).
  • Icon-only buttons have aria-label describing the action.
  • Language declared at the document level (lang="en-CA") so screen readers pronounce content correctly (WCAG 3.1.1 Language of Page).
  • No auto-playing audio or video.
  • No content flashes more than three times per second (WCAG 2.3.1 Three Flashes).
  • Sessions time out with a 5-minute warning rather than ending silently (WCAG 2.2.1 Timing Adjustable).

Known limitations

We are working on the following gaps and will update this statement when each is resolved:

  • Document previews. PDFs and spreadsheets uploaded by users may not be accessible if the uploader did not tag them correctly. We cannot modify third-party documents on upload. Workaround: use Download to open in your preferred assistive-technology tool.
  • Complex data tables. Some reporting tables (e.g., historical payment ledgers) use dense layouts that may be harder to navigate with a screen reader. We expose a CSV export for every table to make the data linear.
  • Third-party Stripe pages. Payment and billing-portal flows render inside Stripe-hosted pages. Stripe maintains its own accessibility conformance — we link out to it rather than rebuild card entry.
  • Native mobile apps. iOS + Android apps are on the roadmap for Q2 2027 and will follow VoiceOver / TalkBack best practices from day one.
  • Formal third-party audit. We have not yet engaged an external accessibility auditor. Target: Q2 2027. If an audit report is a procurement requirement for your organization, email us and we'll prioritize.

Compatibility

AedoBuild is designed to be compatible with the following assistive technologies and the latest two major versions of each browser:

  • Browsers: Chrome, Edge, Safari, Firefox
  • Screen readers: NVDA + Firefox on Windows, JAWS + Chrome on Windows, VoiceOver + Safari on macOS/iOS, TalkBack + Chrome on Android
  • Operating systems: Windows 10+, macOS 12+, iOS 16+, Android 11+
  • Input methods: mouse, trackpad, keyboard only, touch, switch control, voice control (Dragon, Voice Control)

AedoBuild is not designed to be compatible with Internet Explorer or any browser version older than two years.

Technical specifications

AedoBuild relies on the following technologies, which must be available for the content to work:

  • HTML5
  • CSS (Tailwind + custom)
  • JavaScript (React / Next.js — static fallbacks are provided for critical content such as login, pricing, and legal pages)
  • WAI-ARIA 1.2 attributes where native semantics are insufficient

Assessment approach

Current conformance was self-assessed by the AedoBuild team using:

  • Automated scans with axe DevTools during local development
  • Manual keyboard-only walkthroughs of every primary workflow
  • Screen-reader spot checks (NVDA + VoiceOver)
  • Color-contrast verification against the WCAG 2.1 AA ratios

Self-assessment is less rigorous than a formal third-party audit; we acknowledge this and are planning a professional audit for Q2 2027.

Feedback and contact

We welcome feedback on the accessibility of AedoBuild. If you encounter an accessibility barrier — a page that doesn't work with your assistive technology, a form you can't complete, insufficient contrast, a keyboard trap, or anything else — please contact us:

We aim to acknowledge accessibility feedback within 5 business days and to provide a resolution — or a concrete timeline for one — within 30 calendar days of receipt, in line with the AODA Information and Communications Standard.

Alternative formats and accommodations

If any part of AedoBuild is hard to use with your assistive technology, or if you need information from the site in an alternative format (large print, audio, plain text, or a live walkthrough), ask and we will provide it at no cost.

Formal complaints

If you are not satisfied with our response to an accessibility complaint, you may escalate to the following bodies as appropriate for your jurisdiction:

Review schedule

This statement is reviewed at least once every 12 months, and whenever we release a significant redesign of the product or the marketing site.