ETSI, CEN and CENELEC published EN 301 549 V4.1.1 in September 2026. The new edition updates the European accessibility requirements for ICT products and services. Clauses 9, 10 and 11 — web content, non-web documents and software — now reference the WCAG 2.2 success criteria, and clause 12 has been renamed and rewritten. For documentation teams supplying the EU market, the practical question is narrower than the standard: what does this change about a PDF manual, and what should be dealt with first?
Two things are easy to conflate here and worth separating at the outset. A standard text being published is not the same as that standard being cited in the Official Journal of the European Union (OJEU), and only the second produces a presumption of conformity. As of late October 2026, V4.1.1 has not been cited under the European Accessibility Act (EAA). That does not make it irrelevant — it is the clearest available statement of what accessible means — but it does change what can be said publicly.
Industry sources indicate that a number of consumer electronics manufacturers have recently received compliance notices from EAA conformity assessment bodies asking for product conformity to be reconfirmed against EN 301 549 V4.1.1, with manuals included in the scope. Requirements differ between bodies and by product, and nothing here should be read as a judgement on the legal effect of any notice. From a scheduling point of view, though, the signal is clear: the starting point for manual accessibility work is no longer set by the citation date alone.
Key Takeaways
- ]Scope comes first. The EAA covers listed products and services. Selling into the EU, or being a consumer electronics brand, does not by itself place a manual in scope.
- ]The baseline moved. Clauses 9, 10 and 11 reference WCAG 2.2 Level A and AA. WCAG 2.2 adds nine success criteria, six at Level A or AA, and removes 4.1.1 Parsing.
- ]Most of the work did not move. For a read-only PDF manual, one or two of the new criteria typically apply. Tag structure, reading order, alt text, header relationships and language declaration remain where manuals fail.
- ]One requirement is genuinely new. Clause 10.7 states that a document must not block presentation according to user preference settings, or override platform accessibility settings.
- ]Consistency is judged across a set. Consistent navigation and identification were void for documents in V3.2.1; V4.1.1 applies them within a set of documents.
- ]Clause 12 depends on form. Information in digital form meets the web, document or software requirements that match its form. The single-accessible-format exemption is gone.
- ]Citation status is a separate question. No version of EN 301 549 has been cited under the EAA. V3.2.1 is cited under the Web Accessibility Directive, a different instrument.
- ]The leverage is upstream. Almost every clause 10 requirement can be solved in the source file. Post-export repair has to be repeated at every revision.
1. What Changed in EN 301 549 V4.1.1
Three things matter to documentation teams — the WCAG baseline moved from 2.1 to 2.2, clause 10 gained a requirement on user preferences, and clause 12 was renamed and rewritten so that each digital form has to stand on its own.
EN 301 549 V4.1.1 was adopted on 24 August 2026 and published by ETSI on 2 September 2026, marked 2026-09. It was prepared jointly by CEN, CENELEC and ETSI under European Commission standardisation request M/587, and the text is free to download.
Three changes that touch manuals
The baseline moves to WCAG 2.2. Clauses 9, 10 and 11 previously referenced WCAG 2.1 and now reference WCAG 2.2 Level A and AA. Read as a documentation requirement, this is the technical basis behind the phrase “build to WCAG 2.2 AA”.
Clause 10 gains 10.7. A non-web document shall not block the user agent's modes of operation that present the document according to user preference settings, or override the platform's accessibility settings, unless that is essential. No earlier edition carried an equivalent.
Clause 12 is rewritten. It moves from “Documentation and support services” to “Information about products and services”, and the format-by-format structure is replaced by a requirement that applies to whichever digital form the information takes.
| Date | Event | What it means in practice |
|---|---|---|
| 24 Aug 2026 | V4.1.1 adopted | Technical text fixed; a gap analysis can rely on it |
| 2 Sep 2026 | ETSI publishes the text | The version number can be cited in specifications and tender responses |
| During 2026 | Some conformity assessment bodies issue notices citing the new edition | The practical start signal for manual work, ahead of any citation |
| Not announced | OJEU citation, which would create a presumption of conformity | Industry expectation has pointed to around mid-December 2026; no date has been published |
Which edition applies to you
Three questions settle it, in this order.
- ]Does the notice, contract or tender name an edition? If it does, that edition governs, whatever the citation status says.
- ]Is the product or service in scope of the EAA at all? Section 2 deals with this.
- ]Is the manual published in more than one form? If a PDF and an HTML version both exist, both have to work.
Where the answers conflict — a notice citing V4.1.1 while the internal specification still says V3.2.1 — the resolution is not to pick one. Take the higher baseline. WCAG 2.2 is backwards compatible with 2.1, so work done to 2.2 satisfies both; work done to 2.1 will need revisiting.
2. Is Your Manual in Scope of the EAA?
Not automatically. The EAA covers the products and services listed in the Directive, and scope depends on the category, the operator's role and any applicable exemptions. A manual is in scope because the product is, not because the product is sold in Europe.
The EAA, Directive (EU) 2019/882, has applied since 28 June 2025. Its product scope is a defined list rather than a general principle. On the product side, examples include computers and operating systems, smartphones and certain communications terminals, e-readers, equipment related to digital television services, and some self-service terminals. On the service side, electronic communications, certain transport services, consumer banking, e-books, e-commerce and access to audiovisual media services appear. The Directive's own text and the way member states have implemented it govern; a “made for Europe” or “consumer electronics” label is not a scope test.
B2B is not an automatic exclusion
It is equally a mistake to treat business-to-business supply as outside the Directive. Whether the EAA applies turns on the product or service category, the role of the economic operator, actual use and any statutory exemption. A B2B label neither establishes nor excludes scope. Borderline cases are better assessed against the specific facts and, where needed, national law.
What Annex I asks of instructions for use
For products within scope, Annex I sets accessibility requirements for product information and instructions for use. In outline, and subject to the text of the Annex itself:
- ]Availability. Instructions are to be publicly available when the product is placed on the market and supplied with it.
- ]More than one sensory channel. Information is not to rely on text alone, images alone or audio alone.
- ]Understandability. Content is to be clear and in plain language.
- ]Convertible text. Content is to be in a text form capable of generating assistive formats.
- ]Alternatives for non-text content. Diagrams, schematics and warning icons are to have an alternative.
The conditions, the responsible party and the precise wording belong to the Annex, not to this summary. Annex I also requires product information to describe the product's accessibility features and how they work with assistive technology. In practice that is a substantive chapter rather than a disclaimer paragraph: where the features are, how to enable them, what they work with.
3. Published, Cited and Legally Effective Are Three Different Things
Publication makes a technical text available. Citation in the OJEU is what gives a harmonised standard its legal effect under a given Directive. Neither is the same as what a customer or a conformity assessment body is asking for today.
A harmonised standard produces a presumption of conformity only once it has been cited in the Official Journal under the relevant Directive. Until then it remains a technical reference: authoritative, widely used, frequently written into contracts, but without that legal effect.
Where V3.2.1 actually sits
This point is routinely garbled, including by suppliers. V3.2.1 is cited in the OJEU under the Web Accessibility Directive, Directive (EU) 2016/2102, which covers public sector bodies' websites and mobile apps, through Commission Implementing Decision (EU) 2021/1339. That citation does not make V3.2.1 a standard cited under the EAA. AccessibleEU, the European Commission's accessibility resource centre, confirmed in September 2026 that V3.2.1 remains the reference until V4.1.1 is formally cited.
Three things you can say publicly
External communication is easier when three statements are kept apart:
- ]“We are preparing against EN 301 549 V4.1.1.” A statement about your own programme.
- ]“Our contract or customer requires V4.1.1.” A statement about a commercial obligation.
- ]“We hold a presumption of conformity under the EAA.” A statement about legal effect, which as of late October 2026 no EN 301 549 version supports.
Blurring the first into the third is the common failure, and the one most likely to be tested by a customer's compliance team or by a competitor.
4. What This Means Clause by Clause for Non-Web Documents
Clause 10 now points at WCAG 2.2 A/AA. Six criteria are new to the clause. One requirement, 10.7, has no earlier equivalent, and consistency is now assessed across a set of documents rather than treated as void.
4.1 Clause 10 points at WCAG 2.2
Clause 10 does not restate WCAG. It refers to individual success criteria, adapted where the wording assumes a web page, and marks a small number as void because the unit of conformance for a document is a file rather than a set of pages. Two consequences are often lost.
First, “clause 10 references WCAG 2.2” and “this document is affected by all of WCAG 2.2” are different claims. The first is a fixed technical basis. The second depends on which features the document actually contains.
Second, EN 301 549 addresses the gap directly. Clause 10.0 carries a note to the effect that a success criterion whose feature does not occur in the document is satisfied. A read-only manual with no form controls, no authentication and no time-based media is not required to invent them.
4.2 Six new A/AA criteria, and where they land
WCAG 2.2 added nine success criteria in total. Six are Level A or AA, all six enter clause 10, and their effect on a manual varies considerably.
| WCAG 2.2 criterion | EN 301 549 | Level | What it requires | Where it lands in a manual |
|---|---|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | 10.2.4.11 | AA | A focused component is not entirely hidden by author-created content | Interactive documents: form fields, pop-ups. Not a footer problem in static pages |
| 2.5.7 Dragging Movements | 10.2.5.7 | AA | Any dragging operation has a single-pointer alternative unless dragging is essential | Documents with interactive controls or operating instructions; confirm against actual function |
| 2.5.8 Target Size (Minimum) | 10.2.5.8 | AA | Pointer targets usually at least 24 by 24 CSS pixels, with stated exceptions | Links, buttons and form controls. Do not equate print or pixel dimensions with CSS pixels without conversion |
| 3.2.6 Consistent Help | 10.3.2.6 | A | Repeated help mechanisms keep a consistent relative order | Check clause 10 scope and the set-of-documents definition; “multi-volume” alone does not create a set |
| 3.3.7 Redundant Entry | 10.3.3.7 | A | Information already provided is auto-populated or selectable | Multi-page fillable forms; read-only manuals rarely engage it |
| 3.3.8 Accessible Authentication (Minimum) | 10.3.3.8 | AA | No cognitive function test as the only authentication route | Sign-in and authentication flows; not a general PDF layout obligation |
For a read-only, non-fillable manual without interactive controls, one or two of these six typically apply. It is worth being precise about which, because the same table is often quoted as evidence that every manual needs six new pieces of work.
4.3 Where the rework actually sits
Sorting the changes by type is more useful than counting them. Most of what fails a manual was already required in the WCAG 2.1 era.
| Type of change | What it covers | What it means for a manual project |
|---|---|---|
| Long-standing requirements | Tags and semantics, reading order, alternative text, header relationships, language declaration | Where most rework sits, and largely independent of this edition |
| New A/AA criteria in 2.2 | 10.2.5.8 and 10.3.3.7 throughout; 10.2.4.11, 10.2.5.7 and 10.3.2.6 depending on function | Affects only documents that carry the corresponding interactive features |
| Strengthened in 2.2 | Restrictions on zoom and reflow, operating together with 10.7 | Check whether protection settings block the reader's preferences |
| Removed in 2.2 | 4.1.1 Parsing | No parsing check; structural problems are still caught by other clauses |
4.4 Clause 10.7: do not block the reader's preferences
10.7 is the genuinely new document requirement in this edition. Three failures account for most of its practical impact.
Zoom or reflow is locked. Some protected PDFs disable both, often as an incidental setting rather than a deliberate design choice.
Text is broken into individually positioned fragments. This reads out of order in a screen reader and cannot reflow, because there is no logical flow to reflow.
Foreground and background colours are hard-coded. When a reader enables high contrast or replaces document colours, text and background can collide and the content disappears.
These tend to appear in visually polished layout work, because the cause sits in design decisions rather than in the export step. Zoom, reflow, colour and font preferences all make reasonable test cases — but whether a given PDF must reflow in the same way an HTML page would is a question for the file format, the reader's capability and the clause text, not a general rule.
4.5 Consistency is now judged across a set of documents
In V3.2.1, consistent navigation and consistent identification were void for documents as a whole. V4.1.1 applies them within a set of documents: across volumes of the same manual, or across a family of manuals for related products, navigation and the naming of equivalent elements should agree.
The standard defines what constitutes a set. “Multi-volume” alone does not settle it, and neither does a shared product family. Where a set does exist, the effect is to upgrade “each document correct on its own” to “the set coherent as a whole”. That is close to unachievable when each volume is laid out separately, and straightforward when all volumes come from one structured source.
4.6 Clause 12 depends on the form the information takes
Clause 12 is now titled “Information about products and services”. Information about a product made available in digital form is to meet the web, non-web document or software requirements that correspond to its form. The phrase “at least one accessible electronic format” from V3.2.1 is not retained.
Read plainly, where a manufacturer publishes both an HTML manual and a PDF manual, the PDF is no longer excused by the HTML. It is also worth resisting the mirror-image error: it does not follow that every format published simultaneously carries identical obligations in every circumstance. Clause 12, the purpose of the information, the form actually published, Annex I and the citation status all bear on the assessment.
A note on PDF/UA. PDF/UA, the ISO 14289 series, specifies how an accessible PDF is to be structurally built: the tag tree, reading order, language entries and titles. It is a technical specification for a file format. A PDF/UA tool result is a statement about structure, not by itself a finding about conformity with the EAA or with EN 301 549, which turns on the clause 10 criteria. For the structural detail and how checking tools differ, see our article on PDF accessibility and compliance checks.
5. Applying This to a PDF Manual
Short answer: Almost every clause 10 requirement can be solved at source-file stage. What matters operationally is that each requirement maps to a specific action and a checkable piece of evidence.
The table below sets out the clauses that do most of the work on a typical manual, with a reference action and something that can be shown afterwards. It is a working list rather than a conformity claim, and the applicable clauses still depend on the document in front of you.
| Clause | Check | Reference action | Evidence |
|---|---|---|---|
| 10.1.3.1 Info and relationships | Headings, lists and tables carry correct semantics | Map paragraph styles to heading levels; use real list and table tags | Continuous heading levels in the tag tree; list and table tags present |
| 10.1.3.2 Meaningful sequence | Reading order matches the logic of the content | Reorder the source story flow; correct the tag sequence after export | Assistive technology reads in chapter order; tables read row by row |
| 10.1.1.1 Non-text content | Informative images carry accurate, useful alt text | Write alt text for informative images; mark decorative elements as artifacts | Figure tags carry alt text; decorative elements absent from the read order |
| 10.3.1.1 Language of page | Main language and required language changes declared | Set main and per-range language tags at export | Language field correct; mixed-language paragraphs carry language tags |
| 10.2.4.2 Document title | Programmatically determinable descriptive title | Write the title into metadata and set the viewer to show it instead of the file name | Viewer title bar shows the correct title |
| 10.1.4.3 Contrast (minimum) | 4.5:1 for body text, 3:1 for large text | Check brand colours against both light and dark layouts | Colour sampling record passes item by item |
| 10.7 User preferences | Content stays readable and reflowable under magnification or preference settings | Do not lock zoom or reflow; do not hard-code foreground and background colours | No content lost at 200% zoom; content visible under high contrast |
| 10.2.5.8 Target size (minimum) | Interactive controls and hit areas are usable by pointer | Enlarge form controls or extend the hit area | Measured control size meets 24 by 24 CSS pixels |
| 12.1.1 Accessibility features | Manual explains the product's accessibility features and their use | Add an accessibility features chapter covering activation and assistive-technology pairing | Dedicated chapter present, with a feature list |
| Set-of-documents consistency | Navigation and naming consistent within the set | One template, one style map, one terminology base | Sampled chapter structure and terminology agree across volumes |
| Interactive features, where present | Keyboard, focus, redundant entry and authentication checked individually | Check the applicable criteria and exceptions against actual function | Test record and exception notes |
| Clauses not applicable | 10.2.4.1 Bypass blocks; 10.2.4.5 Multiple ways | No remediation required; bookmarks and a linked contents list remain worth keeping for navigation | Report records the clause as not applicable |
Two kinds of action sit in that table. Some happen in the source file: structure, styles, reading order, artifact decisions. Others are verified after export: metadata, bookmarks, language, measured contrast. Doing only the second kind amounts to patching a document whose structure was never sound, which is the usual reason a manual survives three rounds of review and still fails.
The four-step process
First, source assessment. Check whether paragraph styles map to heading levels, whether lists are real lists, whether tables retain header relationships, whether layers and master pages introduce redundant content. This step decides whether the rest is feasible, and how much rework follows.
Second, structured production and export. Build semantics in the source, set document title and language, write alt text for informative images, distinguish decorative elements, and generate bookmarks and tags where needed. This is normally the most labour-intensive stage, particularly where the source file has to be rebuilt or the project runs across several languages; our desktop publishing services page covers that side of the work.
Third, automated checking and human review. Tools find what machines can find: whether the file is tagged, whether a language is set, whether a title exists, whether figures carry alt text. Whether the alt text is accurate, whether the reading order is logical, whether a table is understandable, and whether the document works with an actual screen reader, need a person.
Fourth, remediation and records. Log the clauses applied, the issues found, the fixes made, the tool output and the scope of human review. Where the source file is unavailable, assess whether PDF-level repair is feasible; complex layouts or structural problems that run deep may need the source rebuilt.
A checklist of this kind exists to make the process repeatable. It is not a regulatory inventory, and completing it is not the same as being certified.
6. Three Things Multilingual Projects Miss
Language attributes set only at document level. An English manual quoting a German warning or a French regulatory clause needs those runs tagged, or a screen reader applies English pronunciation rules to German text. Mixed-language passages cluster in safety and compliance sections, which is where the cost of getting it wrong is highest.
Alt text that was never localised. Images are reused across languages; alt text is not language-neutral. An instruction reading “press the green button on the right” left in English inside an Arabic manual is not an alternative. Alt text belongs in the translation package, not in the layout file as a technical attribute.
Reading order in right-to-left languages. Arabic and Hebrew manuals are laid out right to left, but the tag tree and reading order still follow the logical order of the content. Mirroring the page without rebuilding the structure is the most common RTL failure: the visual result looks correct and the audio result does not.
7. Seven Misconceptions and a Pre-Publish Record
The misconceptions below are the ones that most often change a project's scope after it has started.
| Misconception | More accurate reading |
|---|---|
| Every manual sold into the EU is automatically caught by the EAA | The EAA covers listed products and services. Confirm scope, operator role, exemptions and member state implementation first |
| Publication of V4.1.1 means it already gives a presumption of conformity | Publication and OJEU citation are separate events; status should be taken from EU official sources |
| Checking against WCAG 2.2 AA proves the whole manual compliant | The applicable EN 301 549 clauses, the EAA requirements, the document form and its actual function also bear on the assessment |
| Alt text on every image is enough | Alt text is one part. Structure, reading order, language, tables and interactive features fail independently |
| A green automated report is sufficient | Automated results cannot judge every semantic or usability issue; human review and assistive-technology testing remain necessary |
| A PDF/UA result equals EAA or EN 301 549 compliance | PDF/UA supports structural validation but does not on its own cover all regulatory and standard requirements |
| One digital format can always substitute for another | Assess under clause 12, the purpose of the information, the form published and the applicable rules; avoid blanket commitments |
The record below is not a certification. It is the minimum that makes an assessment reviewable six months later, when the people who did the work have moved on and the questions are being asked by someone else.
| Record | What to keep |
|---|---|
| Scope judgement | Product or service category, intended users, economic operator role, and the basis for the judgement |
| Standard and contract basis | Edition applied, contract requirements, latest OJEU status |
| Document properties | Document title, main language and any required language runs |
| Structure check | Heading levels, reading order, table structure, link names, alt text, bookmarks |
| User preference testing | Scope of magnification, reflow, colour and other preference testing |
| Interactive feature testing | Where present, records for keyboard, focus, target size, redundant entry and authentication |
| Validation evidence | Automated results, human review record, known limitations |
| Remediation record | Issue list with fixes, and the feasibility assessment for legacy remediation |
FAQ
When does EN 301 549 V4.1.1 take effect?
It depends which layer of “take effect” is meant. The text was published by ETSI in September 2026 and its technical content is available now. A presumption of conformity under the EAA requires citation in the OJEU, which as of late October 2026 has not happened. The EAA itself has applied since 28 June 2025. Keeping “published”, “cited” and “presumption of conformity” as three separate statements prevents most misunderstandings.
Is EN 301 549 V4.1.1 mandatory under the EAA?
Not in that form. The EAA sets the legal requirements, and a harmonised standard gives a presumption of conformity once cited under it. No version of EN 301 549 has been cited under the EAA, so no version currently carries that effect. V4.1.1 remains the clearest statement of what accessible means, and the edition customers are most likely to ask for.
Does clause 9 or clause 10 apply to a PDF manual?
A PDF distributed as a downloadable file or shipped with a product is normally assessed under clause 10, non-web documents. Clause 9 covers web content, including documents embedded in and rendered with a web page. A product's landing and download pages fall under clause 9 in their own right, and if they carry product information they need checking separately. The test is how the content is presented, not the file extension.
Why does the OJEU matter if the text is already published?
Publication makes the technical document available. Citation is what gives it legal effect as a harmonised standard under a particular Directive. They are different events with different consequences, and a project schedule keyed to the wrong one is either needlessly late or unhelpfully early.
Do business-to-business manuals fall outside the EAA?
Not by virtue of being B2B. Scope depends on the product or service category, the operator's role, actual use and any exemptions, and member state implementation may add detail. Borderline cases are worth a legal or compliance opinion rather than a judgement call inside the documentation team.
Should we build to WCAG 2.1 or WCAG 2.2?
For technical preparation against V4.1.1, check the applicable clause 10 requirements and the WCAG 2.2 A/AA criteria they reference. Where a contract or procurement document names a different version, record both and map between them. For most manual projects, building to WCAG 2.2 AA also covers the 2.1 requirements, which makes it the lower-risk choice. What should be avoided is presenting preparation for the new edition as a present legal obligation for every company.
How do PDF/UA, WCAG and EN 301 549 relate?
WCAG describes what makes content usable, through success criteria aimed at the reader's experience. EN 301 549 is the ICT accessibility standard and contains requirements adapted to different technology forms, including clause 10 for non-web documents. PDF/UA addresses how a PDF is structured internally. They support each other; they are not interchangeable, and a result in one is not a result in the others.
Will accessibility work change the visual design?
In most cases no. A good deal of it is achieved through tags, reading order, language and metadata while the visual design stays as it is, and remediation works the same way. What can require visual change is complex layout that cannot be restructured, text that is too small, contrast that does not reach the threshold, or content that cannot respond to user preferences. Promising that appearance will not change at all is a commitment worth avoiding until the document has been assessed.
Does every language need separate work?
Yes. The structural template can be reused, but tags, language attributes, alt text, RTL mixing and the actual reading experience each need checking per language. Set-of-documents consistency also means chapter structure and terminology should agree across language versions.
What evidence should a supplier deliver?
Useful evidence includes the accessible document itself, a statement of the clauses applied and the test scope, automated results, human review and assistive-technology test records, and an issue list with fixes. What counts as sufficient depends on the project agreement and the applicable rules; a single tool report is not a substitute for the rest.
Conclusion: Start With Scope, Then Structure
For a manual heading to the EU market, the sequence that holds up is: establish whether the EAA applies, select the clauses that match the product and the document form, and keep records someone else can review. EN 301 549 V4.1.1 is the current technical reference; until its citation status is settled, external communication should keep preparation, contractual requirement and legal presumption apart.
For most manual projects, the effort is better spent on tag structure, reading order, alt text and language declaration than on chasing the newest criteria. Those four are where documents fail, they are checkable, and improvements in them show up in validation rather than in a claim.
This article explains standards and documentation workflow; it is not legal advice. Scope, operator obligations and member state requirements should be confirmed against Directive (EU) 2019/882, national implementing rules, the latest OJEU information and qualified advice.
References
- ETSI, CEN and CENELEC, EN 301 549 V4.1.1 (2026-09) — Accessibility requirements for ICT products and services. https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.01_60/en_301549v040101p.pdf
- Directive (EU) 2019/882 (European Accessibility Act). https://eur-lex.europa.eu/eli/dir/2019/882/oj
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
- W3C WAI, What's New in WCAG 2.2. https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
- AccessibleEU, The European accessibility standard EN 301 549 has been updated. https://accessible-eu-centre.ec.europa.eu/content-corner/news/new-version-en-301-549-standard-now-available-2026-09-07_en
ETSI, CEN and CENELEC, EN 301 549 V4.1.1 (2026-09) — Accessibility requirements for ICT products and services.
Directive (EU) 2019/882 (European Accessibility Act).
W3C, Web Content Accessibility Guidelines (WCAG) 2.2.
W3C WAI, What's New in WCAG 2.2.
AccessibleEU, The European accessibility standard EN 301 549 has been updated.
