Creating an accessible Web version of EN 301 549

I agree. That would have many advantages, such as:

Better accessibility of the document.
Better presentation when using a small screen, such as a smartphone.
Easier to make deep links pointing directly to specific clauses.
Better precision when using search.

But I suppose the PDF version will still need to be the formal standard, for publication in the EU Official Journal. So a mechanism must be put in place that ensures that such a web version will always have the same content as the formal PDF version. And necessary resources for producing and maintaining a web version must be made available.

I agree with the above summary of the benefits of moving to a Web version of the standard.

It is worth noting that those responsible for updating EN 301 549, and those in the CEN/CENELEC/ETSI eAcc Joint Technical Body who will approve its publication will not be able to mandate in what format(s) the document is published.

But any observations made in this issue will be useful to support internal efforts to persuade the Standards bodies to change or extend their publication policies to allow a Web version of a standard to be treated as an "official" version of the standard.

I am fully supporting all proposals that enhance the usability and accessibility of EN 301 549, including the proposal to create a Web version! One strikingly large difficulty in training the accessibility stakeholders that me and my partners in Estonia are facing has been the poor usability of EN 301 549 (a 186-page long and complex pdf file is inflexible to use), and I am very concerned as many service providers in the European Union have to follow the standard from 2025.

However, as I understood in the spring of 2023 from the discussions of drafting the ETSI's Specialist Task Force Proposal about Accessibility of ETSI Deliverables, there are many concerns from the standard author's side that need to be addressed. Thus, we have to make sure that we are involving them in solution-finding activities as well.

I'd love to see this happen. What can I do to get this moving?

For a quick solution I guess the most practical way would be to ask Accessibility Standards Canada to re-publish the html version they had online for a few months at https://accessible.canada.ca/en-301-549-accessibility-requirements-ict-products-and-services

(An archived version can still be found at https://web.archive.org/web/20240119050545/https://accessible.canada.ca/en-301-549-accessibility-requirements-ict-products-and-services )

For a sustainable solution, I think ETSI/CEN/CENELEC should host the standard, so that URL:s can be used for reference without worrying about the pages being taken down or the content somehow different from the original.

Perhaps ETSI could re-publish the Canadian copy, with suitable disclaimers added, and pointers to the PDF original, in the same folder as the PDF (https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/ )?

I understand the Canadian version is now online: https://accessible.canada.ca/en-301-549-accessibility-requirements-ict-products-and-services-1 (hurray) Is this a solution for the long term?

The document on that link seems to have multiple conflicting copyright statements, claiming that all rights are held both by the Canadian body, and then further down by CEN and later by ETSI.

Then down in the Foreward it says "This Harmonised European Standard (EN) has been produced by ETSI Technical Committee Human Factors (HF), and the eAccessibility Joint Working Group (JWG) of CEN/CENELEC/ETSI and is now submitted for the combined Public Enquiry and Vote phase of the standards EN Approval Procedure."

So it seems to me like a somewhat careless lash-up based on a pre-publication release of the previous version.

ETSI should try to do something better. I support the idea of an approved HTML version, but this isn't it.

The Canadian online version is definitely a significant step forward as it is a web version that brings enhanced accessibility and immediate benefits (for all). But I definitely don't see it as the best long-term solution.

Navigation around the Canadian site is entirely built upon the links in the automatically generated Table of Contents that is in the ETSI Word version of the document (if you look at the anchor tags in the source you will see codes like "a href="#_Toc66969536""). As well as these codes having no obvious meaningful link that relates to the number or title of the requirement, the table of contents only goes down to level 3 headings (which only covers a subset of all of the requirements). These links go to the top of a group of requirements rather than to an individual requirement.

What is really needed is for each requirement to have its own unique meaningful anchor tag, then it will be possible to really effectively navigate the standard and entries in every table, for example, can include links straight to the requirement or test in the standard.

Given the fundamentally logically-structured nature of the standard, it should be feasible to programmatically generate a unique and useful tag for each requirement in the standard, and then the web version of the EN would be significantly more navigable and useful.

I think that having any web version of the EN is a good step forward, so I welcome the Canadian effort. But I agree with the legal issues pointed out by @jeffreym and the navigation issues that @pluke has detected.

We can always hope that ETSI publishes an official HTML version of EN 301 549. If so, I agree with the proposal from @pluke to have unique (and descriptive) anchors for each requirement.

If we could enrich the web-version with everything the web has to offer (also in terms of semantics), that would be great!

Is the underlying document of the current .pdf indeed a word-file? Ideally, there would be a "neutral" source-file that exports to multiple formats. I can imagine that .epub would also be interesting as a format.

But that's ideally. A self-hosted HTML-copy would already be a great step forward.

DISCLAIMER: The following is only my personal rationale for the current ETSI document production process and does not represent an "official" position.

The default source file format in ETSI is, and has been for decades, MS Word. Conversion from the Word document to PDF is done at the end of the process and is controlled by ETSI staff (with no direct involvement of those who create and review the documents).

The .doc(x) format is pretty much a standard for business documents and hence ETSI assumes that all of those from the ETSI member companies will be able to generate, distribute, and review documents in Word format. This is also a production/review format that most ETSI member organisations seem to be very committed to, and generally unenthusiastic about moving away from.

I totally agree with Erik Kroes that the ideal would be to have a common source and for all (accessible) versions of that to be generated from that source. The problem in moving away from MS Word format is the availability of, and familiarity with, the tools used to generate and review documents in that format. It would also be necessary for ETSI EditHelp to completely change their toolset for checking and converting documents in that common format. Currently they have well-developed macros that check documents to see how they conform to the very extensive ETSI Drafting Rules. All such important processes would need to be migrated to a different platform.

IF it is possible to devise an effective process for producing accessible version of ETSI deliverables that are based around having a Word document as its basis, then the introduction of such a scheme would probably meet the least resistance within ETSI and its member companies.

The .docx file format used by current versions of Word is an ISO standard.

The ISO standard for the Word .docx file format is ISO/IEC 29500. This standard defines the Office Open XML File Formats, which includes the .docx file extension used by Microsoft Word. The standard is divided into several parts, with Part 1 specifying the Strict variant and Part 4 specifying the Transitional variant. The Transitional variant is the most commonly used and is designed to incorporate the full semantics and functionality of the binary .doc format produced by earlier versions of Microsoft Word.

For more detailed technical information and extensions related to the .docx file format as presented in the ISO/IEC-29500 specification, you can refer to the Microsoft documentation titled "[MS-DOCX]: Word Extensions to the Office Open XML (.docx) File Format".

In fact, the .docx format is really an XML file which is compressed using the common Zip method. You can use an unzipper on a .docx file to see the contents (including the XML of the text document and any other files required such as pictures.

So, while not trivial, it is certainly possible to create a tool that extracts anything from the Word file (including cross-references) and create an HTML version from it. Word can itself save the file out as HTML, though that might not be the best. There are other tools for it.

If ETSI were to invest in such a transformation tool, they would be able to use it for ALL of their standards, and it wouldn't affect their other toolsets or the process of creating PDFs. It would be a separate process branch from the same (Word) source document.

added STF614 Accepted label

Those updating the EN are very aware that having a Web version would greatly improve the accessibility of the document. The possible creation of a Web version of the EN is being taken into account during the current updating process e.g. the inclusion of more cross-linking within the document will be very beneficial if converted to an HTML version of the document.

However, the task of updating the document obliges us at present to continue to work on draft Word documents as this is the only format that we are expected to work with during the exercise of updating and subsequent approval of the document. I can assure @altiniera that ETSI is actively looking at the creation of Web versions of future standardization deliverables, and EN 301 549 would be at the head of the queue for a candidate major deliverable.

As there is nothing that those of us working on the task of updating can do to directly address your issue, I am giving it the label "STF614 accepted" in recognition that your valid request is acknowledged and will hopefully be acted on outside of this updating activity as soon as possible. The issue will also be closed.

closed

mentioned in issue #219

Creating an accessible Web version of EN 301 549

Designs

Child items ...

Activity