Accessibility in Photo Product Editors: What We Learned from Testing 21 Services

September 2, 2025
A person using an orthopedic arm orthosis while typing on a laptop, symbolizing accessibility challenges in photo product editors.

Accessibility in web-to-print isn’t just about compliance – it’s about ensuring every customer can create and order products without barriers. We reviewed 21 photo product editors to see how well they support people with disabilities. Here’s what we learned – and why it matters for your business.

Introduction

Modern photo product editors power millions of personalized products every year – yet for many customers, they remain hard or impossible to use. Accessibility isn’t just a compliance checkbox; it’s a core part of product quality, conversion, and brand trust. That’s why we want to understand how leading editors support people with disabilities across the full creation flow.

In July 2025, we tested 21 representative services operating in different markets and product categories. Our analysis focused strictly on the editor experience itself – covering project creation, modification, and adding to cart. We deliberately excluded the surrounding e-commerce journey (navigation to the editor, cart, and payment) to isolate how the editor behaves.

We evaluated support for key disability groups – especially blind and low-vision users and people with motor impairments – because these groups expose the most complicated UX challenges in a canvas-based, highly interactive tool. For a flow to be considered independently usable, an editor needed to:

  • work properly with screen readers,
  • be fully operable without a mouse (keyboard-only or alternative inputs),
  • remain usable under magnification without hiding meaningful content.

Where patterns repeated across disability groups, we consolidated the findings to keep this article focused and actionable.

Analysis Assumptions

This analysis centers on evaluating the accessibility of the editing tools for users with different types of disabilities throughout the full project lifecycle: creation, modification, and adding to cart. The scope deliberately focuses on the editor components themselves; therefore, it excludes both the initial navigation through e-commerce to reach the editor and the downstream shopping cart and payment processes.

Disability groups that were taken into consideration:

Visual impairments:

blind person,

person with low vision,

person with color blindness.

Hearing impairments:

deaf person,

person with hearing loss.

Motor impairments:

person with limited hand and finger mobility (paralysis, amputations, coordination disorders, spinal cord injuries, neurological diseases),

person using alternative input methods (e.g., keyboard only, eye-tracking devices, switches).

Speech impairments:

person with articulation difficulties,

mute person or those using alternative forms of communication.

Cognitive, linguistic, and neurological impairments:

person with dyslexia, dyscalculia, dysgraphia,

person with autism, ADHD,

person with mental health conditions (e.g., anxiety disorders, depression, schizophrenia),

person with memory impairment, concentration problems.

Neurological impairments:

person with epilepsy and other seizure disorders, which may be triggered by flashing elements on the page.

When analyzing various solutions available on the market, we found that the conclusions for some disabilities were identical. Therefore, we limited the analysis itself, with detailed problems and solutions, to three categories mentioned below. The remaining categories were summarized at the end with a collective explanation regarding support for these groups of people.

Introduction to Detailed Analysis

For the purpose of categorizing the success criterion, to what extent a person with given disabilities is able to complete the process, we assumed that the following conditions must be met for a person to successfully create their project:

Blind → The editor must properly support screen readers and enable complete project design without using a mouse.

Low vision → The editor must significantly support screen readers and enable editor operation mostly without using a mouse, but we allow for some degree of mouse usage or visual perception of certain elements to be required. We particularly think of the project workspace here.

Additionally, editors should not have significant problems with color contrast, and zooming in on the page shouldn’t hide meaningful content.

Motor impairment → The editor must enable complete project creation without using a mouse.

Success criteria:

✅ – A person with the given disability group is able to independently use the editor to achieve a satisfactory result.

⚠️ – A person with the given disability group is able to use the editor to achieve a satisfactory result, assuming they do not use all functionalities, or their disability is not severely advanced.

⛔ – A person with the given disability group is not able to independently use the editor to achieve a satisfactory result.

Accessibility Analysis

For a more detailed analysis, check the notes at the bottom of this article ↓

No.Service NameLinkMain Market ServedBlind personLow visionMotor impairment
1CEWE Photo Worldhttps://cewe.plEurope (Poland, Germany, UK, etc.)⚠️
2Saal Digitalhttps://saal-digital.plEurope (Poland, Germany, UK, etc.)
3Empik Fotohttps://empikfoto.plPoland, Central Europe
4Snapfishhttps://snapfish.comGlobally (especially USA/UK)⚠️
5Shutterfly version 1https://shutterfly.comUSA, with significant exports to the UK, Canada, and Australia.
6Shutterfly version 2https://shutterfly.comUSA, with significant exports to the UK, Canada, and Australia.⚠️
7Mixbookhttps://mixbook.comGlobally (USA, Canada, Europe, Australia)
8Artifact Uprisinghttps://artifactuprising.comUSA, with global exports.⚠️
9Zazzlehttps://zazzle.comGlobally⚠️
10Photowebhttps://photoweb.frFrance, with limited shipping to neighboring countries.
11Ifolorhttps://ifolor.chSwitzerland / Europe
12Albellihttps://albelli.nlEurope (especially the Benelux, UK, France, Germany)
13Smartphoto FRhttps://smartphoto.frFrance / Europe
14MyPosterhttps://myposter.deGermany, Europe, USA
15Moonpighttps://moonpig.comGlobally (with local printing in the UK, USA, AU, IE)⚠️⚠️⚠️
16Piktohttps://pikto.comCanada, with global exports.⚠️
17Wonderblyhttps://wonderbly.comGlobally⚠️
18Framkallahttps://framkalla.comSweden⚠️
19Profotonethttps://profotonet.comBenelux (Netherlands)
20Rikordahttps://rikorda.itItaly
21VistaPrinthttps://vistaprint.esSpain / Globally

Conclusions from Detailed Analysis

As can be observed in the detailed report, the vast majority of editors are currently unable to offer users with disabilities meaningful use of the editors. The main problem or difficulty that manifests in editors is the workspace where users can customize their projects. If we want to allow users some degree of freedom, we can no longer effectively enable screen readers and mouse-free interfaces to modify the project. The only editor that could offer users independent use and project ordering was an editor with a very simplified interface, which essentially came down to forms where only content was filled in, while the product layout remained unchanged.

An additional conclusion is that the interface around the workspace is not currently well-handled everywhere to offer support for people with disabilities. This partly stems from the fact that even if we adapt this interface around, the user effectively cannot independently create the project and must rely on external assistance.

The most common form of mitigating this problem, the possibility of independently using an editor, is for companies to offer product design by company employees after photos are submitted in advance.

The detailed analysis is based on 21 specific services. However, during the exploration of this topic, we also used other editors, and the conclusions from those others, which were not specified here as concrete items, are also similar. This shows that the problem is indeed widespread.

Conclusions for Remaining Disability Groups

● Visual impairments → This group was covered in the detailed analysis.

● Hearing impairments → Photo product editors are applications that do not rely on audio materials. In some cases, video content may appear as tutorials demonstrating how to operate the editor; however, these instances are rare and considered optional elements. They are not essential for the proper use of the editors, so they have been omitted from this analysis.

● Motor impairments → This group was covered in the detailed analysis.

● Speech impairments → Photo product editors do not rely on speech, and such individuals should not have problems using editors.

● Cognitive, linguistic, and neurological impairments → Photo product editors often require numerous mechanisms allowing modification of user projects and complex interfaces, which may cause difficulties for people with these types of disabilities. This is certainly an area worth investigating. Nevertheless, it may be challenging to offer users the possibility of creating their dream project without providing these tools. We omitted this group in this analysis, recognizing problems already in other groups, but it is certainly worth returning to this area in the future. Especially since there is a chance that various AI solutions, which are developing very dynamically, will be able to help in this field significantly.

● Neurological impairments → None of the analyzed photo product editors relied on sudden interface changes, particularly flashing or frequently changing elements. Therefore, we determined that this does not pose a problem in using editors and did not specify this as a separate item in the report.

Summary

The analysis revealed that most photo product editors are not adapted to the needs of people with disabilities. The biggest challenge is the project workspace, which makes independent design difficult without a vision and a mouse.

Editors implementing functionalities that facilitate work with photo product editors are starting to emerge (for example, Shutterfly version 2). However, these solutions remain rudimentary and do not permit independent use of the editor.

Even the interfaces surrounding the workspace often fail to meet accessibility standards. Furthermore, even when they are adapted, they do not allow users to use the editor independently.

The accessibility of photo product editors requires further analysis and the search for solutions to resolve the problems currently faced by people with disabilities. However, this is certainly not an easy task, and it will take time before these issues can be effectively addressed in the field of online photo product editors.

If you’re facing similar challenges and want to explore how Printbox can deliver you the editor, which is both more inclusive and future-ready, get in touch with us – we’ll help you identify quick wins and map out a sustainable accessibility strategy.


Additional detailed information

More detailed information regarding the tests of individual solutions.

1. CEWE Photo World

  • A significant part of the application interface lacks textual descriptions (labels, aria-labels) for functions, which means that users relying on screen readers are not informed about the effects of interacting with a given element.
  • Image descriptions from the asset library are inaccessible or omitted; images do not have explanatory alternative texts.
  • The semantic layer of the code is insufficient – custom tags and SVG elements are often used, which complicates screen readers’ ability to properly present content.
  • The application allows navigation through the interface using the keyboard, but interaction with the main workspace (used for design) is practically impossible without a mouse – there are no keyboard alternatives.
  • The application handles pop-ups correctly, allowing full keyboard navigation and tabbing between active elements (including support for closing and moving between controls).
  • The application responds appropriately to changes in interface size. The layout is responsive, enabling comfortable use of the editor in an enlarged view.

2. Saal Digital

  • The editor’s application interface significantly lacks keyboard navigation support, making it difficult for users who cannot use a mouse to use the tool.
  • The semantic structure of the application primarily uses <div> elements, which do not provide a logical and readable presentation of content for assistive technologies.
  • Interactive interface elements do not have sufficient descriptions explaining to users what effect they can expect from interacting with a given element.
  • When zooming the page to 200%, the layout does not adjust properly, cutting off parts of the interface and making it difficult to access individual functions.
  • Most graphic elements do not have alternative text descriptions, which prevents blind or visually impaired individuals from understanding the visual content presented.

3. Empik Foto

  • The editor is not adapted for reading content by screen readers.
  • There is a lack of semantic elements in the HTML structure.
  • There are no descriptions of the actions of interactive elements or alternative text for images.
  • Keyboard navigation is not supported.
  • Most interface elements do not support tabbing, which makes keyboard interaction difficult.
  • Elements scale and adjust the layout of the page without cutting off content.

4. Snapfish

  • A larger part of the interface around the workspace correctly supports screen readers.
  • Elements have defined roles, and they have labels explaining what will happen upon interaction.
  • There is no screen reader support for the project content presentation.
  • The interface around the workspace is operable by keyboard to navigate through slides, though it is not very intuitive.
  • The workspace itself lacks keyboard support and cannot be operated via keyboard, so user can’t do a project on their own without a mouse.
  • Focus order for graphic interface elements is partially maintained.
  • It is difficult to exit lists of elements with the keyboard, making keyboard navigation challenging.
  • When zooming in the application, the layout adjusts appropriately to the changed zoom level.

5. Shutterfly version 1 – poor support for Web Accessibility

  • Shutterfly offers two versions of editors for photobooks. This version has limited support for web accessibility.
  • Screen readers read some parts of the interface correctly, but many controls are not properly recognized.
  • The semantic structure of elements is lacking because mainly divs are used, and there are no interaction descriptions for these elements.
  • Alternative descriptions for graphics are missing.
  • It is not possible to navigate the application interface using the keyboard, making the editor essentially unusable.
  • The page layout adjusts correctly when zoomed to 200%.

6. Shutterfly version 2 – good support for WebAccessibility

  • Shutterfly offers two versions of editors for photobooks. This version supports web accessibility.
  • Excellent support for screen readers, with most graphical elements correctly describing their roles and explaining interactions.
  • Lack of support for screen readers regarding content in the project workspace.
  • Unique alternative descriptions are used for graphics, enhancing accessibility.
  • The ability to add user photos to the workspace is a definite plus. However, there are no options for better positioning them.
  • Focus order is appropriate, and navigation through the interface is possible outside the workspace, but users occasionally must navigate through all elements in a given list unnecessarily; tabbing between groups of elements would improve this experience.
  • Overall support for keyboard navigation is at a good level.
  • A useful navigation menu enables quick access to specific interface sections, such as the workspace, asset side panel, and photo bottom panel.
  • While the editor offers good support for mouse-free usage and direct navigation to the workspace, interaction within the workspace itself cannot be achieved without a mouse. Users cannot move components or enter editing mode, hindering practical project work.
  • When zooming the page to 200%, the interface does not function correctly. The workspace is completely hidden, and controls in the upper panel go off-screen, making them inaccessible.

7. Mixbook

  • Screen readers correctly read many parts of the interface.
  • The screen reader does not support the non-working area at all.
  • Some more complex interface elements are not read adequately because they lack defined roles and information about the action triggered by interaction.
  • There are no alternative texts for graphics.
  • The editor cannot be operated with a keyboard.
  • There is no support for tabbing through the application interface.
  • When the page is zoomed to 200%, the layout adjusts correctly, and the content is not hidden.

8. Artifact Uprising

  • Most of the interface is properly accessible using a screen reader.
  • Some interface elements are not read correctly.
  • The screen reader doesn’t support the area that the user uses to design their project.
  • The application allows keyboard navigation through almost the entire interface, though it is sometimes unintuitive.
  • There is no keyboard support for editing user projects; users can access this section but cannot effectively modify the presentation with a keyboard.
  • Photos cannot be added from the keyboard.
  • The page layout behaves correctly when zoomed to 200%.

9. Zazzle

  • It provides good support for screen readers in the interface due to the use of semantic HTML elements and clear descriptions of interactive elements.
  • Lack of adequate screen reader support in the user workspace.
  • Alternative text descriptions for images are used, but are not entirely unique and are grouped into categories.
  • Good keyboard support is available around the workspace interface, allowing for extensive keyboard functionality.
  • Users can add components and modify some components’ properties within the workspace.
  • Existing elements cannot be edited or selected without a mouse, making it difficult to achieve the desired effect when creating a project.
  • The editor does not function correctly when zoomed to 200%, resulting in parts of the interface being cut off.

10. Photoweb

  • Lack of proper screen reader support.
  • Semantic HTML elements are used incorrectly, hindering proper interpretation by screen readers.
  • Absence of alternative descriptors for images.
  • The editor provides limited keyboard navigation support, not indicating the current focus location.
  • Practical inability to create a project without using a mouse.
  • The interface does not function correctly when zoomed to 200%, causing content to be hidden in some areas.

11. Ifolor

  • The reader has trouble correctly interpreting interface elements due to a lack of semantic elements or descriptions.
  • There are no meaningful alternative texts for images.
  • Tap support in the editor interface is minimal and does not highlight selected elements.
  • Users cannot design projects using only the keyboard.
  • When zoomed to 200%, the interface layout adjusts correctly.

12. Albelli

  • Lack of proper screen reader support due to missing semantic elements or descriptors for interactive interface elements.
  • Absence of alternative descriptions for images.
  • No support for keyboard navigation in the application interface, making it impossible to design without using a keyboard.
  • Zooming the page to 200% causes some interface elements to disappear.

13. Smartphoto FR

  • Lack of adequate support for screen readers.
  • Inability to navigate the interface without a mouse, both in the workspace and around it.
  • Contrast issues in some interface elements.
  • Some interface parts are hidden when zoomed to 200%, leading to improper functionality.

14. MyPoster

  • Screen readers do not function properly due to the lack of semantic HTML elements and element descriptors.
  • Keyboard navigation within the application interface is not supported.
  • There are no alternative descriptions for photos and graphics.
  • Increasing the page zoom to 200% causes some content to be cut off.

15. Moonpig

  • The editor is designed for simpler products than photo books.
  • Screen reader support is high, with most elements handled correctly and interface descriptions or semantic elements used.
  • Alternative descriptions for images used in projects are missing.
  • The editor supports tab navigation throughout the application interface and workspace.
  • Not all actions available with a mouse can be performed using only the keyboard, such as moving elements within the project.
  • Tab navigation can sometimes be unintuitive, with unexpected jumps occurring.
  • At 200% zoom, the page maintains a correct appearance.

16. Pikto

  • Excellent support for screen readers in the interface surrounding the workspace, but a lack of support for the workspace itself.
  • The interface utilizes semantic and well-defined elements.
  • Alt text for images is used, but generic; individual alt texts are missing.
  • Keyboard navigation is possible throughout the application interface except for the project workspace.
  • Users cannot design their projects without using a mouse.
  • Menus and dropdowns do not expand and do not allow option selection via keyboard.
  • The browser zooms to 200% functions correctly, and the content is not cut off.

17. Wonderbly

  • The service offers books in a very simplified format.
  • The photobook design interface is very limited.
  • The process consists mainly of filling out successive form fields.
  • Screen reader support is very good, but the user can’t see the book as it is meant to appear. They can only read the text that is present, without seeing the graphics that are included.
  • The interface for screen readers is well-designed and clearly presents available actions and ongoing processes.
  • Projects can be completed entirely without using a mouse.
  • The interface is adaptable if the user scales the version up to 200%.

18. Framkalla

  • Very good screen reader support due to semantic HTML elements and interface descriptions.
  • Lack of screen reader support within the user’s design workspace.
  • Alternative text for images is present but generic, not unique.
  • Problems with the contrast of some texts on the page.
  • Excellent keyboard support for interface elements surrounding the workspace.
  • Lack of keyboard support for designing or working inside the workspace.
  • Some components around the workspace, like drop-downs and pop-ups, have keyboard accessibility issues.
  • The editor behaves correctly when zoomed in up to 200%.

19. Profotonet

  • Limited support for screen readers.
  • Tabbing through the application interface is possible, but not all elements are accessible.
  • The lack of information about the currently selected element makes keyboard navigation difficult.
  • The application interface is practically unusable without a mouse.
  • Zooming the interface to 200% does not cause display issues.

20. Rikorda

  • No proper support for screen readers.
  • No alternative text for images.
  • No keyboard support for navigating the interface.
  • Interface behaves correctly when zoomed in up to 200%.

21. VistaPrint

  • Lack of proper screen reader support due to missing semantic elements or descriptors for interactive interface elements.
  • Absence of alternative descriptions for images.
  • No support for keyboard navigation in the application interface, making it impossible to design without using a keyboard.
  • Zooming the page to 200% causes some interface elements to disappear.

A life-long learner and a super curious person, always trying to raise the bar for the quality of software we are developing at Printbox. As a Head of Front-End Engineering, Szczepan is responsible for all things on front-end with strong emphasis on making our software customizable. He loves developing talents and helping people solve problems.