We are evaluating mail merge to make Accessible PDF from Word templates containing the TextBox object to control layout.
The problem is, the ADAA Tag we get from a TextBox is a Figure, not a Paragraph.
Is there a way (like a callback) to control what ADA tags gets generated for the TextBox or other Word object?
@pcleaveland Unfortunately, there is no way to control this behavior. We will consider exporting content inside textboxes as paragraphs to PDF document structure.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): WORDSNET-27597
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
@pcleaveland We have completed analyzing the issue. This is quite specific request. Textboxes in MS Word document are used to break the regular flow of the document and they are exported both by Aspose.Words and MS Word either as a <Sect> or <Figure> depending on the presence of the graphics. The detection of the graphics may be tuned so in customer case there may be a <Sect> tag instead of <Figure> tag but it will not solve the customer request. Exporting textboxes as <P> tag is wrong in general case. So we close this issue as ‘Not a Bug’.
As a workaround you could postprocess the Aspose.Words PDF output for their custom scenario. Or as another option you could change the MS Word document generation. Actually, as it is seen from screenshot, you seems to be building a table out of the textboxes. This is not an accessible way to build MS Word documents. From accessible perspective, if you want to have a table in the document, then it has to be a real table instead of bunch of textboxes. This way the source document will be accessible and output PDF will be properly tagged.
Please don’t close this yet.
We never said it was a bug. We just want some guidance.
There are two GOOD REASONS we are using text boxes in this case. Believe me, it is not easy, so we would only do it if we had no alternative.
Reason 1) This particular document has a unique requirement that the layout be an exact size, with excess text getting cropped. The layout is NOT ALLOWED to stretch and flow in any way.
Reason 2) Using a Table for layout is NOT ALLOWED by the ADA standards. To be ADA compliant, Tables must have consistent columns with headers and regular repeating data structure. When we used a Table for layout of a page, the ADA checkers FAIL the Tables test.
Given those constraints, the TextBox seemed the best bet. Do you know of an alternative Word structure to meet the requirements. We are open to all options.
We might have to do post processing, but that would be tedious.
You mentioned
The detection of the graphics may be tuned so in your case there may be a tag instead of tag
What exactly does this mean? And how would we do it?
Peter
@pcleaveland I will forward your concerns to our development team.
I corrected the post. The sentence should look like this:
The detection of the graphics may be tuned so in customer case there may be a
<Sect>tag instead of<Figure>tag but it will not solve the customer request.
OK, HOW would we do that, so we can evaluate the result?
@pcleaveland There is no way to achieve this. It means that we could make this change in our code, but anyways this will not resolve the problem.
OK, thanks for the reply, I understand.
For the sake of flexibility, if you ever DO implement anything like this, I would request you do it as an optional ADA Tagging Callback, so the customer can see the Word object and exert control over the ADA tag created, when needed.
But I will not expect this any time soon.
@pcleaveland I will consult with the developer responsible for this feature and get back to you soon.
Using a Table for layout is NOT ALLOWED by the ADA standards. To be ADA compliant, Tables must have consistent columns with headers and regular repeating data structure. When we used a Table for layout of a page, the ADA checkers FAIL the Tables test.
I’m not sure about particular ADA PDF requirements, but modern Section 508 PDF requirements are relied on the WCAG and PDF/UA. Table tags in Aspose.Words PDF output are compatible with both WCAG and PDF/UA as long as the original MS Word document is accessible. You could find more info on accessibility requirements on DOCX->PDF conversion in this article.
Moreover WCAG states that tabular data must be presented with table tags. So when you are using other tags for tabular data, you are making document to technically pass the validation but in fact it is not accessible.
If you provide the generated PDF document (and source DOCX file) which do not pass accessibility checks, we could investigate this issue.
For the sake of flexibility, if you ever DO implement anything like this, I would request you do it as an optional ADA Tagging Callback, so the customer can see the Word object and exert control over the ADA tag created, when needed.
Out main goal is to convert accessible MS Word documents to accessible PDF documents and preserve as much related information from source document as possible. At the moment generation of custom PDF tags which are not related to accessibility is not on our roadmap. This task is expected to be done by post-processing of Aspose.Words PDF output with third-party PDF processing libraries like Aspose.PDF.
The issues you have found earlier (filed as WORDSNET-27597) have been fixed in this Aspose.Words for .NET 24.12 update also available on NuGet.