Accessibility at Fungies

Fungies provides an electronic commerce service through websites and mobile devices that enables consumers to interact with offers, proceed through checkout and enter into transactions electronically. This statement covers the following parts of the Fungies electronic commerce service:

• fungies.io — our website, including pricing, product and documentation pages
• The Fungies app — the seller dashboard for products, offers, orders and payouts
• Checkout — all three forms: the hosted page, the overlay, and the embedded element
• The customer portal — where buyers find invoices, subscriptions and downloads

Content published by sellers, such as product names, descriptions, images and store branding, is not created or controlled by Fungies. To the extent that such content falls within the statutory exclusions for content not created, financed or controlled by the economic operator, it is outside the scope of those requirements. Fungies nevertheless provides sellers with tools intended to make accessible content possible.

Third-party components embedded in our pages, including payment-provider frames, may be controlled by their providers. Fungies remains responsible for the accessibility of the service and for the way third-party components are integrated, labelled and operated within Fungies, including keyboard focus, accessible names and the surrounding interaction.

Fungies treats the service as an electronic commerce service within the meaning of the Polish Act of 26 April 2024 on ensuring accessibility requirements for certain products and services by economic operators (the Polish Accessibility Act, “PAD”).

We use the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, as our principal accessibility standard. We also use EN 301 549 as a technical reference when assessing accessibility.

The service is being operated against WCAG 2.2 Level AA and the accessibility requirements applicable to electronic commerce services under PAD. Known limitations are listed below. This document does not claim that every accessibility requirement is currently satisfied; the identified defects are being addressed through the corrective process described below.

Information and interface components are presented so users can perceive them through the available sensory channels. The service is designed to support accessible use by people with different sensory, cognitive and motor needs.

• Text alternatives for images

  What we do

  Images that carry meaning have descriptive alternative text. Decorative images are marked so screen readers skip them rather than announcing filenames.

• Meaningful sequence

  What we do

  Content is ordered in the markup the same way it reads on screen, so a screen reader encounters it in the intended order.

• Instructions not tied to shape, size or position

  What we do

  We do not rely on phrases like “the button on the right”. Instructions name the control.

• Information not conveyed by colour alone

  What we do

  Order status, validation errors and required fields all carry text or an icon as well as colour.

• Text contrast of at least 4.5:1

  What we do

  Our colour palette is defined centrally and checked for contrast, so body text meets the minimum wherever it appears.

• Contrast for controls and indicators

  What we do

  Buttons, input borders and focus indicators meet the 3:1 minimum for non-text contrast.

• Text resizing to 200%

  What we do

  Layouts use relative units, so text scales to 200% without content being lost or clipped.

• Reflow without horizontal scrolling

  What we do

  Pages reflow to a 320 pixel width, so you can zoom to 400% without scrolling in two directions.

• Text spacing overrides

  What we do

  Increasing line height, letter or word spacing does not cut off or overlap content.

• Content shown on hover or focus

  What we do

  Tooltips and popovers can be dismissed without moving the pointer, and stay visible long enough to read.

• Orientation

  What we do

  Nothing is locked to portrait or landscape. The interface works either way.

• Identifying the purpose of inputs

  What we do

  Checkout fields declare their purpose, so browsers and assistive tools can fill in name, email, address and card details automatically.

• Avoiding images of text

  What we do

  Text is real text, not pictures of text, so it scales and can be read aloud.

The service is designed to be operable with keyboard, switch, voice-control and pointer input, subject to the known limitations listed below.

• Everything works by keyboard

  What we do

  Every action, including completing a purchase, can be done from the keyboard alone. Nothing requires a mouse.

• No keyboard traps

  What we do

  You can always move focus out of a component using the keyboard. Dialogs can be closed with Escape.

• Character key shortcuts

  What we do

  We do not bind actions to single letter keys, so speech input users do not trigger them by accident.

• Adjustable timing

  What we do

  Where a session or a checkout has a time limit, we warn you before it expires and let you extend it.

• Pausing moving content

  What we do

  Anything that moves, scrolls or auto-updates can be paused or stopped.

• No flashing content

  What we do

  Nothing on our surfaces flashes more than three times a second.

• Skipping repeated blocks

  What we do

  A skip link and proper landmark regions let you jump past navigation straight to the main content.

• Page titles

  What we do

  Every page has a unique, descriptive title, including each step of checkout.

• Logical focus order

  What we do

  Tabbing moves through the page in an order that matches how it reads.

• Link purpose is clear

  What we do

  Link text describes its destination. We avoid bare “click here” and “read more”.

• More than one way to find a page

  What we do

  Our site offers navigation, search and a sitemap rather than a single route to any page.

• Descriptive headings and labels

  What we do

  Headings describe the section they introduce and labels describe the field they sit on.

• Visible focus

  What we do

  The focused element always has a clearly visible indicator. We never remove the focus ring without replacing it.

• Focus is not hidden

  What we do

  Sticky headers, banners and cookie notices do not cover the element you have tabbed to.

• Pointer gestures have alternatives

  What we do

  Anything doable with a multi-point or path-based gesture can also be done with a single tap or click.

• Pointer cancellation

  What we do

  Actions fire on release, not on press, so you can slide off a control to cancel.

• Visible label matches the name

  What we do

  The accessible name of a control starts with its visible text, so voice control users can say what they see.

• Motion is not required

  What we do

  No function requires tilting or shaking a device.

• Dragging has an alternative

  What we do

  Where something can be dragged, such as reordering, there is a non-dragging way to do the same thing.

• Target size

  What we do

  Interactive targets are at least 24 by 24 CSS pixels, or have enough spacing around them.

Information and operation are presented in a consistent and understandable way, with clear labels, instructions, error messages and predictable navigation.

• Language of the page

  What we do

  Every page declares its language, so screen readers use the right pronunciation.

• Language of parts

  What we do

  Passages in another language are marked, which matters on our localised checkout.

• No change on focus

  What we do

  Moving focus to a control never by itself changes the page or submits anything.

• No change on input

  What we do

  Changing a setting such as currency or country does not submit the form or navigate without warning you first.

• Consistent navigation

  What we do

  Navigation appears in the same place and the same order on every page.

• Consistent identification

  What we do

  Components that do the same thing are labelled the same way throughout.

• Help is in a consistent place

  What we do

  Support and contact links sit in the same location across pages, so you do not hunt for them.

• Errors are identified in text

  What we do

  When something is wrong we say so in text and point at the field, rather than only turning it red.

• Labels and instructions

  What we do

  Every input has a visible label and, where a format is required, an example.

• Errors suggest a correction

  What we do

  Messages say how to fix the problem, not only that one exists.

• Financial transactions are reversible or confirmable

  What we do

  Before a payment completes you see a review step, and you can go back and change it.

• No redundant re-entry

  What we do

  Information you have already given in a flow is carried forward rather than asked for twice.

• Authentication does not require memory tests

  What we do

  Signing in does not depend on solving a puzzle or recalling a code unaided. Password managers and pasting are supported.

The service is designed to work with current assistive technologies and standard web technologies. Known interoperability defects are listed below and are being remediated.

• Name, role and value are exposed

  What we do

  Controls are built from standard HTML elements wherever possible, so assistive technology is told what each one is, what state it is in, and what it does. Where we build a custom component, we supply the same information through ARIA. This is the area where our current defects sit, and they are listed below.

• Status messages are announced

  What we do

  Confirmations, errors and progress updates are announced by screen readers without stealing focus from what you were doing.

The following practical descriptions explain how the accessibility features apply to common ways of using the service. They complement, but do not replace, the technical and legal requirements described elsewhere in this document.

• Use a screen reader

  What we have done

  Pages are built from standard HTML with a single main heading and a correct heading order, so you can navigate by structure instead of reading everything. Landmarks let you jump straight to navigation, main content or the footer. Form fields are properly labelled, and confirmations and errors are announced without taking focus away from where you were. Tables have real header cells so figures are read with their column and row.

• Cannot use a mouse

  What we have done

  Every action can be completed from the keyboard, including checkout. Tab order follows the reading order, the focused element is always clearly outlined, and dialogs close with Escape. A skip link gets you past the navigation on every page.

• Have low vision

  What we have done

  Text can be enlarged to 200% and the page zoomed to 400% with everything still reachable and nothing overlapping. Body text meets a 4.5:1 contrast ratio, and controls and focus outlines meet 3:1. Text is real text rather than images, so it stays sharp at any size. Your own text-spacing settings are respected.

• Are colour blind

  What we have done

  Nothing depends on colour alone. Order status, validation errors and required fields are all marked with text or an icon as well as colour.

• Use voice control

  What we have done

  The accessible name of every control begins with its visible text, so saying what you see works. We avoid single-key shortcuts that speech input could trigger by accident.

• Find fine movement difficult

  What we have done

  Interactive targets are at least 24 by 24 pixels or well-spaced. Actions fire when you release rather than when you press, so you can slide away to cancel. Anything you can drag can also be done without dragging.

• Are sensitive to motion

  What we have done

  We honour your operating system's reduced-motion setting, and anything that moves or auto-updates can be paused.

• Find long or complex forms difficult

  What we have done

  Checkout asks only for what it needs and carries forward anything you have already given. Errors say how to fix the problem rather than only flagging it. A review step before payment lets you check and change everything, and support sits in the same place on every page.

• Are deaf or hard of hearing

  What we have done

  No part of buying or selling through Fungies depends on hearing anything. Where we publish video, it carries captions.

An accessibility audit of fungies.io in September 2026 identified the limitations listed below. The seller dashboard, checkout and customer portal are also subject to continuing audit and remediation. We update this document when material findings or remediation status change.

• Some interactive elements can receive keyboard focus while being hidden from screen readers

  Who it affects

  Screen reader and keyboard users. Focus can land somewhere that is not announced.

  Status

  Fix in progress. This comes from one shared component and accounts for most of what we found.

• Some controls are nested inside other controls

  Who it affects

  Screen reader users, who may not be told correctly what a control does

  Status

  Fix in progress

• Some lists and definition lists are not correctly structured

  Who it affects

  Screen reader users, who lose the grouping and item counts

  Status

  Fix in progress

• One embedded frame has no accessible name

  Who it affects

  Screen reader users, who are not told what the frame contains

  Status

  Fix in progress

• One component uses an ARIA role without its required structure

  Who it affects

  Screen reader users, who may hear it described incorrectly

  Status

  Fix in progress

Our audit of the seller dashboard, checkout and customer portal is under way. We will update this page with relevant findings and progress as the audit continues.

Issue tracking and remediation are part of the accessibility monitoring process. Each confirmed issue is assigned an owner, a priority and a remediation status. Fixes are verified through appropriate automated and manual testing before being treated as closed.

The service is designed to work with recent versions of common assistive technologies and browsers. The combinations tested are listed below. Fungies requires JavaScript for checkout and the dashboard. Internet Explorer is not supported, and browsers more than two major versions out of date may not display all functionality correctly.

• NVDA

  Browser

  Firefox

  Platform

  Windows

• JAWS

  Browser

  Chrome

  Platform

  Windows

• VoiceOver

  Browser

  Safari

  Platform

  macOS and iOS

• TalkBack

  Browser

  Chrome

  Platform

  Android

• Keyboard only, no mouse

  Browser

  Any supported browser

  Platform

  All

• Browser zoom to 400%

  Browser

  Any supported browser

  Platform

  Desktop

• Speech recognition, such as Dragon or Voice Control

  Browser

  Any supported browser

  Platform

  All

When you embed our checkout in your own store, accessibility is shared between the Fungies service and the page into which it is embedded. Fungies is responsible for the checkout itself, including its markup, keyboard and focus behaviour, field labels, error messages and default colours and contrast. The seller is responsible for the surrounding page, including its heading structure and landmarks, the control that opens the overlay, and any colours or branding introduced by the seller.

Accessibility requirements may also apply to the seller’s own store. This document does not determine the seller’s separate legal obligations. Three things are worth knowing if accessibility matters to your own business.

• Custom colours can break contrast. If you restyle checkout, check your text still meets 4.5:1 against its background. Pale text on a pale background is a conformance failure even though every feature you used is supported.
• Use a real button to open the overlay. If the trigger in your page is not a focusable button, keyboard users cannot open checkout at all, no matter how accessible the checkout is.
• You may have your own obligations. If you sell to consumers in the EU, accessibility requirements may apply to your store. Consider seeking legal advice on how they apply to your business.

The service is designed and tested for perceivability, operability, understandability and compatibility. In addition, for the electronic commerce service, Fungies addresses accessibility of identification, security and payment functions that form part of the service. These functions are tested as part of checkout and related user journeys.

Accessibility is considered in product development and release work. The monitoring process combines automated accessibility scanning, manual keyboard testing, screen-reader testing, zoom and reflow testing, and contrast checks. The main user journeys tested include account and seller workflows, publishing a product and completing a purchase. Findings are recorded, prioritised and assigned for remediation. Significant service changes and changes in accessibility requirements trigger a review of the relevant accessibility controls and tests.

Where a defect means that the service does not meet an applicable accessibility requirement, Fungies takes corrective action necessary to restore conformity. Where a known limitation remains, this document is updated with the limitation and its remediation status. Accessibility information and monitoring records are retained for as long as the service remains offered, subject to applicable legal requirements.

A consumer may submit a formal complaint about failure to ensure accessibility requirements for the Fungies service. A complaint may be sent in writing, by post, to an electronic-delivery address designated for that purpose, orally by telephone or in person for the record, or electronically using a communication method designated by Fungies. Our contact details are:

• Email: support@fungies.io
• Post: FUNGIES EUROPE PSA, Al. Jerozolimskie 109 / 70, 02-011 Warszawa, Poland

To be treated as a formal complaint, the complaint should include:

1. the consumer’s name and surname;
2. a correspondence address, email address or telephone number, together with the preferred contact method;
3. the service to which the complaint relates; and
4. the accessibility requirement that the service does not meet, together with a request that Fungies ensure compliance.

The consumer may also indicate a preferred way of ensuring accessibility.

• We confirm we have received your report

  When

  Within 2 working days

• We give you an assessment, and either a fix date or a workaround

  When

  Within 10 working days

• If the problem stops you completing a purchase, we prioritise it

  When

  Treated as urgent

In a particularly complex case that prevents a response within the aforementioned deadlines, Fungies will notify the consumer within that period of the reason for the delay and provide a new deadline of no more than 60 days from receipt of the complaint.

Please note that even if your complaint does not meet the formal complaint criteria, we will do our best to address the matter in a similar way to a formal complaint and within the deadlines set out above.

The response to a formal complaint will state the outcome. If the complaint is rejected, the response will include factual and legal reasons. If the complaint is accepted, the response will specify the implementation deadline, which may not exceed 6 months from the date of the response. The response will also identify the authorised person who issued it by name, surname and position. Where a complaint is rejected, the response will include the information concerning any available appeal route, amicable dispute-resolution options where applicable, and the possibility of notifying the competent market-surveillance authority of non-compliance.

If a formal complaint is rejected, consumers may use the notification route referred to in Article 37(6)(3) of PAD, in accordance with the applicable procedure.

We use automated and manual testing together, because automated tools find only about a third of accessibility problems.

• Automated scanning against WCAG 2.2 Level AA, run as part of our development process so regressions are caught before release
• Manual keyboard testing of our main journeys: signing up, publishing a product, and completing a purchase
• Screen reader testing on the combinations listed above
• Zoom and reflow testing up to 400%
• Contrast checking across our design system rather than page by page, so a fix applies everywhere at once

We review this statement at least once a year, and whenever we redesign a significant part of the service. We update it when we fix something listed here, and when we find something new.

This document is an accessibility information and complaint document; it does not replace the service terms, privacy notice or other consumer information required by applicable law.