Single Sign-On for Spotler Group

Introduction

We have been working with the Spotler Group for over 3 years. After starting work on the Email Editor project, the client invited us to collaborate on the creation of the Single Sign-On system.

Focus

• Creating a Single Sign-On system for all Spotler Group products.
• Creating a central platform that would offer Spotler Group cross-selling opportunities.
• Enhancing the representation of the Spotler brand among the companies that have joined the Spotler Group.

Objective

To create an SSO system that would unify various products of the Spotler Group under a single brand.

Needs

• The solution had to be flexible enough to operate within the existing systems. These systems were built using different technologies, by independent teams with different approaches to user identity management.
• Due to existing contracts and the need to protect privacy, we were required to create a product that could be hosted on the client’s infrastructure.
• As security was one of our top priorities, solutions already used by large enterprises were introduced.

Approach

We started with discovery workshops, during which we received both technical information about the projects that the SSO would cover and a specification of business requirements.

The results of the workshop provided a basis for conducting an extensive review of commercially available SSO solutions. We presented the advantages and disadvantages of each solution to the client’s Steering Group. After selecting a core solution, a draft of the proposed architecture was prepared. Until that time, the process had been supported by our architect, who had already created similar solutions for other clients.

We used lessons learned from previous projects to avoid potential pitfalls. The next step consisted of the implementation, first of the MVP version and then of the testing phase. The verification of the MVP version was conducted simultaneously with the onboarding of the technical support staff, who provided additional feedback on the part of the application responsible for handling user requests.

The next stage involved deploying the solution to the production environment and beginning the onboarding of customers. Throughout the entire process, our team not only improved the solution but also provided assistance to the teams responsible for specific Spotler Group products in integrating with the SSO system.

In managing the work of the development team from ArdentCode, we used the Kanban method. The entire process was supervised by a manager from Spotler.

During the project, we delivered weekly progress reports. Initially, the reports were presented to the Steering Group, and later to the CTO and Head of Product Development at Spotler.

Key changes

• Replacing the existing sign-on systems using a staged release approach (i.e., onboarding small groups of customers instead of all users at once) by migrating existing users.
• Creating new onboarding procedures and account creation processes in the products covered by the SSO.

Results

• Until June 2025, we connected 9 Spotler Group products, creating new cross-selling opportunities for the group.
• We completed the integration with 3 external identity providers.
• We completed deployment in the production infrastructure, distributed between two data centers, with full redundancy of both applications and databases.
• We completed the migration of the first user groups.

Conclusion

SSO enables improved security and therefore helps protect the privacy and safety of Spotler Group users. Ultimately, after the migration has been completed, the system will also enable a reduction in costs related to the maintenance of authentication systems.

A great cooperation – what made Fusion more inclusive, sustainable, and ready for the future?

Introduction:

Wolters Kluwer invited us to collaborate on a blended team tasked with developing a fully accessible InView Essential RoadRunner product within the Fusion ecosystem. InView Essential RoadRunner is meant to replace an existing product built for blind users, which is set to be discontinued. Fusion is a family of research products that share a unified design and codebase. While the accessibility of InView Essential was our primary objective, this architecture enabled us to enhance accessibility across the entire Fusion product line.

Focus:

• Analysis of the existing functionalities in terms of adhering to accessibility requirements.
• Creating and/or adapting the existing components to meet the WCAG 2.1 AA standard.
• Testing scenarios and collaborating daily with the WCAG specialist assigned by the client.
• Using screen readers and tools for automatic detection of accessibility issues.
• Ensuring that our application is and remains accessible thanks to unit and e2e tests.
• Maintaining the functionality of other products that use the same components.

Objective:

Creating a fully accessible research product ready for production, while simultaneously enhancing accessibility in related products.

Needs:

1. Collaborating with teams from other products.
2. Creating and adapting components to meet WCAG standards, focusing on keyboard interactions, HTML markup semantics, and screen reader compatibility.
3. Establishing accessibility monitoring and tests to prevent regressions.
4. Sharing knowledge on best practices for component development.
5. Testing and fixing issues.

Approach:

1. Analysis of Functional Requirements: We conducted an analysis to determine which components from the Fusion ecosystem could be utilized and defined an initial scope of work required to create a baseline product.
2. Iterative Accessibility Analysis: We reviewed each view and use case, identifying issues related to HTML semantics, interactions, screen reader (SR) announcements and other accessibility challenges for impaired users. The analysis was supported by accessibility tools such as Axe, established design patterns, and documentation provided by the WCAG specialist, which was available for some of the analysed cases.
3. Ongoing Coordination: We continuously aligned priorities and schedules with the client and other product teams. The work was divided into specific tasks, estimated, and planned within sprints. After each sprint, progress was presented.
4. Implementation and Testing: The solution was developed and tested, undergoing verification by the QA team and the WCAG specialist.
5. Documentation Preparation: We created the necessary documentation, including materials required to prepare the product for deployment in the production environment.

Key changes:

1. Implementation of accessibility requirements for all the Fusion capabilities adopted by our product.
2. Setting up a process for accessibility implementation not only for our team, but also for others to use in the future. For example, we did not always have a complete specification of interactions or recommendations from the WCAG specialist. To accelerate the work, we conducted accessibility analyses based on our own experience, best practices, and known patterns. The WCAG specialist later reviewed our assumptions at the final implementation stage and provided suggestions when necessary.
3. Ongoing issue resolution and synchronization with other teams, as our changes impacted multiple products.

Results:

1. Delivering a fully accessible research product, particularly for users with disabilities.
2. Creating reusable components that are utilized in related products, thereby improving their overall accessibility.
3. Making the Fusion platform future-proof in terms of accessibility, especially in the light of the planned implementation of The European Accessibility Act in 2025, which will require organizations to ensure that their products are accessible.
4. Enhancing WK’s reputation as a partner committed to supporting individuals with impairments.

Conclusion:

Our team, ArdentCode, has significantly contributed to raising the level of accessibility and awareness within Fusion. We have demonstrated our ability to quickly acquire advanced knowledge in a given field. We ensured that capabilities meet accessibility standards, providing an inclusive user experience that supports assistive technologies—based on WCAG 2.1 AA criteria and best practices for web accessibility.

WCAG #2 – 994 accessibility fixes, one compliant platform

Introduction:    

Focus: 

• Ensuring that VitalLaw complies with WCAG 2.2 Level AA standards as recently more laws focus on web accessibility compliance. 

• Addressing all accessibility issues identified by an external audit. 

• Utilizing the ArdentCode team to implement the necessary fixes. 

Objective:   

To ensure that VitalLaw meets WCAG 2.2 Level AA standards, to enhance accessibility and compliance, thereby improving user experience and ensuring compliance with legal requirements. 

Needs:  

1. Ensuring that VitalLaw complies with WCAG 2.2 Level AA standards, especially as more laws nowadays focus on web accessibility compliance. 

2. Fix all identified accessibility issues in the VitalLaw platform. 

Approach:  

1. An external company conducted a thorough audit to identify accessibility issues. 

2. The ArdentCode team addressed all 994 reported issues, creating Jira tickets for each WCAG success criterion. 

3. External dependencies were resolved in collaboration with various teams 

4. Fixes were implemented in areas such as keyboard accessibility, colour contrast, HTML semantics and many others. 

5. Merged PRs covering some of the work, with ongoing efforts to fix issues, including those awaiting solutions from UI/UX designers and other teams responsible for external dependencies. 

Key changes: 

• Jira tickets were created for each WCAG success criterion, allowing developers to dive deeper into specific requirements. 

• All issues that could be fixed in the main repository of the project were addressed and fixed. 

• External dependencies were resolved in collaboration with various teams. 

Results:  

1. 994 accessibility issues were identified and addressed. 

2. Improved compliance with WCAG 2.2 Level AA standards. 

3. Enhanced user experience for all users, including those with disabilities. 

4. Strengthened Wolters Kluwer’s reputation for accessibility and compliance. 

5. Contributed to a more inclusive digital environment, in line with global accessibility standards. 

Conclusion:  

Our collaboration with Wolters Kluwer has significantly improved the accessibility of their VitalLaw platform, demonstrating ArdentCode’s capability to handle complex accessibility challenges and deliver compliant solutions. This project highlights our commitment to creating inclusive digital experiences. 

WCAG #1 – solutions with amazing scalability

Introduction:     

Focus:  

• Shift the focus from the components that only look well to the components that also behave well. 

• Provide the set of components that adhere to the best accessibility standards – WCAG 

• Provide solutions that are compliant with ADA and EAA 

Objective:   

We aim to revise our principles to ensure that our components are not only visually appealing but also exhibit excellent functionality and behavior.   

Needs:  

Build DEV team awareness of the necessity of accessibility and providing information on what it involves. 

Provide the components that prioritize accessibility, usability, and meet legal standards.  

Approach:  

1. Leveraging our knowledge to address complex challenges and avoid common pitfalls. 

2. Analyzing how to implement WCAG requirements in client environments, ensuring compliance while sidestepping typical issues. 

3. We have introduced automated accessibility testing into our Continuous Integration pipeline. 

4. Proper keyboard navigation is now the must have in our components. 

5. We started using the screen reader on a daily basis. 

6. Strong collaboration with UX team regarding accessibility challenges. 

Key changes:  

• All the new components follow the best practices of the WCAG 

• We introduced an automated verification process using the AXE tool to ensure that all new components comply with accessibility standards. 

• All the new components put emphasis on intuitive keyboard navigation  

• All the new components are built with semantically correct HTML 

• All the new components are tested across all the most often used browsers and screen readers 

Results:  

1. Components strictly adhere to WCAG AA guidelines and follow the best practices outlined by the W3C, ensuring that they are as semantic as possible and offer a seamless user experience.  

2. Hundreds of product teams can build their applications based on the blocks that meet the highest standards. 

Conclusion:  

The new strategy that we applied while creating the components helps us to provide the highest quality building blocks for our clients. These can be recommended as inspirational for other teams as a great starting point while building the user-friendly solutions yet following the guidelines of the ADA and EAA. The components are meticulously designed to meet these requirements, helping clients avoid potential legal challenges while fostering an inclusive online environment.