HawaiiAna

I want to add some information here. PAC is (much) more strict than necessary. PAC2024 is even worse than PAC2021 when it comes to unnecessary failures and warnings that don't add anything to accessibility (WCAG) in my opinion.
According to European law only WCAG rules should be applied to digital documents like PDF (clause 10 of the EN301549). PDF/UA is an official standard for PDF, but it's not required in the EN301549 (EU) or section 508 (US).
Something like the "alternative description" on a Link-tag that PAC and PDF/UA require is not needed for WCAG or for accessibility. In fact, if screen readers would be able read that attribute it would probably cause extra problems. It would either replace the link text or add something to it. Better to have just a good link text.
The "missing Bounding Box" attribute isn't part of PDF/UA (ISO 1.7) or WCAG as far as I know. I have found some comments on bounding boxes in general in that ISO. And I found also that extra attention must be paid to bounding boxes of tables and figures, but it wasn't clear to me if that extra attention is part of the PDF reader (like Acrobat) or the PDF creator. It's not in the Matterhorn either (list of failures in PDF/UA). Anyway, I couldn't find anything that would explain why PAC treats a missing Bounding Box attribute on a tag as a failure. The only failure I have encountered in my work as an auditor and remediator of PDFs is when a Figure tag points to the wrong part of the visible page. That can be fixed by putting the Bounding Box attribute on that tag and to make sure it points to the right section of the visible page. But that seems to be a rare problem.
I do agree with what Layoutman said about the other problems like placement (block or inline) of objects and the many problems caused by InDesign with span tags and story tags. It would be wonderful if Affinity Publisher could do a better job.

I make accessible PDFs, because my best customers cannot any more accept anything else. The situation has been here the same over 2 years. That's declared by the rules how public money can be consumed. 
Adobe Indesign offers a way to make PDFs which Adobe call "Accessible". Hopefully Serif succeeds to avoid copying the inferior solution of Adobe. Let me explain some of the most idiotic features of the Adobe solution:
The result is not Accessible - no matter what Adobe Acrobat accessibility checker happens to write. Actually Adobe has understood how to avoid lawsuits. Acrobat doesn't claim anything accessible. It says only "No errors were found". As useful as a blind chicken!
The result does not fulfill formal PDF/UA nor WGAC accessibility criterions. A good formal accessibility tester is PAC 2021. Virtually any image, link, table ad form field is tagged wrong by Indesign and must be manually fixed in Acrobat. Especially often attribute objects bounding box and placement  are missing or wrong. Unfortunately fixing manually is not so easy. There are at least as many errors as there's images, links tables and form fields. In addition the the tag tree is full of Span and Story tags. The tags which need fixing are hidden deep.  It's much easier to tag say 100 page book manually in Acrobat than to fix the mess generated by Indesign.
A big part of the problem is Adobe's idea to use text styles as the basis of tagging. Layout artists hate it. (I like use a couple of them because their artistic ability and stylistic confidence is a high boost of what I can deliver).
In Indesign any piece of text must in any case to be selected  in Indesign and marked to be included to the tagged content. It would be a gift from the heaven if  the used tag could be inserted in this phase and the tagging by text style could be totally skipped. If someone really wants the story and span tag -jumble caused by tagging by text style -idea I gladly like to let him continue in his masochism, but I do not want the same. That's way I tag manually in Acrobat. 
Tagging in Acrobat has a drawback. The customers often want to make content changes. They do not understand why in the hell I do not give already the first version as an accessible PDF, but before making the tagged PDF I require an email confirmation "this version is final and the next change will be paid separately"
The customers have learned to require some quality. Many of my rivals are dropped because
- some of them only said "this PDF is accessible" I reality there could be say 100 red and 200 yellow errors in PAC2021 checklists and the screen reader simulation could be unreadable.
- some of them did not lie, but they do not know how to convert PDFs accessible in Acrobat or have found it too difficult.
Today the customers do not accept a single red nor yellow error in PAC2021's PDF/UA nor WGAC checklists. In addition the PAC2021's screen reader simulator must show a simple linear layout which contains proper captions and alt texts for images and links. The text level must not change randomly. A single paragraph must look a single paragraph.
Adobe stuff costs too much. Your products are more affordable and the developments in ver.2 make also professional usage meaningful. Hopefully this happens also in the field of accessibility. But do it properly, without copying the Indesign approach.
 

From today's newsletter: "The Tags Panel in Affinity Publisher 2.3 is just the start of a series of improvements we’re making to PDF accessibility. Upcoming updates will provide support for reading order, heading tags and other document structure tools that will further enhance your PDFs."
How AWESOME is that? Thanks, Serif team!

From today's newsletter: "The Tags Panel in Affinity Publisher 2.3 is just the start of a series of improvements we’re making to PDF accessibility. Upcoming updates will provide support for reading order, heading tags and other document structure tools that will further enhance your PDFs."
How AWESOME is that? Thanks, Serif team!

I'd like to bring Serif's attention to this issue one more time.  I just find it interesting that this topic was opened in 2018, almost 5 years ago and here we are 2023. There was v2 in November but this most important issue was not addressed. 

Would be nice to get some response here from the Company. Hellooo
 
 
 
@Serif Info Bot

I've been focusing on HTML and web-specific accessibility tree type things, but this year I attended CSUN conference and learned a bit more about PDF accessibility.
I'm trying to think through the steps that would be needed.
When creating documents, we already use paragraph styles. Those aren't necessarily semantic, however they aren't a big leap from tagging things. I'm laying out a pricing sheet in Publisher right now (which is fairly simple) - but as an example, if there was a panel like the paragraph styles panel - but with h1, h2, h3, h4 - (or however they do it in PDF land) - it would be quick to select the headings and assign them to their respective hierarchical tags. There could be a panel for "Assistive technology"  and it could be like the "appearance" panel / and contextual. Whatever was selected could have its options. An image could have alt text. A block of text could have optional headings. Given that there's a history panel - and we're able to record state and key: value pairs for just about everything - I'd be curious what the hold up is here. Is it a gap in the real-world reasoning for how it works? (as you can tell - I don't know either / on the actual PDF output side) (or the legal side) - But as someone who would use a screen-reader or braille reader to read a basic PDF document, that part seems like something we can illustrate to help move this forward.
As it stands, Publisher can't be used to create official (legal) digital documents for any company - unless you plan on sending them out for remediation.

Accessible files can be accessed, read, processed, and used by those with disabilities who must use assistive technologies with their computers: they include screen readers, magnification software, dyslexia software, and mobility software (when someone can't operate a keyboard or mouse).
Accessible ICT (Information Communications Technology, such as PDFs, EPUB, digital media, websites) is required by the governments of most industrialized countries; it is usually part of the country's civil rights and equal access to education legislation, such as the ADA in the US. See this world map for details: https://www.3playmedia.com/blog/countries-that-have-adopted-wcag-standards-map/  But note that many more countries are in the process of formally adopting the standards and are already producing accessible files.
The United Nations and other non-partisan international organizations promote accessibility because nearly 1/3 of the world's population has a disability or impairment that prevents them from reading and using digital content. See https://www.karlencommunications.com/DisabilityRights.html
Accessibility means any type of file that is available digitally, whether via a website or other type of media, must meet the accessibility requirements spelled out by the PDF/UA-1 standards (for PDFs), WCAG 2.1 (for websites), and EPUB 3 (for EPUBs).  From Affinity Publisher, it would apply to PDFs and EPUBs made from Publisher layouts.
The standards are international: individual countries pass the legislation that requires the various accessibility standards to ensure that no citizen is prevented from accessing and reading digital information, such as textbooks for school, financial and legal paperwork, user manuals, employment/school/work applications, news, libraries/research ... just about everything we all read and/or download from the web.
Graphic designers create the bulk of this type of content, and right now, only MS Word, Adobe InDesign and QuarkXPress have tools to export tagged, accessible PDFs.
There's an opportunity for Affinity to add accessibility tools to Publisher and create a solid competitor to InDesign. I can't begin to count the number of designers who work for governments (national and local), academia (preschool through post-secondary), or for major industries that are required to have accessible ICT.  They're stuck with InDesign because it's the only viable tool right now.
They'd jump ship in a heartbeat if Affinity gave them accessibility tools in Publisher.
—Bevi Chagnon / PubCom.com
Trainer, consultant, and book author for accessible documents.
US Delegate to the ISO committee for the PDF/UA standards.
Advisor and beta tester to software companies for building accessibility tools.

@erssie, you could try the Pave website to change the PDF that Affinity produces into an accessible one. 
https://pave-pdf.org/?lang=en
They offer a free online tool which might be the best option for you.
Accessible PDF's is more than just the alt-texts. You'll need tags so a screenreader can easily read the text. If there are any headings, lists or tables in it the tags will show that to the screenreader, just like on a website. Even if your blind group members tell you it's fine without them it still might cause a problem when someone uses a different PDF reader. Pave should be able to fix that for you.
To check the PDF when it's finished the also free PAC tool might help. It's what most people working in accessibility use to check PDFs.
https://pdfua.foundation/en/pdf-accessibility-checker-pac/register
This tool is simple to use, but make sure you read the manual to understand the outcome. Just ask here if you have questions and I'll try to help, because I don't think you'll need to fix everything that PAC shows as a fault. It's a bit too strict.

I'm not a company, I'm just little ol' me but I design knitting patterns for charity. Some of them include charts and diagrams. Blind people do knit but those charts/diagrams are often inaccessible. I've just spent a few very long days translating a charted design into line by line instructions for knitting the stitches, and in my rough pattern in Word I have my alt text descriptions on my photographs etc. Word creates a pdf that my blind knitting group have told me is working with alt text on the photos etc. I would now like to lay that out in Affinity Publisher, was struggling as I am new to it, and could not find a place to put a text description of a photo, so have ended up here. I still want to do my work in Affinity Publisher and would like to avoid using Adobe products although i have a free Acrobat Reader DC. I understand that Affinity is not going to give me an accessible pdf as far as trying to put alt text to my photos, which is a shame. But if I create a PDF from Affinity, will it be editable by any editor to add the descriptions on photos afterwards to comply with various screen readers or Read Aloud software? And does that mean Id have to subscribe to a PDF Editor. I have spent days and days, with a hand disability and needing a lot of support, to try and make my patterns accessible. I'm willing to do what it takes, and I am not a company just an individual, but its frustrating to not find the tools to do so. And I cannot afford Adobe subscriptions or other ones out there, which is why I purchased Affinity. I was going to volunteer as well, free of charge as I work so slowly with my disability, to translate others knitting patterns or craft literature into accessible documents so that people with impaired vision can easily listen to instructions and knit along at the same time. I'm scared that I might get prosecuted in the future for doing that if I don't have the right tools. It'd be a crying shame if I have to go from doing my own layouts to just using Word again. That is an awkward thing to use, I hate it. I'm already complying with regards to text size, type and layout to standards set for knitwear designers, its just the alt text thing I can't do. I also cannot afford to pay accessibility editors to do it as I am volunteering anyway.
Can someone tell me where after Affinity they are going to put their alt text on? And if its not available automatically, can I just put a readable caption below/or above the photo in line with it for it to be read out? 

To add to @JohannaH's great list of resources, for anyone new to PDF accessibility and would like to know more:
AccessAbility 2: A Practical Handbook on Accessible Graphic Design | RGD  A good and brief overview of how typography, colour and language affect accessibility (digitally, and in print) It has some short guides for making accessible PDFs from InDesign or Word (+Acrobat) It also has a really useful section on how to convey the benefits of prioritising accessibility to bosses, stakeholders and co-workers As a side-note, the PDF document itself (now) also functions as a good example of tag structure and use of alt text  WebAIM: Alternative Text For me, alternative text (or alt-text) is frequently the part that stumps me the most WebAIM's guide gives a good outline of the "What", "When", "Where" and "How" of writing alt-text, with examples Accessible-PDF.info A good resource for troubleshooting! Last of all, my biggest (subjective) tip – sometimes the most accessible PDF may be no PDF at all... by which I mean:
Explore what the best format(s) for the digital output of your project is going to be, before defaulting to PDF: A well-structured HTML document is the gold standard for accessibility, and offers the most flexibility for users to tailor the content to their specific needs A "reflowable" EPUB3 is basically a portable HTML document For your content, there may be fewer steps involved in making a well-structured and accessible HTML or EPUB3 document Tools for creating accessible HTML and EPUB3 documents are far more widely available (and free) As a user-friendly way for writers to generate structured HTML documents from plain text, consider incorporating Markdown – as used by the online tool AROW, for example Not everyone can afford a subscription to Creative Cloud (or even Acrobat Pro on its own)! Only share information as a PDF if you absolutely have to ...and provide the important information in an alternative format, such as – you guessed it – HTML and/or EPUB3 Not to say PDFs aren't useful (they're not going anywhere) – but asking this question at the beginning could save you a lot of unnecessary headaches later.
Also – as @JohannaH highlighted, and many weary PDF remediators will tell you – Acrobat Pro and InDesign / QuarkXpress / MS Word don't represent the best, simplest, or most intuitive processes for creating accessible documents. They are just the least-worst tools available, and these are just useful guides for making the most of them Keep pushing for better tools!

absolute necessity... besides it also is HTML & CSS thus web and ePub.  win Win WIN....

I totally agree with others on this subject. It's part of my job to check accessibility of PDFs. And most of them aren't accessible.
But according to the law all content on a government (related) website in my country (part of the EU) and many other countries should be accessible. So that includes all PDFs on that website. Of course there is an exception for old documents. But new PDFs just have to be properly tagged so a screenreader is able to use it and read it to a blind person. And when that's the case, then it is usually also accessible to other tools used to help people to read or understand digital content.
Within a bit more than a year the process of making all content on all websites in the EU will start and in June 2025 all company websites have to be accessible except the ones from very small companies. https://en.wikipedia.org/wiki/European_Accessibility_Act
If Affinity doesn't solve this problem it will be impossible for designers to use this software as their products can not be published on websites anymore. We would be left with Adobe products just because they do have tags in PDFs, not because they are very good at it, they are not.
I love all Affinity software, but I have to use other software to create accessible PDFs, like Adobe Acrobat, MS Word, Axes4 (Word Plugin and PDF QuickFix). I want to use Affinity!!
Affinity team, please add tagging to creating PDFs!
And please have a look at other things like a contrast checker, a checker of the the headings, and so on.
Here you'll find some info:
https://www.pdfa.org/wp-content/uploads/2019/06/TaggedPDFBestPracticeGuideSyntax.pdf
https://www.pdfa.org/wp-content/uploads/2014/06/MatterhornProtocol_1-02.pdf
https://www.axes4.com/resources.html
https://www.access-for-all.ch/en/pdf-accessibility-checker.html
https://www.access-for-all.ch/en/pdf-accessibility-checker/vip-pdf-reader.html

I totally agree. I don't know many designers who even know it's possible to create an accessible PDF, or what it actually means. But everyone gets it for web work. I can't see a single disadvantage of PDFs were created to be accessible by default.

I'd love to see Affinity Publisher support tagged and accessible PDFs from the ground up, ideally with full support for PDF/UA. Many institutions and government bodies require this for public documents, and making it part of the program's logic could be a major selling point.
I am not convinced that the way in which InDesign implements this in is the best way of going about it; it tends to create a lot of extra work that most people don't bother with. Instead, it should be possible to use this structural information to make document creation more efficient and improve a print/Web workflow.

I'm a Mac user and trying to avoid going back to Adobe after enjoying the warm embrace of Affinity products, but now have a client asking for accessible PDFs. As a complete noob to tagging and making accessible PDFs, this question might seem naïve, but here we go. As Affinity products still can't generate accessible PDFs, is it possible to make a standard PDF from AfPublisher then "retro-fit" all the accessibility features in software like Foxit Pro?