WCAG compliance with Aspose Sheets and Aspose Slides when converting to pdf?

Good morning,

Thank you both for this information. Please can I further ask how I carry out the same WCAG compliance with Aspose Sheets and Aspose Slides when converting to pdf?

Thank you,

Stan

@modern.gov,

Well, you may simply convert MS Excel file to PDF via Aspose.Cells APIs and then use Aspose.PDF API to convert the output PDF (by Aspose.Cells) to render WCAG compliance PDF. Similarly you may try to use Aspose.Slides to render Powerpoint presentation to PDF and then use Aspose.PDF API to convert the output PDF (by Aspose.Slides API) to render to WCAG compliance PDF.

Anyways, for your requirements, we have also logged your feature requests for both APIs into our database. Following are the tickets logged for your demanded feature:

  • CELLSNET-46642 (Aspose.Cells)
  • SLIDESNET-40996 (Aspose.Slides)

Once we have an update on any of the tickets, we will let you know.

Hi Amjad,

Apologies, I am unclear are these two tickets so that Slides and Cells can export WCAG compliant structured documents?

We don’t use them often but I just need to be clear so that I can advise customer’s accordingly.

Thank you,

Stan @moderngov

@modern.gov,

Currently Aspose.Slides and Aspose.Cells do not provide this feature while converting to PDF. That is why we have logged new feature requests under these two tickets for the respective products. When these tickets will be resolved, this feature will be directly available using each of the product.

Hope this clarifies the query.

Hello,

Sorry I’m need a bit of clarification about, CELLSNET-46642 (Aspose.Cells) and SLIDESNET-40996 (Aspose.Slides) to prevent any issues down the line, and if necessary assurances regarding the different Compliance formats available.

We are working to comply with The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 which comes in to force 23rd September 2019; so my first question is will these fixes be ready well in advance of this date (so that we can confidence test them, and roll new version out to customers)?

My second question is then about the various compliance options on the Pdf Export options across the product. Each product (Words, Slides, Sheets) offers a compliance option which are normally Pdf15, PdfA1a, PdfA1b (However slides does not even offer PdfA1a). Based on my research PdfA1a is best; but it has short comings (such as a lack of transparency) that will cause problems for our customers. PdfA-2 and better PdfA-3, but don’t seem to be available as part of your product. Is this something that will be implemented, or are you planning on adding a Pdf/UA option that ensures compliance with ISO-14289? If there is no need to implement these in your product to meet accessibility standards please can I have a statement of confidence that your product meets the accessibility standards that I can take to my boss?

Thank you for your continued help,

Stan

For your above question from reference of Aspose.Cells we can not share ETA at this moment but supported version might be available in the fourth quarter of 2019. From Reference of Aspose.Slides ETA is not earlier than 2019’Q2.

We have plan to implement this feature and will inform you once this feature implemented in Aspose.Slides.

Hi Adnan,

Thank you for confirming you will be adding PdfA1a to Aspose.Slides.

The question about compliance types goes deeper than that though. I’ll try and explain with an example:

If I use Aspose.Words to make a word document and want to convert it to a pdf using Aspose.Words.Document.Save() I can set it to create a structured document with
opts.ExportDocumentStructure = true; But then the Pdf itself should also be a suitable format to be accessible.

It is therefore my understanding that I need to set opts.Compliance to a suitable value. The available options only being Pdf15, PdfA1a, PdfA1b. And while PdfA1a is technically accessible it has shortcomings, with the expected standard being Pdf/AU. Therefore I am asking for either:

  1. A statement explaining that I have misunderstood the relationships of the different compliance levels to Accessibility.
  2. A statement from you confirming that PdfA1a is suitable to meet the compliance needs of ISO-14289, the WCAG standards and associated EU/UK legislation.
  3. Details confirming that there is going to be a Pdf/UA option available for the compliance and when this will be available in your software.
  4. A method in the existing product by which I can take a word document and convert it to a PDF/UA (ISO-14289) compliant pdf.

I appreciate we are getting in depth on this matter but I have to demonstrate that in using Aspose I can meet the legislate requirement, so your help is very very much appreciated.

Thank you and have a good weekend,

Stan

@modern.gov,

I like to inform that we are investigating your requirements on our end and will share feedback with you soon.

Hi Adnan,

I believe I can offer some more information to assist you in scoping our requirements.

The WCAG 2.1 standards for pdfs can be found here: PDF Techniques | Techniques for WCAG 2.0 (Please note while these are the WCAG 2.0 they are not changed for WCAG 2.1).

The bulk of these are controlled by the document author so the only requirement regarding your product is that when converting to pdf is that any accessibility structure they have added is not lost or altered on conversion.

However; there are also the following requirements I believe we will directly need to do programatically, I have broken them down by product:

Aspose Words/Aspose.Slides/Aspose.Sheets

  • Export of document structure
  • The creation of bookmarks from syntactic headings (document outline)
  • The preservation of a document’s language flag (/LANG in the pdf)
  • The ability to optionally set a document’s language flag.
  • The ability to specify the pdf document’s title.

Aspose Pdf

  • Ability to specify the document language on a pdf (/LANG)
  • Ability to specify the title of a pdf file (/TITLE)
  • Ability to mark specific Aspose.Pdf.Stamps as ‘Artifacts’

We are combining multiple pdf documents via Aspose.Pdf.Facades.PdfFileEditor.Concatenate so it is important that no accessibility elements are lost in this process.

I am happy, within reason, to carry out a small amount of post processing of our concatenated document regarding elements such as /LANG and /TITLE.

Document format
The discussed pdf 1.5, pdfa1a, and pdf1b are all quite old formats, each superseded by new versions so ideally we would benefit from being able to convert to a new compliance format from each of the office formats (ideally this would be Pdf/UA); however, if you can provide confidence that accessible documents created in the various office suites maintain WCAG 2.1 compliance when converted to pdf1.5 then I may be able to continue to use Pdf1.5 in the near future.

Conclusion
I appreciate that some of the products can already do the required actions and in these cases please can you advise on the setting I require. I am already aware of the Words.PdfOptions.ExportDocumentStructure so that one does not require addressing and I understand that this is to be added to Sheets and Slides, but for any others I would appreciate guidance.

Thank you for your continued help,

Stan

@modern.gov,

I have observed the requirements shared by you and have created an investigation ticket with ID SLIDESNET-41023 in our issue tracking system to investigate whether it is possible to meet the illustrated requirements using Aspose.Slides or not. I will share the feedback with you in this regard as soon as possible.

@modern.gov,

Please try our latest version/fix: Aspose.Cells for .NET v19.3.2 (attached)

In the fix v19.3.2, we now support to save to tagged PDF using the new API: PdfSaveOptions.ExportDocumentStructure .
e.g
Sample code:

Workbook wb = new Workbook(srcFile);

PdfSaveOptions saveOptions = new PdfSaveOptions();
saveOptions.ExportDocumentStructure = true;

wb.Save(outFile.pdf, saveOptions);

Please note, currently, we only support to create tagged PDF as what Aspose.Words API does. It may not be WCAG 2.0 compliant. The ticket is still Open and we will continue to look into it.

Let us know your feedback.
Aspose.Cells19.3.2 For .Net2.Zip (4.8 MB)
Aspose.Cells19.3.2 For .Net2_AuthenticodeSigned.Zip (4.8 MB)
Aspose.Cells19.3.2 For .Net4.0.Zip (4.9 MB)

Good morning Gentlemen,

Is there an update on the progress with the outstanding requests on this case please? As we are drawing closer to the deadline and I need to provide an update on this.

Thank you,

Stan

@modern.gov,

Regarding issue “CELLSNET-46642”, please see our reply in the previous post:

Regarding issues (SLIDESNET-40996; SLIDESNET-41023), the tentative ETA is 2019’Q4.

Good morning,

Regarding:

It there a less tentative update?

Thanks,

Stan

@modern.gov,

I am afraid, we cannot fix the issues related to Aspose.Slides API soon. We are very sorry but due to more priority issues (on hand), the tentative ETA for these issues is 2020’Q1.

The issues you have found earlier (filed as SLIDESNET-41023,SLIDESNET-40996) have been fixed in this update.

Good afternoon,

In reference to SLIDESNET-40996; I have upgraded to Aspose Slides 20.8 via Nuget. Please can you advise me what property I need to set to enable ExportDocumentStructure?

Thank you,

Stan

@modern.gov

I suggest you to please try using following option in PdfOptions class on your end.

PdfOptions.Compliance = PdfCompliance.PdfUal;

Good morning Mudassir,

Thank you, I’ve checked the Aspose.Slides.Export.PdfCompliance enum and I only have ‘PdfUa’, I assume this is what you are referring to, but please can you clarify?

While this solution is fine if it exports the document structure, I was suprised as both Aspose.Words and Aspose.Sheets have an property ‘bool ExportDocumentStructure’ on their Options class so I had assumed it would be consistent; but as I say, if it does the job then that is fine.

Many thanks,

Stan

@modern.gov

Yes, you are right as it was a typographical error. Please check this link for your kind reference.

Secondly, you are right. We try to maintain as much uniformity as possible in our APIs for easy utility but sometimes things are implemented differently inside and hence have different ways to use.