EN 301 549 12.1 -- Product Documentation
What It Is
ETSI EN 301 549 v3.2.1 clause 12.1 splits product documentation into two testable sub-clauses[1]. Clause 12.1.1 Accessibility and compatibility features requires that the documentation shipped with the ICT -- whether delivered separately or embedded in the product -- list and explain how to use every accessibility and compatibility feature the ICT provides. Clause 12.1.2 Accessible documentation requires that the documentation itself be provided in at least one electronic format that conforms to clause 9 (web content) or clause 10 (non-web documents), so the documentation meets the same bar as the product it describes[2].
"Documentation" here is the full set of user-facing instructional material: user manuals, installation guides, quick-start cards, online help, in-product help text, FAQs, and release notes. A printed manual or a marketing PDF is not disqualified -- 12.1.2 allows additional non-conforming formats -- but at least one electronic format in the set has to meet clause 9 or clause 10.
Why It Matters
The failure mode is mechanical. A product can pass every clause 5 through 11 requirement -- keyboard operable, screen-reader labelled, high-contrast, captioned -- and still fail the users it was built for, because the instructions that describe those features are locked in an untagged PDF, a video with no transcript, or a help site that fails clause 9. A blind user cannot discover the screen-reader mode if the "Accessibility" page in the help centre is an image of text. A user with low vision cannot follow the setup steps if the quick-start guide reflows incorrectly at 400% zoom. Clause 12.1 exists because the accessibility of the product and the accessibility of its documentation are a single user path, and breaking either end breaks the whole path.
12.1.1 targets a different failure: features that exist but are not documented. If the high-contrast toggle is buried three menus deep and no manual names it, the feature is effectively invisible to the population that needs it. The clause forces the vendor to enumerate accessibility features in the documentation, not just ship them in the binary.
How It Relates to WCAG
Clause 12.1.2 is a pointer, not a new technical bar: it delegates to clause 9 (which tracks WCAG 2.1 Level AA for web content) and clause 10 (the same WCAG criteria applied to non-web electronic documents, plus PDF/UA-style structural requirements). What 12.1 adds on top of WCAG is the enumeration requirement in 12.1.1 -- listing accessibility and compatibility features explicitly -- which no WCAG success criterion imposes. WCAG tells you the help page has to be perceivable; 12.1.1 tells you the help page has to actually name the accessibility features.
Practical Implications
- Publish documentation as accessible HTML first. HTML is the cleanest path to clause 9 conformance and avoids the tag-tree fragility of PDF. Use PDF/UA only when the distribution channel forces it, and run the PDF through a tag-tree audit before shipping.
- Create a dedicated "Accessibility features" section in the user manual and the online help. Label it with that phrase -- not "Ease of use", not "Advanced settings", not buried under "Preferences". Clause 12.1.1 wants an enumerable list a screen-reader user can jump to by heading.
- Surface the accessibility documentation from the main navigation. If a user has to search the FAQ to find the list of assistive-technology compatibility notes, the documentation is technically present but not discoverable.
- If a tutorial is delivered as video, ship captions, a transcript, and an equivalent text walkthrough. Video-only instructions fail clause 9 / clause 10 regardless of how polished the video is.
- Keep the accessibility section versioned with the product. A feature added in release 4.2 that is still undocumented in release 4.5 is a 12.1.1 failure for every release in between.
- Document compatibility with named assistive technologies (screen readers, switch interfaces, voice control) rather than asserting generic "AT support". 12.1.1 asks for the compatibility features, which means naming what the product has been tested against.