Accessibility statement

MapleCrew connects customers with independent local service providers across Ontario. Both sides of that connection need to be able to use the platform — a customer booking a cleaning, and a provider managing the jobs that pay them. This statement explains how we approach that.

We aim to identify, prevent and remove barriers that make the site or app harder to use for people with disabilities, and we use the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — published by the World Wide Web Consortium (W3C) — as our design target for new and existing screens.

We look to WCAG, to Ontario's Accessibility for Ontarians with Disabilities Act (AODA) and Human Rights Code, and to the guidance published by Accessibility Standards Canada, as reference points for good practice, whether or not a given requirement applies to a business our size.

Browsing services, booking a job, messaging a provider and tracking a booking should all be usable with a keyboard, a screen reader, or at a larger text size. If a step in that flow is not working for you, that is a bug we want to know about, not something you need to work around.

If a disability means a job needs to be arranged differently — how a provider should announce themselves at the door, where to find written instructions instead of a phone call, extra time needed for access — say so in your booking notes. Our acceptable use policy treats that as a reasonable accommodation request, to be met wherever it reasonably can be, not a special demand.

Providers are independent professionals, not MapleCrew employees, and the same design target applies to the screens they use: registering, submitting verification documents, setting services and rates, accepting or declining jobs, and messaging customers.

If part of onboarding or the day-to-day app is a genuine barrier because of a disability — a document upload step, a form, a confirmation flow — tell us. We would rather adjust the process than lose a provider who cannot get past a screen.

Keyboard accessibility

Interactive elements — links, buttons, form fields, menus — are built to be reachable and operable from a keyboard alone, without a mouse or a touchscreen. Visible focus states are part of the design system, so it is possible to see where keyboard focus currently is.

Screen-reader support

Pages use semantic HTML and labelled controls so a screen reader can announce what something is and what it does. Purely decorative images are marked so they are skipped rather than read aloud; meaningful images carry a description.

Text resize and zoom

We do not disable browser zoom or pinch-to-zoom. Text can be resized using your browser or device settings, and layouts are built to reflow rather than clip or overlap when text is made larger.

Colour and contrast

Text and interface colours are chosen to meet WCAG 2.2 AA contrast ratios against their background, and colour is not used as the only way to convey information — status, for example, is also shown with text or an icon, not colour alone.

Reduced motion

Where the interface uses animation, we aim to respect your operating system's “reduce motion” setting rather than override it. This is an area we are still extending across the site — see “Known limitations.”

Booking, registration, sign-in and profile forms use real labels rather than placeholder text standing in for a label, so a screen reader announces what each field is for even after you start typing.

When a field fails validation, the error is associated with that specific field programmatically, not only shown as coloured text nearby, so assistive technology can find and announce it — and it explains what to fix, not just that something is wrong.

The provider app is built with Expo and React Native, which map onto each platform's native accessibility APIs — VoiceOver on iOS, TalkBack on Android — so standard controls are announced and operable through the platform's own screen reader rather than a custom one.

Touch targets, spacing and text size on both the website's mobile layout and the provider app follow the same design target as desktop. Push notifications are not yet part of the app; where we send updates today, they are also available in-app and by email, not through a channel that assumes you can see a phone screen at a particular moment.

Our policies and account communications are written in plain digital text so they work with browser zoom, screen readers and translation tools by default, rather than being locked into a fixed-layout document.

If you need something from us in a different format — read aloud over the phone, sent as plain text instead of an image, or explained a different way — write to support@maplecrewservices.com and tell us what would help. We are a small team and cannot promise every format, but we will do what is reasonably available to us.

For a specific booking, add the request to your job notes so it reaches the provider directly. For anything about using the account, the app, or the booking flow itself, write to support@maplecrewservices.com describing what you are trying to do and where it is not working. Include the page or screen if you can — it is the fastest way for us to find the actual barrier.

We welcome feedback on the accessibility of the website and the provider app, whether that is a specific problem, a general comment, or something that worked well. Write to support@maplecrewservices.com with “Accessibility” in the subject line so it is easy to find.

We are a small team, so we cannot commit to a fixed response time, but every message is read by a person, not routed to a queue.

We would rather list what we know is incomplete than imply the platform has been fully checked against every WCAG 2.2 AA success criterion, because it has not:

• Reduced-motion support currently covers some animated elements, not every one, across the website.
• Newer screens — including recent additions to provider onboarding — have not yet had a dedicated accessibility pass, even where they follow the same design system as older, checked screens.
• Card payment fields are hosted by our payment processor rather than built by us, so their accessibility depends in part on that provider, not only on MapleCrew.
• We have not commissioned an independent, third-party accessibility audit of the platform.

None of this is presented as compliant today. It is the honest state of an actively developed platform, and the next section is what we do about it.

Accessibility is treated as an ongoing design target, not a one-time project. As screens are built or reworked, we check them against WCAG 2.2 AA rather than adding accessibility afterward, and reports from customers and providers are the fastest way a real barrier gets prioritised over a theoretical one.

This statement will be updated as our practices change. If we materially change how we approach accessibility, the version and date at the top of this page will change.

MapleCrew Inc., Ontario, Canada. Accessibility questions, feedback and accommodation requests: support@maplecrewservices.com. Other ways to reach us are on the contact page.

This statement was last reviewed on the date shown at the top of this page.