EN 301 549 V4.1.1, clause by clause: what changed and what it means

V4.1.1 was prepared under the European Commission's standardisation request C(2022) 6456 (M/587) to provide one voluntary means of conforming to the essential requirements of Directive (EU) 2019/882, the European Accessibility Act. V3.2.1, by contrast, was prepared under request C(2017) 2585 for Directive (EU) 2016/2102, the Web Accessibility Directive. That difference in mandate is why v4 has an EAA annex and v3 does not, and why the citation that matters for private-sector sellers is still ahead.

The ETSI cover sheet gives the dates that frame the next two years:

• 24 August 2026: date of adoption by ETSI, CEN and CENELEC, after the national vote on the V4.1.0 final draft (25 June to 24 August 2026).
• 2 September 2026: publication of V4.1.1 (2026-09).
• 30 November 2026: latest date for national standards bodies to announce the EN. This is the date behind Deque's “30 November” citation estimate; it is an ETSI milestone, not an Official Journal date.
• 31 May 2027: latest date for national publication or endorsement.
• 31 May 2028: withdrawal of any conflicting national standard.

The foreword lists the significant changes since V3.2.1 in one paragraph: the real-time text requirements in clause 6.2 “significantly revised and extended to include total conversation”; clauses 9, 10 and 11 updated to WCAG 2.2; a new Annex ZA for the Web Accessibility Directive (replacing the old Annex A); a new Annex ZB for the European Accessibility Act; and a new clause A.2 for evaluating a specific product or service against the Act. The rest of this page is what those five lines look like at clause level, plus the changes the foreword does not mention.

V3.2.1 had one user-preferences clause, 11.7, which asked software to follow a fixed list of platform settings: measurement units, colour, contrast, font type, font size and focus cursor. V4.1.1 replaces that list with a concept, “documented platform accessibility features”, and extends the duty from software to web pages and documents through three parallel clauses:

• 9.7 User preferences for web pages(new): a web page must not block the browser's modes of operation that present the page according to user preference settings, and must not explicitly override user preferences for documented platform accessibility features, unless that is essential to the page. The note names the CSS forced-color-adjust property as the kind of override the clause limits to essential cases.
• 10.7 User preferences for non-web documents(new): the same duty for documents, aimed at files that lock out the viewer's reflow, colour or text-size modes.
• 11.7 User preferences(rewritten): software that is not designed to be isolated from its platform must follow the values of the user's preference settings for documented platform accessibility features unless not doing so is essential to the software's function. The notes list colour filters, contrast, text size, pointer size and text cursor as the kinds of feature meant, and say that a user agent (browser or document viewer) meets the clause by offering at least one mode that enforces the user's settings when rendering content.

The chain closes through two older clauses: 11.6.1 requires platform software to give users control over its documented accessibility features and 11.6.2 forbids software from disrupting them, while 12.3 requires product documentation to say what the accessibility features are and how to use them. In other words, the features a platform documents under 12.3 are the features that 9.7, 10.7 and 11.7 oblige content and apps to respect. For a web team the practical test is simple: with Windows high contrast, a larger system text size and a custom cursor switched on, does the page still honour them?

V3.2.1's clause 6 was titled “ICT with two-way voice communication” and held 17requirements. V4.1.1's is “ICT supporting real-time bidirectional communication” with 38, 20 of them new. The standard now describes a communication system end to end: clients, systems, interconnection, roaming, and emergency communications, each with a set of requirements that must hold in every scenario.

6.0 Operational scenarios

Eight new self-scoping clauses, 6.0.2 to 6.0.9, define the situations in which the rest of clause 6 must be met: a communication client, a communication system with its own clients, a system connecting to another system, a system serving a roaming visiting client, and the same four again for emergency communications with public safety answering points (PSAPs), including a client that is abroad and contacts the visited country's PSAP over an IP-based system that does not use roaming at call-control level. Annex C turns each scenario into test preconditions, so a product is tested in the configurations it will actually be used in.

6.1 Voice

6.1.1 (new) requires ICT that connects to other ICT for voice to document how its voice interoperates, covering at least 100 Hz to 7 000 Hz, either by mutual agreement or by implementing ITU-T G.722. 6.1.2 keeps the 250 Hz to 7 000 Hz capture and presentation range from the old 6.1. 6.1.3 (attached listening devices down to 100 Hz) and 6.1.4 (subtitles for voice calls within 2 seconds) are recommendations.

6.2 Real-time text

This is the rewrite the foreword flags. The headline change is in 6.2.1.1: where V3.2.1 excused ICT from providing RTT when that would require redesign, V4.1.1 simply requires that ICT providing real-time voice “shall provide functionality that allows real-time bidirectional RTT communication”, with notes that this implicitly covers interoperation and multi-party use. Clause 6.2 holds 16 requirements in all:

• 6.2.1.2 Concurrent voice and RTT and 6.2.1.3 Single user action (new): one action must act on all media when a session is started, answered, modified or ended.
• 6.2.2.1 to 6.2.2.5 Display of RTT: sources distinguished (a label such as Speaker 1 is enough), all active communicators indicated, a real-time indicator of non-local audio, text presented as blocks in relative time order (block ends at sentence punctuation plus space, a line separator, or 5 seconds of silence), and the ability to review the whole conversation during and, if recorded, after the session.
• 6.2.3 DTMF during RTT: touch-tone digits must be sendable by a method distinct from typing them as text.
• 6.2.4 Responsiveness: the 500 ms transmission limit from the smallest reliably composed unit of text is kept, with a note that 300 ms or less feels better.
• 6.2.5 to 6.2.9 (new): erasing text from the current end without being blocked by earlier line breaks, 90 characters per second from 3 simultaneous sources in multi-party calls, a character set covering Latin-1, the regional scripts, platform emoji and U+FFFD, RTT input through every general text-input method, and RTT media that can be requested, answered or added mid-call regardless of settings.
• 6.2.10 RTT interoperability: the old 6.2.3, now a documentation requirement with ITU-T T.140 plus IETF RFC 4103 (updated by RFC 9071) as the fallback that always satisfies it.

6.3 to 6.7 Caller ID, alternatives, video, total conversation

6.3 (caller identification in text and programmatically determinable) and 6.4 (voicemail, auto-attendant and IVR usable without hearing or speech) survive with rewritten preconditions. 6.5 keeps the video floor of QVGA, 20 frames per second and 100 ms audio-video synchronisation, and widens 6.5.6 from identifying who is signing to indicating all active participants. 6.6 (alternatives to video-based services) is now labelled a recommendation. 6.7 is new: 6.7.1 Total conversation provision requires any ICT that provides real-time voice and includes video to also provide RTT conforming to 6.2, so that voice, video and text are available together, and 6.7.2 requires documented video interoperability (ITU-T H.264 constrained baseline level 3 as the fallback, H.265 or VP8 where codecs are negotiated).

Why 28 June 2027 is in this clause

The European Accessibility Act requires, in Article 4(8) and Annex I Section V, that emergency communications to the single European emergency number 112 be answered by the most appropriate PSAP using synchronised voice and text, including real-time text, and synchronised video where video is provided. Article 31(3) lets member states apply that requirement as late as 28 June 2027. The emergency scenarios in 6.0.6 to 6.0.9, the note in 6.2.10 that emergency communications are “an important case” of required interoperation, and the pointer in 13.3 to ETSI EN 303 919 (the detailed emergency-communications standard) are V4.1.1 giving the Act a testable definition of what an accessible 112 call is. For vendors of PSAP software, telecoms equipment and emergency apps, clause 6 is the part of the standard with a hard date attached.

A harmonised standard needs a formal map from the law's essential requirements to its own clauses. V3.2.1 had one such map, Annex A, for the Web Accessibility Directive. V4.1.1 has three Z annexes plus a working annex:

• Annex ZA replaces the old Annex A: Table ZA.1 for web pages and documents and Table ZA.2 for mobile applications under Directive (EU) 2016/2102, drawing on clauses 9, 10 and 11 and parts of 5, 6, 7 and 12.
• Annex ZB maps Directive (EU) 2019/882: ZB.1 provision of information on products, ZB.2 user interface and functionality of products plus support services, ZB.3 information about specific products, ZB.4 accessibility of services (the general service requirements of the Act's Annex I Section III), and ZB.5 functionality of specific services. Each row quotes the essential requirement and names the clauses that cover it.
• Annex ZC covers the other directives that the Act's Annex I Section VI refers to, by pointing back at the ZB tables.
• Clause A.2 is the working route. Its clause A.2.0 says, in a paragraph headed “Important”, that each of A.2.1 to A.2.5 is to be considered in order, that every requirement in a table whose condition applies must be assessed, and that Table A.5 applies to all ICT. The note in ZB.0 adds that a product can fall into several rows of several ZB tables, which “makes the tables in Annex ZB impractical for use in assessing whether a specific ICT product or service meets all the applicable requirements”, and sends assessors to A.2.

• WCAG 2.2: the six new criteria at 10.2.4.11, 10.2.5.7, 10.2.5.8, 10.3.2.6, 10.3.3.7 and 10.3.3.8, and 10.4.1.1 Parsing void. Focus Not Obscured applies only where the document accepts keyboard input (forms and interactive PDFs, not a flat report).
• 10.7 User preferences for non-web documents (new): the document must not block the viewer's preference-driven modes or override documented platform accessibility features unless essential.
• Sets of documents: 10.3.2.3 Consistent navigation and 10.3.2.4 Consistent identification, void in V3.2.1, now apply to a document within a set of documents, alongside 10.3.2.6 Consistent Help. A multi-file manual or a series of statements is a set.
• 10.2.4.2 Non-web document titled is reworded to require a title where the format has a programmatically determinable title that common authoring tools can edit; the substance (a title describing name, topic or purpose) is unchanged.
• 10.5 Subtitle positioning and 10.6 Audio description timing are now explicitly labelled recommendations, as their Annex C entries always treated them.
• Terminology: captions are subtitles throughout; the notes point out that WCAG's definition of captions covers both words.
• PDF/UA: note 11 to clause 10.0 names ISO 14289-1:2014 (PDF/UA-1) and ISO 14289-2:2024 (PDF/UA-2) as the technical standards for accessible PDF that “would be useful in meeting EN 301 549”, the first time the 2024 edition is referenced; note 9 recommends Schema.org accessibility metadata for discoverability. See the PDF accessibility guide and the free PDF accessibility checker.

• The open/closed split is gone. V3.2.1 numbered many software clauses as X.1 (open functionality) and X.2 (closed functionality, redirecting to clause 5.1). V4.1.1 has one clause per criterion whose precondition excludes functionality “closed to programmatic access of information by assistive technologies”; clause 5.1 covers closed functionality, and gains 5.1.8 Identify input purpose (closed functionality), which requires the purpose of user-data fields to be presented in audio. 17 v3 closed-functionality variants therefore disappear from clause 11, including the three not-applicable slots for Parsing, Name/role/value and Status messages.
• WCAG 2.2: 11.2.4.11, 11.2.5.7, 11.2.5.8, 11.3.3.7 and 11.3.3.8 are new; 11.3.2.6 Consistent Help is void; 11.4.1.1 Parsing is void; 11.2.4.2 (software titled) is a requirement where it was void.
• 11.5 is now “Interoperability with keyboards and assistive technology”. 11.5.1 becomes informative, 11.5.2.2 is void because its content merged into 11.5.2.1 (platform software must provide documented accessibility services covering every concept in 11.5.2.5 to 11.5.2.17), and 11.5.2.3 Use of accessibility services is demoted from a requirement to a recommendation. The thirteen object-information, relationship, action and notification clauses (11.5.2.5 to 11.5.2.17) carry over.
• 11.6 is now “Documented accessibility features” and 11.7 User preferences is rewritten as described above.
• Authoring tools moved to clause 5.10. The old 11.8.1 to 11.8.5 (content technology, accessible content creation, preservation in transformations, repair assistance, templates) are now generic requirements that apply to any ICT with authoring functionality, including web-based editors, and their targets now include clause 11 as well as 9 and 10. A CMS, a form builder or a design tool that outputs web content is in scope whether or not it is itself non-web software.

Clause 4: statements become criteria

The “functional performance statements” are now “functional performance criteria”, and every one is written with “shall”: where ICT provides visual modes of operation, it “shall provide at least one mode of operation that does not require vision”, and so on. A new 4.2.11 Privacy requires that using accessibility features does not cost the user privacy. Annex C gives each criterion a two-check test: the ICT passes if it meets every requirement that Annex B marks as primary or secondary for that criterion, or if there is evidence of the outcome. The notes also add a measurable floor for the first time: best practice for the smallest text is an x-height of at least 8 CSS pixels, 1.2 mm at 400 mm.

Clause 5: generic requirements

Every closed-functionality clause in 5.1 now starts “Where ICT includes closed functionality” and 5.1.3.3 Auditory output correlation is promoted from a recommendation to a requirement. The two operable-parts clauses 5.5.1 and 5.5.2 collapse into 5.5 Tactilely discernible operable parts, which lets a touchscreen edge, corner or tactile marker count as a discernible part. 5.10 is the relocated authoring-tool clause.

Clause 7: video capabilities

Captions become subtitles; 7.1.2 keeps the 100 ms synchronisation to the subtitle timecode; 7.1.5 is reworded so a player must be able to play spoken subtitles that exist, not generate them; and 7.3 User control of audiovisual accessibility features now requires that subtitles, audio description or spoken subtitles can each be switched with a single operation at the same level as the volume control.

Clause 8: hardware, and a rewritten 8.3

Standard connections, colour and contrast leave 8.1 to become 8.6, 8.7 and the new 8.8 (non-digital characters, symbols and unlabelled parts must contrast light-on-dark or dark-on-light; a Michelson contrast of 0.7 and 0.4 is the usual approach). 8.3 Stationary ICT is rebuilt around two sets of dimensions, Set 1 for designs with no functional or design restrictions and Set 2 for designs with them: display screens no lower than 800 mm (8.3.2), operating information no higher than 1 600 mm or 2 000 mm (8.3.3), one of each control between 800 mm and 1 100 mm or between 380 mm and 1 220 mm (8.3.5), all controls within a 900 mm horizontal span (8.3.6), reach depth of 300 mm or 510/610 mm (8.3.7), obstruction limits for forward and side reach (8.3.9, 8.3.10) and knee and toe clearance from Table 8.2 (8.3.11). The v3 clear-floor-space, change-in-level and alcove clauses are gone; access space is declared out of scope and left to the built-environment standards.

Clause 12: information about products and services

12.1 and 12.2 route digital information about a product or service, including support services, to clauses 9, 10 or 11 by format; 12.3 keeps the duty to document accessibility features and how to get support; 12.4 and 12.5 are new and require electronic programme guides to state, and let users check without playing the item, whether subtitles, audio description, spoken subtitles and sign language are available. The v3 “effective communication” clause for support services has no direct successor.

Clause 13: relay services

The five per-service clauses (text, sign, lip-reading, captioned telephony, speech-to-speech) are replaced by 13.1.2 Relay service access (five invocation requirements: using the primary user's normal destination addresses, conveying caller ID, user-controlled invocation on outgoing and incoming calls, emergency invocation) and 13.1.3 Relay service requirements (relaying action for every modality, pass-through of unconverted media, conference participation, accepting PSAP-initiated invocations). 13.2 is void and 13.3 Access to emergency services is informative, deferring to clause 6 and EN 303 919.