Published case study — attributed implementation
Danova NextAirports, ports and public transport
Travel information for people with disabilities.
- The need
- Travellers with disabilities need practical accessibility information before setting off. Transport partners across the Danube Region held that information on separate websites, in different formats and languages.
- What we built
- We built a multilingual platform that brings partner accessibility information into one place. Travellers can explore transport locations, while partners publish through a shared content structure.
Illustrative stock photo, not project imagery.Darcy Lawrey / Pexels
Published case study — attributed implementation
This page documents only the structure or implementation supported by the recorded sources. No measured outcome or testimonial is currently approved for publication.
The published web experience
Explore selected screens from the project. The complete site opens separately for current content and full interaction.
Start from one accessible entry point
The homepage introduces the regional application and gives travellers a direct route to accessibility information from participating transport partners.
Captured from the published website.The operational problem
Accessibility information was distributed across partner websites, content structures, and languages. Travellers had to assemble context from separate sources, while partners lacked one consistent way to publish comparable information and keep it current across the regional application.
This page separates implemented structure from unverified outcomes or claims. Existing public identities remain bounded by each case's declared status and sources. Any new or expanded identity, testimonial, metric, or verified outcome requires claim-specific evidence and publication approval.
Current-state flow
The repeated handoffs the system is designed to replace or make visible.
- 01
Each partner prepares and owns the accessibility information for its locations and services.
- 02
Similar details are published through different website structures, labels, languages, and media formats.
- 03
Travellers move between sources to understand facilities, assistance procedures, and transport options before visiting.
- 04
Content changes need to be reflected in a shared regional application without creating another manual publishing process.
Constraints and risks
These conditions shape the architecture before automation begins.
Accessibility is the core interface
Semantic structure, keyboard navigation, screen-reader compatibility, contrast, responsive layouts, and voice-control support must work as one system rather than as later fixes.
Different partner systems
Each organisation has its own website and technology, so the shared application needs a stable content contract without prescribing one partner stack.
Multilingual, multi-format content
Information must support English and local languages alongside appropriate alternatives such as video and sign-language interpretation.
System design
A traceable path from intake to action, with uncertainty surfaced before it becomes an operational error.
Accessible partner template
A repeatable page structure gives every partner a clear way to publish the required accessibility information using stable fields and accessible components.
Standardized data layer
Partner APIs send the agreed content model to a central database, where records can be validated and kept aligned with their source.
Danova Next public application
A partner directory and detailed transport pages present the centralized content in an accessible, multilingual, responsive experience.
Responsibility by design
The system does not treat every task as an AI task.
Deterministic responsibilities
Repeatable rules own validation, state, and system changes.
- Validate partner responses against the agreed field and content structure.
- Associate every update with the correct partner, location, transport mode, and language.
- Store accepted content in the central data model and expose its latest approved state.
- Render consistent partner-list and partner-detail views from the same structured records.
- Keep text, video, sign-language, and language variants attached to the correct content item.
- Surface failed imports or structural changes for review instead of silently publishing incomplete information.
Bounded-AI responsibilities
AI assists with narrow interpretation work and exposes its basis.
- Generative AI is not required to decide, rewrite, or publish accessibility information in the core application flow.
- Accessibility and data-publishing behaviour remain based on explicit structures, reviewed content, and tested interface components.
Human approvals and exceptions
People keep authority over consequential and ambiguous cases.
- Partners approve their accessibility content and provide the required language and media alternatives.
- Accessibility specialists and testers with disabilities validate the interface with assistive technologies and real usage scenarios.
- The delivery team reviews schema mismatches, structural changes, and failed updates before altering the public experience.
- Project owners decide when new partners and content types are ready to enter the shared platform.
Integration surface
Connect to the existing operating environment without pretending every tool is a system of record.
- Partner websites
- The source pages and content owned by participating airports, ports, and public-transport organisations.
- Standardized partner APIs
- A shared response structure that lets different partner systems send comparable accessibility data.
- Central data layer
- Partner, location, language, transport, accessibility, and media records used by the public application.
- Danova Next application
- The public directory and detailed information experience used by travellers.
- Accessibility validation
- Assistive-technology checks and testing with people with visual, hearing, and mobility disabilities.
What the engagement should deliver
Not just a demo: the operating model, working system, tests, controls, and handover needed to own it.
- Accessible partner-page template and shared content structure
- Centralized partner database and standardized API response contract
- Responsive Danova Next web application with partner directory and detail pages
- Multilingual content support and alternative media formats
- Accessibility testing with assistive tools and testers with disabilities
- Partner documentation, validation rules, and implementation handover
Limitations and next phase
Start narrow enough to validate the operating model before expanding its authority or scope.
- The freshness and completeness of public information depend on each partner maintaining its source content and API response.
- A standardized response contract reduces inconsistency, but partner-side structural changes still require coordination and validation.
- Accessibility is an ongoing operating responsibility; new content, browsers, devices, and partner additions need continued review.
Possible next phase
Expand the partner network through the same data contract, then add shared monitoring for update health, content freshness, and recurring accessibility checks.
Your workflow will be different
Turn the blueprint into a system shaped around your tools and controls.
Bring the current steps, owners, systems, and recurring exceptions. The first conversation is for mapping the workflow and deciding whether a custom build is justified.