Accessibility Statement

Last updated: July 11, 2026

This Accessibility Statement applies to the Jobiko web application, the Jobiko browser extension, and related web properties (collectively, the "Service"). Jobiko is operated by WTech ("WTech," "we," "us," or "our"), a sole proprietorship (entreprise individuelle) of Abdoul Raouf Wendyam Issoufou Sawadogo, with a business address at 2255 Rue de l'Université, Québec (Québec) G1V 0A7, in the Province of Quebec, Canada.

1. Our commitment

WTech is committed to making Jobiko usable by the widest possible audience, including people who use assistive technologies such as screen readers, screen magnifiers, voice-control software, alternative input devices, and keyboard-only navigation.

We treat accessibility as an ongoing engineering and design practice rather than a one-time project. We aim to consider accessibility throughout our work — when we design new features, build components, write content, and review changes before release.

We recognize that some users rely on accessible design to find work and submit job applications. Because the core purpose of Jobiko is to help people apply for jobs, removing barriers in our product directly affects people's livelihoods, and we take that responsibility seriously.

2. Target standard

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, published by the World Wide Web Consortium (W3C).

WCAG defines requirements across four principles — that content be Perceivable, Operable, Understandable, and Robust — for people with a wide range of disabilities, including visual, auditory, motor, cognitive, and neurological disabilities.

"Aim to conform" means we have adopted WCAG 2.1 AA as our single working standard and design toward it, but we do not claim full, audited conformance across every page, component, and document at this time. Known gaps are described in Section 4.

In the United States, WCAG 2.1 AA also serves as the technical baseline for the standards we work toward under the Americans with Disabilities Act (ADA) and Section 508 (see Section 6); we treat WCAG 2.1 AA as the common reference across all of our target markets so that we are not measuring against multiple, divergent standards.

How we test against this standard. Our current assessment methodology combines (a) automated accessibility checks integrated into our development process, (b) manual keyboard-only testing of primary user flows, and (c) manual screen-reader testing using at least one screen reader on desktop. We have not yet commissioned a formal, independent third-party accessibility audit or conformance certification (for example, a VPAT/ACR for Section 508 purposes). Until such an audit is completed, statements in this document describe our design intent and internal testing, not certified conformance. Our assessment approach and its limits are described further in Section 7.

3. Measures we take

We have implemented, and continue to maintain, the following measures to support accessibility across the Jobiko web application and, where applicable, the browser extension:

• Semantic HTML. We use native HTML elements and landmark structure (headings, lists, navigation, main content regions, and form controls) so that assistive technologies can interpret page structure and meaning.
• Keyboard navigation. We design core interactive elements — including menus, dialogs, the multi-step onboarding wizard, the application tracker, and standard form controls — to be reachable and operable using a keyboard alone, without requiring a mouse or pointer. This is our design intent and is covered by our internal keyboard testing of primary flows; we have not yet verified keyboard operability across every screen, and certain richer components have known limitations (see Section 4). Where the workflow hands off to third-party pages — for example, payment screens or external Applicant Tracking System (ATS) forms reached during auto-apply — the keyboard accessibility of those externally hosted pages is determined by the third party and is outside our control.
• Visible focus states. Interactive elements are designed to show a clearly visible focus indicator so that keyboard and switch-device users can track their current position on the page.
• Color and contrast tokens. Our design system uses defined color tokens intended to meet WCAG 2.1 AA contrast ratios for text and meaningful interface elements. We aim not to rely on color alone to convey information (for example, application status is paired with text or icons, not color only).
• Reduced-motion support. We respect the operating-system "reduce motion" preference (prefers-reduced-motion). When a user has requested reduced motion, we reduce or remove non-essential animation in our interface and illustrations.
• ARIA labels and roles. Where native HTML semantics are not sufficient — for example, in custom widgets, icon-only buttons, and status messages — we apply appropriate ARIA labels, roles, and live-region announcements to communicate purpose and state.
• Language attribute per locale. Pages declare the active content language (for example, lang="en", lang="fr", or lang="es") so that screen readers can use the correct pronunciation and voice. Jobiko's interface is available in English, French, and Spanish, and the language attribute is set according to the selected locale.
• Forms and error handling. Form fields are designed to have associated labels, and we aim to present validation errors in text that is programmatically associated with the relevant field.
• Responsive and zoom-tolerant layout. Layouts are designed to adapt to different screen sizes and to remain usable when text is enlarged or the page is zoomed.

We review accessibility as part of our design and development process and aim to address regressions as they are identified.

4. Known limitations

We are committed to honesty about where we fall short. Despite our efforts, some parts of the Service may not yet fully meet WCAG 2.1 AA. Known and possible limitations include:

• Complex interactive widgets. Some richer components — such as data visualizations and analytics charts (for example, the application funnel and match-score charts), drag-or-reorder interactions, and multi-step queues — may have incomplete keyboard support, labeling, or alternative text in certain views.
  • Accessible alternatives available today: The Analytics screen offers CSV export of the underlying data, which can be opened in a spreadsheet or screen-reader-friendly tool; this is the recommended accessible alternative to the on-screen charts. The application tracker can be operated without drag-and-drop — status, priority, and other fields can be set through standard form controls and menus rather than by dragging. If you cannot complete a task that currently depends on a chart or a drag interaction, contact us (Section 5) and we will provide the information or perform the action through an alternative channel.
• Document and PDF previews. Generated resumes and cover letters are rendered as HTML and as PDF files. The in-app PDF preview, and downloaded PDF documents, are not yet reliably tagged for accessibility (for example, tagged headings, reading order, and document structure) and may not be reliably navigable by all screen readers. As a more accessible alternative available today, every generated document can be viewed in the in-app HTML view, which carries semantic structure (headings, lists, and labeled sections) that assistive technologies can interpret. Planned work: we are working toward producing accessibility-tagged ("tagged PDF") output for downloaded documents and aim to begin rolling this out within 12 months of the "Last updated" date above; until then, the HTML view is the recommended accessible format, and you can contact us (Section 5) to request an accessible copy of any generated document.
• Browser extension. The Jobiko browser extension captures job postings and assists with auto-filling application forms across 40+ third-party Applicant Tracking System (ATS) sites. Two scopes are involved here, and they have different limitations:
  • Our own extension interface (the side panel, capture controls, and status indicators) may have accessibility gaps we have not yet fully resolved. We have not yet completed dedicated screen-reader and keyboard testing of the extension interface across all of the 40+ supported ATS sites; our current testing has focused on a subset of high-volume sites, and we have not yet verified the full set. Planned work: we aim to complete a keyboard and screen-reader review of the extension's own interface within 12 months of the "Last updated" date above and to publish remaining gaps here as we identify them.
  • The third-party ATS pages themselves — the external job-application forms that the extension fills — are built and hosted by those third parties. Their accessibility is determined by each ATS provider and is outside our control. Because of this, we cannot guarantee that an auto-filled form is operable by assistive technology even when our extension is functioning as intended.
• Auto-apply workflow. Auto-apply is a best-effort, automated form-fill attempt and is not guaranteed to succeed on every site. Its in-app review-and-send screens may contain interactive elements that are not yet fully optimized for assistive technology. In addition, when auto-apply submits to an external ATS form, the accessibility of that destination form is set by the third party (see "Browser extension" above) and is outside our control.
• Third-party and embedded content. Some flows rely on third-party services — for example, Stripe for payment and checkout, and authentication providers (Google, Apple, LinkedIn). The accessibility of those externally hosted screens is determined by those providers and is not under our control.
• AI-generated content. Resume and cover-letter content generated with the help of AI model providers (such as Anthropic and OpenAI) is produced from your inputs and may vary in structure. We render this content into our own templates rather than displaying raw model output, and in the HTML view we apply semantic structure — for example, headings for resume sections, lists for skills and experience, and labeled regions for cover letters — so that screen readers can navigate it. Because the generated text itself varies, we cannot guarantee that every output is structured optimally for assistive technologies, and generated layouts that are primarily visual (such as template styling) are conveyed through structure and text rather than relying on decorative imagery; we do not generate meaningful information as images that would require alternative text. If a generated document is difficult to navigate with assistive technology, use the HTML view and contact us (Section 5).

This list is not exhaustive. If you encounter a barrier that is not listed here, please tell us using the contact details in Section 5 — your feedback helps us prioritize fixes.

5. Feedback and contact

We welcome your feedback on the accessibility of Jobiko. If you experience a barrier, cannot complete a task, or need information or a feature in an alternative accessible format, please contact us:

• Email: support@jobiko.org
• Subject line (suggested): "Accessibility — [brief description]"

To help us investigate, please include where possible:

• the page, screen, or feature involved (and the URL, if applicable);
• a description of the problem and what you were trying to do;
• the assistive technology, browser, and operating system you were using; and
• how you would like us to respond (for example, by email or phone).

Target response time: We aim to acknowledge accessibility reports within 5 business days and to provide a substantive response — including a plan or timeframe for any fix — within 15 business days. Complex issues may take longer; if so, we will keep you informed of progress.

If you are unable to use email. We currently do not operate a dedicated accessibility telephone line. If email is not an accessible channel for you, you may:

• ask a person you trust to send the report on your behalf using the email above (please have them note that they are writing for you);
• use the contact or feedback form available within the Jobiko web application's Settings; or
• request, through any of these channels, that we follow up with you by a method that works for you (for example, a phone call back at a number you provide).

A dedicated alternate accessibility contact channel (such as a phone or relay-service contact) is planned; until it is available, email is our monitored accessibility channel, and we will arrange an alternative format or a call-back on request.

6. Applicable laws and regulations

Jobiko currently serves users in Canada, the United States, and Latin America (including Brazil and Mexico). The European Union and the United Kingdom are out of scope for this version of the Service; accessibility obligations specific to those regions (for example, the European Accessibility Act or EN 301 549) are treated as future work and may require additional compliance measures before we offer the Service there.

We design toward, and reference, the following frameworks:

• Canada (federal): The Accessible Canada Act (ACA) and its goal of a barrier-free Canada, and the related Web Content Accessibility Guidelines expectations. We use WCAG 2.1 AA as our working standard consistent with these objectives.

• Quebec: The Province of Quebec's accessibility obligations, including the Act to secure handicapped persons in the exercise of their rights with a view to achieving social, school and workplace integration and applicable government accessibility standards. Quebec is our home jurisdiction.

• United States: We work on a best-effort basis toward the expectations associated with the Americans with Disabilities Act (ADA) as applied to digital services, and toward the Section 508 technical standards, which reference WCAG 2.1 Level AA as their conformance baseline. This is the same standard we adopt in Section 2, so our US target and our general working standard are the same. We do not represent that the Service has been formally certified or audited for ADA or Section 508 conformance, and we have not yet produced a VPAT/Accessibility Conformance Report; see Section 7 for the status of independent assessment.

• Latin America: We adopt WCAG 2.1 AA as our technical design standard across the Latin American markets we serve (for example, Brazil and Mexico). We use the word "baseline" to mean that WCAG 2.1 AA is the minimum technical target we design to — not that it is sufficient, on its own, for legal compliance in every country. Individual countries have their own national accessibility frameworks, several of which are themselves built on WCAG, including:

  • Brazil: the Lei Brasileira de Inclusão (LBI), Law No. 13.146/2015, and the federal government's web accessibility model eMAG (Modelo de Acessibilidade em Governo Eletrônico), which is aligned with WCAG.
  • Mexico: the Ley General para la Inclusión de las Personas con Discapacidad and related federal digital-accessibility guidance, which likewise draws on WCAG.
  • Other markets in the region may have their own requirements that we will identify as we expand.

  Where a national framework imposes obligations beyond WCAG 2.1 AA, we treat closing that gap as future work: we will assess the specific country requirements before relying on this Service as compliant in that market, and we will update this statement accordingly. We do not currently represent that the Service is certified as compliant with any specific Latin American national accessibility law.

This statement does not create rights or obligations beyond those required by applicable law. The operator is WTech, a sole proprietorship (entreprise individuelle) of Abdoul Raouf Wendyam Issoufou Sawadogo, registered in Québec, Canada (NEQ 2282211947).

7. Assessment and review

We assess the accessibility of Jobiko through a combination of internal design and engineering review, automated checks integrated into our development process, and manual testing with keyboard navigation and screen readers (the methodology summarized in Section 2). This internal testing currently covers our primary user flows and a subset of supported surfaces; it does not yet cover every page, component, document, or supported ATS site, as noted in the known limitations in Section 4.

We have not yet commissioned a formal, independent third-party accessibility audit, and we have not yet produced a formal conformance report (such as a VPAT/ACR for US Section 508 purposes). We intend to commission an independent assessment as the product matures and to update this statement with its scope and findings; until then, the statements here reflect our design intent and internal testing rather than certified conformance.

Review cadence: We review and update this Accessibility Statement at least once every 12 months, and sooner when we make significant changes to the Service or become aware of material accessibility issues. The "Last updated" date at the top of this statement reflects the most recent review.

8. Governing law

This Accessibility Statement, and any dispute relating to the accessibility of the Service, is governed by the laws of the Province of Quebec and the laws of Canada applicable therein, and the parties submit to the jurisdiction of the courts of the judicial district of Montreal, Quebec, except where applicable consumer-protection or accessibility law provides otherwise.

Questions about this statement: support@jobiko.org. Security issues unrelated to accessibility: security@jobiko.org.