Affinity By Canva

With the release of Affinity by Canva, I was curious how they were doing on supporting creating accessible PDF output. A very quick cursory initial check showed some hopeful signs, but I wanted to take a more detailed look, so I’ve put together a brief test document to check some of the more common document features. This isn’t at all meant to be all-encompassing and comprehensive; it’s just what popped to mind as I was experimenting. My hope is to occasionally update this as I think of more test cases (or have more test cases suggested to me) and as Affinity is updated.

More details are in the document itself, but in brief, I set up several test cases using various Affinity features, exported to tagged PDF, and checked the PDF in Acrobat to see how things looked.

If you’d like to play along at home, you can download the source .af document (5 MB .zip) and the exported .pdf document (721 KB .pdf) to review yourself and otherwise do with as you wish under a Creative Commons BY 4.0 license.

The executive summary TL;DR: Canva/Affinity is making improvements, but Affinity in its current state is definitely not ready to be a replacement for Adobe InDesign. If you’re an Affinity die-hard and have the time and resources to do remediation work in Acrobat Pro or using a tool like CommonLook, you could certainly go that route, but don’t expect to be able to export an accessible PDF from Affinity just yet.

I do want to be clear that none of this is to say that Affinity is “bad” or shouldn’t be used; on the contrary, I’m looking forward to using it as much as I can (for experimentation and any print-only work I do). This is all intended to encourage Canva/Affinity to continue working on this aspect of their software.

Test Case 1: Paragraphs

Result: Fail. Any paragraph that is more than one line gets one P tag for every line, rather than one P tag for the entire paragraph. In addition, if there are any deviations from the base style (using character styles, manual formatting, adding hyperlinks, etc.), all of those end up in their own individual P tags instead of being wrapped in Span tags inside the P tag.

Test Case 2: Headings

Result: Pass (with qualifications). When creating styles, PDF (and EPUB) export tagging can be assigned — as long as you only need P or H1 through H6; no other tags (like BlockQuote, for example) can be assigned to styles. Within that, though, text given a heading style does export with the correct tag…but once again, if the heading spans more than one line, it ends up being two H1 (or whatever level) tags rather than one.

Test Case 3: Images

Result: Pass/Fail (yes, both).

Pass: Images can be placed inline or floated; if floated, they can be anchored within text. Alt text can be assigned various ways, either manually or (in theory, I didn’t test this) automatically pulled from the image’s XMP metadata. The alt text pane also supports adding extended description and summary text, though I haven’t played with these fields yet. Alt text is correctly added to the Figure tag in the PDF.

Fail: Though the images were placed inline with the text in the document, the Figure tag was placed at the end of the content for its parent text frame rather than at the proper place within the text.

Test Case 4: Lists

Result: Fail. Lists are tagged as paragraphs, without any L or child LI, LBL, or LBODY tags.

Test Case 5: Languages

Result: Fail. I could not find any way to designate a base language for the document as a whole. Character and paragraph styles can be given a language setting, but (in addition to the character style being tagged as a new P rather than a Span within the paragraph) the language is not set in the tag properties.

Test Case 6: Tables

Result: Fail. Simple tables can be added and their visual presentation can be adjusted, but I found no way to set header rows or columns. Tables also cannot be given alt text (at least, not with the same Tags pane used to add alt text to images).

The table was not tagged with any Table or child TR, TH, or TD tags, just a lot of P tags. In addition, though the table was inline with text later in the document, it was placed as a Sect at nearly the top of the document, the first tags underneath the opening H1 tags.

Test Case 7: Table of Contents

Result: Fail. Affinity can automatically generate a table of contents from the header styles used in a document. However, the exported PDF does not use any TOC or associated child tags; every line of the table of contents is a P tag followed by a Link tag that contains two Link - OBJR tags, one for the text of the item and one for the page number.

Test Case 8: Reading Order

Result: Pass (with qualifications). Affinity has a Reading Order panel which allows you to rearrange items, group items together into articles, and toggle items off and on, and this does properly affect the tags in the exported PDF. In an earlier test document (not publicly distributable), I was easily able to put all of the objects in their correct reading order. However, in this test document, the images (which are placed inline with the text, and therefore within a text frame) don’t appear in the reading order panel, and as noted above, don’t have their Figure tags placed in the correct location.

Test Case 9: Master Pages

Result: Pass. My test document had master pages set up with footer text; this text was properly excluded (artifacted) in the PDF.

Test Case 10: There is no test ten…

…because I ran out of ideas right then. But more can be added! When I have time, I want to add more objects to play with the reading order pane more, explore Affinity’s footnotes/index/reference support (which at this point I don’t expect to be tagged correctly, but maybe someday), and there are probably plenty of other things that more experienced accessibility and/or document creation professionals might think of.

Conclusion

As noted in the TL;DR up top, Affinity is a long way away from being able to replace InDesign when it comes to creating accessible PDFs.

That said — they’re working on it! This is more support than the last version of Affinity had, and there are more signs here and there that more may be in development. For example, while I was looking for a way to specify a base document language, I checked the File > Document Metadata option, and it’s a series of checkboxes and fields for specifying exactly which accessibility features a document supports, its conformance level, a certifier’s name and credentials, and so on. (The actual basic document metadata, including title, author, copyright info, etc., can be set with the Window > References > Fields pane, and does get properly added to the exported PDF.)

While there’s certainly work to be done, I’m encouraged to see the features that have been added so far, and as noted above, want to encourage Affinity to continue working on this aspect of the app. I would love to be able to finally drop InDesign (as I dropped Photoshop and Illustrator years ago) and move entirely over to Affinity (well…entirely aside from Acrobat…).

Addendum: ePub output

Out of curiosity and a question on Mastodon (that I don’t actually think was directed at me, but that’s okay), I exported this test document to ePub format, using both the “fixed layout” and “reflowable” options. I then checked each file in both Thorium Reader and Apple’s Books app, and ran them through the Ace by DAISY ePub accessibility checker.

It should be noted that I did not change anything about the file for this test, and I created the document with PDF in mind, not ePub, so this may affect the results.

I’m not as experienced in checking ePub files, but a few notes:

Ace by DAISY reported errors with both documents. The fixed layout version had eight errors, three serious and five moderate; the reflowable version had 22 errors, one critical, 16 serious, and five moderate. The ePubs and Ace by DAISY reports may be downloaded for you to review. All downloadable files are .zip files that you’ll need to decompress — I know that ePubs are already zipped, but my WordPress configuration wouldn’t allow me to upload the .epub file.

The fixed layout version is much larger than the reflowable. I think that’s because the reflowable version seems to have scaled and compressed the photos in the document, while the fixed layout version left them at their original sizes. This may have been an export setting in Affinity that I didn’t adjust.

Neither document has bookmarks automatically defined.

The fixed layout version in Thorium using Thorium’s built-in reader reads the images outside of their placement in the text, instead speaking them at the beginning of the second page. The table on page three also gets read at the beginning of the third page. This does not happen with the reflowable version; images are read in their correct locations.

There’s an odd black square graphic that appears at the end of the Test 3 section in the reflowable version that is not present in the original Affinity file. I have no idea where this image is coming from.

Using Apple Books’s built-in reader, the reflowable version seemed to read properly, but the fixed layout version was missing large chunks of text.

With the aforementioned caveat that this document wasn’t created with ePub in mind, which may be affecting things, my first impression is that, as with PDF tagging, Affinity has some work to do with creating accessible ePub files. This is definitely an app that currently is much more aimed at visual presentation (whether print or electronic), with accessibility being an afterthought. Once again, I hope this improves over time as future versions are released.

I’ve been an Affinity Photo/Designer/Publisher user since sometime before 2019 (the first mention I can find here), and have recommended them to a lot of people as a less expensive but (nearly) equivalent alternative to Adobe’s Photoshop/Illustrator/InDesign suite of apps. Last year Affinity was acquired by Canva, which did not thrill me (I’m not a fan of Canva, as accessibility has never seemed to be a high priority for them, and remediating PDFs created by Canva users is an ongoing exercise in frustration), but at the time they pledged to uphold Affinity’s pricing and quality. All we could do at that point was wait to see what happened.

A few weeks ago, Affinity closed their forums, opened a Discord server, removed the ability to purchase the current versions of the Affinity suite of apps, and started posting vague “something big is coming” posts to their social media channels and email lists. Not surprisingly, this did not go over well with much of the existing user base, and we’ve had three weeks of FUD (fear, uncertainty, and doubt), with a lot of people (including me) expecting that Canva would taking Affinity down the road of enshittification.

Yesterday was the big announcement, and…

The Affinity by Canva startup splash screen.

…as it turns out, it looks to me at first blush that it doesn’t suck. The short version:

Affinity Photo, Designer, and Publisher have been deprecated, all replaced with a single unified application called Affinity by Canva.
1. The existing versions of the old Affinity suite (version 2.6.5) will continue to work, so existing users can continue to use those if they don’t want to update. In theory, these will work indefinitely; in practice, that depends on how long Canva keeps the registration servers active and when Apple releases a macOS update that breaks the apps in some way. Hopefully, neither of those things happens for quite some time (and if Canva ever does decide to retire the registration servers, I’d really hope that they’d at least be kind enough to issue a final update for the apps that removes the registration check; I don’t expect it, but it would be the best possible way to formally “end of life” support for these apps).
Affinity by Canva is free.
1. You do need to sign in with a Canva account. But you had to sign in to Affinity with Serif account, and Canva now owns Serif, so this isn’t exactly a big surprise for me.
The upsell is that if you want to use AI features, you have to pony up for a paid Canva Pro account. Assumedly, they figure there are enough people on the AI bandwagon that this, in combination with Canva’s coffers, will be enough to subsidize the app for all the people who don’t want or need the AI features.
1. “AI features” is a little vague, but it seems to cover both generative AI and machine learning tools.
2. Affinity’s new “Machine Learning Models” preferences section has four optional installs: Segmentation (“allows Photo to create precise, detailed pixel selections”), Depth Estimation (“allows Photo to build a depth map from pixel layers or placed images”), Colorization (“used to restore realistic colors from a black and white pixel layer”), and Super Resolution (“allows pixel layers to be scaled up in size without loss of quality”). Of these, Segmentation is the only one that currently is installable without a Canva Pro account; the other three options are locked. The preferences dialog does have a note that “all machine learning operations in Affinity Photo are performed ‘on-device’ — so no data leaves your device at any time”.
3. The Canva AI Integrations page on the new Affinity site indicates that available AI tools also include generative features such as automatically expanding the edges of an image and text-to-image generation (interestingly, this includes both pixel and vector objects).
4. In the FAQs at the bottom of the integrations promo page, Canva says that Affinity content is not used to train AI. “In Affinity, your content is stored locally on your device and we don’t have access to it. If you choose to upload or export content to Canva, you remain in control of whether it can be used to train AI features — you can review and update your privacy preferences any time in your Canva settings.”
  1. If you, like me, are not a fan of generative AI, I do recommend checking your Canva account settings and disabling everything you can (I’ve done this myself). The relevant settings are under “Personal Privacy” (I disabled everything) and “AI Personalization”.
5. I actually feel like this is an acceptable approach. Since I’m no fan of generative AI, I can simply not sign up for a Canva Pro account, disable the “Canva AI” button in Affinity’s top button bar, and not worry about it; people who do want to use it can pay the money to do so. I do wish there was a clearer distinction between generative AI and on-device machine learning tools and that more of the on-device machine learning tools were available without being locked behind the paywall; that said, the one paywalled feature I’d be most likely to occasionally want to use is the Super Resolution upscaling, and I can do that in an external app on the occasional instances where I need it.

So at this point, I’m feeling mostly okay with the changes. There are still some reservations, of course.

I’m not entirely sold on the “single app” approach. Generally, a “one stop shop” approach tends to mean that a program is okay at doing a lot of things instead of being really good at doing one thing, and it would be a shame if this change meant reduced functionality. That said, Affinity has said that this was their original vision, and they’ve long had an early version of this in their existing apps, with top-bar buttons in each app that would switch you into an embedded “light” version of the other apps for specific tasks, so it does feel like a pretty natural evolution.

A lot of this does depend on how much trust you put in Canva. Of course, that goes with any customer/app/developer relationship. I have my skepticism, but I’m also going to recognize that at least right now, Canva does seem to be holding to the promises that they made when they acquired Serif/Affinity.

Time will tell how well Canva actually holds to their promises of continuing to provide a free illustration, design, and publishing app that’s powerful enough to compete with three of Adobe’s major apps. Right now, I’m landing…maybe not on “cautiously optimistic”, but at least somewhere in “cautiously hopeful”.

Finally, one very promising thing I’ve already found. While I haven’t done any in-depth experimenting yet, I did take a peek at the new Typography section, and styles can now define PDF export tags! The selection of available tags to choose from is currently somewhat limited (just P and H1 through H6), but the option is there. I created a quick sample document, chose the Export: PDF (digital – high quality) option, and there is a “Tagged” option that is enabled by default for this export setting (it’s also enabled by default for the PDF (digital – small size) and PDF (for export) options; the PDF (for print), PDF (press ready), PDF (flatten), PDF/X-1a:2003, PDF/X-3:2003, and PDF/X-4 options all default to having the “Tagged” option disabled).

When I exported the PDF (38 KB PDF) and checked it in Acrobat, the good news is that the heading and paragraph tags exist! The less-good news is that paragraphs that go over multiple lines are tagged with one P tag per line, instead of one P tag per paragraph.

So accessible output support is a bit of a mixed bag right now (only a few tags available, imperfect tagging on export), but it’s at least a good improvement over the prior versions. Here’s the current help page on creating accessible PDFs, and hopefully this is a promising sign of more to come.