Exploring Rocket Software’s Commitment to Accessibility

Our mission at Rocket Software is about more than just delivering innovative solutions. Every aspect of our work is guided by our broader values—Empathy, Humanity, Trust, and Love. And within those values, Rocket Software puts a great emphasis on accessibility. No matter the technology, system, or IT environment, we are committed to delivering solutions that work for everyone.

To learn a bit more about how we approach our solutions from an accessibility standpoint, we sat down with Rocket Software Principal Software Architect, Brian Kunz.

Brian boasts more than 20 years of experience building and designing front-end applications. He became fully involved with accessibility in 2024 while leading the effort to build foundational accessibility components needed for Rocket Content Services’ new user interface, Rocket Content Explorer.

How would you define accessibility from a software and development perspective?

From a software standpoint, it comes down to making the keyboard work with the application. The keyboard interface is the driver for any assistive technologies like screen readers. If something needs to be manipulated on the screen, it needs to be able to be manipulated by a series of keyboard commands; those keyboard commands are common and known to the end users. As an end user, I should be able to do everything in an application without ever touching the mouse.

We focus so much on making mouse-driven applications—that's the mindset that needs to change.

From a development perspective, accessibility is a skill, and it's a skill that most developers don't really have. This was true for me, and it was true for every developer who worked on our new UI project.

Agile practices are likely a key factor in why accessibility isn’t more of a focus. Developers have historically concentrated on the look of the application and whether the mouse works when clicked; that’s been the threshold for calling a feature done. And once that feature is completed, you move on to the next one because the objective is to add as many features as possible.

So, accessibility becomes a victim of time in favor of “getting a feature done.” It's not that developers don't want to make accessible applications – but we’ve overlooked the importance of coding for accessibility because it does require additional time. Management focus is also a factor, as coding for accessibility requires a bit more time and effort from everyone involved.

Accessibility can be a secondary skill set that is just not talked about or promoted, but that is something that we would like to change. We want accessibility to be a natural part of any project.

In layman’s terms, can you explain the four principles of the Web Content Accessibility Guidelines (WCAG) and share why they’re important?

There's an acronym for this, POUR. This stands for Perceivable, Operable, Understandable, and Robust.

Let's start with perceivable. This is how you make a complex application that is both visually compelling and beautifully designed in a way that the relationships between visual elements on the screen can be communicated to those without the benefit of sight. For example, how does a user know that there's a button that, when pressed, displays a new panel of information they can access? Or, when an operation happens and the screen changes even in a subtle way, how is this change communicated to the user in a way other than visual? Perceivable is painting a picture in somebody's mind about where they are in an application and how the application is structured.

When we talk about operable, this means that any element that can be manipulated must be able to be accessed via the keyboard. And we acknowledge that assistive technologies also include options such as voice recognition for users with motor impairments because keyboards might not be an option. Operable means that everything that can be manipulated such as a button, a list box, a text input, and so on must be operable via the keyboard or voice command. This creates unique challenges for things that are traditionally done with a mouse such as dragging and sizing. When coding for accessibility, we must evaluate the mouse, not as the primary means of change, but just as another tool. We don’t want to exclude functionality such as click-and-drag simply because a user can't use a mouse.

Next is understandable. Ensuring something is understandable means guaranteeing that any widget works like a user expects. Assistive technologies identify items on a screen and share messages such as “button” or “table” when a user navigates. This kind of basic description conveys to the user how they can manipulate that element, as well as to how utilize common keyboard shortcuts that are provided by assistive technology. For example, if a user knows that what’s in focus is a combo box, the user knows that they can activate the box via an enter key or down arrow key, etc. As developers, we need to ensure that the activities and order of activities for a particular item match the expected experience for a user relying on assistive technologies—otherwise, you create a scenario that is confusing to the user and a technology that can’t be used effectively.

Finally, we come to robust. There are coding conventions and attributes that developers should utilize to ensure that our software works with any assistive technologies. The WCAG standards are the contract that we as developers code to and which are also used by the developers of the assistive technologies. As long as both development groups do their parts, we end up with a functional accessible experience for our end users. We code to a standard, not for a specific assistive technology.

Robustness speaks to writing software that will work with various other user agents and assistive technologies. The other aspect of robustness is that a user can quickly move around the application with just a few keyboard actions. If developers have designed an application correctly, the application permits a user with a keyboard to navigate to places on the screen quickly without having to tab through every single control or every single item on the screen.

For individuals who are colorblind, how do you ensure that color contrast guidelines are met within a website or application’s design and what types of tools might you?

There's a ratio for foreground and background colors that the WCAG recommends; this ratio is 4.5 to 1. It’s a bit challenging to describe exactly what that means, but it addresses color shades between the foreground and the background in the application.

So, how do we determine this? It starts with the very beginnings of the design. We’ve used a tool called Figma to create rich wireframe designs for the application. This tool helps us to ensure that the design itself does not violate the color contrast ratio. We want to avoid designing something that we think looks good and devote time and resources to it, only to realize that it won’t pass color contrast checks.

There's also a tool that we use in the browser called Accessibility Insights; this is a browser plugin that you can turn on for any page and it will tell you if there are violations of the ratio I mentioned before. The tool can also render the application in grayscale, which is a neat way to look at what’s been developed so you can take the color out of the equation entirely and see how it looks with grayscale contrast and evaluate how easy it is to distinguish items.

What strategies have you used to educate and promote accessibility best practices among development and design teams?

So, it might scare you if you look at the WCAG specification. It's big. It's very technical and feels hard to consume. But once you get past the initial sting, it's very simple once it clicks into place. That's something that happened to me on my own journey. I knew I needed to do this, and this was the right thing to do.

I found that once this understanding clicked into place, I now have a new enthusiasm for accessibility. Coding in this way makes our applications so much stronger and it's not that complex after all…and you start to wonder why you avoided these coding strategies until now.

My goal is to make coding for accessibility second nature for front-end developers so that it’s not looked at as an extra thing or viewed as difficult or not worth the effort. I helped our development team by providing basic schematics on the visual designs for how to consider accessibility. As the expert on the team, I was able to say, “Hey when you make this screen, consider these aspects for the screen and these various other items for accessibility.” They applied those practices while completing their coding and we then evaluated it during our standard code review process. There was always a little rework that needed to be completed because this was new to everybody; we were developing new skills, and everyone was learning. So, we tested and massaged the code until we got the experience that we wanted.

Out of this experience, I’ve created a series of progressive training videos that are available to any Rocketeer who is working to incorporate accessibility. I’ve generated nearly 5 hours of content – this won’t be something that will take a lot of time. These videos provide a primer for understanding the basic concepts and learning how they're put into practice with a small sample application.

My goal is to remove the fear of adopting WCAG standards by showing that it's pretty simple. Also, our teams have developed a library of UI widgets that already manage most of the aspects of accessibility, so this will help other teams to build better products in the future by utilizing these widgets. Other teams won't have to worry about the accessibility within that widget because it's already managed for them.

Any tips or tricks you’d share with developers or teams who are just embarking on an Accessibility journey?

My tip is to use HTML5 as HTML5 was intended. You get a lot of accessibility for free just by doing that. Then look at the basic elements when you're coding for a visual design.

If something represents a list of content, use the actual list elements in HTML5. If something behaves like a button, make it a button. If you're presenting tabular data, use the table elements because assistive technologies will provide semantic information to their users if you use these basic elements. As developers, we tend to use generic containers that are styled to look like something specific and then manually apply click handlers to them. That’s a path of least resistance and it makes something that looks good and is clickable by a mouse, but it doesn't have any meaning to people who are using an assistive technology. Utilizing the basic elements of HTML5 will give you half of what you need (at least).

In terms of technical resources, there's a patterns page. This was the resource that really made everything click for me. This page has a specification for every single type of widget you could ever want; it has examples, code samples, keyboard specifications for various elements, etc. You can even use an assistive technology such as JAWS to test against the example widgets to see how JAWS handles things. It was a wonderful way for me to understand when I started to learn that coding for accessibility isn't that hard; I only had to change a few things when I was coding.

What’s the most interesting thing you’ve learned while working on an Accessibility-focused project?

The easy answer is that I can see Rocket Software’s core value of empathy in what we’re doing. We want our software to be usable by everyone. As I mentioned earlier, in our agile development world, we focus on the quickest path to getting a feature done and this results in us writing applications that might exclude certain users. This isn’t intentional and there’s no malice, but we can easily overlook those with disabilities and don't consider their experience and the difficulties they might experience when using our software.

We need to change our mindset with everything we put a Rocket Software name on. It's about being aware of the diverse needs of our users and not creating exclusionary tools, even if that means things take a little longer to code and test. That's why I want accessible coding strategies to be second nature for our developers, so they don't even necessarily think “I'm doing this for accessibility,” – instead, it’s a foundational part of coding for any project.

The future is exciting to me. There’s potential with the new functionality we’ve introduced. I’m now looking at how we can use something like Rocket® Content Smart Chat to bridge gaps when interacting with content in an application – not just the application itself. For example, if we present an image document to a user, could Rocket® Content Smart Chat then provide a summary of what the image is and inform the user by stating “This is an image of XYZ” or provide a summary of a document where “this document is a payment slip for materials purchased.” Things like that could save somebody time. Users wouldn’t have to read the entire document to realize, oh, this isn't the document I'm looking for.

Instead, they receive that summary quickly and then can move on to their next task. I think that there's even more we can do utilizing cutting-edge technologies to make our accessible experience even better.

It's exciting for me and I feel great pride in how we’re at the forefront of this type of initiative internally. Having this WCAG experience for users is game-changing.

Learn more about the newest features in Rocket Content Services.