|
|
Rank: Advanced Member
Groups: Member
Joined: 11/8/2017
Posts: 74
|
Hello, I have generated a PDF with the latest version on EO-PDF (25.1.22, using GenerateTags=true) and using PAC (PDF Accessibility Checker - https://pac.pdf-accessibility.org/en) to validate my generated PDF - after opening the PDF in PAC then when viewing the "Results in detail" I am receiving a lot of "Path object not tagged" (under PDF/UA | Basic Requirements | Content | Tagged Content and artefacts) from my SVG's - an example below
Code: HTML/ASPX
<svg xmlns="http://www.w3.org/2000/svg" width="100%" role="img" aria-labelledby="title-pl-639b5cb3-43c3-4f87-a4d3-cb433413bc6a desc-pl-639b5cb3-43c3-4f87-a4d3-cb433413bc6a" height="1.716in">
<g>
<rect x="0" y="0" width="100%" height="100%" fill-opacity="0.0"></rect>
<title id="title-pl-639b5cb3-43c3-4f87-a4d3-cb433413bc6a">My title</title>
<desc id="desc-pl-639b5cb3-43c3-4f87-a4d3-cb433413bc6a">My description</desc>
<rect x="5%" stroke="#000" stroke-width="1" class="my-class" y="0.46499999999999997in" width="48.675324675324674%" height="0.25in" rx="0.125in" ry="0.125in"></rect>
</g>
</svg>
Is this something that should be hidden as decorative by EO-PDF (as per https://www.w3.org/WAI/WCAG21/Techniques/pdf/PDF4) ?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,342
|
Hi,
It's not possible to support tags on SVG path because of the way Chromium associates tags to an HTML node through an internally generated node Id. This ID only exists for real DOM nodes which makes it impossible to generate tags for internally generated nodes (such as pseudo nodes created by the rendering engine to render a list number or bullet). It is done this way because the tags are implemented together with accessibility data, and accessibility data exists on the element (such as aria-xxx attributes).
In the case of a SVG path, the path is not a DOM node/element. So the internal node -> tags association can not be established. As a result no tags are generated.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/8/2017
Posts: 74
|
Thanks for the reply - given your explanation is it possible to tag parts of the SVG (aria/role/id) within the HTML to allow the PDF accessibility checker (PAC) to ignore ... or perhaps is there scope within the EO-PDF API (that we could leverage) to detect these nodes (pre or post generation) to allow PAC to ignore/not-flag?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,342
|
Hi,
Not without extensive code changes to the Chromium browser engine. Tag is only a part of the much bigger accessibility support which also covers other things like screen reader. The underlying accessibility support mechanism does not go into the SVG --- so it is impossible for the higher PDF tag layer to get any information from anything inside the SVG. In order to achieve that, the entire accessibility support layer has to be extended to go into SVG. Obviously this is something that is both impractical and risky.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/8/2017
Posts: 74
|
Ok thanks for that - I understand the complexity unravelling the SVG structure when rendered within a PDF. I realize that it is very difficult to automate making decisions to mark/unmark these objects as they are in separate parts, however is there a way to at least access (read and potentially update) the raw (perhaps unparsed) PDF/SVG objects (rect, etc) via the EO-PDF API. Note I'm not expecting these to be in any class structure - even just the raw (PDF markup) text would be a start
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,342
|
No. There is no such interface. As you would expect, once the SVG is rendered, it's rendered into a serial of painting instructions such as Path, Stroke, Fill, etc, but they are mixed in together with everything else on a page. Without proper tag information, there is no easy way to direct associate any of those painting instructions to a specific SVG node. Beside such raw data are not exposed through our API because we need to manage them internally (for example, to merge them when we add additional output to a page), so allowing user code to modify them directly would cause problems with such features since they would not be aware of the underlying data has been modified externally.
|
|