We're proud to provide Accessibility services.

Earlier in the year, Last Call Media worked with the Massachusetts Department of Unemployment Assistance on a project in which we implemented automated testing and other automation processes. Word of the successful outcomes traveled through departments. When it came time to enhance the DFML’s program with DevOps automation, they contacted LCM.

What the DFML had was a team of teams each optimized to their own workflows and working on individual pieces of one greater product. The component-based team model increases efficiency as the larger technical foundations of a product are built, yet the integrations between those components can become a blind spot needing special consideration: integration testing was a known need in the project strategy. Last Call Media was brought on to be the integration testing team, and we knew from experience that concentrating testing of all functionality to a separate group, and as a final “phase” all work must pass through, leads to surprise issues arising too late in the life of the project. This was important as the timeline was one of the most important factors of this project: constituents needed to be able to apply for PFML benefits on January 1, 2021, no matter what.

As we began to work with the existing teams, we saw exactly what we could bring to the table: a strong strategy, clear approach, and defined process for integrating all work across every team, and systematically testing that work, as early in the development process as possible, so that fully tested product releases could be done with confidence and ease.

There were four main aspects of this project that needed to be considered in order to achieve success:

• The claimant portal, built using React, where constituents would be able to submit PFML claims and receive updates about the status of those claims,
• The claim call center, where customer service representatives would take calls from claimants and enter their claim information into the claimant portal,
• The claims processing system, the tool in which customer service representatives can process PFML claims via a task queue (and which is fed information from the portal, call center, and other third-party tools), and
• The API that would bring all of these parts together to work seamlessly.

Then, of course, there’s the testing. LCM began our work by establishing three types of tests that all project work would need to pass in order to be considered complete:

• End-to-End (E2E) testing: automated continuous verification of the functionality and integration of all 4 systems.
• Load and Stress testing: verifying the E2E functionality and integration under substantial strain to see what the system can sustain, where it breaks, what breaks it, etc.
• Business Simulation testing: verifying if the people behind the scenes who will be doing this work on a daily basis can effectively perform said work with the systems and functionality that have been put into place, and whether this work can be performed when there is a substantial amount of it.

As we worked to set up the proper tests for the product, we found many opportunities to gain alignment across all of the development teams with our overall testing philosophy: it should be a part of each team’s workflow instead of a final phase removed from the team(s) performing the work. We helped coach each team on delivering value incrementally, and their eventual ownership of where the E2E testing suite impacts their work. LCM brought testing to the program and enabled the teams to absorb it as their own.

Earlier in the year, Last Call Media worked with the Massachusetts Department of Unemployment Assistance on a project in which we implemented automated testing and other automation processes. Word of the successful outcomes traveled through departments. When it came time to enhance the DFML’s program with DevOps automation, they contacted LCM.

What the DFML had was a team of teams each optimized to their own workflows and working on individual pieces of one greater product. The component-based team model increases efficiency as the larger technical foundations of a product are built, yet the integrations between those components can become a blind spot needing special consideration: integration testing was a known need in the project strategy. Last Call Media was brought on to be the integration testing team, and we knew from experience that concentrating testing of all functionality to a separate group, and as a final “phase” all work must pass through, leads to surprise issues arising too late in the life of the project. This was important as the timeline was one of the most important factors of this project: constituents needed to be able to apply for PFML benefits on January 1, 2021, no matter what.

As we began to work with the existing teams, we saw exactly what we could bring to the table: a strong strategy, clear approach, and defined process for integrating all work across every team, and systematically testing that work, as early in the development process as possible, so that fully tested product releases could be done with confidence and ease.

There were four main aspects of this project that needed to be considered in order to achieve success:

• The claimant portal, built using React, where constituents would be able to submit PFML claims and receive updates about the status of those claims,
• The claim call center, where customer service representatives would take calls from claimants and enter their claim information into the claimant portal,
• The claims processing system, the tool in which customer service representatives can process PFML claims via a task queue (and which is fed information from the portal, call center, and other third-party tools), and
• The API that would bring all of these parts together to work seamlessly.

Then, of course, there’s the testing. LCM began our work by establishing three types of tests that all project work would need to pass in order to be considered complete:

• End-to-End (E2E) testing: automated continuous verification of the functionality and integration of all 4 systems.
• Load and Stress testing: verifying the E2E functionality and integration under substantial strain to see what the system can sustain, where it breaks, what breaks it, etc.
• Business Simulation testing: verifying if the people behind the scenes who will be doing this work on a daily basis can effectively perform said work with the systems and functionality that have been put into place, and whether this work can be performed when there is a substantial amount of it.

As we worked to set up the proper tests for the product, we found many opportunities to gain alignment across all of the development teams with our overall testing philosophy: it should be a part of each team’s workflow instead of a final phase removed from the team(s) performing the work. We helped coach each team on delivering value incrementally, and their eventual ownership of where the E2E testing suite impacts their work. LCM brought testing to the program and enabled the teams to absorb it as their own.

Working with PVPC 

We took the project from initial discovery and strategy through information architecture, design, and development. We were able to deliver a compelling, modern, and effective design, with PVPC’s target users in mind. Our discovery and strategy informed a new design for improved site navigation and menu structure, re-working the existing navigation system to create a more fluid experience visiting the site.

LCM and Amherst College worked together with student advocates, Title IX, LGBTQ, and other campus offices and organizations to design and develop an iOS App that puts valuable information, from a Drupal site Amherst can administer, into the hands of students. The major feature of the app was to direct assault survivors to emergency contact information, help services, and other advocacy groups, anonymously and quickly.

SUNY Potsdam partnered with Last Call Media and Acquia to migrate their site to Drupal 7. Leveraging the scrum methodology, LCM broke down and organized the major site features into a prioritized backlog, groomed for two-week iterations. While planning and backlog refinement was ongoing several times a week, the core development team at LCM met with Potsdam every other Friday to review work completed, provide training on the new CMS, and to facilitate the feedback-gathering process.

Since SUNY Potsdam had recently gone through a redesign, the project required the new site to maintain the existing look and feel. We began with an in-depth audit of all the different page types and page elements. Instead of doing this manually page by page, we first looked for a programmatic solution. Since CommonSpot did not provide a way to generate this information within the CMS, LCM used its HTML Crawler tool to programmatically crawl the existing production site and analyze the various HTML tags to determine page elements (such as slideshows, feeds, etc), including where and how often they appear. This provided tremendous visibility into the site’s underlying structure, which was critical in planning our approach to the migration to Drupal.

After reviewing this data with SUNY Potsdam, we began the process of consolidation– instead of building one-off page elements, we consolidated similar elements into single widgets that behaved differently based on where on the page it was placed. This helped reduce the vast number of options a content author has to choose from, making it easier for them to do what they need to do: focus on the content. To achieve the desired platform flexibility, LCM built a repository of flexible and adaptable widgets to allow the marketing team at Potsdam to build custom pages. 

The migration included several different page templates and tens of thousands of pieces of content, which required writing and testing a series of migration scripts to get all the content from one CMS to another without downtime or a lengthy content freeze. Since the CommonSpot installation did not have a concept of structured content, LCM used it’s HTML crawler tool again to programmatically identify page content and then map it to its new location in Drupal. Once the custom scripts were written and tested, the migration took only 15 minutes for tens of thousands of pieces of unique content and the associated metadata, such as date published, authoring information, and URL. 

The new site also pulls in events automatically from their event management system, SOGo, and tags the event to the relevant department or office in the CMS so that it appears on that organization’s page.  

Lastly, in order to make it as easy as possible for content authors to login to the site, we leveraged the identity management service at Potsdam, Active Directory, to allow users to use their domain credentials to authenticate with Drupal.

When it’s business as usual, the site serves as a platform to generate awareness for how someone can better prepare themselves and their family in the event of an emergency. Visitors can download checklists, and complete forms, in addition to reading about how to prepare for different kinds of disasters, like an earthquake or tsunami. However, in the event of an emergency, the City can quickly enable a separate emergency home page which presents visitors with vastly different dynamic content updated in real time specific to the emergency, including an embedded interactive Google Crisis Map that displays information aggregated from a variety of external sources managed by the City.

Last Call Media provided a direct replacement of the existing site in Drupal 8, leveraging the out-of-the box D8 accessibility features and the user-friendly D8 in-place content editing interface. We also reduced the maintenance burden by bringing the blog, which had been a separate site, into the main site.

Our accessibility audit revealed that the original color palette used for the site designed relied heavily on colors that did not meet WCAG 2.0 contrast requirements. We were able to identify a compliant color scheme that remained within the existing brand guidelines for the new site. The site also relied heavily on icon fonts which were not taking advantage of Unicode’s private use area, and the HTML elements displaying the icons did not use appropriate ARIA attributes. Rebuilding the icon font and HTML markup to take advantage of those tools helped to greatly improve the screen reader experience for the site.

Another area that needed improvement was general accessibility related to interactive elements. Sections like flyout menus and tabs were difficult to navigate via keyboard, and were missing ARIA attributes that make them easier to understand and use. During the rebuild we switched away from using mostly-homegrown CSS and JS, and leveraged the Foundation CSS/JS framework instead. This change provided a couple of benefits - many of the missing accessibility features are included in the components provided by Foundation out of the box, it helped keep the nuanced details of the styling more consistent across different areas of the site, and it expedited the development process as well.

When it’s business as usual, the site serves as a platform to generate awareness for how someone can better prepare themselves and their family in the event of an emergency. Visitors can download checklists, and complete forms, in addition to reading about how to prepare for different kinds of disasters, like an earthquake or tsunami. However, in the event of an emergency, the City can quickly enable a separate emergency home page which presents visitors with vastly different dynamic content updated in real time specific to the emergency, including an embedded interactive Google Crisis Map that displays information aggregated from a variety of external sources managed by the City.

Last Call Media provided a direct replacement of the existing site in Drupal 8, leveraging the out-of-the box D8 accessibility features and the user-friendly D8 in-place content editing interface. We also reduced the maintenance burden by bringing the blog, which had been a separate site, into the main site.

Our accessibility audit revealed that the original color palette used for the site designed relied heavily on colors that did not meet WCAG 2.0 contrast requirements. We were able to identify a compliant color scheme that remained within the existing brand guidelines for the new site. The site also relied heavily on icon fonts which were not taking advantage of Unicode’s private use area, and the HTML elements displaying the icons did not use appropriate ARIA attributes. Rebuilding the icon font and HTML markup to take advantage of those tools helped to greatly improve the screen reader experience for the site.

Another area that needed improvement was general accessibility related to interactive elements. Sections like flyout menus and tabs were difficult to navigate via keyboard, and were missing ARIA attributes that make them easier to understand and use. During the rebuild we switched away from using mostly-homegrown CSS and JS, and leveraged the Foundation CSS/JS framework instead. This change provided a couple of benefits - many of the missing accessibility features are included in the components provided by Foundation out of the box, it helped keep the nuanced details of the styling more consistent across different areas of the site, and it expedited the development process as well.

Goals

The main goal of this effort was to liven up the site and encourage users to interact with elements on the page. As an unintended consequence of implementing a highly flexible component-based theme — in which pieces of content could be mixed and matched in basically unlimited ways on any given page — the overall look and feel had come out very clean and organized, but at the same time more boxy and “dull” than we’d anticipated! Alongside this, there was also the challenge of giving the theme an institutional, educational feel that still felt friendly and helpful instead of overly corporate and austere. 

Process

The first step in the process of adding microinteractions was to make sure the interactions were unified in their intent. For example, a rise on hover means the item is clickable, and if implemented on something that doesn’t click, would confuse the user.

Hover is a near universal sign for “this is clickable”, so we utilised a hover effect with shadow for the menu. For buttons, we opted to change from a simple color fade on hover, to a left to right swipe to change the color. This is more engaging than a simple color change, but it isn’t distracting from what the call to action is asking the user to do. It also matches the movement exhibited in the menu when items are hovered over. This addition of motion design to the menu helps users better understand where they are in a detailed navigation, and have a stronger understanding of the menu and product hierarchies.

Some other elements of movement added, purely for aesthetics and to engage the user, were a hover effect where the background shapes move behind a product shot when moused over. This added interest to otherwise somewhat repetitive images of computers, and hopefully caused the user to take a second look. Another was a fade and slide in of images, from the side the image is on. This creates a very welcoming feeling as you scroll down the page. In addition, we added a video background to the banner area of the homepage, tinted Blackboard blue so as not to distract from the text and call to action button over it.

In order to maintain our accessibility standards we had to think about users that may not be comfortable with the video at the top of the homepage, so we included a pause button to stop it from playing.

Results

The team at Blackboard is happy with the results of this effort, and it brings a really fresh engaging experience to the site. We would love to do another round of user testing (link to solution story about that) to see how or why these additions add to the site for users.