Design, Code, Comply: Accessibility in Workforce Learning

See how Resolute helped one client build a more functional, accessible and scalable web experience by instituting accessibility beset practices and leveraging Progress tools.

In a world where most of our lives play out online, web accessibility shouldn’t be treated as an afterthought. Designing with inclusivity in mind is no longer optional; it’s essential. Just like a chair needs four sturdy legs to be safe for everyone, digital experiences need to be built with all users in mind.

But when the platform in question is educational, the stakes are even higher. These platforms serve a diverse range of learners—some with visual, auditory, motor or cognitive impairments, and face stricter accessibility requirements than general websites.

That’s why Resolute was proud to partner with a U.S.-based company providing online training tools for frontline employees. The platform had recently been acquired by a leading provider of online compliance and workforce training, further raising the bar for performance, accessibility and scalability. The goal: build a more functional, accessible and scalable web experience.

When Design Slows You Down

The project started with a familiar pain point: fragmentation. The client’s design ecosystem was spread across multiple sources:

• An internal Figma library shaped by years of brand tweaks
• A partially customized theme inside Progress ThemeBuilder
• A live site with Progress Kendo UI components that didn’t always align with the designs

This led to confusion, delays and inconsistencies, especially around accessibility. Developers struggled to map designs to actual components. Theming was brittle. And certain UI patterns weren’t usable for people relying on keyboard navigation or assistive technologies.

Resolute was brought in to clean it up, streamline the workflow and help the client move toward a more compliant and scalable solution.

Fixing the Foundation: ThemeBuilder in Action

Our UX/UI team began by auditing the client’s existing design system. They worked closely with their internal team to unify the visual language and migrate it into Progress ThemeBuilder, which served as the central source of truth for styling and theming moving forward.

ThemeBuilder wasn’t just a convenience; it helped enforce consistency in design tokens like colors, borders and spacing, while also helping to align with accessibility best practices.

The UX/UI team’s work included:

• Consolidating redundant button and form variations
• Fixing visual issues with contrast, spacing and typography
• Helping the design team understand how to use ThemeBuilder effectively to support long-term accessibility

From Visuals to Code: Accessibility in the Build

Once the design foundation was solid, our frontend team began implementing the new UI in code. Over several months, the platform’s frontend was rebuilt with accessibility as a core requirement, focusing not just on how it looked, but how it worked for every user.

This wasn’t just about good UX; it was also about meeting real compliance needs. Since the platform serves a broad user base in the U.S., including educational and government-affiliated organizations, several legal standards apply, including:

• ADA (Americans with Disabilities Act): Particularly Title III, which applies to educational institutions and commercial websites
• Section 508 of the Rehabilitation Act: For platforms receiving federal funding or working with government entities

To meet these requirements, we aligned the build with WCAG 2.1 Level AA guidelines developed by the W3C (World Wide Web Consortium), currently the most widely used benchmark for web accessibility in the U.S.

What that looked like in code:

• Every interactive element was accessible via keyboard navigation (tab, arrows, etc.).
• Clear, visible focus states were implemented for all buttons, links and forms.
• We structured the app using semantic HTML and applied ARIA roles for assistive tech (e.g., <button>, <nav>, <form>). Yet, we applied ARIA roles only when necessary for custom components or non-semantic elements, avoiding over-reliance on ARIA. It’s crucial to use ARIA only when native HTML elements can’t provide the required functionality.
• For use cases beyond the default configurations of Kendo UI or ThemeBuilder, we wrote custom HTML overrides.
• Duplicate labels or screen reader confusion were avoided using attributes like aria-hidden="true" where needed.

Testing was both automated and manual. Tools like axe DevTools, WAVE and ChromeVox helped flag contrast issues, label duplication and navigation traps. But human testing mattered just as much. Therefore, a touchscreen laptop was used to simulate real user scenarios, check responsiveness and validate how elements behaved across screen sizes and input types.

When Customization Adds Complexity

Telerik ThemeBuilder and Kendo UI offer strong accessibility features, but when components are heavily customized, unexpected issues can appear. Resolute helped the client troubleshoot several edge cases:

• Buttons built without the base component didn’t render properly
• Some forms displayed labels twice to screen readers (e.g., “Username Username”)
• Blazor components lacked alt-text bindings, requiring a workaround

None of these problems were dealbreakers, but they showed how expertise matters. Without frontend developers who understand both the framework and accessibility requirements, these issues could have gone unnoticed.

Accessibility = Structure + Semantics + SEO

There’s another benefit to building with accessibility in mind: better search engine optimization (SEO). Many of the same practices that support users with disabilities, like using semantic HTML, a well-structured HTML DOM (Document Object Model) and meaningful headings, also help search engines understand and rank your content.

The frontend implementation in this case included:

• One <h1> per page, with clean heading hierarchies for structure like <h2> for sections and <h3> inside components
• Alt-text for all meaningful images
• Descriptive link text and accessible navigation

The result? A platform that’s easier to use, more discoverable and legally compliant.

Knowledge Transfer Matters

Resolute’s role expanded beyond design and development work. We trained the client’s internal team to maintain and build on the system with accessibility in mind. That included:

• Documenting all accessibility decisions and techniques used
• Providing reusable design patterns in ThemeBuilder
• Running training sessions on WCAG basics and development workflow tips

Accessibility isn’t something you do once. It’s a practice. So, we made sure the team could carry that forward.

Final Thoughts

Accessibility is a shared responsibility—across design, development and leadership. Our client understood that, and, with the right tools and support, made serious progress toward a platform that works for everyone.

Progress ThemeBuilder helped streamline and standardize the design-to-code process. Resolute helped connect the dots by aligning compliance, usability and long-term scalability.

Learn more about how Resolute can help address usability issues, starting with the UX Assessment.