Wiktor Wiśniewski: store accessibility after the EAA – complaints, penalties and WCAG audits in practice
Audits, penalties, processes – what do you need to know about them?
Episode in Polish, English subtitles available. Below: an edited English translation of the full conversation.
Wiktor Wiśniewski, at the time of recording a digital accessibility expert at wecanfly, talks to Maciek Czerniak about what an online store has to do after 28 June 2025, when Poland's law implementing the European Accessibility Act (EAA) started to apply. He explains what WCAG audits look like (in his projects about 25% of 2,000–4,000 tests fail on the first pass), what sanctions PFRON, the Polish regulator, can impose, how to handle complaints and what to publish on the site, and what a US accessibility case taught him. The episode is for e-commerce owners and managers who want to bring their store in line with the rules without overspending. We checked the facts about the law against its text and add the state as of October 2026 in the takeaways.
Key takeaways
- The rules cover consumer services listed in Poland's Act of 26 April 2024 on accessibility requirements for certain products and services (in force since 28 June 2025): e-commerce, retail banking and services accompanying passenger transport, as well as telecoms, access to audiovisual media services and e-books. Services provided by microenterprises (fewer than 10 employees and up to EUR 2 million in turnover or balance sheet total) are exempt. Wiktor warns companies near the threshold: one good December or one new hire can change their status. (28:35, 29:06)
- The fine is up to ten times the previous year's average monthly salary in Poland, but no more than 10% of turnover (Art. 73); in 2025 the cap was about PLN 81,800, while Wiktor mentions PLN 70,000–80,000. More serious than the fine is a PFRON order to fix the issues within up to 120 days and a ban on providing the service for up to 180 days (Art. 62), so "we'll just pay the fine" is not a strategy. State as of October 2026: the public sources we checked (the text of the act, PFRON materials) contain no information about fines imposed on online stores. (11:25)
- A store needs its own reporting channel (a form, a dedicated email address), not just complaints submitted in person or by post. The act gives 30 days to reply to a complaint (up to 60 days in complex cases, after notifying the customer); without a reply in time, the complaint is deemed accepted and the request has to be met within 6 months (Art. 37). A customer whose issue isn't resolved can notify the President of PFRON. (23:36)
- On the site, state the supported browsers and screen readers (Chrome on desktop and on mobile are separate sets of bugs; better to support one "duo" well than nothing), the date of the latest audit and a roadmap of fixes that actually changes. A note on the conversation: the act requires the service provider to assess the service's conformity and to publish information on how the service meets the accessibility requirements (Art. 32), and PFRON can request information within a deadline it sets (the conversation mentions 60 days). The name "accessibility statement" comes from the rules for public bodies. (23:36, 26:13, 27:23)
- Audit scale: WCAG 2.1 at level AA (50 success criteria; "I think 51" in the conversation) means, in Wiktor's projects, 800–1,000 tests per page and 2,000–4,000 tests for 20–40 unique features, of which about 25% fail. Fixing contrast once removes about 5% of errors, while a single bug can take a week. (5:05, 7:37)
- From a US case: a demand letter full of generalities, a paid audit costing "as much as a car", screen readers set up in a non-standard way and niche browsers. In Wiktor's view a 100% accessible site is almost impossible (he hasn't seen such a store yet), so what counts is company policy, a response process and transparency: the Polish act allows a requirement not to be met where it would be a disproportionate burden (Art. 21), but this has to be assessed and justified. (13:52, 17:42, 18:28, 20:17, 21:58)
- AI helps: in one of Wiktor's projects, alt text was added to 400 customer review photos with a single click (to be checked by a person), and an n8n script searches weekly for overly generic links such as "View all". A new area is Instagram Stories-style video under the "Buy now" button, which needs transcripts and audio description. To get started, Wiktor advises communicating that the store responds to reports and auditing the menu and hero banner yourself. To find out where your store loses customers, including people with disabilities, see our Shopify UX and usability audit. (33:36, 35:14, 39:21, 41:01)
Guest
At the time of recording, Wiktor Wiśniewski was a Senior Full-Stack Developer and digital accessibility expert at wecanfly and mohi.to, running WCAG audits and implementing accessibility in Shopify stores. This is his second episode on accessibility in our podcast. Wiktor on LinkedIn.
Host
Maciek Czerniak is a co-founder of wecanfly, a Shopify Premier Partner agency that helps established brands with complex migrations to Shopify Plus.
How AI-driven search is changing store traffic, and how to prepare a store for it, is covered in our article Agentic commerce and GEO: how to prepare your store for AI-driven sales.
Transcript
This transcript is based on the recording of this episode. We edited it for readability: we corrected transcription errors, punctuation, and merged sentences that were cut off mid-flow. We did not change the content, order, or meaning of anything said. Any errors or inaccuracies are our responsibility alone — not our guests'. If you spot something that needs correcting, email us.
Episode recorded in Polish a few days after 28 June 2025, when Poland's law implementing the European Accessibility Act started to apply (released 29 July 2025); the teaser and the conference announcement at the start of the video are not repeated here.
What changed after 28 June 2025?
Maciek: Wiktor Wiśniewski. Welcome to our little podcast for the second time. Good morning.
Wiktor: Good morning.
Maciek: I don't know if you know, Wiktor, but your previous episode was our number one until recently, and is now number two, but it's still one of our most-watched episodes.
Wiktor: Which is a big surprise to me, because I thought the common view was that digital accessibility is a terribly boring topic, so I didn't expect to cause a stir with it. And yet here we are: the topic is alive, and given recent events it has come even more alive. We'll see how it goes.
Maciek: And it has come alive because, as of a few days ago, maybe a few weeks by the time we publish this, that is since 28 June, we have a new law in force. So it would be good to talk about what we've learned and found out in that time. Has a wave of lawsuits started, of customers raising the issue? Where would we like to start?
Wiktor: We can start with what's been happening in our own backyard, because on the other continent, the American one, I'd say it's business as usual. The lawyers are running wild. I recently even had the chance to see what it looks like at the level of communication between the two parties. There were a few surprises…
Maciek: You were asked in by the client as an expert.
Wiktor: Yes. A classic case: there's an injured party, there's a company that also has a physical store, and we have to settle it. I think we'll start with what's been going on here, because a lot has been going on here too. These are two separate continents, two separate approaches to the law, and that affects how we approach accessibility, how we communicate with the client, how we build our policy around it. So let's start with how it's done here, and then we'll look at how it's done in a market full of sharks and dangers.
What do accessibility audits look like?
Maciek: All right, let's start with our home market, then. We already have the first projects delivered, the first accessible websites. Can you tell us a bit about what these audits look like?
Wiktor: Yes. Audits look a bit different every time, because clients have different needs. Sometimes there's more than one subcontractor on a project and everything has to be brought together. If I don't have direct contact with that subcontractor and I want to pass on as much knowledge and as many comments as possible, the audit is richer in content. It also takes a bit more time, and I try to cover the topic as fully as possible, so that whoever reads it later won't have questions. It's different on projects where we're the only ones. Then the audits are a bit more simplified, we can take shortcuts. Those are audits strictly for internal, project use. Audits that are later published to the world look a bit different again. Their structure differs from the PFRON audits, PFRON being the State Fund for Rehabilitation of Disabled Persons, which will supervise and enforce everything here in Poland. It can also ask for these audits, or challenge them. PFRON started a project two years ago: they're working on a market surveillance system, as part of which they train people. They employ, if I remember correctly, 210 people, and the project adds another 23 full-time posts, if I understand it right. The whole project is worth 30 million zloty, so they'll be checking these audits carefully. Each of these audits has a slightly different structure, a different purpose, communicates things differently. So, to answer the original question of what the audit will look like: it depends.
How many violations does a typical WCAG audit find?
Maciek: OK, and as for the audits you already have under your belt: if you could average it out, without pointing a finger at any particular brand, what scale of violations are we talking about?
Wiktor: WCAG at level AA, version 2.1, because there are several versions, has 51 or 53 criteria. I think 51. If I split pages into sections, I get on average 800–1,000 tests per page. If a site has 200 subpages, we don't test all of them, only the unique components, because various sections repeat. We're not going to test the same thing over and over. Usually a platform has around 20, 30, 40 different features. That gives us 2,000, 3,000, 4,000 tests, of which 25% fail at that stage of testing. It may turn out that once we start fixing things, more issues appear that weren't visible before. So there's quite a lot. I should also point out that errors like contrast you fix once and about 5% disappear in one go. But there can be that one bug that takes you a whole week of work. So it depends.
One broken button or "screen readers don't work": what complaints look like
Maciek: It depends. All right. By the way, I think PFRON should hire someone who knows how to run a few thousand tests, because every violation carries a penalty, right?
Wiktor: That's a good question, and it opens up the topic of complaints. Because if I'm a customer, I can in theory tell PFRON or the brand that they have an error in this specific place, that something under this specific button doesn't work. But I can also say that screen readers don't work on the site. And what then? In the two cases the scale of fixes is completely different. The question is whether we'll all look at these abuses the same way. In the American market, the client gets a big email full of generalities. They don't specify what exactly is wrong. If you want to know, you have to order an audit from them, which, by the way, isn't cheap: it's a fairly large sum, you could easily buy a car with it. That's how it works there: you have to deal with the complaint and fix it within a set time. How it will look in practice here is a question mark. I wouldn't like to bring politics into it, but I have to: different heads of institutions, different parties will probably enforce these laws differently. A law is a tool, and it can be used for a just cause or oppressively.
What penalties apply for a lack of accessibility?
Maciek: OK, before we move on to the American continent, I'm still interested in these penalties. I'm trying to work it out in my head, assuming I might be penalised for a few thousand, a few hundred or a few dozen violations. Do we know the maximum penalty?
Wiktor: The maximum is 10% of the previous year's turnover, but not more than 10 average salaries. Here in Poland that's currently around 70,000–80,000 zloty. That's the upper limit, though. And now the question is whether these penalties can recur. Let's look at a single case. There's a penalty, and it might be tempting, when we ask our team for an estimate of how long the fix will take and they say too long, to conclude that it makes more financial sense to pay the penalty, despite the reputational damage and so on, because it can also make the news. It varies. But the law provides for various sanctions. Above all, PFRON can order the errors to be fixed within 120 days, and if not, they can in theory block the service for 180 days, which for an online store would often mean the end of the business. I wouldn't count on paying the penalty and everything being fine. That doesn't work everywhere.
Maciek: So far there have been no cases of such a penalty actually being enforced.
Wiktor: And that brings us back to how they'll use this law.
What does an accessibility case look like in the US?
Maciek: Of course, we're not encouraging anyone to pay penalties and leave accessibility to itself. I wouldn't treat that as an option. We've talked a bit about the benefits of implementing accessibility on a site. Apart from reputation, we said it's simply good business to take care of people who have various limitations or disabilities. Could we move on now to that case, because I think it's really interesting how it works in the States. Tell us a bit about it, as far as you can share the details, of course.
Wiktor: At first it really outraged me, because when we talk about digital accessibility, we're driven by lofty moral goals: we want to help people get rid of barriers. But this particular case showed me the dark side of capitalism, because the whole process of reporting errors is designed to tell you as little as possible and point out as many problems as possible with those generalities I mentioned earlier. The complaint that lands on your desk is meant to be overwhelming. You're not supposed to understand it. Ideally, you shouldn't manage to deal with it in the time given at all. Detailed attachments are thrown in too. We get a big wall of text made of generalities that you have to understand, and experience tells me most people don't, because it's packed with technicalities or terms very specific to accessibility. At the very end there are screenshots, videos, a clip of some moment of going through the site, captioned: here are your errors. How many errors are there? Can you tell? It's a bit like a spot-the-difference exercise from primary school. You go further, you dig in, you really try and want to understand. You see the screen reader reading various things, and at some point, instead of "minus 19%", it reads "19". And you think: an error, but this error makes no sense. That was the first unpleasant surprise: for these presentations they adjust the screen reader settings so that they behave in a non-standard way. You have to be able to tell whether it's an error on your side or someone deliberately set up the reader that way.
Maciek: And they don't give you any path for reproducing the error, either.
Wiktor: They do, but it costs money.
Maciek: OK.
Wiktor: It's a service. In theory I could say I understand them a bit, because time is money and someone has to sit there and reply to you.
Maciek: But at the same time they're holding a gun to your head, putting you up against the wall, burying you in tons of paperwork.
Wiktor: They say: if you don't know, then we'll tell you everything. We'll do a full audit of your entire site, and it'll be our audit, so we'll make sure you fix our findings, and you'll have peace of mind.
Maciek: But does that open up any option for us here?
Wiktor: I'll tell you, it's terribly outrageous, but it doesn't end there, because the injured party doesn't reach for one of the popular browsers like Chrome or Safari, they pick some niche one, because there are lots of them now. We have browsers that assist…
Maciek: We have Arc, for example, which was recently discontinued.
Wiktor: Yes, you put it well, discontinued. Easy come, easy go. But there are also browsers that get rid of ads but mine cryptocurrency. There are lots of them.
Maciek: They have a trace share of the market, but they exist.
Wiktor: Yes. So it's good to protect yourself against audits like that and say: we support only these screen readers and these browsers, and we'd like to support the rest, but we don't have the funds for it. Which is entirely true, because with so many on the market, instead of delivering projects we'd do nothing but sit and test different browsers. Let me remind you that some of these errors aren't because I as a developer did something wrong, there's simply a bug in the browser that will be fixed in the next version or isn't there in later versions. It's software, it's allowed not to work.
Maciek: The library you use may be…
Wiktor: Yes. That leads us to the next conclusion: creating a 100% accessible website is, in fact, either incredibly hard or impossible. At least with the current standards. Someone malicious might say you can build a site in plain HTML and it'll work. But many companies sell through aesthetics, through user experience. And yes, we can switch features off, simplify everything to the maximum, but the question is whether our business will survive that.
Maciek: OK.
Wiktor: So company policy is very important here: communicating that there are processes that respond to such incidents, such comments. You also need to open a communication channel so that people can report things at all. And you need to write what you're doing to make it better. Let's not kid ourselves, making a 100% accessible site is incredibly hard. I think the courts, in America or here, are aware of that, but the art is to run the case in a way that shows the company in the worst possible light.
Is there such a thing as a fully accessible online store?
Maciek: I see. I'm convinced that a 100% accessible site is probably some kind of Holy Grail. But in your research or in your work, have you come across sites you could confidently say are accessible and well made in that respect?
Wiktor: No. I haven't yet seen an online store that was 100% accessible. Although there are companies where you can see they're really trying. I think an interesting example for me is Apple. I'm not saying every page of theirs is fully accessible. They too put aesthetics somewhat above accessibility, I'd even say often much more so. Recently there was that interface with the glass elements. We were all holding our heads, wondering how that could get through. But OK. Still, when you go through some of their pages and look into the details, you can see there's someone there who's really trying. And that's interesting. There were also a few examples on Samsung's site, but I've seen a great many stores and I haven't yet seen one anywhere that was 100%.
Maciek: OK.
Wiktor: And these are certainly companies that are constantly exposed to various lawsuits. So that leads me to two assumptions. The first is that they have very good lawyers. […]
Are government and institutional websites accessible?
Maciek: I'm curious whether all the government and institutional websites will be accessible.
Wiktor: They aren't. Here in Poland they aren't. We have, for example, a criterion that says you shouldn't use text in images.
Maciek: You know what we have to do? We have to check PFRON's website. That's the first thing we'll do.
Wiktor: I once maliciously checked one of the institutions that are supposed to supervise the market. Several are listed, each responsible for a given sector. Let me put it this way: I had comments. But, for example, if you go to the website of ZUS, the Polish Social Insurance Institution, and open its accessibility statement, they have an internal audit there. It's published, and in that audit they write that certain modules aren't digitally accessible. And that's the right approach. The audit that's published to the world also explains why something isn't accessible. Something may be inaccessible because of technological limitations. Something may be inaccessible because there's no budget for it, and the law allows for a scenario where something is a disproportionate cost. So it's good to be transparent. In the American market, that transparency affects how you'll be treated in a potential dispute. There, though, the disproportionate-cost argument is harder to use.
What can a store do right now?
Maciek: OK. You mentioned the accessibility statement. Could we talk a bit more about what merchants, e-commerce owners, can do already now? It seems to me the statement is only the first thing.
Wiktor: Yes. I always recommend that everyone thinks it through, maybe before we get to the design part. First, you need to set up some form, a dedicated email address, where people who have accessibility concerns can report them. If we don't have such a contact form, an alternative form can be found on PFRON's website, and I wouldn't wish on anyone users who choose that route. It's better to try to resolve the issue between yourselves first. Of course this is regulated too. I recently saw that you have to respond to such a complaint within 30 days. If you don't respond, it's automatically accepted. There's also a period within which you have to fix it. You can't drag it out for two or three years and play dumb, saying you're working on it. That's the first thing. I've also seen on some websites, and in my opinion it misses the point, but some insist on it, that complaints can be submitted in person during opening hours or by post. I keep thinking about it, because imagine you want to attach a video or a photo to the complaint. What then? You go to the newsagent with a CD-ROM? It's a bit like a government office or a university where nobody has heard of email. Let's not go in that direction, I don't recommend it, because, as I said, there are alternative ways of reporting problems, and it serves no purpose. It even looks bad for your image, because it only highlights reluctance to take steps in this direction. So contact and communication are key. Next, the statement must say which browsers we support, so we don't end up in a situation where someone uses Internet Explorer and demands that everything works. And I've seen court cases from Poland documented online, this was 2019, where the court recognised Internet Explorer as a popular browser.
Maciek: Certainly in public administration.
Wiktor: Exactly. It's good to specify which browsers and which screen readers we support. Because if there are four or five leading screen readers, and we decide to support two browsers… Chrome on desktop and on mobile have to be treated separately, each has its own bugs. I've had cases where everything worked on desktop, and then I checked on a phone and it didn't. Add Safari to that and imagine how many different combinations you have to test. It's a lot. That's why it's good to say: this we support, this we try to support. And I'm not saying this to encourage companies to avoid working on accessibility, but so they don't fall into excessive costs they can't bear. It's better to support one duo than to support nothing and just try.
Maciek: Sure.
Wiktor: Next, the accessibility statement must include the date of the internal audit. It's good to do them. The law doesn't require it, but if PFRON comes and asks, we have 60 days. Let's not leave it to the last minute, let's prepare in advance. There must be a date. It would be good to include some kind of roadmap, meaning: we're aware of our errors and we're working on them. And it would be very good if that roadmap weren't there just for show, because there are sites that analyse page history, so if the same roadmap hangs there for two years, that's a signal it's a form of evasion. Those are the main things I'd recommend doing quickly, as far as the statement and what we want to tell the world are concerned.
Who do the new rules apply to?
Maciek: We forgot, or rather I forgot, one very important question. Do all entities, all companies fall under this law and these requirements?
Wiktor: No. Sectors are listed: e-commerce, banking, transport and, I think, one more that I've forgotten, but which doesn't concern us at all. The general rule is: if you provide a service, you're subject to these regulations. If you have a price list on your site, if people can order something from you online. And if you're not a microenterprise.
Maciek: Is a microenterprise defined here?
Wiktor: It's a company that employs up to 10 people and, I think, has up to 2 million euros in annual revenue. But I have to warn you: if someone is on that threshold, it may turn out they'll have one good month, December, or hire one more employee. In theory you could push everyone onto freelance contracts, but let's maybe not recommend that. And there's already a problem. So that's how it is. Questions also come up sometimes about whether a module that's closed to a selected group of users should be digitally accessible too. My answer: if someone built their platform on a component library, and the same components that are in the hidden part are also on the home page, it's hard for that module to be inaccessible. But if that situation does exist, you have to ask whether access to that area is for a very narrow, selected group of users, for example trade partners, or whether it's enough to register to get access. The directive and the law don't answer that question. If it were up to me, that's how I'd judge it, because if I can't get access somewhere, how can I test it? But on the other hand, if one of our trade partners has a disability and reports an issue, it would be better to deal with it.
Have the new rules changed design trends?
Maciek: Sure. I have one more question to wrap up. I'm wondering whether you've noticed these changes in the law affecting e-commerce trends in some way. Have you noticed designers becoming more aware?
Wiktor: I'd say awareness has recently started to grow, which is a very pleasant surprise, because I remember a year ago it was mostly testers banging the drum about it, though not only them. We did an episode too. Interest was low, even among employees. But now it's reached the point where it's even required in various job roles, so there's no getting around it. I'm noticing a very interesting trend: all newly created designs have high contrast. It's an interesting phenomenon. I'm not saying these designs are brilliant. My point is that there's a trend, a change, because in recent years grey moods dominated, Apple-style minimalism. And now we have this change, and it also ties in nicely with what's happening around artificial intelligence and search engines. I remember two or three years ago, when I worked on online stores, a large part of my time went on all sorts of landing pages. Stores were built around creating as much content as possible, because if you hit the right combination of keywords, the page would rank high in Google. Now people don't use Google, because, first, we have the summary at the very top, and if someone does use it, second, the first two links are ads, and the third and fourth, if anyone gets that far, are probably the monopolists. So that's the wrong direction.
AI and accessibility: reviews with photos and automated link checks
Maciek: Here's a curious fact for you: we've seen the first month in which the leads coming into our agency from tools like ChatGPT outnumbered enquiries from Google.
Wiktor: Yes. That's very nice and interesting, because the results ChatGPT suggests depend on whether these models judge a site to be authentic. What content appears on our pages, and where it appears, affects whether we show up in that chat. For example, a big trend now is sections with user reviews and user photos of a given product. Of course, customers upload photos of varying quality, but they still appear. And here I want to stress: that has to be digitally accessible too. I can't imagine photos uploaded by users not having alt text. But you can handle it in two ways. The first, recommended one, is to ask users to try to write these descriptions. Instagram has such an option; of course, people use it to varying degrees. And the second: the timing worked out nicely, because we have artificial intelligence and it can work. Recently we added descriptions to 400 photos with one click. Of course you have to check afterwards whether the descriptions are correct, but the quality is high enough that AI can even recognise the brand of a product without being given any context.
Maciek: Great case.
Wiktor: Which is truly amazing. While we're at it: AI can be used for a rough analysis of the state of accessibility. For example, I built myself a script in n8n, an automation tool, which finds all the links on a site and tries to answer a question I gave it: is this link too generic? Because overly generic links are also an accessibility problem. We can't have a link that says "View all", we have to change it to "View all products in this category". We need to know where the link leads, it can't be too vague. A sighted person can tell that the link refers to the product carousel next to it. But for someone using a screen reader it's not so obvious. Then we give the link an alternative name and it works much better. But if someone has 300, 400, 1,000 pages, go and find all those links. That's what we have this automation for. The problem with such solutions is that they're not deterministic algorithms, meaning ones that give the same result every time. The script runs once a week at night and in the morning sends an email saying there are such-and-such links to fix, and every week it reports something different. But it's already something, because experience tells me people don't really want to do this. These projects work well when you can throw a developer or designer at them, but then there's the content side, and there's no one left to do it.
Maciek: Especially at the scale we're talking about here.
Wiktor: Yes. Going back to the beginning, AI ties in nicely here. We have a lot of work to do on increasing the authenticity of content. Changes in e-commerce in general are happening and they're big. I'd say last year we even saw stagnation, at least from my perspective no revolutions were happening, and now FAQ sections are popping up on sites like mushrooms after rain. They're nice, because in them we ask a question someone might potentially ask ChatGPT, and we have the answer right away, and that answer is linked. Even better when it's on a product page, because there's already a "Buy now" button, right?
Maciek: Mhm.
Wiktor: Wonders like that are happening, and it's all connected: these changes are happening visually, but also on the technical side. You have to reach for completely different tools, different integrations. There are many dilemmas, because we're not going to build a reviews module from scratch, we reach for ready-made solutions. But will those ready-made solutions be digitally accessible? Can we do it better? How much will it cost? Lots of questions like that come up along the way, and we try to answer them.
New, less obvious areas: videos under the "Buy now" button
Maciek: OK, I said that would be the last question, but I have one more last question. In your recent projects or audits, have you come across any new, less obvious areas of accessibility? Obviously the website has to be accessible, probably the mobile app too, but maybe some other areas as well?
Wiktor: Yes. An interesting area that has started appearing on product pages is an Instagram Stories-style component. Under the button you have…
Maciek: Right.
Wiktor: Under the "Buy now" button you have those little circles. Each recording is from some influencer or from a user. And there are videos, and for videos there are, I think, three or four criteria. You need a transcript, you need audio description if there's something important that isn't said out loud. And that creates new problems: first for design, because that button has to go somewhere, and second for developers, because it has to be programmed somehow. Ideally the transcripts should be synchronised with the video.
Maciek: Mhm.
Wiktor: When we have an influencer, or someone voluntarily created such content, it's a problem at practically every level. But users expect it, it drives sales. Whoever can solve these problems will simply be ahead. That's the first example. I'm wondering whether there was a second one. I'd say videos cause the most stress here.
Maciek: OK.
Wiktor: Right next to images. Everything else, as we know, can be handed to the team. It'll get sorted somehow.
Two tips to get started
Maciek: Sure. All right, Wiktor, if you were to leave listeners with one thought or tip: what could or should they do now to make their site more accessible?
Wiktor: I'd leave two tips. First: communicate that we know these regulations and that we respond to users' comments. The second thing I'd recommend: try to tackle the problem. Pick elements at the very top of the page, for example the menu or a hero banner, try to audit them yourself, see how it goes, and try to fix them. See how it goes up against the company's processes. Then we'll have a full picture of how much we can do ourselves and where we need help. Some companies do it this way and it works. It's a good start.
Maciek: Great. All right, Wiktor, I think we can finish here. Thank you very much for the conversation.
Wiktor: Thanks.
Maciek: We're eagerly awaiting the first inspections and rulings in our Polish and European backyard.
Wiktor: I hope there'll be as few of them as possible.
Maciek: Exactly, we're keeping our fingers crossed. And if there are, because it can't be ruled out…
Wiktor: We're keeping our fingers crossed that they go well.
Maciek: Exactly. And that nobody goes straight to PFRON. As soon as anything like that comes up, we'll probably let you know.
Wiktor: There's a lot going on all the time. We're keeping up, we'll keep you posted.
Maciek: And thank you too for listening and watching, and see you in the next episode. Thanks.
Wiktor: Thanks.



