Skip to content
Implementation & Decisions

How Can an On-Product Code Make Packaging Information More Accessible?

See how an on-product code can route to accessible digital information while keeping routing, presentation, language and packaging-law duties separate.

Reading time
6 min
Last verified
Sources
5
Share article
LinkedIn X Email
A plain white box carrying a QR on a white background with a hand holding a phone showing a product record.

The short answer

An on-product code can move information from a physically constrained pack into a digital presentation that is easier to navigate, enlarge, hear or operate with assistive technology. The code is only the route: accessibility depends on the destination, its content and the interaction design.

That means accessibility should not be reduced to a barcode decision. Carrier choice, digital routing and accessible presentation are separate layers, and the right carrier still has to work for the product and use case. See how to choose a carrier that still works in the real world.

Activatea Product.
Share
LinkedInXEmail
Navigate this page

The job is routing plus presentation

Packaging has physical limits. Space is finite, type can be small and complex instructions can be difficult to present in a form that works for every person.

A digital route can give the same product identity access to richer resources, but four things still have to line up:

LayerJobBoundary
Physical carrier or optical identityGives the person a usable way to startThe presence of a code does not make the information accessible
Product or resource routingConnects the identified product to the right digital resourceRouting does not guarantee that the destination is usable
Digital presentationPresents text, structure and interaction in an accessible formAccessible presentation has to be implemented and tested
Optional contextCan help select between resources where an implementation supports itA generic context mechanism is not a universal accessibility-preference profile

GS1's Resolver Standard 1.2.1 supports multiple typed links associated with an identified entity, with optional language and media metadata. That is a useful technical capability for connecting one product identity to different resources.

The same standard also gives an important limit. Its context attribute does not define a universal value space, and resolvers are not obliged to support it. A standards-based context parameter is therefore not evidence that accessibility preferences can automatically travel across brands and resolvers.

The existing guide on what happens when you scan owns the deeper resolver and routing mechanics.

Before the scan: make the route usable

The physical route still matters.

A digital destination cannot help someone who cannot locate or operate the entry point. Different optical carriers can have different practical properties, and accessibility requirements should be considered alongside print space, scanner support, packaging materials, operating environment and the other jobs the carrier has to perform.

This article does not choose the carrier. The point is narrower: accessibility is a service and presentation requirement, not simply a decision to place a QR code on a pack.

There is already bounded deployment evidence for optical-code accessibility services. Kellanova reported in September 2025 that NaviLens codes had been deployed across its products in Europe, using the technology to support product location and access to information. That is evidence of a scaled proprietary implementation within one multinational brand portfolio.

It is not evidence of industry-wide adoption, cross-brand interoperability or a measured outcome for every user.

During the route: send people to the right resource

Once the route is activated, the system has to select the right resource.

That may mean choosing information for a particular product, product version or market. A resolver can expose multiple links, and language or media metadata can help distinguish resources where those semantics are supported.

The important design boundary is that the routing layer should not be confused with the accessibility layer itself.

A code can resolve correctly and still land on a page that is difficult to use with a keyboard, screen reader or zoom. Equally, an accessible page can exist without being easy to discover from the physical product.

Both sides of the journey matter.

After the route: accessibility lives in the presentation

WCAG 2.2 is the current W3C Recommendation for accessible web content. It provides a normative technical basis for accessible digital presentation.

That is where digital information can do work that a small physical pack struggles to do. WCAG 2.2 provides a defined technical basis for making digital content and interactions accessible rather than relying on the physical route alone.

WCAG 2.2 does not prove that any named brand implementation conforms to every requirement. It also does not mandate a particular optical code on a product.

The practical lesson is simple: the destination needs to be treated as an accessible digital product in its own right, not as a web page that becomes accessible merely because it was opened from a code.

What is demonstrated now

Three things are established at different layers.

NOW: accessible digital presentation is a current technical practice, accessible optical-code routing exists in bounded deployments and EU accessibility law is binding within its scope.

Accessible digital presentation is established technical practice. WCAG 2.2 defines current normative requirements for web accessibility.

Accessible on-product routing is deployed in bounded systems. Kellanova's NaviLens deployment provides first-party evidence that an optical code can be used at scale within one brand portfolio to help people locate products and access information.

Accessibility also has a legal context in the EU. Directive (EU) 2019/882, the European Accessibility Act, creates binding accessibility requirements for products and services within its scope, including requirements around accessible information and instructions.

That legal point must remain bounded. The Directive does not create a universal rule that every package must carry a QR code, NaviLens code or Digital Product Passport. It applies to the products and services within its scope and should not be stretched into a general packaging-carrier mandate.

Language and localisation are a different decision

Accessible presentation and language selection can work together, but they are not the same requirement.

A product identity can potentially route to different language resources. Whether a particular language is required, which market rules apply and how multilingual content should be structured are separate questions.

Do not treat an accessibility route as proof that language obligations have been met. The Knowledge guide on EU countries, languages and DPP presentation owns that decision.

Packaging law is a different decision

The same separation applies to packaging regulation.

A digital route may be useful for presenting information, but that does not by itself establish compliance with packaging rules or decide what must remain physically on the pack.

The legal owner for that question is the Packaging and Packaging Waste Regulation guide. This article owns the accessibility routing and presentation job, not PPWR compliance.

What is not established

The evidence does not support a universal cross-brand accessibility-preference layer today.

GS1 Resolver 1.2.1 has an optional context mechanism, but the standard does not define a universal value space for it and resolvers are not required to support it. That is not enough to claim that a person's accessibility preferences can automatically be expressed once and honoured across different brands, products and resolver services.

This article therefore does not claim that:

  • universal cross-brand accessibility-preference routing or automatic personalisation is established today;
  • the GS1 Resolver context attribute is a normative shared accessibility-preference vocabulary;
  • WCAG 2.2 or the European Accessibility Act universally mandates one optical carrier for all packaging;
  • a scannable route guarantees that people discover, use or understand the information.

The last boundary matters beyond accessibility. A Joint Research Centre behavioural study of QR-code access to food information found substantial non-use in its controlled online setting. The study is not a test of NaviLens or every packaging context, but it is good evidence against treating code presence as equivalent to information exposure.

Design implications

ActivateDigital implementation view: treat accessibility as a presentation and service requirement in its own right, then choose the carrier and routing architecture that can support it.

A useful implementation flow is:

Before: make the physical route discoverable and operable for the intended audience.

During: resolve to the correct product resource without assuming a universal preference profile exists.

After: make the destination perceivable, operable and understandable, provide appropriate alternatives and test the interaction with the assistive technologies and user needs that matter for the service.

This is implementation guidance, not a claim that one technology or standard satisfies every legal requirement.

It also keeps the architecture honest. If the route changes, the accessible destination should remain a governed service. If the destination changes, the carrier should not have to be reinvented. If personalisation is introduced, its semantics and governance should be explicit rather than inferred from a generic context parameter.

For the adjacent post-sale service question, see what a product code can do after the sale.

What would change this answer

This page should be reviewed when accessibility law or official guidance changes, when GS1 Resolver semantics materially change, or when a normative multi-brand preference vocabulary and negotiation mechanism is both published and implemented.

Repeatable independently verifiable cross-brand deployments would also matter. Until then, accessible routing is established in bounded systems, while universal preference portability remains NOT_SUPPORTED.

Keep exploring

The questions this page usually raises next.

Sources

Sources checked as at 4 September 2026.

Does this reach your products?

Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.