A click-by-click guide is mostly pictures. That is the point of it: eleven screenshots with a red box around the button you press next. It is also why a colleague using a screen reader gets almost nothing from it. The alt text, if there is any, says "screenshot" eleven times.
This is solvable, and for a growing number of European organisations it is not optional. Which rule binds you depends less on what you write than on who reads it.
Full disclosure: we build Loopyback, an EU-hosted process documentation tool that produces screenshot-heavy guides. We have the exact problem this article describes, and further down we say plainly what we have not solved.
Which regime actually reaches your documentation
| Regime | Who it binds | Does it reach internal SOPs? | Reference standard |
|---|---|---|---|
| Directive (EU) 2016/2102, Web Accessibility Directive | Public sector bodies | Yes for intranets and extranets, subject to a grandfathering carve-out | EN 301 549 |
| Directive (EU) 2019/882, European Accessibility Act | Operators placing listed products and services on the market | Not internal documentation; yes for consumer-facing support content | EN 301 549 |
| Directive 2000/78/EC, article 5 | Every employer, no size threshold | Yes, as an individual reasonable accommodation duty | No standard, an outcome test |
The public sector case is the strongest and the least known. Article 1(4)(g) of the Web Accessibility Directive excludes the content of extranets and intranets published before 23 September 2019 "until such websites undergo a substantial revision". Read that the other way round: an intranet page published or substantially revised after that date is in scope. Plenty of organisations transposed this without anyone telling the people who write the work instructions. In the Netherlands it lands as the Tijdelijk besluit digitale toegankelijkheid overheid, in France as the RGAA under article 47 of loi n° 2005-102, in Spain as Real Decreto 1112/2018, in Germany as BITV 2.0 for federal bodies alongside Land-level rules.
The EAA is narrower than the marketing around it suggests. It has applied since 28 June 2025 and covers listed products and services provided to consumers: e-commerce, consumer banking, e-books, passenger transport, electronic communications, and a defined set of hardware. Your internal onboarding SOP is not an e-commerce service. But if your product is in scope, the help documentation your customers read is part of that service, and EN 301 549 is explicit about it.
The employment duty applies to everyone and has no threshold. Article 5 of Directive 2000/78/EC requires employers to take appropriate measures to enable a person with a disability to have access to, participate in and advance in employment, unless that would impose a disproportionate burden. If a colleague cannot follow the SOP everyone else is measured against, that is where the argument lands, not in a harmonised standard.
What EN 301 549 asks of documentation specifically
Most people know EN 301 549 as "the EU's WCAG", and clause 9 does map web content to WCAG 2.1 level AA. Two clauses speak about documentation directly, and they are the ones that get missed:
- 12.1.2 requires product documentation to be available in a web format conforming to clause 9, or a non-web format conforming to clause 10.
- 12.2.4 applies the same requirement to documentation provided by support services.
The practical translation: a PDF full of screenshots satisfies neither unless it is a tagged, structured PDF. Exporting to PDF does not make documentation accessible. It usually makes it harder to fix later.
Four failures specific to screenshot guides
1.1.1 Non-text content. Every screenshot needs a text alternative conveying the same information. "Screenshot of the settings page" is a filename, not an alternative. The pattern that works is to write the step text so the screenshot confirms it rather than carries it, then mark purely decorative screenshots as decorative.
1.4.5 Images of text. A guide that puts the field label only inside the image fails this. If the step text says "click Save", the image is illustration and you are fine.
1.4.3 Contrast. Annotation colour is the common trap. A thin light-red box on a light-grey interface is invisible to a lot of people and disappears entirely in greyscale printing. Combine colour with shape or a step number.
1.3.1 and 2.4.6, structure and headings. Numbered steps must be real ordered-list markup, not bold paragraphs with digits typed in front. This is the cheapest fix on the list and the most commonly skipped.
Notice what falls out of doing this properly: writing the alt text forces the step text to stand alone, which makes the guide better for everyone. It also makes it translatable, searchable and readable on a phone. If you already produce multilingual SOPs, half of this work is done, because text that survives translation is text that does not live inside an image.
Where accessibility and the GDPR pull the same way
There is a useful overlap here. Good alt text describes the function of the screen, not its contents. "The user list, with the Invite button top right" is better alt text and less personal data than reading out the eleven names visible in the table. Writing to the function rather than the pixels satisfies WCAG 1.1.1 and supports data minimisation under Article 5(1)(c) at the same time.
The same logic applies to version control. If your quality system already treats guides as controlled documents, accessibility is a property you can attach to the template rather than chase per document. Our piece on ISO 9001 documented information covers that side of it.
What Loopyback does and does not do
We generate step text automatically from the recorded actions, so each step has a real text layer rather than a bare image, and the HTML and Markdown exports keep steps as ordered-list markup. Redaction runs in the browser before upload, which helps with the alt-text-versus-personal-data tension above. Pricing is in euros: free, €16 per month personal, €24 per seat for teams.
What we do not do: we do not generate WCAG-quality alt text, and we will not claim otherwise. Our automatic descriptions are derived from the element you clicked, which is a reasonable starting point and not a conformance statement. Our PDF export is not a tagged accessible PDF. If you need a formal accessibility statement under Article 7 of the Web Accessibility Directive, the defensible route today is the HTML output rather than the PDF, and you should test it yourself rather than take our word for it.
Common mistakes
Buying an overlay widget instead of fixing the content. An overlay cannot invent alt text for a screenshot it has never seen, and several European bodies have been openly sceptical of overlay claims.
Auditing the intranet homepage and not the documents on it. The navigation passes, the guides fail, and the guides are what people actually need.
Treating the accessibility statement as the deliverable. Article 7 requires the statement to describe non-accessible content and provide a feedback mechanism. A candid statement with a remediation plan is worth more than an optimistic one.
Assuming PDF is a safe archive format. Untagged PDF is one of the hardest formats to remediate afterwards. Keep the source in HTML or Markdown and generate the PDF from it.
Waiting for a complaint. The reasonable accommodation duty is individual and reactive by design, but a documentation set that only works for sighted mouse users is a standing condition, not an incident.
FAQ
We are a private company. Does any of this bind our internal SOPs?
The Web Accessibility Directive does not, and the EAA almost certainly does not. Article 5 of Directive 2000/78/EC does, on an individual basis. Beyond the law, public sector clients increasingly pass accessibility requirements down through procurement, so the requirement can arrive through a contract rather than a regulator.
Is the target WCAG 2.1 AA or 2.2?
EN 301 549 is the reference in EU law and its published version maps clause 9 to WCAG 2.1 level AA. WCAG 2.2 adds success criteria that are sensible to adopt now, but conformity is assessed against the harmonised standard, so check the version cited in your national transposition before you promise anything.
How do we retrofit hundreds of existing guides?
Not alphabetically. Rank by traffic and by consequence: the safety instruction and the ten most-opened guides first. Then fix the template, so everything written from next month starts compliant and the backlog stops growing.
Does automatically generated alt text count?
As a draft. A description derived from a click target cannot know what information the image is meant to convey in this particular context. Treat it as a placeholder a human confirms, never as a conformance claim.
Founder of Loopyback
Daan is the founder of Loopyback, a Belgium based tool that turns workflows into step by step guides. He writes about documentation, SOPs and getting knowledge out of people's heads.