Important business work should be reachable.

This Accessibility Statement explains how KOMERRA Technologies Limited approaches digital accessibility across its websites, applications, public pages, dashboards, forms, documents, customer-facing services, and support channels.

Our objective is to make important business work understandable and operable by as many people as reasonably possible, including people with visual, hearing, mobility, speech, cognitive, learning, and neurological disabilities.

Accessibility is treated as a core aspect of product quality, not as a separate mode added after the product has been designed.

This Statement describes our accessibility target, design and engineering practices, current limitations, testing approach, accommodation process, and how to report an accessibility barrier.

This Statement should be read together with the KOMERRA Terms of Service, Privacy Policy, Security & Trust page, Responsible AI framework, and applicable customer or enterprise agreements.

KOMERRA is operated by KOMERRA Technologies Limited, a company registered in the Federal Republic of Nigeria with registration number 9681120.

Accessibility questions and barrier reports may be sent to support@komerra.app.

Use “Accessibility Barrier” in the subject so that the request can be identified and routed appropriately.

Where a barrier prevents access to ordinary support channels, another person may contact KOMERRA on the affected user’s behalf with the user’s permission.

KOMERRA is committed to improving access to its digital products and services for people with disabilities.

We aim to design core tasks so they do not depend exclusively on sight, hearing, precise pointer movement, colour perception, rapid interaction, complex memory, or a particular device orientation.

Important workflows should remain understandable, keyboard operable, responsive, zoomable, and compatible with commonly used assistive technologies where reasonably applicable.

Accessibility work includes design, content, code, testing, support, procurement, documentation, incident handling, and continuing improvement.

No digital product is automatically accessible merely because it uses a modern framework, design system, semantic HTML, or an accessibility-testing tool.

KOMERRA uses the Web Content Accessibility Guidelines 2.2 at Level AA as its principal accessibility benchmark for web content and web applications.

WCAG organizes accessibility requirements around four broad principles: content and controls should be perceivable, operable, understandable, and robust.

For native or hybrid mobile applications, KOMERRA may use WCAG 2.2 Level A and AA requirements together with relevant mobile accessibility guidance and platform accessibility conventions.

Other legal, contractual, procurement, industry, or country-specific accessibility requirements may also apply depending on the service, customer, market, and deployment.

Our target is alignment with applicable WCAG 2.2 Level A and Level AA success criteria for supported core experiences.

Targeting WCAG 2.2 Level AA is not the same as claiming that every KOMERRA page, workflow, document, integration, or third-party surface currently conforms fully.

A full conformance statement should be made only after the relevant scope has been evaluated and all applicable Level A and Level AA requirements have been satisfied without unresolved exceptions.

KOMERRA does not rely on this Statement alone as proof of full accessibility conformance, certification, regulatory approval, or independent assurance.

Different parts of the platform may be at different stages of implementation, testing, remediation, or third-party dependency.

Where a formal accessibility assessment is completed, KOMERRA may publish the assessed scope, standard, method, date, known exceptions, and remediation status.

This Statement is intended to cover KOMERRA-controlled public websites, registration and authentication experiences, business dashboards, administrative surfaces, Mini Stores, Trust Passports, support forms, policy pages, billing interfaces, and other supported digital experiences.

It also describes expectations for documents, charts, AI-generated content, notifications, integrations, and mobile experiences where KOMERRA controls the relevant design or implementation.

Independent websites, applications, payment pages, messaging platforms, social networks, map services, operating systems, browsers, banks, and other third-party services are outside KOMERRA’s complete control.

Business-created content may introduce accessibility barriers even when the surrounding KOMERRA interface is accessible.

KOMERRA aims to build accessibility into the ordinary product experience rather than requiring a person to discover and activate a separate accessibility version.

A separate mode can become outdated, incomplete, or inconsistent with the main product if it is maintained as a parallel experience.

Where optional display preferences are provided, they should supplement rather than replace accessible structure, keyboard access, readable contrast, semantic controls, and assistive-technology compatibility.

Users should not have to disclose a disability merely to access the ordinary functions of the platform.

Shared interface components should include accessibility requirements so improvements can apply consistently across public pages, business dashboards, administrative tools, and customer-facing experiences.

Buttons, links, fields, menus, dialogs, tabs, tables, alerts, tooltips, drawers, selection controls, and navigation patterns should have defined keyboard, focus, naming, state, error, and screen-reader behaviour.

A visually polished component should not be accepted as production ready where its accessible role, name, state, focus behaviour, or keyboard interaction is missing.

Custom components should use native HTML elements where those elements already provide the required semantics and interaction.

Accessible component behaviour must be preserved when components are restyled, animated, resized, or reused in a different context.

Pages should use meaningful landmarks, headings, lists, tables, labels, buttons, links, and other semantic elements.

Heading levels should describe the content hierarchy instead of being selected only for visual size.

Regions such as navigation, main content, search, forms, complementary content, and footers should be identifiable where appropriate.

Visual grouping alone should not be the only way related information is communicated.

Where content order changes responsively, the reading and keyboard order should remain logical.

Pages should have descriptive titles that help users understand their current location.

Navigation should remain reasonably consistent across related pages and workflows.

Links should communicate their purpose from their text or accessible context rather than relying repeatedly on vague phrases such as “click here”.

Where practical, users should have more than one reasonable way to locate important pages, such as navigation, search, breadcrumbs, or related links.

Skip links or equivalent mechanisms should allow keyboard users to bypass repeated navigation where appropriate.

Core KOMERRA functionality should be operable through a keyboard without requiring a mouse or touch gesture.

Keyboard users should be able to reach, activate, and exit interactive controls in a logical order.

Menus, dialogs, drawers, tabs, disclosure controls, date inputs, file controls, tables, and other interactive components should have documented keyboard behaviour.

Keyboard focus must not become trapped in a component unless the component intentionally contains focus and provides a clear way to exit.

Drag-and-drop functionality should have an accessible alternative where dragging is not essential to the underlying task.

Keyboard shortcuts should not interfere unexpectedly with assistive technology or ordinary typing.

Interactive controls should show a visible focus indicator when reached through keyboard navigation.

Focus indicators should remain sufficiently distinguishable from the surrounding interface and should not depend solely on a subtle colour change.

Sticky headers, banners, cookie notices, dialogs, drawers, and floating controls should not completely obscure the focused element.

When a dialog or similar component opens, focus should move to an appropriate location within it and return logically when the component closes.

After a route change, validation failure, deletion confirmation, or other significant update, focus should be managed so users can locate the changed content.

KOMERRA aims to support commonly used screen readers and assistive technologies in combination with supported browsers and operating systems.

Interactive controls should expose an appropriate accessible name, role, value, state, and description where required.

Status changes, validation messages, progress updates, saved confirmations, loading states, and critical errors should be communicated programmatically where visual presentation alone would not be sufficient.

Decorative icons and illustrations should be hidden from assistive technology where they add no independent information.

Icons used as controls must have an accessible name that explains the action.

Testing with one assistive-technology combination does not guarantee identical behaviour across every device, browser, or assistive product.

Form controls should have persistent and programmatically associated labels.

Placeholder text should not be the only label or instruction for an input.

Required fields, expected formats, constraints, and material consequences should be explained before submission where practical.

Related controls should be grouped and described appropriately.

Autocomplete attributes and input purposes should be used where they improve accessible completion and are appropriate for the information requested.

A form should not require unnecessarily complex input where a simpler and equally secure method is available.

Errors should be identified in text and associated with the relevant field or section.

Colour, border styling, or an icon should not be the only indication that an error occurred.

Where practical, error messages should explain how the problem can be corrected rather than only stating that the submission failed.

Forms should preserve correctly entered information after a validation error where security and privacy allow.

Where a submission has important legal, financial, or destructive consequences, users should be able to review, correct, and confirm material information before completion.

A summary should help users locate multiple errors in long or complex forms where appropriate.

Authentication should be designed so that a person is not unnecessarily required to solve, remember, transcribe, or manipulate information in a way that creates an avoidable cognitive or motor barrier.

Password managers and paste functionality should not be blocked without a strong and documented security reason.

Passkeys, one-time codes, recovery methods, and multi-factor authentication should use clear labels and instructions.

Where a security challenge presents an accessibility barrier, an accessible alternative should be available where reasonably possible without weakening necessary security controls.

Biometric authentication should remain optional where another secure authentication method is available.

KOMERRA will not ask users to weaken Account security as an accessibility accommodation.

Where a task has a time limit, users should be informed of the limit where appropriate.

Users should be able to extend, adjust, or avoid non-essential time limits where reasonably possible.

Security-related session expiry may remain necessary, but warnings and recovery paths should reduce unnecessary loss of entered information.

A person should not lose substantial form content silently because a session expired without warning.

Certain real-time provider operations may have limits outside KOMERRA’s control, and those limits should be explained where they affect completion.

KOMERRA is designed for use across small mobile devices, tablets, laptops, desktops, and larger displays.

Core content and functionality should reflow without requiring users to shrink an entire desktop layout beyond practical readability.

Users should be able to enlarge text and zoom supported pages without losing essential content, controls, labels, or functionality.

Horizontal scrolling may remain necessary for content whose meaning depends on two-dimensional layout, such as certain wide data tables, timelines, canvases, or charts.

Where horizontal overflow remains necessary, it should be deliberate, contained, labelled where helpful, and accompanied by a reasonable alternative where possible.

Core mobile workflows should not require one device orientation unless a specific orientation is essential to the activity.

Controls should not be positioned so close together that ordinary touch interaction becomes unnecessarily difficult.

Primary actions should remain reachable and understandable on smaller screens.

Touch gestures requiring multiple fingers, complex paths, or precise movement should have a simpler alternative where practical.

Mobile interfaces should accommodate operating-system text scaling and accessibility settings to the extent supported by the platform and implementation.

Buttons, links, checkboxes, menu triggers, icon controls, and other pointer targets should be large enough and sufficiently separated for reliable use.

Small icon-only controls should not be used where the action cannot be operated accurately or understood without unnecessary precision.

Critical or destructive actions should not be positioned in a way that makes accidental activation unusually likely.

Where a compact interface is necessary, spacing, grouping, confirmation, and alternative interaction should reduce accidental input.

Text, controls, focus indicators, icons, borders, charts, and status information should use contrast appropriate to their purpose and size.

KOMERRA’s dark evergreen, near-black, lime, porcelain, and supporting colours must be tested in their actual combinations rather than assumed to be accessible because the palette appears high contrast.

Colour must not be the only method used to communicate success, failure, warning, payment status, verification, priority, inventory condition, or another important distinction.

Words, icons, patterns, labels, or other cues should supplement colour where meaning would otherwise be lost.

Business-selected branding colours may require automatic contrast protection, warnings, or restricted combinations.

Body text should use readable sizing, spacing, line length, and contrast.

Important information should not be embedded entirely within decorative images where ordinary text can communicate it more accessibly.

Users should be able to enlarge text without text being clipped, overlapped, hidden, or rendered unusable.

All-uppercase text and unusually wide letter spacing should be limited to short labels rather than long passages.

Content should use clear headings, short paragraphs, descriptive labels, and lists where those structures improve understanding.

KOMERRA aims to explain business actions, costs, consequences, errors, permissions, security events, and AI recommendations in language appropriate to the user and task.

Unnecessary jargon, unexplained abbreviations, ambiguous controls, and hidden consequences can create barriers even where an interface is technically keyboard accessible.

Complex workflows should be divided into understandable steps where practical.

Important instructions should remain available while the user completes the task rather than relying only on memory.

Consistent names, control locations, help routes, and interaction patterns should be used across related experiences.

Critical actions should use clear confirmation language instead of vague prompts that require the user to guess the consequence.

Motion should support understanding, feedback, or orientation rather than delay or prevent task completion.

KOMERRA should respect a user’s reduced-motion preference and remove, disable, or shorten non-essential animation where appropriate.

Loading animations should not become the only way progress or status is communicated.

Content should avoid flashes and visual patterns capable of creating a seizure risk.

Parallax, automatic movement, looping effects, and animated backgrounds should be limited and should not interfere with reading, focus, or control activation.

Essential motion should be accompanied by another understandable cue where practical.

Meaningful images should have text alternatives appropriate to their purpose and context.

Decorative images should use empty alternatives or otherwise be excluded from the accessibility tree.

Complex images may require a nearby description, summary, data table, or another accessible equivalent.

Text alternatives should communicate the purpose or information conveyed rather than attempting to describe every visual detail unnecessarily.

Icons used beside visible text may be decorative, while icon-only controls require an accessible name.

Business-uploaded images may not automatically contain useful alternative text, so businesses should provide meaningful descriptions where the image communicates important product or service information.

Prerecorded video containing meaningful speech should provide captions or an equivalent accessible transcript where KOMERRA controls the content and the media is intended for general use.

Meaningful audio-only content should have a transcript where appropriate.

Important visual information in video may require audio description or another text-based explanation.

Media controls should be keyboard accessible and labelled for assistive technology.

Audio should not begin automatically without a clear and accessible way to stop or control it.

Third-party video players may introduce limitations outside KOMERRA’s complete control.

KOMERRA may process voice notes and audio to provide transcription, translation, summaries, or structured business information.

Automatically produced transcripts may be inaccurate because of noise, accents, language switching, recording quality, multiple speakers, speed, or specialized terminology.

A transcript should not become the only available form of important source information where access to the original audio remains necessary.

Users should be able to review and correct material transcriptions before using them for important business actions.

Where an audio workflow creates a barrier, a text-input route should be available where practical.

Tables should use meaningful headers and relationships where tabular structure is appropriate.

Tables should not be used only to achieve visual page layout.

Interactive data grids should expose their structure, selection, sorting, editing, and navigation behaviour appropriately.

Dense tables may use controlled horizontal scrolling on small screens, but essential actions and context should remain discoverable.

Where a table is too complex for effective assistive use, a simplified, filtered, exported, or summary representation should be considered.

Empty, loading, error, and filtered states should be communicated clearly.

Charts should not rely solely on colour, shape, hover interaction, or visual position to communicate important business information.

Important charts should provide a text summary, accessible data table, downloadable data, or another equivalent where practical.

Tooltips that appear only on hover should also be available through keyboard or another accessible interaction.

Axis labels, legends, units, time periods, values, and data status should be clear.

AI-generated insights should be understandable without requiring a user to interpret a visual chart alone.

Decorative visualizations should not obscure the underlying operational information.

KOMERRA may generate invoices, quotations, receipts, delivery notes, reports, exports, and other business documents.

Generated documents should use a logical reading order, meaningful headings, selectable text, clear labels, sufficient contrast, and understandable tables where the selected format supports those features.

A visually polished document is not necessarily accessible if its text is flattened into an image, its reading order is incorrect, or its fields and tables lack structure.

Where an exported PDF or other document format presents a barrier, KOMERRA may provide an HTML view, structured data export, plain-text version, or other reasonable alternative where available.

Business-provided logos, images, colour schemes, templates, and custom content can affect the accessibility of generated documents.

The accessibility of files after they are edited through external software is outside KOMERRA’s control.

Users may upload documents, images, spreadsheets, receipts, identity materials, and other files that KOMERRA did not create.

KOMERRA cannot guarantee that every uploaded file is accessible.

Businesses should avoid using image-only documents where searchable or structured documents are reasonably available.

Where an inaccessible uploaded document contains information necessary for a customer, staff member, or other person, the business should provide an accessible alternative upon reasonable request.

Optical character recognition may help extract text but does not automatically create a fully accessible document.

AI may help generate, summarize, translate, classify, or restructure content, but AI Output is not automatically accessible.

AI-generated headings, descriptions, alternative text, transcripts, captions, plain-language summaries, and document structures should be reviewed before publication.

Generated alternative text may omit context, invent details, or describe irrelevant features.

Generated summaries may remove information important to a person with a disability or change the meaning of the source.

An AI feature must not refuse access to an ordinary task merely because a user interacts differently or uses assistive technology.

Accessibility-related AI features should preserve privacy and should not require unnecessary disclosure of a person’s disability.

The primary language of a page or document should be identified programmatically where practical.

Changes in language within content should also be identified where they materially affect pronunciation or comprehension.

KOMERRA may support English, Nigerian English, Pidgin, and selected Nigerian languages, but availability and accuracy may differ by feature, provider, model, dialect, and release.

Machine translation can introduce errors and should be reviewed before it is used for important instructions, payment information, customer commitments, legal terms, or safety information.

Accessibility support should not be assumed to be identical across every supported language.

Important notifications should be perceivable without depending solely on their screen position, colour, animation, or temporary appearance.

Success messages, failures, warnings, saved states, loading progress, and background completion should be announced appropriately where they affect the user’s task.

Temporary toast messages should remain available long enough to be understood or should also appear in a persistent notification history where their importance requires it.

A loading screen should communicate that processing is continuing and should not prevent access longer than necessary.

Repeated or rapidly updating status messages should avoid overwhelming assistive-technology users.

Dialogs and overlays should have an accessible name and clear purpose.

Keyboard focus should move into an opened dialog and remain within it until the dialog is closed where modal behaviour is intended.

Users should have a clear method for closing non-essential overlays.

Background content should not remain accidentally interactive while a modal dialog is active.

Consent banners, support widgets, chat tools, and floating controls should not cover essential content or obscure keyboard focus.

Actions such as Account deletion, Workspace deletion, refund requests, staff removal, permission changes, document publication, payment confirmation, and security changes should communicate their consequences clearly.

Users should receive an opportunity to review and correct material information before irreversible action where practical.

Confirmation should not depend on colour, animation, precise pointer movement, or inaccessible drag interaction.

A confirmation interface should identify the affected resource and action rather than using a vague question such as “Are you sure?” without context.

Accessibility accommodations must not bypass required identity, authority, tenant, security, or payment controls.

KOMERRA aims to make the Mini Store framework, navigation, product structure, cart, checkout, order forms, and customer Account surfaces accessible.

Businesses remain responsible for the accessibility and accuracy of their product descriptions, uploaded images, videos, custom policies, contact information, and other Business Content.

Businesses should provide meaningful text descriptions for products where the image communicates information needed to make a purchasing decision.

Size, colour, material, ingredients, compatibility, delivery, availability, price, and other important information should be available as text rather than only inside an image.

Custom branding should not reduce text contrast, hide focus indicators, or make controls difficult to identify.

Trust Passport business information, verification indicators, policies, status, and customer-facing explanations should be understandable without relying solely on colour or visual badges.

A verification icon should have an accessible name and accompanying text explaining what was checked and what the indicator does not guarantee.

Public trust information should use meaningful headings and an understandable reading order.

Business-uploaded evidence and documents may require an accessible alternative where they are published for customer use.

The absence of a visual disability-related barrier does not mean the underlying verification or trust claim is accurate; accessibility and factual accuracy are separate requirements.

Administrative and support interfaces should be held to accessibility expectations appropriate to their operational importance.

Accessibility should not be limited to customer-facing marketing pages while staff, support, security, and administrative tools remain unusable by people with disabilities.

Dense data, bulk operations, filters, moderation tools, audit logs, and management dialogs require intentional keyboard and screen-reader design.

Administrative shortcuts should have accessible alternatives and should not conflict with assistive technology.

A staff member should not need unnecessary assistance from another person to perform ordinary duties because an internal interface was excluded from accessibility planning.

KOMERRA-controlled pricing, bundle selection, billing history, Credit usage, refund requests, and payment-status information should be understandable and keyboard operable.

Prices, currencies, taxes, action costs, bundle quantities, and renewal terms should be available as text.

Payment status should not be communicated solely through colour.

A browser redirect or payment-provider surface may be controlled by an independent provider and may have accessibility characteristics outside KOMERRA’s complete control.

Where a provider creates a material barrier, users should report the problem so KOMERRA can investigate an alternative provider route or accommodation where reasonably available.

KOMERRA will not request sensitive payment credentials through an accessibility-support process.

KOMERRA integrates with or links to independent providers for payments, messaging, email, social channels, maps, identity verification, analytics, video, support, storage, and other functions.

KOMERRA cannot guarantee the accessibility of every third-party website, application, embedded widget, hosted checkout, message composer, verification screen, or provider-controlled document.

Provider accessibility should be considered during selection and review where the provider performs a material user-facing function.

A provider’s accessibility statement or certification applies to the provider’s stated scope and does not automatically establish end-to-end accessibility for KOMERRA.

Where a third-party barrier blocks a core KOMERRA task, we will assess whether a reasonable alternative or assisted process is available.

Businesses can upload or publish product images, descriptions, documents, policies, logos, colour choices, videos, and other content through KOMERRA.

KOMERRA may provide accessible templates, prompts, warnings, validation, or guidance, but the business remains responsible for the content it provides.

A business should correct an accessibility barrier in its public content when informed and where correction is reasonably possible.

KOMERRA may restrict customization options that would make essential controls unreadable, invisible, misleading, or unusable.

KOMERRA may also provide automatic contrast protection or accessible defaults while allowing limited brand customization.

Accessibility depends on a combination of the KOMERRA application, browser, operating system, device, assistive technology, extensions, user settings, and third-party services.

KOMERRA aims to support current versions of widely used browsers and operating systems consistent with its published technical-support policy.

Older, unsupported, modified, or highly customized technologies may not provide the same level of accessibility.

Browser extensions, forced-colour settings, zoom tools, password managers, translation tools, and assistive technologies can also affect presentation or behaviour.

Where a problem occurs, identifying the complete technology combination helps KOMERRA reproduce and investigate it.

Accessibility is an ongoing process, and barriers may remain in parts of the platform.

Potential limitations may include complex data tables, interactive charts, generated PDF documents, uploaded Business Content, third-party payment or verification screens, provider-hosted messaging experiences, early-release features, and highly customized public pages.

Some advanced drag, canvas, timeline, chart, or visualization experiences may require an alternative interaction or representation.

Automatically generated captions, transcripts, translations, alternative text, and AI summaries may require correction.

Older components or pages introduced before current accessibility requirements may require remediation.

KOMERRA will not describe a limitation as resolved until the relevant production behaviour has been verified.

KOMERRA aims to combine automated testing, code review, design review, manual keyboard testing, assistive-technology testing, zoom and reflow checks, contrast evaluation, and task-based usability review.

Testing should cover core public, customer, business, billing, administrative, and support workflows according to their significance and risk.

Representative testing may include registration, login, onboarding, navigation, forms, search, order creation, document generation, staff management, billing, public pages, and Account deletion.

Accessibility testing should occur during component development, feature review, release validation, regression testing, and remediation.

A test result applies to the tested version, scope, content, browser, device, and assistive-technology combination rather than proving permanent universal conformance.

Automated accessibility tools can identify many common technical issues but cannot determine whether every interaction is understandable or usable.

An automated score does not prove WCAG conformance.

Automated tools may miss incorrect reading order, confusing keyboard behaviour, poor alternative text, inaccessible error recovery, cognitive barriers, misleading labels, and task-level difficulties.

Passing an automated check must therefore be supported by manual and assistive-technology evaluation appropriate to the feature.

Accessibility checks should form part of development and deployment controls without being treated as the only quality gate.

Where practical, KOMERRA should include people with disabilities in research, usability testing, feedback, and product review.

People with disabilities are not a single user group and may use different strategies, technologies, preferences, and accommodations.

A person should be compensated fairly where they are engaged to perform formal research or testing.

Testing should not require unnecessary disclosure of medical information.

User feedback should influence component design, workflow priorities, documentation, support procedures, and remediation decisions.

Accessibility should be considered when KOMERRA selects material user-facing software, components, libraries, payment providers, verification providers, document tools, support systems, and other vendors.

Evaluation may include accessibility documentation, conformance reports, keyboard operation, assistive-technology behaviour, known limitations, support commitments, and remediation history.

A vendor’s accessibility claim should not be accepted automatically without considering the actual KOMERRA integration and workflow.

Where no fully accessible provider is reasonably available, the risk and available alternatives should be documented and reviewed.

Accessibility defects should be prioritized according to severity, affected task, number of users, availability of alternatives, security impact, financial consequence, and legal or contractual significance.

A barrier preventing registration, authentication, payment review, Account security, customer ordering, essential document access, or support may require urgent attention.

Lower-impact visual inconsistencies may be scheduled according to ordinary product maintenance.

A temporary alternative should not become a permanent substitute for repairing a recurring barrier where remediation is reasonably possible.

Accessibility regressions introduced by a release should be tracked and corrected rather than accepted merely because an earlier version was accessible.

Where a digital barrier prevents a person from completing a core task, KOMERRA will consider a reasonable alternative or assisted process.

An accommodation may include providing information in another accessible format, assisting with a form, supplying a text or table alternative, using another support channel, or helping the person complete a supported workflow.

The accommodation provided depends on the task, urgency, security requirements, available technology, user preference, and risk.

An accommodation will not bypass required identity verification, Account authority, tenant isolation, payment verification, fraud controls, or another person’s rights.

KOMERRA may ask for information about the barrier and preferred interaction but will not require unnecessary medical documentation merely to investigate an ordinary accessibility problem.

Report a barrier to support@komerra.app with “Accessibility Barrier” in the subject.

Describe the page, feature, document, or task affected and what you were trying to accomplish.

Where available, include the page address, approximate date and time, Account or Workspace, device, operating system, browser, assistive technology, zoom level, and relevant error or request identifier.

Explain the result you expected, the result you experienced, and any workaround already attempted.

You may also describe the alternative format or interaction that would be useful.

Do not include passwords, one-time passwords, recovery codes, private keys, card security codes, bank PINs, or unnecessary identity documents.

KOMERRA will record and assess accessibility reports according to their scope, severity, effect, reproducibility, and available alternatives.

We may request additional information where the barrier cannot be reproduced or the affected technology combination is unclear.

A report may be connected with an existing issue, component, provider limitation, document problem, or broader product remediation plan.

Where an immediate repair is not reasonably available, KOMERRA will consider a temporary accessible alternative for the affected task.

The reporter may receive updates about material progress or the available resolution where reasonably possible.

Security, privacy, another person’s information, or confidential provider details may limit the technical information that can be disclosed.

State clearly where a barrier prevents access to an urgent Account-security, payment, refund, customer, legal, or time-sensitive task.

KOMERRA will prioritize the report according to the potential consequence and availability of an alternative.

An urgent request should still provide enough information to verify the Account, authority, affected task, and required action safely.

Urgency does not authorize KOMERRA to bypass security or disclose another person’s information.

KOMERRA will not restrict an Account merely because a person reports an accessibility barrier, requests an accommodation, questions a design decision, or raises a good-faith accessibility concern.

This does not protect fraudulent reports, harassment, security attacks, threats, or deliberate misuse of support channels.

Accessibility feedback may be critical, detailed, or persistent without becoming prohibited merely because KOMERRA disagrees with it.

Where you believe an accessibility request was not handled appropriately, you may ask KOMERRA to reconsider the matter.

Use “Accessibility Review” in the subject and identify the original support case or report where available.

Explain the unresolved barrier, the effect on the task, the response received, and the remedy or alternative you are requesting.

KOMERRA may assign a different reviewer where appropriate.

Nothing in this Statement removes a right to contact a competent authority, disability-rights body, consumer-protection authority, court, or other applicable complaint channel.

Accessibility support requests may reveal information about a person’s disability, assistive technology, communication preference, or functional needs.

KOMERRA will process this information only for legitimate support, accommodation, product-improvement, legal, security, and accountability purposes described in the Privacy Policy.

Users should not be required to disclose a diagnosis where describing the barrier and required accommodation is sufficient.

Accessibility information should be accessible only to personnel and providers with a legitimate need.

Aggregated or de-identified accessibility feedback may be used to improve the platform.

Businesses using KOMERRA are responsible for the accessibility of the content, documents, images, videos, product information, policies, colours, and customer communications they provide.

Businesses should respond reasonably where a customer or staff member requests an accessible version of information the business controls.

Businesses should not use custom content or branding to hide required disclosures, reduce contrast, remove labels, or make essential information available only visually.

KOMERRA may provide accessible defaults and guidance, but those measures cannot guarantee that every business-created page or document remains accessible.

KOMERRA does not claim that every current page, feature, provider, integration, generated document, or business-created experience is free from accessibility barriers.

KOMERRA does not claim full WCAG 2.2 Level AA conformance unless the stated scope has been appropriately evaluated and the claim remains current.

KOMERRA does not claim that automated testing, semantic HTML, a design system, or assistive-technology testing with one configuration proves universal accessibility.

KOMERRA does not claim that a third-party provider’s conformance report automatically establishes end-to-end conformance for KOMERRA.

KOMERRA does not claim that AI-generated captions, transcripts, summaries, translations, or alternative text are always accurate.

Our commitment is to identify barriers, provide reasonable alternatives, correct verified problems, and improve accessibility as the platform develops.

This Statement should be reviewed when material products, components, providers, accessibility standards, legal requirements, testing results, or known limitations change.

The public Statement should remain consistent with the actual production platform and should not describe planned controls as universally implemented.

Completed assessments, material limitations, remediation progress, and formal conformance claims may be added when verified.

Historical versions may be retained for accountability.

This Statement was last reviewed on 20 July 2026.

Send accessibility questions, accommodation requests, and barrier reports to support@komerra.app.

Use “Accessibility Barrier” for a problem affecting access to a page, document, control, or workflow.

Use “Accessibility Review” to ask for reconsideration of an earlier response.

Include the affected page or task, device, browser, assistive technology, observed problem, and preferred alternative where available.

Do not send passwords, private keys, one-time passwords, recovery codes, card security codes, bank PINs, or unnecessary identity documents through ordinary email.