Polish law on ensuring that certain products and services meet accessibility requirements (Dziennik Ustaw 2024, item 731, Sejm ISAP, opened 29.08.2026) covers electronic commerce services, and it has applied since 28 June 2025. For a restaurant that has a narrow, practical meaning: the part of your site through which a guest completes an order is a service in the sense of that act. The decorative part of the site is not the subject of this page at all.
This page holds two things: what is covered and what the ordering path has to survive. It does not print the designation of a technical standard, because the act does not contain one -- that absence was measured, not assumed. It does not print a fine in money either, because the act sets the fine by a formula tied to an indicator that changes every year.
Electronic commerce service — a category named in the act. The act defines it as a service offered or provided at a distance through websites and mobile devices, at the individual request of a consumer, with a view to concluding a contract. Ordering and paying online fall inside it. A page that only shows your address and opening hours does not, by itself.
Application date — 28 June 2025. It is written into the act, in the article that puts the act into force. The requirement is not a future one, and that single fact changes the tone of every conversation with a supplier.
Micro-enterprise exemption — the act says its provisions do not apply to services offered or provided by micro-enterprises. The exemption is real, it is one line, and it is not a matter of how small the owner feels the business is.
Ordering path — the sequence of screens from choosing a dish to a confirmed order. Accessibility is measured along the whole path: nine accessible screens out of ten produce an inaccessible order. That is why this page keeps saying "path" and not "site".
Harmonised standard — a technical measure the act points to rather than writes out. It defines the term by reference to European regulation 1025/2012 and grants a presumption of conformity to whoever follows such standards. The measure lives in the standard; the act names only the mechanism.
Online ordering is an electronic commerce service, and the act names it
The scope article lists the services the act applies to, and electronic commerce -- "handlu elektronicznego" in the original list -- is one of them. That article opens with a phrase mattering as much as the list: the provisions apply to services offered or provided to consumers. A business-to-business ordering panel for your suppliers is a different animal; a guest ordering dinner is the addressee the act had in mind.
The definition article then explains what the category means: services offered or provided at a distance, through websites and mobile devices, at the individual request of the consumer and with a view to concluding a contract. Read that definition against your own site honestly. A menu page with a phone number is information. A basket, a delivery-address field, a time slot and a payment button are a service.
Two consequences follow, and both are usually missed. The act reaches your mobile application if you have one, because the definition names mobile devices next to websites. And it reaches a service you did not build: if ordering happens inside a widget embedded from an outside supplier, the service is still offered by you, to your consumer, on your page. Who wrote the code is a question for your contract, not for the act.
The date the requirement started is written into the act itself
The act ends with an article that puts it into force on 28 June 2025, with a short list of provisions that started earlier. The most common mistake in this area is a tense error: treating an applicable requirement as a plan for next year. There are two dated reliefs in the act, and neither of them moves that date.
The first relief concerns contracts. Service contracts concluded before the act entered into force may continue unchanged until they expire, but no longer than 28 June 2030. Until that date a provider may also continue using products it was already using before, even if those products are not accessible. This is a transition for equipment and paperwork, not a five-year holiday from the requirement.
The second relief concerns old content. The act does not apply to pre-recorded media published before it entered into force, to document files published before that day, or to archived content that has not been updated or edited since. That last condition is the one that quietly expires: the moment you edit an archived page, it stops being archived content.
Who the act takes out of scope, and why that is not "all small businesses"
The exclusions article states that the provisions do not apply to services offered or provided by micro-enterprises. A genuine exemption, worth checking against your own case before spending anything.
Here is the measured detail that changes how you check it. The definitions article contains thirty-eight definitions, counted one by one, and the term "micro-enterprise" is not among them. The act uses the word without defining it, so the criteria live in general Polish business law, outside this act. This page prints no article number for that other law: the number was not measured here, and a plausible number is worse than none.
What this means in practice:
- the test is arithmetic -- headcount and financial thresholds -- and not a feeling about the size of the business;
- the test is applied to the enterprise, not to the restaurant as a room;
- a group of establishments under one company can pass the size test as separate rooms and fail it as one enterprise;
- the answer can change from one year to the next, in both directions, and nobody sends you a letter when it does.
And the exemption removes the legal obligation, not the guest who cannot finish the order. If a share of your delivery revenue arrives from people using a screen reader, a keyboard, or an enlarged text size, that share is lost by a broken path on either side of the exemption. The commercial half of the same subject is on the page about what stays with you in online ordering, and the operational half is in the article on online orders for restaurants.
What has to be accessible: not "the website", but the path to a completed order
The act sets general requirements for services and then adds a short list of extra requirements for electronic commerce specifically.
The general requirements: information about how the service works must be available through more than one sensory channel; text has to be presented in formats that assistive technology can read; the size and shape of the typeface, the contrast and the line spacing have to be adequate; anything that is not text needs an alternative. A separate item covers websites and mobile applications, requiring them to be perceivable, operable, understandable and compatible.
The additional requirements for electronic commerce are two: information about the accessibility of the products and services offered has to be provided, and the identification of the parties, security, payments and electronic signature have to work too. The moment where money and identity change hands is inside the requirement, not only the browsing part.
For a restaurant that is a path, not a page:
- find the menu;
- read what a dish contains;
- put it in the basket and change the quantity;
- choose delivery or collection and a time;
- enter an address and a phone number;
- read the total, including delivery cost;
- pay;
- receive a confirmation that can be read, not only seen.
Each of those eight steps is a place where the path can end -- which is why the formula below multiplies instead of averaging.
Five places that break first: contrast, focus, labels, session time, errors
The table below is not a standard. It is the short list of failures that show up first on restaurant ordering paths, with the check that catches each of them in under a minute.
| Place | How it breaks | Who it cuts off | One-minute check |
|---|---|---|---|
| Contrast | Light grey price on white, brand colour as the only signal of an active button | Anyone in daylight; low vision; older guests | Turn the screen brightness down by half and read the price of one dish out loud |
| Keyboard focus | The outline around the focused element is styled away, so you cannot see where you are | Keyboard and screen reader users; anyone with a trembling hand | Press Tab ten times, saying out loud where you are on each press |
| Field labels | The label exists only as placeholder text and vanishes when typing starts | Screen reader users; anyone interrupted mid-form | Click into the address field, start typing, check it still says what it wants |
| Session time | The basket or the delivery slot expires silently after a few minutes | Anyone who types slowly, checks the address, or answers the door | Fill the basket, leave the tab for ten minutes, come back and try to pay |
| Error messages | A red border with no text, or text far from the field it belongs to | Screen reader users; colour-blind guests; everyone in a hurry | Submit the form empty and see whether the reason reads as words |
A menu published as a picture is the most common way to cut guests off
A photographed or exported menu is convenient exactly once, at the moment of publishing. After that it is a wall: no text assistive technology can read, none a browser can enlarge, none a search engine can index, none a guest can paste into a translator.
The share formula above puts a number on it, and the number is brutal by design: a menu that exists only as a picture scores zero however many dishes it contains, because there is no partial reading.
This is also where accessibility and information duties overlap. Composition information -- what is in a dish -- carries its own separate obligations, and a picture defeats them in the same motion. That subject has its own page on allergen information in the menu. The same content, seen from the visibility side rather than the legal side, is covered in the article on restaurant data in Google, on the site and on portals; a menu that machines cannot read is invisible to more than one audience at once, which is why the page on search visibility treats readable text as a precondition rather than an optimisation.
A booking widget from an outside supplier: whose responsibility is it
The act puts the conformity assessment of a service on the service provider. It also requires that the terms of service, or an equivalent document, publicly state how the service meets the accessibility requirements, and that the provider keeps an eye on changes to the service, to the requirements, and to the harmonised standards. If the service turns out not to comply, the provider has to take corrective action and to notify the supervisory authority.
Notice what is missing from that description: the supplier who wrote the widget. Your guest sees one path, with your name on it.
| Part | Who builds it | Who answers for it | What to put in the contract |
|---|---|---|---|
| Your own pages: menu, contact, delivery zone | Your web supplier | You | Accessibility as an acceptance criterion, not an extra |
| Embedded booking or ordering widget | Outside platform | You, as provider of the service | A written accessibility statement from the platform, and a right to leave without it |
| Payment step | Payment provider | You, for its being reachable and usable inside your path | Confirmation that the payment screens are inside the platform accessibility commitment |
| Menu content: dishes, prices, composition | Your kitchen and manager | You | Menu supplied as text, never as an exported picture |
| Confirmation email and message | Whichever system sends them | You | Plain-text alternative, not only a designed template |
The practical version of that table is one sentence. Before signing anything, ask the platform in writing how its product meets the accessibility requirements for electronic commerce services under Polish law. An answer that names the mechanism is a partner; "our product is modern and responsive" is a supplier who has not read the act, and you will be the one carrying it.
The same applies to the tools around the order rather than inside it. A form that collects inquiries, a booking flow and a chat assistant are all part of the path a guest walks: see inquiry forms, taking and managing bookings and a text assistant on the site. Ask each of them the same thing, in the contract rather than in a later argument.
Harmonised standards: where the measure of accessibility comes from
This is the part where most articles on this subject start inventing, so here is the measured statement instead.
The act does not contain the designation of any technical accessibility standard. That is not an impression: the full text was searched, and the strings people expect there -- the European standard designation, the web content guidelines abbreviation, the standards body name -- appear zero times. What the act contains is a mechanism. It defines a harmonised standard by reference to European regulation 1025/2012, grants a presumption of conformity to a service that follows such standards, and requires the documentation to list which ones were applied.
The measure exists, and the act deliberately does not freeze it into its own text: an act quoting a version number would be obsolete the day that standard was revised.
For an owner, the practical consequence is one sentence for the brief: name, in writing, which harmonised standards the work claims to follow, and keep that statement with the documentation. A supplier who cannot name what they measured against has not measured anything. That is all this page says about the technical measure, because that is all the act says.
How to check your own ordering path in twenty minutes without special equipment
You do not need software to find the first failure. A keyboard is enough.
The keyboard run
Open your own site and put the mouse physically out of reach -- the reflex is stronger than the intention. Complete an order using only Tab, Shift+Tab, Enter, Space and the arrow keys. Write down the first step where you get stuck: where you cannot see what is focused, cannot open the dish options, cannot change the quantity, cannot reach the payment button. That step is your result; everything after it is untested, because a guest never got there either.
The enlargement run
Reload and set the browser text size to 200 %. Walk the same path, looking for text hidden behind other text, buttons sliding out of the visible area and prices cut in half. Then narrow the window to phone width and repeat.
The reading run
Turn on the screen reader already installed on your machine -- every desktop and every phone ships with one. You do not need to be fluent in it. Three answers are enough: does it say what each form field is for, does it read the price and the delivery cost, does it read the confirmation.
Writing the result down so it survives
Record what you did, on what date, on what device, and where the run stopped. That record is the beginning of the documentation the act expects to exist, and it turns a vague complaint to a supplier into a specific one. A run nobody wrote down gets repeated from scratch in six months.
Two measures that refuse to flatter you
The first formula is a product on purpose.
Ordering path accessibility = a1 x a2 x ... x an
where each ai = 1 if step i can be completed with a keyboard and with a screen reader, 0 otherwiseDimension: dimensionless, since every factor is dimensionless. Worked example: an eight-step path where seven steps pass and the payment button cannot be reached by keyboard gives 1 x 1 x 1 x 1 x 1 x 1 x 1 x 0 = 0. The average of the same eight values would be 0.875, which reads like a good result and describes an order that cannot be placed. That gap between 0 and 0.875 is the entire reason the measure multiplies.
The second formula is a share.
Share of menu items readable as text = items available as text / total itemsDimension: items divided by items, so a dimensionless share between 0 and 1. An item existing only inside a picture or an exported document does not count in the numerator. Worked example: 60 dishes, of which 45 are on the page as text and 15 live only inside a photographed lunch board, scores 45 / 60 = 0.75. A menu that is one single image scores 0.00 however large it is -- the count check that keeps this formula honest.
What to put in the contract so you do not pay twice
Accessibility retrofitted into a finished site is expensive for a boring reason: the failures sit in the structure, and the structure is the last thing anybody wants to reopen. Written into the brief at the start, it is close to free. The clauses that change the outcome:
- Acceptance is measured on a path, not on a page. The deliverable is a completed order using only a keyboard, not a set of screens that look right.
- The supplier names the harmonised standards or technical specifications applied, in writing, in the handover documentation.
- Menu content is supplied as text. Pictures of menus are refused at acceptance, not discussed later.
- Third-party components carry their own written statement. If a booking or payment widget cannot produce one, that is a reason to pick another, and the contract says so before the integration is built.
- Changes are re-checked. The act expects the assessment to be reviewed when the service changes; the contract says who does that, when and at whose cost.
The clause everybody forgets
Add a sentence about who fixes an accessibility defect found after handover, and within what time. Without it every defect becomes a negotiation, and negotiations are slower than repairs. Writing supplier obligations down -- for tills, accounting and stock -- is the subject of connecting systems together; the obligation is yours, so the specification has to be yours too.
Who supervises this, and how non-compliance ends
Supervision is split between several authorities, and for electronic commerce services the act names the minister responsible for computerisation. Useful to know before someone tells you it belongs elsewhere.
There is also a route that starts with your guest. A consumer has the right to complain to the business about a failure to ensure accessibility. The complaint has required content: who is complaining, how to contact them, which service is meant, and which requirement was not met, together with a demand to meet it. A complaint missing those elements is left without examination.
The timings are the part worth memorising, because they are short:
- an answer is due within 30 days of receiving the complaint;
- in particularly complicated cases the business must notify the delay and give a new date, no later than 60 days;
- missing the deadline means the complaint is treated as accepted in line with what the consumer demanded, and the demand then has to be met within no more than 6 months, the same ceiling that applies when a complaint is accepted outright.
That third point deserves a second reading: silence is not a defence here, it is a decision against you made on your behalf.
The financial sanction is a formula, not an amount
The act provides for a financial penalty on a service provider -- among other cases, for failing to ensure the accessibility of services, for failing to carry out the conformity assessment, and for failing to notify a non-compliance.
This page prints the formula and does not substitute a number into it: the multiplier applies to an indicator republished every year, so any amount in money written here would already be wrong when read, and a confidently wrong figure is worse than an honest formula. The size is then set with regard to the extent of the infringement, its gravity, the number of products or services concerned, and the number of people adversely affected; the penalty is payable within 14 days of the decision becoming final, into a state accessibility fund named in the act.
One more clause closes the most popular escape route. The act does allow a business to argue that a requirement would fundamentally alter the service or impose a disproportionate burden -- assessed by the business itself against three cost criteria, documented, kept for five years, notified in writing to the supervisory authority, and repeated at least every five years or whenever the service changes. And it does not apply at all where external funding was obtained for that very requirement.
Frequently asked questions
Does the Polish accessibility act cover restaurant online ordering?
Yes, where ordering is genuinely a service offered to consumers at a distance. The act lists electronic commerce among the services it applies to, and defines that category as services offered at a distance through websites and mobile devices at the consumer request, with a view to concluding a contract. An informational page with a phone number is not that; a basket, a delivery slot and a payment step are.
Since when has the requirement applied?
Since 28 June 2025, the date written into the article that puts the act into force. Two transitional reliefs exist -- contracts signed before that day may run unchanged until they expire, but no later than 28 June 2030, and old published media, document files and untouched archived content stay outside the act -- but neither postpones the date itself.
Are small restaurants exempt from it?
The act says its provisions do not apply to services offered by micro-enterprises, so an exemption exists. What the act does not do is define the term: its definitions article holds thirty-eight definitions and this is not one of them, so the criteria come from general business law outside this act. Check your numbers, not your impression, and re-check when the business grows.
Is a menu published as an image acceptable?
Not as the only version. A picture holds no text to read aloud, to enlarge or to translate, so every dish inside it is unreachable for part of your customers. Publish the menu as text; a picture may sit alongside it, never instead of it. The same choice decides whether composition information reaches the guest at all.
Who is responsible for a third-party booking widget?
You are, as the provider of the service, whatever the widget origin. The act puts the conformity assessment on the service provider and requires the terms of service, or an equivalent document, to state publicly how the service meets the requirements. The supplier role is contractual: ask for a written accessibility statement before integration, and make its absence a reason not to integrate.
What breaks accessibility first on a restaurant site?
Five things: contrast too low to read a price, an invisible keyboard focus, labels that exist only as placeholder text, a basket or delivery slot that expires silently, and error messages that are colour without words. Each is checkable in about a minute, and each can end the path on its own.
How can I check my own ordering path in twenty minutes?
Move the mouse out of reach and complete a real order with the keyboard alone; write down the first step where you get stuck. Repeat with the browser text size at 200 % and at phone width. Then run it once with the screen reader already on your device, listening for the fields, the total and the confirmation. Three runs and one page of notes.
What to do with this today
Walk your own ordering path using only the keyboard, from choosing a dish to the confirmation screen. The first step where you get stuck sets the whole path to zero -- and it is usually the step that takes about an hour to repair. Once you know which step it is, the rest of the work has an order and a price.
The neighbouring obligations meet the same path from other directions: consent to contact and call recording covers the same booking form from the data side, cash acceptance and price display covers showing the price as a duty rather than a design choice, and an AI restaurant management system describes where the online channel lives once it works. The rest of the material sits in the restaurant section.
On the operational side: why customers do not leave inquiries shows how many silences are structural rather than commercial, restaurant automation for reservations, suppliers and reviews places the ordering path among the other flows, and one queue for inquiries instead of five explains why a complaint due in 30 days should not arrive into five different inboxes.