This article was co-written by Mari Yamaha and Jeremy Clayton, two Blndspt Consultants who spearheaded the Angular Upgrade + A11Y Remediation for Mastercard.

—

Blndspt partnered with MasterCard Inc. to remediate accessibility (A11Y) along with upgrading technologies across multiple applications. One upgrade in particular, was to update the codebase from Angular 1.4 to Angular 4.4.1.

Three Blndspt developers completed this project in roughly 3 months. The finished project was a success as it complies with WCAG 2.0 and reached AA success level.

—

Why Upgrade for Accessibility?

Tech debt is a burden that accumulates over time. The debt is more than just its technologies. It comes with financial burden, employee retention/satisfaction, and countless performance debts. With the world of development moving so rapidly, BlndSpt strives to come out ahead before our clients fall behind.

We, as consultants saw an opportunity when faced with MasterCard’s need for accessibility remediation and their application being out of date (Angular 1.4). We upgraded the app with the latest technologies (from AngularJS to Angular 2+) with benefits that included accessibility. Some features include, built-in support for ARIA attributes out of the box, newer versions of User Interface (UI) libraries, such as Bootstrap and Material, which have better accessibility support and improves performance.

The Upgrade + A11Y Remediation Process

Our challenge was to update the established code base while seamlessly transitioning the code and utilize newer technologies. In addition to our efforts, other teams were working on functionality changes and management wanted to see our progress every sprint. The upgrade process spanned several weeks (sprints), with weekly testing and code merging.

How Blndspt Helped:

We developed a remediation process to achieve this goal, like the following:

• Convert JS files to Typescript files
• Reformat file hierarchy to fit Angular 2+ style guide
• Upgrade to Angular 1.6 and convert Controllers to Components
• Bring in Angular 4 and the ngUpgrade library which allows mixing Angular 1 and Angular 4 in the same application
• Convert build packages from gulp to webpack
• Upgrade the code to Angular 4 section by section by converting Components and Services into Classes, at the same time updating the routing so it is testable
• Rewrite karma and jasmine unit tests to pass new code base
• Strip out the Angular 1 files and structures

We gradually upgraded the application so that changes would be introduced to the main branch more often. We concluded that this was the most efficient process.

—

Difficulty of New Technologies: AngularJS to Angular 2+ Conversion

The difficulty of upgrading from AngularJS to Angular 2+ depends on how structured the original AngularJS code was written. AngularJS is more flexible in terms of sharing data via $scope and $rootscope among nested controllers and directives. Angular 2+ needs more structure. Overuse of $broadcast and $emit also make it difficult to convert.

For this project, the effort turned out to be semi-difficult. The fairly large and complex application had numerous use cases that were difficult to test. Data models in $scope were large and messy. Ultimately, all of this made the process more time consuming, as we looked through many files to locate where values were being set and being used.

How Blndspt Helped:

We reviewed the code in great detail to gain knowledge of the application. We refactored the code once we had sufficient understanding,

Conversions such as the following were necessary:

• Pass data via Component @Input/@Output for immediate parent/child Components
• Upgrade one component at a time, beginning with the most depth child
• Move things into Service to share data among groups of Components
• Utilize ViewChild for parent component to interact with child components
• Replace $broadcast and $emit with observables in services

We strove to make sure existing functionalities remained intact. We updated and added more unit tests to account for the new technologies being introduced. The resulting code is easier to read, maintain, and will scale much better.

Along with upgrading the frontend framework, challenges arose from upgrading User Interface (UI) frameworks. Deprecated widgets and the stable version of angular did not have a stable equivalent of bootstrap or material. We should also mention inefficient practices in development by using both frameworks. In response, we:

• forked the documentation from GitHub and checked out to an older version
• utilized the frameworks widgets and components for particular use cases, where one was better than the other
• influenced the client to use one framework (this was not implemented)

—

Incorrect Use of Elements

A common problem we see with AngularJS and other Javascript UI frameworks is developers using non-semantic and wrong semantic elements. Such as adding click interaction on <div> or <tr>. This is done “just because they can” or because it becomes easier to style. This results in screen readers not expecting outside behavior on these elements and decreasing interaction, an enormous problem for accessibility.

How Blndspt Helped:

We used appropriate HTML elements and structure wherever possible. Blndspt also utilized correct semantic elements as we upgraded the code, to comply with WCAG standards. Following standard practice is more preferable than forcing the screen reader to work with custom elements. Therefore, in the future when accessibility rules change or screen reader behavior changes, standard practice enables the UI will always be accessible.

—

Accessibility Can Improve The Design

Another issue, we faced, dealt with the User Interface (UI) design.This was not directly related to the Angular upgrade, but it affected the usability. There was simply too much going on at once for it to be accessible.

How Blndspt Helped:

The design upgrade included a simplified and streamlined layout, therefore, making it comprehensive to screen readers and keyboard accessible. This change benefitted all users, including non-accessibility users since the resulting User Interface (UI) was easier to understand. Our team worked closely with designers and held true to accessibility principles. Accessibility when done right is not a restriction, it should ground the design to be more user-friendly for everyone!

—

Remediation + Upgrade Final Takeaways

The Upgrade + A11Y Remediation Project was a success! Blndspt met the deadline, the application is upgraded and accessible, the interface more intuitive, and the performance soared. It utilized newer frameworks and technologies, enabling future upgrades to be less time consuming.

BlndSpt wants to make sure the web is accessible to everybody. The web is just now beginning to mature, and accessibility (A11Y) is only scratching the surface. Remediation and Tech Upgrade Projects like these will become more in-demand. As more people gain access to the web — more and more people with disabilities will tune in and demand access.

The Blndspt team completed a contract with Mastercard in 2019 providing tech upgrades + A11Y remediation. Read about our other efforts here: Blndspt Team Remediates Mastercard Web Apps