As with CVAA, even now when we’re nearly at the compliance deadline for EAA and past the compliance deadline for GPSR, there’s still a lot of people who are unaware, and even some misinformation complicating things. 

It’s not easily solved by looking at the legislation itself, both are enormous stacks of legalese (EAA is 115 pages, GPSR is 51). So this piece aims to help, to translate into something a bit more clear and manageable. There’s still a lot to cover, but it’ll be concise and in plain English.

But first, a disclaimer:

Summary

EAA and GPSR are two pieces of EU legislation, affecting products and services available to EU citizens.

EAA is accessibility legislation. It brings extensive accessibility requirements for chat or microtransactions in web/mobile games (and other gaming-adjacent things like websites selling games), and some light requirements for other games that have chat functionality. 

If you have a game, website or app that involves player to player chat or any kind of purchasing, you need to be aware of and compliant with EAA. 

GPSR is product safety legislation, meaning games cannot be unsafe. Most notably, this would likely cover photosensitive epilepsy seizures induced by effects in games.

If you are developing any game at all, you must be aware of and compliant with GPSR.

---

EAA

What is the EAA?

The European Accessibility Act is a directive aimed at standardising accessibility regulation across the EU, with dual goals of increasing accessibility and reducing trade barriers that come from different countries having different standards. Directive means that it isn’t a law in itself, instead it’s an instruction for countries to make laws that are in line with it – which has now happened.

There have been standards for the public sector (government websites etc) for a long time, EAA brings similar standards to a range of products and services in the private sector too. 

Does EAA apply to me?

EAA consists of two key lists. Firstly a list of products that must be accessible, if placed on the market after 28th June 2025:

• General purpose computer hardware & operating systems
• Self service terminals (e.g. ATMs, ticket machines)
• Digital communication devices (e.g. smartphones)
• Audiovisual media devices (e.g. TVs, set top boxes)
• E-readers

These generally do not apply to people in the games industry, unless a console has broad enough functionality to meet the definition of general purpose computer hardware.

And secondly a list of services that must be accessible, if provided to consumers after 28th June 2025:

• Electronic communication services
• Audiovisual media services
• Digital elements of passenger transport services
• Consumer banking services
• E-books and e-reader software
• E-commerce services

There are mainly two here that apply to games – electronic communication services, and e-commerce services. And where these things are provided outside of games too, like on a game’s website. And also, in some rare circumstances, audiovisual media services might apply. 

So, what do those three things mean?

Electronic communication services

This is defined as interpersonal & interactive exchange of info over an electronic communications network, where the people participating determine the recipients, so long as the services isn’t merely ancillary. In English – this means digital text/voice/video chat, where the chat function is actually related to the gameplay (like speaking with teammates). 

E-commerce services

This is defined as services provided at a distance, through websites and mobile device-based services by electronic means and at the individual request of a consumer with a view to concluding a consumer contract. Again, in English – this means buying something through a website or mobile app. 

Audiovisual services

This refers specifically to TV programmes, either a scheduled television broadcast or on-demand. I’m not going to cover the requirements for it in this article as it generally doesn’t apply to games. But there are rare exceptions – for example full episodes of Star Wars: Tales of the Underworld shown within Fortnite. If you’re considering something like that, please be aware that there are a range of legal requirements involved.

What’s the timeline?

• • June 27th, 2019: EAA directive published.
  • June 28th, 2022: Deadline for most EU countries to put laws in place to enforce EAA. 
  • June 28th, 2025: Deadline for EAA compliance for all products put on the market after this date and all services provided after this date, and for enforcement to begin.
  • June 28th, 2027: Deadline for a second smaller group of exempted countries to begin enforcement.
  • June 28th, 2030: Deadline for services which rely on legacy inaccessible products to be removed from the market

Are there any exceptions?

Company size

Most importantly, EAA does not apply to micro-enterprises. 

Micro-enterprises are enterprises with less than 10 staff, AND either annual turnover of less than €2 million, OR an annual balance sheet of less than €2 million. 

If you meet that definition, you are exempt from EAA. 

HOWEVER if all of your hopes go to plan you won’t always meet those criteria, you’ll be successful and your business will grow. So it’s still worth getting your ducks in order if you can, as future-proofing – and of course for the benefit of your players.

Unreasonable burden

Individual requirements (not the whole of EAA) can be skipped if they impose a disproportionate burden, or would result in fundamental alteration. There’s a set of criteria to assess this, with quite a high burden of proof, and it all has to be fully documented and re-assessed periodically, and communicated to the authorities of every individual EU country.

Broadly speaking it’s a balance of three things:

1. Ratio of the overall cost of the service Vs cost of accessibility
2. Ratio of the net turnover of the whole company Vs cost of accessibility
3. How much difference non-compliance makes to disabled people. 

The full criteria are in ANNEX VI, conveniently located at the very end of the legal tome.

Content exemptions

There are some specific exemptions for aspects of websites & mobile apps too, the following are exempt:

• Pre-recorded time-based media published before 28th June 2025.
  Office file formats published before 28th June 2025.
• Maps, if there’s an alternative accessible way to access the info.
• Third party content not funded/developed by/under control of you.
• Archived websites/apps, meaning contain no content that is updated or edited after 28th June 2025.

The important ones here are third party content and archives. You aren’t responsible for accessibility of third party content UNLESS you have some kind of relationship with them that goes beyond just hosting it, such as having a contract with a payment service provider – in which case as you chose to pay for that service then you’re liable for any accessibility failings they may have (as are they).

And archives, so if you have ecommerce or chat in an existing web/mobile game or website/app, you don’t fall under EAA UNLESS you make any changes to it after June 28th – any changes at all mean it no longer counts as an archive, so you have to be fully compliant at the time of the update. 

What does enforcement look like?

As it’s a directive rather than a law, it doesn’t contain enforcement, instead it just has guidance for countries on how to do it – that it should be proportional, that there should be some window to fix it before being penalised (e.g. Italy allows 90 days), etc. It’s then up to individual countries to set their own methods and penalties, so that varies from country to country. Some examples of maximum penalties:

• Germany – Fines of up to €100k for inaccessibility, and €10k for not providing accurate info. 
• Italy – Fines of up to €40k for small companies, and up to 5% of annual turnover for large companies (defined as companies with turnover of €500m+). 
• Spain – Fines of up to €600k, together with the service being banned for up to 2 years.
• Ireland – Fines of up €60k fine together with up to 18 months in jail.

Because each country has its own laws, if your service is inaccessible you are in breach of laws in many countries, and can therefore face enforcement in many countries. So it’s pretty serious stuff.

What does compliance look like?

So, how to avoid enforcement?

There are two sides to compliance. First, what you actually have to implement to ensure your services are accessible. Secondly, there are requirements for some process and documentation that sits around it. 

There are also differences between what’s needed for comms & ecommerce, and web/app games Vs other games.

Comms requirements

The requirements for communication service providers are often pretty basic and straightforward.

• If you provide voice chat, you must also provide text chat.
• If you provide video chat, you must provide “total conversation services” – i.e. let players use whatever combo of voice, visuals and text works for them. 

If it’s a regular console or PC game, then that’s all there is to it.

It’s more complicated if it’s a web/mobile game (or not a game), as any website/mobile app involved with delivering the comms has to be accessible through being perceivable, operable, understandable and robust (POUR) – I’ll cover what what POUR means in a bit. 

E-commerce requirements

E-commerce service providers must –

• Ensure functionality for identification, security and payment and identification methods, electronic signatures, and payment services are accessible through being perceivable, operable, understandable and robust (POUR)
• Ensure any website/mobile app involved with delivering the service must be accessible through being POUR. 
• Ensure that if the store sells any EAA-covered products (e.g. smartphones, e-readers), the store has some means of showing/reaching the accessibility info that the product manufacturers are obliged to provide.

What does POUR mean?

Those four pillars of perceivable, operable, understandable and robust are met by using ‘existing harmonised standards’. This means the requirements aren’t in the directive, you’re expected to use standards that already exist. The existing EU standard on digital accessibility is called EN 301 549. What’s in it is roughly the same as the WCAG standard for web accessibility, which you should be familiar with if you’ve ever worked in web. Plus a few extras, and with slightly different requirements for websites Vs mobile apps.

A decent chunk of it is finer details about how to ensuring that blind people have equitable access to the interface, but there’s more to it as well. At a very high level EN 301 549 requires:

• Perceivable: Accessible text content, alternatives for non-text content, alternatives for time-based media, adaptable, distinguishable
• Operable: Keyboard accessible, enough time, seizures & physical reactions, navigable, input modalities
• Understandable: Readable, predictable, input assistance
• Robust: Compatible

At a slightly lower level it looks something like this. Disclaimer that this is not the full list, it’s just merged example to give you a feel of the kind of things that it requires for web/mobile –

• Screenreader support or menu narration, including text equivalents for images, properly named/described UI elements (name/role/state), and communication of relationships (e.g. heading levels, lists).
• Video/audio has captions, audio descriptions or transcripts, and volume controls.
• Don’t use sensory characteristics alone (e.g. shape, colour, size) to convey info.
• Support both portrait and landscape view (unless one is essential).
• Ensure adequate contrast between text/UI and background.
• Support text scaling up to 200%, and configurable line/letter/word spacing.
• Support full keyboard access (if the device the service is running on is compatible with them), with a logical focus order and visible focus indicator 
• Offer skip links for repeated content.
• Avoid dragging, multi-touch and gyro interaction.
• Ensure page/screen titles, link text and headings/labels are descriptive.
• Ensure form fields have visible labels and instructions, and identify errors with suggestions of how to fix them.
• Critical actions (e.g. purchasing) can be confirmed before submission.
• Time limits can be extended or turned off.
• Moving content can be paused/stopped/hidden. 
• No flashing content at more than three times per second.
• Multiple ways to navigate, e.g. search, site map.
• Consistent navigation and element naming across different screens/pages.
• Avoid unexpected changes of context or unpredictable UI behaviour.

For the full details see the EN 301 549 PDF (section 9 for web, section 11 for mobile apps)

So what does this all mean? If effectively means that web/mobile games with chat or e-commerce are now held to the same standards as websites.

It’s nothing new, these are standards that have been around for a very long time. If thought about early, and if your tech supports it, it isn’t hard. But not everyone is in that situation. For example it’s common for people to be using an engine of choice doesn’t support screenreaders/menu narration out of the box (in the way that UIKit does, or GODOT now does), leaving you instead reliant on bespoke or 3rd party solutions. If that’s the case, you need to be putting some very serious and urgent pressure on your engine provider. 

Process & documentation requirements

As well as the implementation side itself, there are some process things that sit around it. All comms / e-commerce service providers must –

• Ensure that any products needed to provide the service meet EAA requirements
• Ensure support channels have accessible modes of communication
• Ensure staff are properly trained to be able to advise service users
• Prepare and provide info on the service and its accessibility, including AT compatibility, in accessible formats, maintained for the duration of the service
• Put processes in place to ensure services remain in conformity
• Notify each authority of every EU country in case of any unconformity
• Provide full conformity information to national authorities on request

If your service is reliant on legacy inaccessible products (for example a game only available on an old console that itself doesn’t meet EAA reqs) it’s still possible to continue doing that until 2030, after which the service has to be withdrawn.

The info on the service and its accessibility (summarising how the service works and how it meets the EAA’s requirements) – goes in the general T&Cs or equivalent, and must be available in accessible formats (e.g. published on an accessible website).

How does EAA relate to CVAA?

CVAA is an existing law for comms accessibility that applies to services provided to US citizens. It has different requirements to CVAA, though with some overlap. 

It doesn’t make much economic or organisational sense to develop different setups for different countries, so if you’re intending to hit both EU and US markets, here’s a combined set of CVAA+EAA comms requirements:

• Register with the FCC as a comms service provider. (CVAA)
• Start working on comms accessibility from early in the design process. (CVAA)
• Involve disabled people in the design process. (CVAA)
• If you have voice chat, ensure it is accessible. If you have text chat, ensure it is accessible. If you have video chat, ensure it is accessible. (CVAA)
• Ensure the comms path – any UI or info needed to locate, navigate to or operate the comms functionality – is accessible. (CVAA)
• If you have voice chat, also provide text chat. If you have video chat, also provide total conversation service. (EAA)
• If comms is delivered through a website or mobile app, ensure it complies with the EN 301 549 accessibility standard. (EAA) 
• Document how the service works (EAA)
• Document how compliance has been met (EAA + CVAA)
• Publish the documentation in the general T&Cs, and in accessible formats (EAA)
• Share documentation with authorities on request (EAA + CVAA)
• Ensure support channels are accessible and staff appropriately trained (EAA)
• Ensure processes are in place to maintain compliance, and notify authorities of every EU country in case of any compliance breach (EAA)

Questions

Answers to a few questions I’ve seen crop up from developers –

But we’ve been told that EAA doesn’t apply to games?

This is a misunderstanding that has spread over the past few of years, presumably stemming from games not being on the list of product types that EAA applies to. However EAA isn’t just about products, it also applies to services, so when those services appear in games those services are covered by EAA.

What does the 2027 deadline mean? Does that mean developers in some countries are temporarily exempt?

It’s the other way around – some countries are temporarily not taking enforcement action, because a country that doesn’t have its laws in place yet can’t enforce them. But it’s fairly moot, as nearly all EU countries do now have their laws in place.

How long after EAA comes into effect do we have to become compliant?

Six years, but that countdown started in 2019, the final compliance deadline is June 28th 2025.

Can I just ignore it?

Any law can be ignored. Whether that’s a good idea is a different question. And while countries are required to give you a chance to fix it before issuing penalties, that time window might not be very long. 

If I have DLC available through a console storefront, is that covered?

Doubly no – the storefront is providing the service rather than you, and it also doesn’t meet EAA’s definition of e-commerce, which is transactions through websites or mobile apps only, not console apps. 

I don’t have microtransactions within my game, but we do sell merch and goodies on our website. Does that fall into the e-commerce coverage?

Yes, e-commerce is defined as any transactions through websites/mobile apps.

My game is older, but we do push patches and updates from time to time… are we exempt?

No, any communication service offered to players after the compliance date is covered, regardless of how old the game is. The only exception is for archived websites & mobile apps (inc. web/mobile games), which are defined as ones that have no updates at all after June 28th 2025.

Are there examples or references of what to do (done well)?

For console/PC games it’s pretty simple – any game with text chat is an example of how to do it well. There aren’t any examples that I’m aware of a game having accessible video chat. For examples of good practice for web/mobile games and websites/apps, look for showcases of WCAG accessibility; while that isn’t 100% the same as EN 301 549, it’s still a decent picture of the kind of thing to aim for.

Does making my game WCAG-compliant mean that it is EAA-compliant?

No. Games in general aren’t covered, EAA reqs for console/PC games are just to include text chat if you have voice chat, or total conversation if you have video chat (neither of which are WCAG requirements). If you have a mobile game or web game that falls under EAA for comms or e-commerce, EN 301 549 then comes into play. EN 301 549 is not entirely the same as WCAG, aiming for WCAG 2.1 will get you most of the way but there are some extra things in EN 301 549 that aren’t covered by WCAG – and again there’s also the text chat/total conversation requirements that sit outside of that.

Our game already has a chat feature that was in place before June 28th, does that fall under EAA?

Yes. Old products aren’t covered, nor are the contents of archived websites/apps, but services are treated differently to products – EAA applies to all services ‘provided to consumers‘ beyond June 28th.

Do non-compliant games have to be pulled?

No, it affects services rather than games. So pulling (or remediating) the service itself would remove the non-compliance.

Our games are sold through a third party payment service. Does that fall under the ‘third party’ exemption?

It depends. If you’ve integrated their service into your game and have some kind of contract/payment setup with them, it isn’t exempt, as the exemption is for third party content not controlled, developed by or funded by you. As you chose to licence it you’re liable (and they are too). If you’ve integrated it but don’t pay anything for it and have no control over its development, then it is exempt. If it isn’t integrated in any way and the transaction is fully handled on a third party site for example, then it’s irrelevant – you aren’t providing an e-commerce service, they are.

If I have DLC available through a console storefront, is that covered?

Doubly no – the storefront is providing the service rather than you, and it also doesn’t meet EAA’s definition of e-commerce, which is transactions through websites or mobile apps only.

Further reading

‘European Accessibility Act & Video Games : Going Over The Facts’
– Player Research

‘Understanding the EAA’
– Tetralogical

European Accessibility Act full text

EN 301 549 full text

WCAG 2.1

‘Demystifying CVAA’
– Ian Hamilton

---

GPSR

What is it?

The General Product Safety Regulation is an update to the EU’s product safety laws, covering a range of aspects like strengthened risk assessment and market surveillance, but also updating for the digital world, to ensure that online distance selling is covered, and that software counts as a product.

It also states that disabled people have a right to safe products, and that safety issues specific to certain types of disability have to be considered.

Unlike EAA it’s a regulation rather than a directive, as rollout has to identical across all countries to allow the setup of the Europe-wide monitoring systems.

GPSR is a bit more straightforward than EAA, so this half of the piece is much shorter!

Does GPSR apply to me?

GPSR applies to products placed on the EU market after 13th December 2024. For online sales, it’s about whether EU citizens are targeted. Just the fact that Eu citizens can purchase isn’t enough, targeted at them means for example being able to pay in Euros, have delivery of a physical product to an EU country, or access info in European languages. 

Products are are required to be safe, meaning presents minimal risk to health and safety. In turn, ‘health and safety’ means ‘a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity’.

Games generally aren’t unsafe, but they can be. The most obvious and serious safety risk is photosensitive epilepsy seizures induced by effects in games, so it’s effectively now illegal for games to include seizure triggers beyond a certain threshold. 

There are other things that could potentially be interpreted as falling within GPSR, like sim sickness, or injury from excessive mashing, or mental health impact from abuse by other players – but seizure risk stands out from the rest as there’s a clear internationally standard on what constitutes safety for it. 

What’s the timeline?

• 23 May, 2023: GPSR regulation published.
• 23 June, 2023: GPSR regulation becomes law.
• December 13th, 2024: GPSR becomes applicable to all products placed on the market after this date.

Are there any exceptions?

There is a small list of exempt product types. Typically things that have their own separate regulations such as food, medicine, and live animals. Games are not on this exemption list. Though antiques are exempt, some old games might fall under that.

Unlike EAA, there is no exemption for small companies; consumers have a universal right to not be harmed by products, regardless of what scale of company made them. 

Games already on the market before the compliance deadline are exempt, the law only applies to games that are placed on the market after December last year. 

What does enforcement look like?

In a very similar way to EAA, each EU country has the ability to define its own penalties and enforcement methods – they just have to be ‘effective, proportionate and dissuasive’.

Ireland for example gives an initial 2 weeks notice to take action, which can be to remedy, or to take off the market, etc. If you don’t do this, you’ve then committed an office subject to penalties that range from max €5k + 6 month imprisonment for minor offences through to €500k + 2 years for serious offences that go to full indictment by trial.

Consumers can report safety issues through EU SafetyGate.

National authorities have the power to require removal of unsafe products from the market.

In the case of serious risks, the EU Commission can remove  products or product categories across the whole of the EU. The EU Commission can also step in to solve any disputes between companies and authorities over risk assessments, and organise spot-testing sweeps of product categories.

What does compliance look like?

In the same way as EAA there are requirements around what to implement, and processes that sit around that. 

Distributors (e.g. storefronts) and importers have their own separate requirements, I won’t cover those here, but they include obligations like traceability,  ensuring only safe products are put on sale, ensuring recall notices are sent, and sharing contact details of the manufacturer or responsible person.

Safety requirements 

As with EAA, GPSR  it doesn’t contain specific measures itself, instead relying on existing standards. If you’ve complied with an existing safety standard, you’re presumed to be compliant with GPSR.

An existing standard for seizure risk reduction exists, it was created in response to the infamous strobing Pokémon episode that hospitalised hundreds of kids – ISO 9241-391:2016. It contains thresholds for what constitutes flashes and patterns, and how much of the screen they are able to take up. It was a created as a balance of risk Vs achievability, so doesn’t guarantee safety, but does try to reach a level where most people with PSE are unlikely to have a seizure induced.

A simplified version of those thresholds is available here – doesn’t exactly match the standard, but it’s close.

There are tools available to analyse video footage and report problem areas, like the Harding Flash Pattern Analyser, or EA’s open source IRIS library (and accompanying Unreal plugin)

Most other safety issues in games don’t have handy standards to lean on, so anything else is just down to what is identified during your safety risk assessment. Though ‘reasonable consumer expectations concerning safety’ should be taken into account.

Notably GPSR lists mental health as a safety risk, citing the example of mental health risks from digitally connected products, particularly for children.

Products are required to be safe primarily by design & features, only falling back on things like warnings and instructions as a last resort.

Process & documentation requirements

Two points of contact must be assigned. A safety contact within your company, responsible for compliance and documentation, with contact details provided to consumers. And a local safety representative who is based within the EU, to do things like verify documentation and act as a go-between between you and the authorities. This is because companies outside the EU selling into the EU make it harder for authorities to do things like track supply chains. This is very important: it is illegal for anyone to sell a product in Europe unless they have an address in Europe.

There are a lot of EU-based companies offering to act as this local ‘responsible economic operator’, but they don’t do this for free, it typically costs a few hundred euros per year. Contact details for both of these people should be provided to the public. This is something to speak to your publisher about, they should be providing it.

Risk assessment must be carried out, and carried out again if there are any substantial changes to the product, together with testing products to ensure safety. 

This must be covered in technical documentation, which includes details on how the products work, what the safety risks are and how they were assessed. A formal declaration of conformity must also be produced.

Safety incidents must be reported, and unsafe products must be recalled. There’s a central portal for doing this through, called EU SafetyGate, though it also needs to be done through the usual sales channels too. A set format for what info goes onto a recall notice is listed in Article 36.

Products must have some kind of identification method, like a serial number, which is easily visible for consumers.

Any safety instructions must be localised for countries the product is made available in.

There must be a communication channel to report safety issues, which in turn must be accessible to disabled people. Records must be kept of reports and actions.

Both authorities and the public must be informed if any safety issues are present or arise.

Questions

Again answers to a few questions I’ve seen crop up from developers –

Is ‘presumed to be compliant’ the same thing as being compliant?

Not quite. It’s enough to initially satisfy authorities, but might not necessarily mean you’re covered if a consumer still encounters a safety issue. 

Does it GPSR only cover photosensitive epilepsy?

No, it covers any kind of risk to health and safety, including mental health. PSE triggers just have a convenient standard to work to. 

Further reading & viewing

‘Questions and Answers about the GPSR’
– European Commission

‘Webinar: Understanding the new rules under the GPSR’
– European Commission

‘UK makers caught out by new EU General Product Safety regs’
– Ross Martin

‘Application of the General Product Safety Regulation to Software’
– Mason, Hayes & Curran

‘The new EU General Product Safety Regulation: What you need to know’
– CMS

GPSR full text

---

Closing thoughts

Despite it being way shorter than the original legalese, this is still a long article. It can seem heavy, I get it.

But for some people, it’s actually not heavy at all.

Companies who already had their ducks in a row for CVAA already have record keeping as part of their workflows. The many companies who already voluntarily screen for photosensitive epilepsy seizure triggers (some have for nearly 20 years now) were already well prepared for GPSR adopting the same standard. Companies already working on menu narration and screenreader support have a huge head start on the mobile & app components of EAA.

Some years ago – I think perhaps 2012 – I remember Tara Voelker telling the audience at one of her talks that while accessibility wasn’t required at the time, you’d be better off tackling it now rather than someone step in and require you to in the future. Prophetic words, and still relevant because anything you do today is putting you in a safe place for tomorrow.

Or in the words of Karl Groves –

“Would you rather tackle accessibility on your own timeline, or someone else’s?”

If you were ever in need of a business case argument for accessibility at your company, safeguarding against future legislation is a pretty strong one.

As developers we need to be pushing ahead in our own work. In our implementations, our practices, our processes. And not just for safeguarding or compliance, but to make games better for more people, to ensure the medium can reach its true potential.

And we need to keep pushing others – pushing engine developers, pushing publishers, pushing our peers – to play their part too.