Case Study – Delinea

The First 60 Days – Delinea

Within the first 60 days (roughly four Agile sprints) after I was onboarded as an accessibility specialist, I did the following:

  • Gap identification and baseline accessibility report using Web Content Accessibility Guidelines 2.1;
  • Reviewed known (reported) issues;
  • Recommended priority of issues and figuring out where best to start on already identified issues;
  • Met with and established check-in cadence for existing clients (relationship repair, updates, etc) so that the clients had information as to what we were doing, even if we were just starting. I could not speak to the past before my hire, but I could do what I could once I was hired, and I could keep the communication channels as open as possible.
  • Figuring out where to start remediating a product already in enterprise use and communicating these changes to users! Any accessibility changes in the application would be pushed to all clients, and so any feedback and communication to specific clients had to track any differences, what clients had previously reported, if regression testing found further issues, etc – harmonizing disparate communications, in other words.

The Why, How, and What

Clearly, part of the issue was getting started. What to tackle first?

We had parallel tracks; we needed to do the gap identification which could establish a baseline of what we were currently dealing with, instead of relying on very outdated information that did not reflect the application at all. And while we had received identified issues, some issues had to be tackled before others could be even planned for.

An stylized ear and eye frame a keyboard cable, with the keyboard underneath the ear and the eye. Icon from the Noun Project.

Keyboard navigation, for example. While keyboard navigation (visual) and keyboard & screen reader combination usage are different, both rely on labels being clear, structural landmarks, interactions being in focus order, focus order indication for visual users, and more. We had to work on the foundational steps of keyboard navigation and inform users of known keyboard traps before even dealing with identified screen reader issues.

I worked closely with Engineering to also establish the following:

  • Structural landmarks such as nav, main, and aside to set up a skip-to-main function and improve keyboard navigation;
  • Visual focus indication border;
  • Checking programmatic focus order, language code declarations (<lang>) and other global website attributes;
  • Communicating timeline of legacy page removal and framework change.

What had already been done?

Engineering had implemented some accessibility improvements into the application navigation by the time I onboarded, and a change to the technology stack in use was already underway.