Skip to content

Multiple Issues with clause 12.3 (ITI3-1 comment from Issue #682)

There are multiple issues with this clause’s updates:

  1. The clause has departed from the original intent of this requirement – which matched what is required by US Revised 508’s 602.2 Accessibility and Compatibility Features requiring documentation of the accessibility features of the ICT and its compatibility with assistive technology. To provide easier capability to report conformance to 508 and to the EN, prefer this be kept truer to the original V3.2.1 version. Additional requirements should be new clauses.

  • Changing “documentation” to “information” greatly expands the scope of this requirement which could be interpreted to be that this must be included in advertising about the product, blog articles about the product, etc. which wasn’t the original intent of this clause – to ensure users can find out how to use accessibility features of the product and its compatibility with AT in the product documentation.

  • Reinstate Note 1 as it provides language harmonized with the U.S. Revised 508 Standards 602.2 Accessibility and Compatibility Features.

  1. The EN 301 549 should not require that a list of any accessibility provisions that are not met be incorporated anywhere there is “information about the ICT”. Such information is problematic to include in integrated help, printed documentation, and electronic documentation.

  • It is questionable whether the EN 301 549 should even include this as an ICT accessibility requirement, because this standard is supposed to be scoped to the requirements for making ICT accessible, not the documentation of how the standard is or isn’t met.

  • There is no argument that providing readily available information about which EN 301 549 provisions are not met is important. However, incorporating that information anywhere there is any information about the ICT is problematic. For example, the ICT documentation and embedded product help are not the correct places to provide that information. Nor would be printed documentation be a good place for such information.

  • Many digital products undergo maintenance on an ongoing basis (fixpacks, point releases, etc.) that could cause the list to become stale if it is in print documentation. Many products already have a self-declaration of conformance available in the form of an Accessibility Conformance Report (ACR) which provides the details of which provisions are and are not met. Allowing product and service vendors the flexibility to maintain a single source of truth (like an ACR) that is readily available, but not tied to the product documentation is the most feasible solution.