The tags and reading order would be created when the PDF is exported from the source design/layout program.
We "assign" tags in the layout, but they don't actually get created until the PDF is being exported.
Affinity already knows how to make a PDF because any software that creates any kind of PDF must follow the international standards for PDFs called ISO 32000. Any PDF must be made to the standard so that the PDF file can be read or viewed by any brand of PDF reader. This is very common in the manufacturing and software world. It's crucial in printing as we see with out PDF/X requirements (another international standard from the ISO for press-quality PDFs).
All Affinity has to do now is add the standards for PDF/UA ISO 14329, an extended version of the PDF standards that includes the requirements for accessibility in a PDF, such as tags and reading orders.
They've already built their programming engine to create general PDFs, now add in the accessibility requirements. I won't be rude and say it's easy for Affinity to do that, but it's not that complicated, either. The hardest part is making the fricking PDF itself to begin with, and they've already done that.
@sheriffderek, since you already know HTML and CSS, let me make a comparison that could help put this into perspective.
HTML requires that standard tags be used to encase all parts of the content, like <p>, <h1>, <h2>, etc. You can't publish a webpage without having your content tagged.
Desktop publishing, on the other hand, has traditionally NOT required this type of tagging, unless you were specifically doing XML, SGML, or tagged content publishing. Tags and accessibility are relatively new to the graphic design industry.
In websites, CSS is what's used to style the content, instructing a browser to take all <p> content and use Source Sans font, for example. Or take all <h1> content and color it RBG ## ## ##. Web developers design with CSS.
CSS is directly like what we do now with our Affinity Publisher paragraph and character styles: we define how a particular portion of text will look, its font, color, alignment, size, etc. — just like CSS does in HTML.
At this point, Publisher doesn't let us designate what tag to put on each type of text. Styles are the most convenient way to do this, as Adobe InDesign has shown for the past decade. As a graphic designer, I need to make a style for my subheadings that specifies Roboto Bold, 24 pt on 26 pt leading, left aligned, no hyphenation — and also tag it as <h2> when the PDF is exported.
We don't put tags inside the desktop publishing layout— no accessibility tags are in the layout. Instead, we give the instructions to add the tags when the PDF is exported. (Note, this is NOT XML, which does tag the content in the layout. PDF Accessibility tags are not XML tags.)
So Affinity needs to expand their current PDF-export utility to include accessibility tags and reading order, and then give us a way to assign the tags and control the reading order in our layouts.
And as a bonus, they could port that utility over to Designer, giving us the ability to make accessible info graphics and small projects in that program, too.
If Affinity did that, eat your heart out Adobe! 😁 Illustrator doesn't have a shred of accessibility in it.
Imagine if we designers had both layout and graphics programs that could make accessible PDFs.
Wow. Game changer for the industry.
—Bevi Chagnon / PubCom.com
Designer | Teacher | Author | Expert for Accessible Documents
Learn about accessibility at our free blog, www.PubCom.com/blog
US Delegate to the ISO committee for the PDF/UA standards.
Advisor and beta tester to software companies for building accessibility tools.
Any chance this is going to be supported in future? I use Wordsflow with all my publishing clients and can't live without it. It's probably one of the main reasons I'm not able to migrate from InDesign to Affinity just yet.
Adding my support for this request -- it would be extremely helpful to be able to link even to text documents, because I have a situation where I want to publish a couple of different layouts of the same text, and right now if I do that, everytime I change one, I have to go into each of the others and make the same change there. If it was possible to link to a text file that I could update and have those changes be automatically made in my Publisher documents when I open them, that would be amazing.
When exporting to PDF using a set of bookmarks based on my Table of Contents, the bookmarks seem to come out okay, but they are out of order -- bookmarks for the middle of the document are at the top of the bookmark list, followed by some for the beginning, and so on. I can't find any logical order for them right now.
Is this a bug, or am I doing something wrong when generating these?