Building accessible components is one of those things we know we should do, but often skip because it feels overwhelming. We need to read about accessibility tips and tricks and a lot of documentation.

You start with a simple dropdown menu, knowing you need to handle keyboard navigation, ARIA attributes, focus management and screen reader support. Before you know it, your “simple” component has 200 lines of accessibility code you’re not even sure is correct. (Unless you’re using the Progress Kendo UI for Angular library, which has accessibility baked in for you. )

What if I told you there’s a way to get the accessibility magic you need, regardless of component library, with full control over your styling with the magic of Angular Aria?

But what is Angular Aria? Let’s make a small intro.

What Is Angular Aria?

Think of Angular Aria as a collection of accessibility superpowers for your components, but instead of manually implementing keyboard navigation, ARIA attributes and focus management, you import a directive, add it to your HTML and, boom, your component is accessible.

The Angular team built these directives following the W3C Accessibility Guidelines, so you don’t have to become an accessibility expert to build compliant components.

Hold On, What About Angular Material?

Great question! If you’ve been using Angular for a while, you’re probably thinking: “We already have Angular Material. Why do we need another library?”

Here are the key differences:

Angular Material gives you complete, prestyled components. They look great out of the box, but they come with Material Design opinions baked in. If you want a button that doesn’t look like a Material button, you’re going to fight the framework.

Angular Aria gives you headless directives—just the accessibility logic, zero styling. You get all the keyboard navigation, ARIA attributes and screen reader support, but you control every pixel of how it looks.

Think of it this way:

• Angular Material: It is plug and play, looks good, works immediately, but everyone has the same result. If you were building a physical doorway to your business, it would look like all other businesses, just with your business name on the sign.
• Angular Aria: This tool is more like the ramp to your front door, enabling anyone to access the business entrance, while allowing you to choose the awning, the window display and the door color.

So when should you use each one? We’ll dive deeper into that later in the article, but here’s the quick answer:

• Use Angular Material when you need to ship fast and Material Design works for you.
• Use Angular Aria when you have custom design requirements and need full control.

Remember, accessibility isn’t optional anymore. It’s a legal requirement in many countries, and, more importantly, it’s the right thing to do.

But implementing accessibility correctly is hard. You need to know:

• Which ARIA attributes to use (and when)
• How keyboard navigation should work for each pattern
• How to manage focus properly
• How screen readers interpret your markup

Angular Aria handles this complexity for you. You focus on the HTML structure, CSS styling and business logic, and Angular Aria takes care of accessibility.

But, as always, the best way to learn is by building something. Let’s do it!

Set Up the Project

First, create a new Angular application. In your terminal, run the following command (be sure to have Node.js installed).

npx @angular/cli@latest new angular-aria-demo

When CLI prompts stylesheet format, pick CSS.

  - **Which stylesheet format would you like to use?** → CSS

Now, navigate to your project and add Angular Aria:

cd angular-aria-demo
npm install @angular/aria

That’s it. We now have a fresh Angular project with Angular Aria installed. Let’s build something accessible!

Building an Accessible Toolbar

Let’s build a text formatting toolbar, the kind you see in rich text editors. This is a perfect example because it looks simple but has surprising accessibility complexity.

Using the CLI, generate a new component editor-toolbar:

ng generate c components/editor-toolbar

Perfect! Open the component with your editor, and import Toolbar, ToolbarWidget and ToolbarWidgetGroup directives provided by @angular/aria/toolbar.

  import { Component } from '@angular/core';
  import { Toolbar, ToolbarWidget, ToolbarWidgetGroup } from '@angular/aria/toolbar';
  
  @Component({
    selector: 'app-editor-toolbar',
    templateUrl: './editor-toolbar.component.html',
    styleUrl: './editor-toolbar.component.css',
    imports: [Toolbar, ToolbarWidget, ToolbarWidgetGroup],
  })
  export class EditorToolbarComponent {}

Now it’s time to build the HTML structure. We create a div container with the directive [ngToolbar], which works as the main container. We also need ToolbarWidget to use with individual buttons and ToolbarWidgetGroup for groups of related buttons.

In the following HTML, we use every directive with divs and button elements. Copy it and paste into the editor-toolbar.html.

  <div ngToolbar aria-label="Text Formatting Tools">
  <div class="group">
   <button ngToolbarWidget
           value="undo"
           type="button"
           aria-label="undo">
     Undo
   </button>
   <button ngToolbarWidget
           value="redo"
           type="button"
           aria-label="redo">
     Redo
   </button>
 </div>

 <div class="separator" role="separator"></div>

 <!-- Text formatting group -->
 <div class="group">
   <button ngToolbarWidget
           value="bold"
           type="button"
           aria-label="bold"
           #bold="ngToolbarWidget"
           [aria-pressed]="bold.selected()">
     Bold
   </button>
   <button ngToolbarWidget
           value="italic"
           type="button"
           aria-label="italic"
           #italic="ngToolbarWidget"
           [aria-pressed]="italic.selected()">
     Italic
   </button>
 </div>

 <div class="separator" role="separator"></div>

 <!-- Alignment group (radio buttons) -->
 <div ngToolbarWidgetGroup
      role="radiogroup"
      class="group"
      aria-label="Text alignment options">
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align left"
           aria-label="align left"
           #leftAlign="ngToolbarWidget"
           [aria-checked]="leftAlign.selected()">
     Left
   </button>
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align center"
           aria-label="align center"
           #centerAlign="ngToolbarWidget"
           [aria-checked]="centerAlign.selected()">
     Center
   </button>
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align right"
           aria-label="align right"
           #rightAlign="ngToolbarWidget"
           [aria-checked]="rightAlign.selected()">
     Right
   </button>
 </div>
</div>

The final step is adding some CSS styles to make it look nice. Open the editor-toolbar.css and paste the following style:

  [ngToolbar] {
 display: flex;
 gap: 8px;
 padding: 8px;
 background: #f5f5f5;
 border-radius: 4px;
}

.group {
 display: flex;
 gap: 4px;
}

.separator {
 width: 1px;
 background: #ddd;
}

button {
 padding: 8px 12px;
 border: 1px solid #ddd;
 background: white;
 border-radius: 4px;
 cursor: pointer;
}

button[aria-pressed="true"],
button[aria-checked="true"] {
 background: #007acc;
 color: white;
}

Perfect, we just added HTML, CSS and Angular Aria directives. To test it, open the app.html and add <app-editor-toolbar></app-editor-toolbar>, save changes and run your app.

ng serve
Initial chunk files | Names         | Raw size
main.js             | main          | 10.50 kB | 
styles.css          | styles        | 95 bytes | 

                    | Initial total | 10.59 kB

Application bundle generation complete. [0.641 seconds] - 2026-01-25T10:16:33.843Z

Watch mode enabled. Watching for file changes...
NOTE: Raw file sizes do not reflect development server per-request transformations.
  ➜  Local:   http://localhost:4200/
  ➜  press h + enter to show help

Try to use your toolbar with your keyboard. You’ll find it works, and we didn’t have to write any code for keyboard navigation logic (like: Arrow keys, Home, End), focus management, ARIA role attributes, screen reader announcements or selection state management. All of that complexity? Gone.

The ngToolbar, ngToolbarWidget and ngToolbarWidgetGroup directives handle all of that automatically.

We now have a fully accessible toolbar that works with keyboard navigation and screen readers, and we only wrote the HTML structure and CSS.

Angular Aria provides directives for the most common interactive patterns, we can get components for search and selection (like Autocomplete, Listbox and Select), navigation and actions (Menu, Menubar and Toolbar like we just built), and content organization (Accordion, Tabs, Tree and Grid). Every directive comes with complete documentation, working examples and API references. You can see the full list of available components in the official Angular Aria documentation.

But I’m a Fan of Angular Material

Yes, I understand Angular Material has a long relationship with Angular devs. You can continue using Angular Material when you:

1. Need to ship fast – You’re building an MVP or internal tool and don’t want to spend time on custom styling.
2. Like Material Design – You’re OK with the Google Material Design aesthetic.
3. Have limited design resources – Your team doesn’t have dedicated designers.

Remember, Angular Material is amazing, but it comes with opinions about how things should look.

If you try to heavily customize Material components, you’ll spend more time fighting the framework than building features. I’ve been there—overriding Material styles with ::ng-deep and !important until the CSS becomes unmaintainable.

And don’t even get me started on theming. Creating a custom theme for Angular Material is… let’s just say “special.” It’s doable, but it’s tricky and requires deep knowledge of Sass and Material’s theming system. (If you’re curious about the complexity, I wrote about it in Theme UI Frameworks in Angular: Part 2 - Custom Theme for Angular Material.)

Angular Aria solves this by giving you zero styles. You start with a blank canvas and build exactly what you need.

Remember for simple cases, native elements are already accessible when you use <button> for buttons, <input type="radio"> for radio buttons or <select> for simple dropdowns. But Angular Aria gives you a third option: headless accessible components that you can style however you want, we can meet accessibility requirements, maintain full design control and avoid reinventing the wheel.

Recap

We learned that accessibility doesn’t have to be overwhelming. Angular Aria gives you production-ready, WCAG-compliant directives that handle the complex parts.

We provide the HTML structure and CSS and Angular Aria provides the accessibility without pain!

But What About Kendo UI?

Maybe you want to ship faster (really fast) and have complex scenarios with datalist, charts, schedulers and complex UI patterns. If you read this article and are thinking: “This is great, but I still have to write all the HTML and CSS myself. Why not just use a complete component library?” you’re asking the right question.

Here’s when Progress Kendo UI for Angular makes more sense than Angular Aria or Angular Material:

Use Kendo UI when you want:

1. Everything out of the box – Prebuilt components with professional styling, themes and accessibility already done
2. Advanced features included – Things like data grids with sorting/filtering, charts, schedulers and complex UI patterns
3. Consistent design system – A cohesive look across all components without writing custom CSS
4. Enterprise-grade support – Professional support, regular updates and guaranteed compatibility
5. Speed PLUS customization – You need to ship fast and need options to customize (you’ll have five fully built theme options plus the ability to tweak those or create your own theme)

There’s no “wrong” choice—just different tools for different jobs.

If you’re building internal tools or you like the Kendo UI design system, Kendo UI saves you weeks of work, and, honestly? I can build complex stuff (data grids, schedulers, charts) in minutes, making Kendo UI the right answer for me.

Plus, you can use the Kendo UI for Angular AI Coding Assistant, an MCP server that automatically scaffolds components for AI agents. Instead of manually writing Kendo UI components, your AI assistant can do it for you.

Want to learn more? Check out my article: Angular and Kendo UI MCP: Making Agents Work for You

• Source code
• Angular Aria Documentation

Developing applications that can be used by everyone is a goal that any app should keep in mind. When I say “for everyone,” I mean that our applications should be able to communicate a clear and understandable purpose, so that people with or without disabilities can use them without issues. In other words, it’s not just about “making it work,” nor about limiting it to a single way of use (such as only being understandable if you can read the buttons).

You’ve probably heard the term A11y, and maybe you’ve stopped to think… What does it mean? A11y refers to the accessibility of our applications. While it’s much more common to hear this term in the web space, mobile applications should also take it into account to offer a better product.

In this article, you’ll learn more about accessibility, some guidelines you can follow to apply it correctly in .NET MAUI, the aspects you should start paying attention to and why A11y is not an extra, but a fundamental part of the quality of a well-built application.

Let’s Talk More About A11y

A11y is an abbreviated form of the word accessibility, and its goal is to allow people with or without visual, auditory, motor or cognitive disabilities to use your apps. A11Y is a type of abbreviation very common in technology, and it is known as a numeronym.

It works as follows:

• A: is the first letter of the word.
• 11: is the number of characters that come after the first letter and before the last one. In Accessibility, specifically in “ccessibilit,” there are 11 letters.
• Y: is the last letter of the word.

That’s why it is abbreviated as: A11y. This method makes it much more convenient to write long terms in a faster way and helps standardize lengthy terminology.

How Can We Apply A11y in Our Apps?

To implement this in our applications, there are accessibility guidelines such as WCAG, which instruct us on how to adapt the tools that mobile devices already provide so they can work together with our apps.

The Web Content Accessibility Guidelines (WCAG) are a set of international guidelines created by the World Wide Web Consortium (W3C). Although web is part of their name, I always recommend applying these practices to all types of applications, including mobile. Our users will thank us for it.

In fact, the official documentation states the following:

“These guidelines address accessibility of web content on any kind of device (including desktops, laptops, kiosks, and mobile devices).”

The WCAG are built on four fundamental principles, known as POUR. WCAG defines what an application must comply with to be accessible, while POUR helps us understand how to think about accessibility from a development perspective.

These four criteria that make up POUR are:

• Perceivable
• Operable
• Understandable
• Robust

Let’s take a closer look at POUR—what each principle means and some examples of how we can translate them into our .NET MAUI applications:

Perceivable

This principle indicates that all the information in the app (including text and UI components) must be perceivable by the user, regardless of how they interact with the device. In other words, our app should not be based solely on visual information.

This is especially important for users who:

• Use screen readers such as TalkBack or VoiceOver
• Have low vision or use larger text sizes

In .NET MAUI, we have SemanticProperties, which help us a lot with this aspect.

Semantic properties are the Microsoft-recommended approach in .NET MAUI to provide accessibility values in applications. This allows us to add a description to our visual elements so that they can be read by the screen reader.

Additionally, I recommend exploring SemanticOrderView. While the individual reading of each visual element is important, being able to provide the user with a reading order so that this reading is coherent greatly enhances a good user experience. For this, we can use SemanticOrderView from the .NET MAUI Community Toolkit.

Let’s explore some examples of implementing the Percievable principle in .NET MAUI:

Alternative Text for Images and Icons

Images and icons are very common in mobile apps, but for a screen reader, an image without a description is 100% invisible. That’s why it’s recommended to tell the screen reader that there is something there and what it should read.

In the following example, you can see the warning.png image used in the UI. When navigating the app with VoiceOver or TalkBack, this image will be announced as “Warning icon.” For this reason, I recommend being as specific as possible when defining its description.

<Image Source="warning.png"
 SemanticProperties.Description="Warning icon" />

What About Decorative Images?

Not all images provide information. In these cases, we can remove them from the accessibility tree so the screen reader ignores them (meaning it won’t read them):

<Image Source="divider.png"
 AutomationProperties.IsInAccessibleTree="False" />

This helps keep the experience cleaner and prevents the screen reader from reading unnecessary elements.

Headings

Screen readers don’t just “read in order” and stop there; they also allow users to navigate by sections. For this reason, it’s important to mark titles or main sections as semantic headings.

<Label Text="Payment Settings" 
 FontSize="24" 
 SemanticProperties.HeadingLevel="Level1" />

This way, the screen reader recognizes this element as a heading and makes navigation within the screen much easier.

Supporting Scalable Text

In addition to screen readers, there is also a significant number of users with low vision. You may have noticed that some people use very large text on their phones; that’s probably why.

As developers, we can contribute to making our app more accessible by allowing it to adapt to the text size users feel most comfortable with.

For this, in .NET MAUI we have FontAutoScalingEnabled, a property that allows the text in our app to automatically scale according to the system preferences.

<Label Text="Payment Settings" 
 FontSize="24" 
 FontAutoScalingEnabled="True" />

With this, if the user increases the text size from the device settings, the Label will scale accordingly, improving readability and aligning with the Perceivable principle.

Operable

The Operable principle states that users must be able to interact with the app without difficulty, regardless of the way they use the device.

In other words, not all users interact in the same way. Some use screen readers, others use a keyboard or assisted navigation. For this reason, the app should not rely solely on complex gestures or interactions that do not provide a clear alternative.

In mobile applications, this principle basically translates into:

• Easy-to-tap controls
• Clear and predictable navigation
• Avoiding interactions that require extreme precision

In .NET MAUI, many of these best practices can be applied directly using the components we already work with. Let’s see NET MAUI some Operable examples we can apply:

Appropriate Size for Interactive Elements

A very common problem is having icons or buttons that are too small, which limits interaction and can make the app difficult—or even impossible—to use for some users.

For this reason, it is recommended to respect minimum sizes for interactive elements:

• iOS: minimum 44 × 44 pt
  This recommendation comes from Apple’s Human Interface Guidelines, where this minimum size is established for interactive elements such as buttons or tappable icons.

• Android: minimum 48 × 48 dp
  On Android, this recommendation comes from the Android Accessibility Guidelines and Material Design.

In .NET MAUI, we can apply this easily, for example:

<Button Text="Continue" 
 HeightRequest="48" 
 Padding="16,12" />

Or for icon ImageButton:

<ImageButton Source="close.png" 
 WidthRequest="48" 
 HeightRequest="48" 
 Padding="12" 
 SemanticProperties.Description="Close" />

Understandable

This principle states that the information and interactions within our app must be easy to understand.

Why is this important?

• Not all users have the same technical level.
• Some may have cognitive difficulties.
• Others are simply using the app for the first time.

In mobile applications, this principle mainly translates into:

• Clear and direct text
• Consistent navigation
• Predictable actions
• Error messages that explain what happened and what to do next

Some examples of Understandable in .NET MAUI:

Clear Language in Text and Labels

Avoid ambiguous or overly technical texts (I’ve literally seen “state error” in apps … that should not happen), especially in buttons and important messages.

For example, for a save button, use text that clearly describes the action:

<Button Text="Save changes" />

Once the save action is executed, if an error occurs, don’t leave the user guessing or hanging. Tell them exactly what happened.

❌ Saving changes failed

✅ The name field cannot contain special characters

The idea is for the user to understand what happened and what the next step is, without having to interpret technical messages.

Robust

This principle states that the app must be robust enough to work correctly across different environments or devices. In other words, the app should continue to work when:

• It runs on different versions of the operating system
• It is used with screen readers such as TalkBack or VoiceOver
• It is used across different platforms
• It adapts to different screen sizes (small, medium and large) without affecting usability or content clarity

An example of the Robust principle in .NET MAUI is the use of OnPlatform.

OnPlatform

Although .NET MAUI abstracts many platform differences—and personally, I try to use OnPlatform as little as possible to keep maintenance easier across Android and iOS, always looking for visual elements that give me the same result—in some cases, Android and iOS behave differently, and using it becomes necessary.

If you run into that situation, you can use OnPlatform to keep the behavior on both platforms exactly how you want it:

<Button Text="Continue" 
 HeightRequest="{OnPlatform iOS=44, Android=48}" 
 Padding="{OnPlatform iOS='16,12', Android='16,14'}" />

This way, you respect each platform’s recommendations while keeping an accessible and consistent experience, aligned with the Robust principle.

Conclusion

And that’s it! In this article, we talked about A11y and why accessibility should be part of how we build mobile apps with .NET MAUI, not something added at the end. By understanding the POUR principles we saw how accessibility can be applied through small, intentional UI decisions.

From making content perceivable and interactions operable, to keeping things understandable and keeping our apps robust across platforms, each choice helps create a better experience for more users.

Remember: users may not know what A11Y is, but they definitely feel it when an app is accessible.

See you in the next article! ‍♀️✨

Maybe you know the acronyms: TDD, BDD or DDD. If not, go on Reddit and you will find enough debates to learn it keeps our industry busy.

Each acronym shifted how we think and how we build software. Now, with new accessibility laws setting a hard deadline, it’s time to add one more: ADD. Accessibility-Driven Development.

Compliance as a Driver of Quality

For years, accessibility was treated as optional or “nice to have.” A box you ticked if you had time. But history shows us that regulations and compliance raise quality and drive standardization.

Think about hardware safety regulations or industry protocols. At first, they seemed like a burden. But once enforced, they became the baseline that allowed whole industries to build better. Today, shipping is faster than ever. Compliance is the safeguard that helps prevent quality from being skipped.

A Time Change in Accessibility

If you’ve worked in UX or frontend development, you’ve probably heard of the Web Content Accessibility Guidelines (WCAG). They’ve been around for decades, laying out the rules: make software perceivable, operable and understandable.

WCAG has been the global guideline for accessibility. But for years, adoption was inconsistent. Companies did what they wanted, or what they could afford.

That changes now. The European Accessibility Act (EAA) is in force as of June 28, 2025. It harmonizes accessibility requirements across the EU and sets real deadlines for compliance. This is the moment accessibility shifts from voluntary guidance to enforceable law. A time change for the industry.

In the U.S., the Americans with Disabilities Act (ADA) has fueled a rise in lawsuits over inaccessible websites and apps. Similarly, Section 508 of the Rehabilitation Act requires federal agencies and contractors to conform to WCAG. Between lawsuits and procurement contracts, WCAG has become the standard in the U.S. too.

Different routes, same outcome: WCAG tells us that we need better software for everyone.

The Disciplines We Already Know

Disciplines reshape the way we develop software. They’re mindsets that force us to shift perspective and raise the quality of the software we ship.

TDD: Test-Driven Development

With TDD, we write failing tests before we write code. It flips the order. Instead of coding first and testing later, we define the boundaries up front.

The discipline: build resilience by considering how software might fail.

BDD: Behavior-Driven Development

BDD takes this further. Instead of only testing functions, we write scenarios in plain language: Given, When, Then. It’s not only developers who can understand, but also stakeholders, product owners, testers.

The discipline: align software with real user expectations.

DDD: Domain-Driven Design

DDD steps back another layer. It tells us: don’t just model features, model the domain itself. Speak the same language as the business. Reflect its truth in your system.

The discipline: design software that mirrors business reality.

Each of these disciplines changed how we think. They aren’t just tools; they’re shifts in mindset.

ADD: Accessibility-Driven Development

Now it’s time for the next discipline: Accessibility-Driven Development.

ADD means designing and testing for the edge user first—the one with constraints. The one who doesn’t use your product the way you do. If it works for them, it will work for everyone.

Think of it like TDD. In TDD, you write a failing test first. In ADD, you define the hardest case first.

Keyboard-only navigation becomes your failing test. A screen reader flow becomes your scenario. High-contrast mode becomes your business constraint. You design and build until those pass.

ADD shifts the mindset. Accessibility isn’t something you sprinkle in at the end. It is a discipline that shapes decisions during building.

The discipline: build software that is accessible to many, not to some.

Why ADD Matters Now

Why now? Without the European Accessibility Act, many teams would keep treating accessibility as optional. But with compliance dates set, ignoring accessibility is no longer a choice.

ADD helps you shift from reactive to proactive. Instead of scrambling with audits and lawsuits, you build accessibility into the process. Compliance becomes a habit, not a fire drill.

Here’s the point: designing for edge cases improves the experience for everyone. It’s called the curb cut effect. Those sidewalk ramps built for wheelchairs are also used by parents with strollers, travelers with luggage and kids on scooters.

You’re not wasting resources on a minority. You’re building better software. Accessibility isn’t overhead. It’s an advantage.

By designing for the most constrained environments, you raise the quality of the entire system.

Closing

Accessibility is not a gesture. It’s a discipline.

A new standard to comply with in software. And compliance has always been a driver of quality. Industry protocols in manufacturing. Safety standards in hardware. Now, accessibility in software.

You don’t have to choose between TDD, BDD and DDD. They’re not a menu. They’re a collection of development disciplines that shape how we build.

The one you need to add next is ADD: Accessibility-Driven Development.

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.

Today is Global Accessibility Awareness Day (GAAD). Celebrated each year on the third Thursday of May, GAAD is dedicated to raising awareness about digital accessibility and inclusion for the more than one billion people worldwide who live with disabilities.

To mark the occasion, we’ve created a quick and interactive accessibility quiz using the Progress KendoReact Form Wizard. The quiz includes questions on accessibility history, core principles and practical tips for React developers.

If you’re building your own accessible forms, be sure to check out the React Form Design Guidelines for helpful tips and best practices.

Once you’re ready, take the quiz and see how much you know about digital accessibility.

Start the quiz here.

Want to Brush Up Before You Start?

If you’d like a refresher before diving into the quiz, we’ve gathered a few helpful articles that provide background on key accessibility concepts and trends:

Web History

• The History of Web Accessibility and How It Impacts Design Today

React

• Getting Started with Accessibility for React

Standards

• What Is Accessible UX Design, and What is an Accessible Application?
• What Does the European Accessibility Act Mean for Developers?

Business

• The Hidden Costs of Inaccessible Apps for Enterprises and How to Avoid Them

Why Accessibility Matters Now More Than Ever

Two recent developments are bringing digital accessibility into sharper focus.

The European Accessibility Act (EAA)

The European Accessibility Act, which goes into effect on June 28, 2025, makes accessibility legally required for digital products used in the EU. Whether your team builds websites, mobile apps or software, if EU citizens use it, you’ll need to comply with standards like WCAG 2.1 Level AA and EN 301 549.

For more details on the EAA, be sure to check out the previous article we’ve written on the topic: What Does the European Accessibility Act Mean for Developers?

A Surge in Accessibility Lawsuits

In March 2025 alone, 457 digital accessibility lawsuits were filed in the U.S., targeting businesses of all sizes—from global brands like Canali and Palmer’s to small shops and nonprofits. The rise in legal action highlights the growing risk of non-compliance with accessibility standards like the Americans with Disabilities Act (ADA), making inclusive design not just a best practice but a legal necessity.

For more data on recent legal activity, you can get more details on the March 2025 lawsuit report here: Accessibility Lawsuits on the Rise: March 2025 Data Highlights Growing Compliance Risks.

Enterprise applications are the backbone of modern businesses, driving efficiency, enabling collaboration and streamlining complex operations. From platforms like Salesforce and SAP to collaboration tools like Microsoft Teams and Slack, these applications play a crucial role in the success of many businesses.

Enterprise apps aren’t just tools—they shape workflows, impact employee productivity and directly influence customer engagement. When accessibility is not prioritized, the impact extends beyond usability challenges by creating barriers that affect business outcomes, employee satisfaction and legal compliance.

In this article, we’ll explore the hidden costs of inaccessible enterprise applications and provide some actionable strategies for building accessible enterprise solutions.

For details on what makes the user experience of an application accessible, be sure to read the article we’ve written earlier on What Is Accessible UX Design, and What Is an Accessible Application?

What Are Enterprise Apps?

Enterprise applications are specialized software solutions designed to support the complex needs of large organizations. These applications enable communication, optimize data management and automate business processes while offering compatibility with legacy systems and maintaining security and scalability standards.

Enterprise apps come in various forms, including internal tools that enhance operational efficiency, enterprise resource planning (ERP) systems that manage company-wide resources, and customer-facing platforms that drive revenue. Whether it’s an HR system that streamlines onboarding or a customer relationship management (CRM) tool that facilitates customer interactions, these applications are integral to business success.

When accessibility is neglected, enterprise apps can sometimes create significant user barriers, leading to reduced productivity, frustrated employees and increased operational costs. The following section will explore the hidden costs of inaccessible enterprise applications and how businesses can proactively address them.

The Hidden Costs of Inaccessible Apps

When enterprise applications lack accessibility features, organizations face consequences beyond mere inconvenience. These hidden costs include legal liabilities, financial impact, brand damage and reduced efficiency. Let’s examine these often-overlooked consequences in a bit more detail.

Legal and Compliance Risks

Accessibility regulations are becoming more stringent worldwide. Standards like the Web Content Accessibility Guidelines (WCAG), the Americans with Disabilities Act (ADA) and the European Accessibility Act (EAA) set clear expectations for digital accessibility. The level of risk enterprises face often depends on whether the app is customer-facing or used internally. Public-facing applications must meet stricter legal requirements, while internal tools that exclude employees with disabilities can lead to workplace discrimination claims and compliance violations under labor laws.

For more details on the European Accessibility Act (EAA), be sure to read our article “What Does the European Accessibility Act Mean for Developers?”

Beyond legal consequences, addressing accessibility issues after an application is built is both costly and resource-intensive. Retrofitting often requires significant code rewrites, whereas integrating accessibility from the start eases compliance while reducing long-term technical debt.

Domino’s Pizza ADA Lawsuit
In a landmark case that reached the Supreme Court, Domino’s Pizza faced significant legal consequences when a blind customer sued them because their website and mobile app weren’t accessible with screen readers. After the Supreme Court declined to hear Domino’s appeal in 2019, the company was required to make their digital properties accessible and pay damages.

Financial Impact

Excluding users from an application due to accessibility barriers can lead to lost opportunities. Whether employees struggle with inaccessible internal tools or customers are unable to engage with a platform, usability issues can directly impact productivity and revenue.

Beyond lost productivity and revenue, organizations that fail to prioritize accessibility may face legal fees, regulatory fines, and settlement costs (see Legal and Compliance Risks section above). A lack of accessibility can also increase customer support costs, as users encountering accessibility issues are more likely to require manual assistance.

Damage to Brand Reputation

In today’s digital-first world, a large part of a company’s reputation is built on user experience. When enterprise applications fail to meet accessibility standards, it signals a lack of inclusivity—which may result in negative feedback, customer frustration and potential brand erosion.

Conversely, businesses championing accessibility can differentiate themselves, strengthening customer loyalty and attracting a more diverse user base. Prioritizing accessibility reduces risks and enhances a company’s reputation as an inclusive and socially responsible organization.

Microsoft’s Accessibility Transformation
Microsoft exemplifies how prioritizing accessibility can elevate brand reputation. After CEO Satya Nadella’s personal experience with his son, who has cerebral palsy, the company transformed its approach to inclusive design across enterprise applications. The results were tangible: innovative features like Eye Control in Windows 10 and Learning Tools in Office not only served users with disabilities but enhanced usability for everyone.

Operational and Employee Productivity Challenges

When enterprise applications aren’t accessible, they create friction in daily workflows. Employees who rely on assistive technologies—such as screen readers, keyboard navigation or voice commands—may struggle to complete tasks efficiently, leading to frustration and decreased productivity. This is particularly problematic in fast-paced business environments where delays can have cascading effects on operations.

Moreover, inaccessible tools can limit team collaboration, preventing employees from fully participating in meetings, documentation processes and decision-making. Organizations that fail to address these barriers may inadvertently exclude skilled employees, impacting team morale and retention rates.

How to Avoid Accessibility Pitfalls

Implementing accessibility in enterprise applications doesn’t need to be overwhelming or prohibitively expensive. With strategic planning and the right approach, organizations can create inclusive digital experiences while minimizing costs and maximizing benefits. The following section will discuss a few strategies for integrating accessibility into enterprise application development.

Build with Accessibility from the Start

Adopting an “accessibility-first” approach when building and maintaining an enterprise application is probably the most important strategy we can discuss. Integrating accessibility into the initial design and development phases is far more efficient than retrofitting existing applications.

By building with accessibility from the start, development teams can address potential barriers before they become embedded in the product architecture. This approach involves incorporating WCAG guidelines into design requirements, establishing accessibility checkpoints throughout the development lifecycle and helping all team members to understand accessibility principles.

Conduct Regular Accessibility Audits

Even with the best intentions, accessibility issues can emerge as applications evolve. Implementing a schedule of regular accessibility audits helps identify and address barriers before they impact users. These audits should combine automated testing tools with manual evaluations by accessibility experts and, ideally, feedback from users with disabilities.

Use Accessible UI Component Libraries

Enterprise applications often incorporate numerous UI components, from form controls to complex data visualizations. Rather than building these components from scratch, organizations can leverage accessible UI component libraries that have already been tested for compatibility with assistive technologies.

Progress Telerik and Kendo UI libraries offer robust solutions for accessible enterprise application development across multiple frameworks, including React, Angular, Vue and Blazor. These libraries provide WCAG-compliant components out of the box, significantly reducing the development effort required to create accessible interfaces while ensuring compliance with international standards, including Section 508 and EN 301 549.

The accessibility benefits of using Kendo UI components extend beyond essential compliance. Each component is engineered with proper semantic markup, appropriate ARIA attributes and keyboard navigation support. For example, complex interactive elements like charts, data grids, date pickers and dropdown menus in Kendo UI work smoothly with screen readers and support alternative input methods, so users can effectively navigate and interact with enterprise applications.

Wrap-up

Accessibility in enterprise applications isn’t just about compliance—it’s a business imperative with far-reaching impacts. Inaccessible apps create legal risks, financial losses, reputation damage and productivity barriers, while accessible design delivers competitive advantages through expanded talent pools, improved user satisfaction and enhanced brand perception.

The strategies outlined in this article—building accessibility from the start, conducting regular audits, and using accessible component libraries like Kendo UI—provide a starting point for creating inclusive enterprise applications.

Accessibility requires ongoing commitment rather than one-time fixes. By making this investment, enterprises not only mitigate risks but position themselves for greater innovation and market reach in an increasingly inclusive digital landscape. For more details on accessibility best practices and security compliance, be sure to explore the following resources:

• Accessibility and Digital Experience | Fireside Chat with Neil Milliken:
• Human-Centered Software Design: A State of the Marketplace Report | Whitepaper

The information provided on this blog does not, and is not intended to, constitute legal advice. Any reader who needs legal advice should contact their counsel to obtain advice with respect to any particular legal matter. No reader, user or browser of this content should act or refrain from acting on the basis of information herein without first seeking legal advice from counsel in their relevant jurisdiction.

Accessibility in user experience (UX) design enables digital products and services to be used by everyone, including individuals with disabilities. A user with low vision should be able to magnify text without losing readability. In contrast, a user with motor disabilities should be able to navigate a site using only a keyboard or voice commands.

A well-designed, accessible UX strategy accounts for these and many other considerations, leading to an accessible experience for all users, not just those with disabilities.

In this article, we explore some key factors that make an application accessible and how leveraging accessible UI libraries, such as Progress Kendo UI libraries, can simplify the development process while assisting users to meet accessibility standards compliance.

What Makes an Application Accessible?

An accessible application (e.g., a web application) is one that can be perceived, understood, navigated and interacted with by people of all abilities. While technical standards like WCAG 2.1 and EN 301 549 provide a framework for accessibility, a genuinely accessible application builds on checklist compliance to deliver an equivalent user experience.

Key aspects of accessible applications include structured content, semantic HTML, keyboard navigability and adaptable interfaces. Every interactive element—whether a button, form field or chart—should be clearly identifiable, operable without a mouse and presented with sufficient contrast. Moreover, proper use of WAI-ARIA attributes enhances assistive technology support by conveying meaningful roles and states for elements that may not have inherent accessibility.

A well-designed accessible application enables functional usability and maintains visual clarity for all users. Text should meet minimum contrast ratios—4.5:1 for regular text and 3:1 for large text, as outlined by WCAG 2.1 AA—to remain readable for individuals with low vision. Additionally, relying solely on color to communicate meaning can create barriers for users with color vision deficiencies. Important information should always be reinforced with alternative indicators, such as text labels, icons or patterns, to aid in clarity for all users.

Beyond the technical aspects, accessibility also extends to content itself. Providing meaningful error messages, alternative text for images and captions for multimedia allows users receive the same level of information, regardless of their method of interaction. By integrating accessibility from the outset, developers can create applications that are not only compliant but also user-friendly and inclusive.

The European Accessibility Act (EAA) and Its Impact

Accessibility has long been a consideration in software development, but the European Accessibility Act (EAA), coming into effect on June 28, 2025, reinforces its significance as a legal mandate. The EAA broadens accessibility requirements beyond public sector websites to encompass private businesses offering digital products and services within the EU.

This directive applies to industries ranging from software and ecommerce to finance and transportation. Companies that operate digital platforms, whether websites, mobile applications or self-service kiosks, must verify that their offerings meet specific accessibility standards. Even businesses based outside the EU must comply if they serve EU users.

For more details on the EAA and its implications for developers, see our previous article, “What Does the European Accessibility Act Mean for Developers?”

Component Libraries & Accessibility

For developers seeking efficient ways to meet accessibility requirements, leveraging prebuilt accessible UI components can significantly streamline the process. For example, Kendo UI, a bundle of UI libraries designed for jQuery, Angular, React and Vue applications, is built with accessibility in mind.

Kendo UI libraries, like KendoReact, adhere to WCAG 2.2 AA, for streamlined compliance across various interactive elements and components. Because KendoReact follows WAI-ARIA best practices, the components provided by these libraries provide clear role definitions, intuitive keyboard navigation and proper semantic markup. This eliminates the need for developers to implement accessibility from scratch, saving time while providing robust support for users with disabilities.

Beyond compliance, Kendo UI components prioritize usability and performance. The components are customizable, responsive and optimized for high-performance rendering. As an example, let’s examine how the React Chart component facilitates accessible data visualization, so that interactive charts and graphs are usable by all users, including those relying on assistive technologies.

Progress Kendo UI also provides the A11y Ocean Blue Theme, which adheres to WCAG 2.1 AA standards:

• Improves color contrast for better readability.
• Adjusts text sizes and spacing for better legibility.
• Works out of the box and can be further customized for specific a11y needs.

Accessible Data Visualization with Kendo UI Charts

One of the most challenging aspects of application accessibility is data visualization. While powerful tools for conveying insights, charts and graphs often present barriers for users relying on assistive technologies. Making that data visualization inclusive requires a combination of thoughtful design, structured markup and well-implemented keyboard interactions.

Kendo UI Charts set an excellent standard for accessible data visualization. Designed to be visually engaging and fully navigable, they offer extensive accessibility support that enables users with disabilities to interact with data effortlessly. The charts comply with WCAG 2.2 AA, support keyboard navigation and work well with screen readers.

Each chart component within a Kendo UI library is enriched with ARIA attributes to provide meaningful descriptions and roles. Users navigating via keyboard can focus on specific data points, legends and tooltips using arrow keys, for a structured reading order. Additionally, the charts offer customization options that allow developers to fine-tune interactions, contrast levels and label readability.

Comprehensive testing has been conducted to validate the accessibility of Kendo UI Charts with automated tools like axe-core and manual testing with screen readers such as NVDA and JAWS. This level of testing shows that the charts deliver an inclusive experience across various environments.

While we’ve shared links above that direct you to the Chart component in the KendoReact library, the Chart component is available in all the different Kendo UI libraries:

• Angular Charts — Kendo UI for Angular
• React Charts — KendoReact
• Vue Native Charts — Kendo UI for Vue
• jQuery Charts — Kendo UI for jQuery

Wrap-up

Accessible UX design and applications are not just regulatory requirements—they are essential for creating inclusive digital experiences that serve everyone. As the European Accessibility Act comes into effect, compliance with standards like WCAG 2.1 Level AA and EN 301 549 becomes mandatory, urging developers and businesses to embed accessibility into every facet of their design and development processes.

Building accessible applications requires a holistic approach—addressing content structure, keyboard navigation, visual clarity and assistive technology support. By leveraging prebuilt accessible UI components, such as those available in Kendo UI for Angular, React, Vue and jQuery, development teams can significantly streamline accessibility implementation without sacrificing functionality or performance.

For more details on accessibility best practices and security compliance, be sure to explore the following resources:

• Accessibility and Security Compliance – Progress Telerik
• European Accessibility Act (EAA) – Full Legal Text
• Human-Centered Software Design: A State of the Marketplace Report | Whitepaper
• Accessibility and Digital Experience | Fireside Chat with Neil Milliken, or watch below:

Accessibility (a11y) is a crucial part of web development, allowing your app to be usable by all, including people with disabilities. One of the most impactful places to start improving accessibility is navigation—the doorway and hallways of your application. If users can’t move through your app effectively (or at all), the rest of your content doesn’t matter.

In this article, I’ll cover a few key improvements you can make to enhance keyboard and screen reader accessibility, improve contrast and provide better user state identification in your navigation. While these examples are shown in an Angular app, the principles apply to any framework—the implementation is the only thing that changes.

Some accessibility updates are now required by the European Accessibility Act. Learn more.

1. Improve Active Link Identification for Clear Navigation

Using RouterLinkActive & AriaCurrentWhenActive

Many users rely on visual cues to understand where they are in an application—but not all users can see those cues. If an active link is only styled visually (e.g., with color), screen reader users won’t have a clear indication of their location, and users with low vision or color blindness may struggle to differentiate between active and inactive links.

To make navigation clearer for everyone, we need to:

✅ Visually indicate the active page (e.g., bold text, underlines or high contrast)
✅ Programmatically indicate the active page so assistive technologies can announce it

Step 1.1: Setting Up Routes in Angular

Before we start, we need to define our routes. In modern Angular, routes are typically defined in a routes.ts file and provided via provideRouter() in app.config.ts.

routes.ts

import {Routes} from '@angular/router';
import {HomeComponent} from './home/home.component';
import {UserComponent} from './user/user.component';
import { ShopComponent } from './shop/shop.component';
export const routes: Routes = [
  { path: '', title: 'App Home Page', component: HomeComponent },
  { path: 'home', title: 'Home Page', component: HomeComponent },
  { path: 'user', title: 'User Page', component: UserComponent },
  { path: 'shop', title: 'Shop Page', component: ShopComponent },
];

app.config.ts

import {ApplicationConfig} from '@angular/core';
import {provideRouter} from '@angular/router';
import {routes} from './app.routes';
export const appConfig: ApplicationConfig = {
  providers: [provideRouter(routes)],
};

Step 1.2. Adding Navigation with Active Styling

Next, we’ll create a simple navigation menu with routerLink to connect each route and a <router-outlet> to display the active route’s content.

⚠️ Heads up! Don’t forget to import RouterLink into your navigation component. If you skip this, your links may fail silently.

app.component.ts

import { Component } from '@angular/core';
import { RouterOutlet, RouterLink } from '@angular/router';

@Component({
  selector: 'app-root',
  template: `
    <nav>
      <a routerLink="home">Home</a>
      <a routerLink="user">User</a>
      <a routerLink="shop">Shop</a>
    </nav>
    <router-outlet />
  `,
  imports: [RouterOutlet, RouterLink],
})
export class AppComponent {}

We have working routes but we need to style it properly for better visibility. Let’s use routerLinkActive to give each anchor an special CSS class, indicating which anchor is currently active.

Step 1.3: Give the Active Link an Active Indicator

app.component.ts (Adding Active Styling)

import { Component } from '@angular/core';
import { RouterOutlet, RouterLink, RouterLinkActive } from '@angular/router';
@Component({
  selector: 'app-root',
  template: `
    <nav>
      <a routerLink="home" routerLinkActive="active-page">Home</a>
      <a routerLink="user" routerLinkActive="active-page">User</a>
      <a routerLink="shop" routerLinkActive="active-page">Shop</a>
    </nav>
    <router-outlet />
  `,
  imports: [RouterOutlet, RouterLink, RouterLinkActive],
})
export class AppComponent {}

At this point, Angular will dynamically apply the active-page class when a link is active. Now, let’s add some CSS to make it visually clear.

Step 1.4: Styling the Active Link

CSS (either in your component file or an external one, your choice)

.active-page { 
  font-weight: 800; //bold would also work
  text-decoration: underline; 
  color: hotpink; 
}

So here, we are giving the active link a CSS class of active-page and then adding styles to that class name in our css file:

✅ Now, users can clearly see which page is active.
But we still have an issue: This solution only benefits sighted users. Screen readers still can’t tell which link is active—which we’ll fix next.

Summary of improvements so far:

✔️ Active links now have clear visual indicators (bold + underline, as well as color)
✔️ Keyboard users can navigate links properly
✔️ Still missing: A way for screen readers to recognize the active link (we’ll fix that next!)

2. Making Active Links Accessible with ariaCurrentWhenActive

While visual indicators like color, bold text and underlining help sighted users, screen readers need additional context. The RouterLinkActive directive allows us to set an aria-current attribute using ariaCurrentWhenActive. This tells assistive technologies which link represents the active page, improving the navigation experience for non-visual users. (Some screen readers will even announce what you set this value to. More on this later.)

So, to recap:

Sighted users benefit from bold text and underlines, but screen reader users need more context.
The RouterLinkActive directive helps visually, but it doesn’t provide semantic meaning for assistive technologies.
Solution: Use aria-current to programmatically identify the active page.

app.component.ts updated!

import { Component } from '@angular/core';
import { RouterOutlet, RouterLink, RouterLinkActive } from '@angular/router';
@Component({
  selector: 'app-root',
  template: `
    <nav>
      <a routerLink="home"
          routerLinkActive="active-page"
          ariaCurrentWhenActive="page">
        Home
      </a>
      <a routerLink="user"
          routerLinkActive="active-page"
          ariaCurrentWhenActive="page">
        User
      </a>
      <a routerLink="shop"
          routerLinkActive="active-page"
          ariaCurrentWhenActive="page">
        Shop
      </a>
    </nav>

    <router-outlet />
  `,
  imports: [RouterOutlet, RouterLink, RouterLinkActive],
})
export class AppComponent {}

✅ With this in place, screen readers will announce the active page when users navigate, improving accessibility.

Demo: Watching Aria-Current in Action

Below is a screen recording demonstrating how the active class (active-page) and aria-current attribute update as you navigate between links.

Key Takeaways

✅ Use RouterLinkActive with ariaCurrentWhenActive to make active links accessible.
✅ Check that your active links do have enough visual contrast.
✅ Style active links with more than just color—use bold text, underlines or other distinguishable elements.

3. Test with a Screen Reader to Provide Users Meaningful Feedback

Once you’ve added RouterLinkActive with ariaCurrentWhenActive, it’s important to test how it behaves with a screen reader. Verifying that assistive technologies properly recognize and announce active links is critical to creating an accessible navigation experience.

After adding RouterLinkActive with ariaCurrentWhenActive, I tested the implementation using VoiceOver on my Mac. The improvements were immediately noticeable. For example, I was able to use the Tab key to navigate between links, and when I pressed Enter, the selected link was properly activated. (This didn’t work before.) Additionally, VoiceOver correctly announced the value we set for ariaCurrentWhenActive, stating “Current Page” when the active link was reached.

This made the navigation experience much clearer and more intuitive for users relying on screen readers. Without ariaCurrentWhenActive, there would be no clear indication of the currently active page, leading to potential confusion. The ability to easily determine one’s position in the app is essential for accessibility, and it enhances the overall user experience for those using assistive technologies.

️ Before:

• The Tab key could navigate between links, but pressing Enter did not activate them reliably.
• Screen readers did not announce which link was currently active.

✅ After:

• Pressing Enter now reliably activates links.
• VoiceOver correctly announces “Current Page” when the active link is reached.

Given how useful this feature is, I wish that ariaCurrentWhenActive were automatically generated whenever routerLink is used. It would save developers time while equipping better accessibility by default. Until that happens, it’s a best practice to explicitly include ariaCurrentWhenActive whenever implementing navigation in an Angular app.

If you’re ready to start improving accessibility, don’t overthink it—just pick one assistive technology and try it with your product. You’ll likely notice major accessibility gaps right away. And don’t let “testing” freak you out or bog you down—just choose one simple but common task (like navigating your site, signing in or adding something to the cart) and try doing it with an assistive technology active, using only your keyboard instead of your mouse.

Here are a few options to get started. Pick one and spend just 10 minutes testing. That quick effort can reveal insights that will significantly enhance your user experience!

Recommended Assistive Technologies:
Windows: NVDA (free), JAWS (paid)
Mac: VoiceOver (built-in)

In Chrome

1. Screen Reader Testing Extensions
• ChromeVox – Google’s screen reader for quick tests (not a full JAWS/NVDA replacement)
• Screen Reader – A simple browser-based tool for basic navigation tests

2. Accessibility Audit & Debugging Tools
• Axe DevTools – Best for automated accessibility testing; identifies issues related to screen reader navigation
• WAVE Evaluation Tool – Highlights accessibility errors visually
• Accessibility Insights for Web – Guided testing from Microsoft
• ARIA DevTools – Helps you inspect ARIA attributes to check compatibility with screen readers

3. Simulate Visual Impairments
• NoCoffee Vision Simulator – Helps you see how users with low vision, color blindness or contrast issues experience your app

So for a complete test, you could select one from each category for your browser of choice:

• Axe DevTools or WAVE for an initial audit.
• ChromeVox to test actual screen reader navigation.
• ARIA DevTools to verify proper ARIA attributes.
• (As well as voiceover, for testing from the system’s side)

But again, a step in the right direction is better than looking the other way. So if you just have time for one, then do it!

Step 4: Use Provided A11y Tools

Are you using a component library? If so, I bet they have taken steps (like the Angular team with their aria directive on routes) to help improve accessibility wherever possible. One example of this would be with the Angular component library from Progress Kendo UI. It has a new theme swatch to enhance contrast.

Progress Kendo UI’s A11y Ocean Blue Theme adheres to WCAG 2.1 AA standards:

• Improves color contrast for better readability.
• Adjusts text sizes and spacing for better legibility.
• Works out of the box and can be further customized for specific a11y needs.

So to get started with our Kendo UI A11y theme, first, let’s install it in our project.

1. Install the desired theme package via npm:

• For the Default theme:

npm install --save @progress/kendo-theme-default

2. Include the theme in your project:

a. Using SCSS (recommended for customization):

• Import the entire theme in your main SCSS file (e.g., styles.scss):

@use "@progress/kendo-theme-default/scss/all.scss";

• Alternatively, to reduce the CSS size, import only the components you use:

@use "@progress/kendo-theme-default/scss/index.scss";
        @include kendo-button;
        @include kendo-grid;

b. Using precompiled CSS:

• In your angular.json file, add the CSS file to the styles array:

"styles": [
          "node_modules/@progress/kendo-theme-default/dist/all.css",
          "src/styles.css"
          ]

Then, we are going to include the the A11y Ocean Blue swatch on top of the default theme. Here is how:

style.scss

@use "@progress/kendo-theme-default/dist/default-ocean-blue-a11y.scss" as *;

For more detailed information, refer to the Kendo UI for Angular Styling and Themes documentation.

Now, any of our components will have higher contrast, just by enabling this theme.

Final Thoughts: Small Changes, Big Impact

Improving your navigation accessibility doesn’t have to be overwhelming. By implementing just a few key changes—like visually and programmatically indicating active links, testing with a screen reader and leveraging built-in accessibility tools—you can create a more inclusive and user-friendly experience for everyone.

Key Takeaways

✔️ Use RouterLinkActive with ariaCurrentWhenActive to make active links both visually and programmatically identifiable.
✔️ Test your navigation with assistive technologies—even 10 minutes of testing can reveal major accessibility gaps.
✔️ Take advantage of available tools, whether it’s browser extensions, screen readers or high-contrast themes like Kendo UI’s A11y Ocean Blue Theme.
Next Steps: Pick one thing from this guide—just one—and give it a try. Whether it’s adding ariaCurrentWhenActive, testing your app with a screen reader, or adjusting contrast, any step toward accessibility is a step in the right direction.

The web should be accessible to everyone—let’s build it that way.

Accessibility in digital experiences has long been a goal for developers, but the European Accessibility Act (EAA) introduces legal mandates that make it an imperative. With the EAA coming into effect on June 28, 2025, developers need to verify that their digital products and services comply with its accessibility standards.

In this article, we’ll break down:

• What the European Accessibility Act entails
• How it affects developers and businesses
• Recommended solutions to streamline accessibility implementation

Understanding the European Accessibility Act (EAA)

The European Accessibility Act (EAA) is a directive designed to improve accessibility across digital products and services within the European Union. It builds upon existing regulations like the Web Accessibility Directive, expanding requirements beyond public sector websites to private companies that offer digital goods and services to EU consumers. The EAA applies to various industries, including:

• Software companies – Compliance is required if you and your team build websites, mobile apps or software used in the EU.
• Ecommerce and online services – Businesses selling online must provide accessible shopping experiences.
• Banking and financial services – Digital banking apps, ATMs and payment services must be accessible.
• Transport and travel services – Ticket booking platforms, airport kiosks and travel apps must accommodate all users.

Even if a business is not based in the EU, if an app or service is used by EU residents, compliance with the EAA is required!

Technical Standards: WCAG 2.1 Level AA and EN 301 549

The European Accessibility Act (EAA) is based on WCAG 2.1 Level AA and EN 301 549, both of which define the technical accessibility requirements for digital products and services.

WCAG 2.1 Level AA (Web Content Accessibility Guidelines) establishes four core principles to test whether content is accessible to all users:

• Perceivable – Content must be presented in a way that all users can understand, including those with visual, auditory or cognitive impairments. This includes implementing alt text, captions and high-contrast themes.
• Operable – Users must be able to navigate and interact with the app using keyboards, screen readers or alternative input methods. All UI components should be focusable and usable.
• Understandable – Information should be easy to read and process. Forms, error messages, and instructions must be clear, consistent and concise.
• Robust – The app should work with assistive technologies and be compatible with evolving accessibility tools. Semantic HTML should be used to help enable compatibility across different platforms.

While WCAG 2.1 Level AA provides the foundation for web accessibility, EN 301 549, a European standard developed by ETSI under the mandate of the European Commission, extends these requirements by defining broader technical specifications, particularly for software applications, hardware and Information and Communication Technology (ICT ) products.

Under EN 301 549, additional compliance areas include:

• Assistive technology support – Verifying that software is compatible with screen readers, braille displays and alternative input methods.
• Real-time text and audio descriptions – Requirements for live captions, text transcripts and alternative communication channels.
• Hardware and operating system accessibility – Covering physical device interfaces, operating system-level features and compatibility with accessibility settings.

If your application already adheres to WCAG 2.1 Level AA, it partially meets EAA requirements. However, full compliance may require additional modifications, particularly in software interoperability, documentation and hardware integration, as outlined in EN 301 549.

For a full understanding of the technical requirements and compliance obligations, be sure to read the European Accessibility Act in detail.

What Developers Need to Do to Build Compliant Apps

The European Accessibility Act does not necessitate a complete redesign, but developers must make structured enhancements to meet compliance. Here are some areas developers can focus on to make their applications accessible:

Conduct an Accessibility Audit

Assess whether your product meets WCAG 2.1 Level AA standards using tools like axe DevTools, Lighthouse and WAVE. Perform manual testing of keyboard navigation, form usability and screen reader compatibility.

Improve Keyboard Navigation & Assistive Tech Support

Verify that all interactive elements—buttons, forms, modals, dropdowns—are fully keyboard-accessible and work with screen readers like NVDA, VoiceOver and JAWS.

Enhance Color Contrast & Readability

Maintain a minimum contrast ratio for text and avoid using color alone to indicate status. Tools like Stark and Contrast Checker can help validate contrast levels.

Use an Accessible UI Component Library

Instead of developing accessibility features from scratch, developers can accelerate compliance by integrating pre-tested, WCAG-compliant UI components. Progress Telerik and Kendo UI offer a robust set of accessibility-ready components for technologies including React, Angular, Vue and Blazor, reducing development effort in meeting compliance with WCAG 2.1, Section 508 and EN 301 549 standards.

For more details on how Telerik and Kendo UI support accessibility compliance, be sure to explore Progress’ Accessibility and Security Compliance Resources.

Curious how the Progress Telerik and Kendo UI component libraries can help? Accessibility compliance comes baked in, giving developers one less thing to figure out.

Learn more

Wrap-up

The European Accessibility Act (EAA) marks a significant step toward creating a more inclusive digital landscape. With compliance becoming mandatory by June 28, 2025, developers and businesses must prioritize accessibility in their applications. Verifying that your digital products meet WCAG 2.1 Level AA and EN 301 549 standards aligns with legal obligations, enhances user experience, broadens audience reach and reinforces a commitment to inclusivity.

By conducting accessibility audits, improving keyboard navigation, enhancing contrast and readability, and leveraging accessible UI component libraries like Telerik and Kendo UI, development teams can efficiently meet EAA requirements while streamlining implementation.

Lastly, accessibility is not just about compliance—it’s about providing equal access for all users. Taking proactive steps now can help future-proof your applications while fostering a more usable, inclusive and legally compliant digital environment.

For more details on accessibility best practices and security compliance, be sure to explore the following resources:

• European Accessibility Act (EAA) – Full Legal Text
• Human-Centered Software Design: A State of the Marketplace Report | Whitepaper
• Accessibility and Digital Experience | Fireside Chat with Neil Milliken, or watch it below:

In the vast world of web development, HyperText Markup Language (HTML) stands as one of the foundational languages that every web developer must grasp. It’s the skeleton of a webpage, defining its structure and content. However, not all HTML is created equal, and understanding the nuances of semantic HTML is crucial for creating accessible, SEO-friendly and maintainable websites.

In this article, we’ll take a look through the basics of semantic HTML, explain its importance and provide practical examples to help you start using it effectively.

HTML: The Bedrock of Modern Web UI Development

Before diving into semantic HTML, it’s essential to understand the role HTML plays in the broader context of web development. HTML serves as the foundational element for all webpages and is the fundamental building block upon which every website is constructed. When Tim Berners-Lee invented HTML in 1991, his goal was to create a language that allowed documents to be shared across a network of computers, which eventually evolved into the World Wide Web. Since then, HTML has undergone significant transformations, adapting to the needs of a rapidly growing digital world.

HTML’s primary purpose is to structure content on the web. It instructs the browser on how to render text, images and other multimedia elements, turning raw data into something visually meaningful and interactive. But HTML is not just about presentation; it’s also about semantics—providing context and meaning to content, which is where the evolution into semantic HTML comes into play.

What Is Semantic HTML?

Semantic HTML refers to the use of HTML elements that clearly describe their meaning in a human and machine-readable way. In simple terms, when we use semantic elements, we’re telling the browser and other technologies (like screen readers and search engines) what kind of content is inside the element.

For example, consider the following two HTML snippets:

<!-- Non-semantic HTML -->
<div id="header">
  <div class="logo">MyLogo</div>
  <div class="nav">Home | About | Contact</div>
</div>

<!-- Semantic HTML -->
<header>
  <h1>MyLogo</h1>
  <nav>
    <ul>
      <li>Home</li>
      <li>About</li>
      <li>Contact</li>
    </ul>
  </nav>
</header>

Both of these snippets will render similarly in a browser. However, the second example uses semantic HTML elements like <header>, <h1> and <nav>, which provide more context about the content they contain. This not only makes code more readable and easier to maintain but also improves accessibility and SEO.

Why Is Semantic HTML Important?

Accessibility

Accessibility is a key consideration when developing modern websites, and semantic HTML plays a vital role in making a website accessible to users with disabilities. For example, screen readers rely on semantic elements to understand the structure of a page and to provide meaningful navigation options to users. When we use semantic tags like <article>, <section>, <header> and <footer>, we help screen readers to better interpret the content, which enhances the user experience for individuals who rely on these technologies.

Consider a visually impaired user who uses a screen reader. If our webpage is structured with non-semantic <div> and tags, the screen reader might struggle to convey the structure and importance of the content. On the other hand, semantic HTML provides clear cues about the role of each piece of content, making the web more inclusive.

SEO (Search Engine Optimization)

Search engines like Google also benefit from semantic HTML. Semantic tags give additional context and meaning to the content, which search engines use to understand the hierarchy and context of a webpage. This understanding helps search engines to rank a webpage more accurately for relevant queries.

For example, the <article> tag indicates that the content inside it is a standalone piece of information, which might be important in the context of a search query. Similarly, the <header> and <footer> tags define the top and bottom sections of a page, helping search engines to better comprehend the structure of a site.

Code Maintainability

Writing clean, semantic HTML improves the maintainability of a codebase. When we use meaningful elements, other developers (or even your future self) can more easily understand the purpose of each section of the code. This can save time and reduce errors during updates and debugging.

Consider a large project where we need to update the navigation structure across multiple pages. If we’ve used a <nav> element consistently, we can quickly locate and modify the relevant sections. In contrast, if we’ve used non-semantic <div> elements with arbitrary classes, finding the right elements to update could be a more time-consuming and error-prone process.

Common Semantic HTML Elements

Now that we’ve covered why semantic HTML is important, let’s look at some of the most commonly used semantic elements and their purposes.

Header

The <header> element represents introductory content or a group of navigational links. It typically contains headings, logos or other elements that are at the beginning of a section or page.

<header>
  <h1>Website Title</h1>
  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">About</a></li>
      <li><a href="#">Contact</a></li>
    </ul>
  </nav>
</header>

Nav

The <nav> element is used for defining a set of navigation links. This helps users and search engines easily identify the main navigation areas of your site.

<nav>
  <ul>
    <li><a href="#">Home</a></li>
    <li><a href="#">Blog</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>

Main

The <main> element is used to enclose the dominant content of the <body> of a document. The content inside <main> should be unique to the document and not include content that is repeated across documents like sidebars or footers.

<main>
  <article>
    <h2>Article Title</h2>
    <p>This is the main content of the article.</p>
  </article>
</main>

Article

The <article> element is intended to represent a self-contained composition in a document, page or website, which is designed to be independently distributed or repurposed, such as in syndication.

<article>
  <h2>Understanding Semantic HTML</h2>
  <p>Semantic HTML is essential for accessibility, SEO, and maintainability.</p>
</article>

Section

The <section> element represents a standalone section of content that typically comes with a heading. It’s used to group related content together.

<section>
  <h3>Introduction</h3>
  <p>This section introduces the topic.</p>
</section>

Aside

The <aside> element is intended for content that is related to the surrounding content but not essential to its primary message.

<aside>
  <h4>Related Information</h4>
  <p>This is additional information related to the main content.</p>
</aside>

Footer

The <footer> element signifies the end section of a page or content, often including details about the author, copyright information or related links.

<footer>
  <p>© 2024 MyWebsite. All rights reserved.</p>
</footer>

To see how all the above elements work in practice, let’s consider a simple webpage structure:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My Webpage</title>
  </head>
  <body>
    <header>
      <h1>My Webpage</h1>
      <nav>
        <ul>
          <li><a href="#">Home</a></li>
          <li><a href="#">About</a></li>
          <li><a href="#">Contact</a></li>
        </ul>
      </nav>
    </header>

    <main>
      <article>
        <h2>Understanding Semantic HTML</h2>
        <p>
          Semantic HTML is essential for accessibility, SEO, and
          maintainability.
        </p>
      </article>

      <section>
        <h3>Benefits of Semantic HTML</h3>
        <p>
          It helps with search engine optimization, accessibility, and code
          readability.
        </p>
      </section>
    </main>

    <aside>
      <h4>Did You Know?</h4>
      <p>Using semantic HTML can improve your site’s accessibility.</p>
    </aside>

    <footer>
      <p>© 2024 My Webpage. All rights reserved.</p>
    </footer>
  </body>
</html>

In the above example, we’ve used a variety of semantic elements to structure the webpage. Each element has a specific role, making the HTML more meaningful and easier to understand for both humans and machines. For a full list of roughly 100 semantic elements that exist in HTML, refer to the MDN HTML elements reference guide.

Wrap-up

Semantic HTML is more than just a buzzword; it’s a crucial aspect of modern web development. By using semantic elements, we can create content that is accessible, SEO-friendly and easier to maintain. Some best practices for writing semantic HTML include:

• Use the right element for the job. Always try to use the most appropriate semantic element for the content you’re marking up. For example, use <article> for blog posts or news articles and <section> for grouping related content.
• Avoid divitis. “Divitis” is a term used to describe the overuse of <div> elements. While <div> has its place, relying too heavily on it when more descriptive elements are available can make your code less readable and less semantic.
• Keep accessibility in mind. When choosing elements, consider how they will affect users who rely on assistive technologies. Use landmarks (like <nav>, <main> and <footer>) to help these users navigate your content more easily.
• Validate your HTML. Use tools like the W3C HTML Validator to check that your code is valid and follows best practices. This can help catch errors and ensure your semantic HTML is well-formed.

Whether you’re building a simple personal blog or a complex web application, understanding and applying semantic HTML will set a strong foundation for your project, making it more robust and user-friendly for all.

When developing an application, it’s important to cover as many scenarios and user needs as possible. One example is accessibility features. Imagine you have a registration form with different fields that visually make logical sense. But now, imagine a visually impaired person using it. This person will use a screen reader, but if it follows the visual order, it might not make sense to someone who is just listening.

Therefore, it’s ideal to establish the specific order in which each field should be read. This way, our application becomes much more accessible and easy to use. For this, we will use the SemanticOrderView from the .NET MAUI Community Toolkit.

What Is .NET MAUI Community Toolkit?

The .NET MAUI Community Toolkit is a curated collection of reusable components thoughtfully developed by the community. It encompasses a range of elements such as animations, converters and behaviors, all designed to accelerate app development. What’s more, it provides compatibility across iOS, Android, macOS and Windows, all thanks to the power of .NET MAUI.

What Is SemanticOrderView?

SemanticOrderView is an API of the .NET MAUI Community Toolkit. It allows us to set the order in which screen readers read the visual elements on our screen, so that it’s as understandable as possible for users who do not have the visual context. Screen readers identify and interpret what is shown on screen, improving accessibility in the new application.

Imagine the following example. You have a form in your app that requires the fields: email, full name, age and country. The default screen reader reads these fields in the exact order they appear on the screen. However, reading the email field first can be confusing for someone without the full visual context of the form, unlike someone who can see it.

Therefore, it would be ideal to reorder the fields so they can be read in a way that makes the most sense, regardless of their visual order.

Let’s look at the example visually:

Next, we will work on setting up this app!

Initial Setup

To correctly implement the SemanticOrderView, you’ll need the .NET MAUI Community Toolkit properly configured in your app. Setting it up is straightforward, as outlined in the steps below:

1. Installation: First, make sure to install the toolkit by adding the Community.Toolkit.Maui NuGet package.

2. Setup in MauiProgram.cs: After adding the NuGet package, navigate to MauiProgram.cs. Right below UseMauiApp<App>(), append:

.UseMauiCommunityToolkit()

3. Namespace Addition: Include the toolkit namespace in your page:

xmlns:toolkit="[http://schemas.microsoft.com/dotnet/2022/maui/toolki](http://schemas.microsoft.com/dotnet/2022/maui/toolkit)t”

How to Implement SemanticOrderView?

Step 1: Let’s start by adding the SemanticOrderView component from the .NET MAUI Community Toolkit. To do this, add the tags indicated below with the SemanticOrderViewSample in the x:Name property. Within this tag, include the code specified in Step 2.

<toolkit:SemanticOrderView x:Name="SemanticOrderViewSample">
    
  <!-- Add the code for Step 2 here. -->
    
</toolkit:SemanticOrderView>

Step 2: Now, we will add the fields that our example will contain:

<VerticalStackLayout Padding="30,0" Spacing="25">
    
  <Entry x:Name="Email" Placeholder="Write your email"/>
    
  <Entry x:Name="Fullname" Placeholder="Write your full name"/>
    
  <Entry x:Name="Age" Placeholder="Write your age"/>
    
  <Entry x:Name="Country" Placeholder="Write your country name"/>
    
</VerticalStackLayout>

⚠️ Note that all entries have the x:Name property with their respective names. This will help us complete the example in the next step.

Step 3: Finally, call the ViewOrder property of the SemanticOrderViewSample and add a View List with the order in which you want the visual elements to be read. Remember to use the names you assigned earlier in the x:Name property for each element.

public MainPage() 
  { 
    InitializeComponent(); 
    this.SemanticOrderViewSample.ViewOrder = new List<View> { Fullname, Email, Country, Age}; 
  }

Yay!

And that’s it! In this simple way, you’ve learned how to organize your visual elements more intuitively, making it easier for people with visual disabilities to use your app!

✍️ Highlight

This is particularly useful when creating user interfaces in a different order than how users and screen readers navigate through them.

References

This article was based on the official documentation:

• https://learn.microsoft.com/en-us/dotnet/communitytoolkit/maui/views/semantic-order-view

The search engine optimization (SEO) strategy for a website is a multifaceted one. Not only do you need to optimize your on-page content, but you need to optimize the technical aspects of the site along with your off-site presence. To make matters more complicated, you also need to be doing image SEO.

In this post, we’ll look at what image SEO is, the benefits of doing it and nine tactics to add to your SEO strategy today.

What Is Image SEO?

Image SEO is a strategy that increases the rankability of a webpage’s visual content. By optimizing your imagery, you not only give your images some visibility in search results, you also provide your website with more opportunities to rank overall.

There are many different spots where your images can appear in Google and other search engines.

Google Images search is a big one.

In this search for “best plants for apartments with low light,” you can see how high-quality images and custom graphics can help draw more visitors to your website.

Google Shopping is another area of search results where the optimization and quality of the images attached to your webpages—and, more specifically, your shop pages—matters.

Even regular search results pages provide an opportunity for your website visuals to appear. This is what the default “All” tab looks like:

At the top are nine results in a “From sources across the web” block. The first organic search result also comes with a featured SERP thumbnail beside it.

There are other areas where images may spring up. For example:

• Image pack
• Image carousel
• Top stories
• Product blocks
• Knowledge panel

Similar to regular SEO, though, there’s no way to just hit a button or enter some HTML that automatically forces Google to display your page or imagery in search results. So you really need to know what the Google algorithm is looking for when it decides what content to rank over other content.

When Should You Do Image SEO?

Always. Well, sort of.

When I say “always,” what I mean is that image SEO should always be part of a website’s overall SEO strategy. And when I say “sort of,” what I mean is that not every image needs to be optimized.

Let me dig into this a bit further:

The term “search engine optimization” makes it seem like we’re creating and optimizing images for Google’s crawlers. The truth is, search engine optimization has as much to do with your visitors as it does the technology they use to find your website.

For instance, we add alt text so that search engines can “read” what’s in our most important images. We also use alt text so that users with visual impairments can “see” what’s inside the image.

Usability and accessibility are vital to the success of a website and its ability to convert.

But not every image needs to be used or accessed. Some images, for instance, are there merely for decorative purposes. While you will still want to do things like resize and compress the image for performance enhancement purposes, you won’t need to add alt text to those images.

There’s no benefit to the user to see/hear what is inside a decorative graphic or stock photo. It also won’t matter when it comes to ranking as these kinds of images won’t appear in search results nor would they be helpful to people searching relevant keywords.

So, yes, image SEO is something to do when building a website. However, you need to pick and choose your battles. First, decide which images need to be optimized. Then, determine what types of optimizations to apply to them.

9 Image SEO Strategies

You may already be using some of these tactics in your regular SEO strategy, performance optimization strategy as well as your video SEO strategy. Regardless, there are some other tasks to add to your list if you’re not already doing them:

1. Use Rank-worthy Images

Not every image on your site needs to rank in Google Images or accompany your pages in regular search results. However, images deserving of special placement should be chosen or designed as such.

Let’s go back to our indoor plant example. Here are some of the images that appear a bit lower on the first search engine results page:

The photos that accompany Apartment Therapy and Lively Root look nice. They’re well-lit, well-framed and colorful. They were good choices in terms of featured images.

So too are the illustrations attached to Apartment Guide and The Spruce. Let’s take a closer look at the illustration in the Apartment Guide post:

This kind of image really stands out because it visually demonstrates what’s about to be covered in the post. It’s not just going to be a list of houseplants. It’s going to show you which plants thrive in low to bright direct light.

These are the types of images that are rank-worthy because they add much more value to the page and tell a story in and of themself. That’s not to say you can’t rank with a stock photo, but if your goal is to increase traffic to your site, then it needs to be unique, memorable and relevant.

2. Resize and Compress All Images

According to HTTP Archive, images continue to leave a huge footprint on websites.

On average, a webpage weighs about 2669.5 KB on desktop and 2364.7 KB on mobile. Images make up a little less than half of that—about 1067.9 KB on desktop and 906.5 KB on mobile.

One way to get these file sizes down is to resize and compress images before uploading them to your server. There are many tools you can use for this, starting with your graphic design software. In addition, you can use free online resizing and compression apps like:

• Image Resizer.com
• ResizeImage.net
• Optimizilla

Resizing and compressing images isn’t so much about making your images more rank-worthy. It’s more about improving webpage loading speeds and, by proxy, the user experience. Faster loading pages retain more visitors, which is something that Google’s algorithms look for when determining what content to rank in results.

3. Use the Right Image Formats

There are a few reasons why image formats matter in SEO.

Page Performance

Some formats tend to be more lightweight than others. And the lighter your page, the more quickly visitors can get to your content and enjoy their on-page experience.

WebP and SVG are the most lightweight image formats. The only problem is that they’re not always accepted by every browser (see more on that below).

JPG and PNG are the other common image file types we use. JPG tends to be more lightweight as it uses lossy compression. However, there’s a tradeoff and it has to do with the next point.

Image Quality

If you want to wow visitors with your visuals and allow them to read or see the details, then they need to be as high-resolution as possible regardless of how much compression you’ve used.

Therein lies the problem. Let’s say you prefer to save your images as either JPG or PNG. JPG’s lossy compression will toss out bits of data from the file to shrink it down. Depending on how much compression you apply, this can make the image appear fuzzy.

PNG’s lossless compression, on the other hand, will only reduce the file size slightly. The image resolution will remain crisp for the most part. However, the file will remain on the heavier side.

Browser Compatibility

According to Can I use…, for instance, most image formats are accepted by all browsers (in their latest version).

The main exception is Internet Explorer, which doesn’t fully accept SVG or WebP.

So when exporting your images, there are two things you can do. Either make sure to export them in universally friendly image formats like PNG and JPG or provide a backup image file and format in case your preferred one gets rejected.

4. Use Image HTML Tags

This is a simple tip, but it’s critical if you want search engine crawlers to find images on your pages.

When marking up your images, make sure they’re contained within the <img> element. The code will look like this:

<img src="indoor-plants.png" width="800" height="500">

You can add different attributes to your <img> tag as well. These are more for improving the appearance of the images on the page to provide the best user experience.

In the example above, you could include tags for width and height. For example:

<img src="indoor-plants.png" width="800" height="500">

You can also add tags for alt text, custom CSS styles, lazy loading and more.

If your CMS isn’t configured to automatically make images responsive or you want to get specific about which files to display at certain breakpoints, you can also add sizes and srcset tags.

5. Add Descriptive Details to the File

In most cases, your users will never see the file names or descriptions you add to your images. That doesn’t mean that they’re not needed for SEO.

There are many contributing factors when it comes to ranking webpages and images in search results. One of them is how clearly you convey to Google what your content is about. And when it comes to images, specifically, you need to provide a succinct but accurate description of what’s in the image so that Google can “see” it.

There are different places to add this information into the file.

The first is the file name itself. Take, for example, the custom illustration from the Apartment Guide post above. It’s a WebP file called low-light-room-map. That’s a good way to describe it.

I probably would’ve added a variation of the page’s primary keyword as well, so something like best-houseplants-low-light-room-map. It’s a little long, but it more accurately describes the content and purpose of the image.

Adding a title is also useful. You can do this by adding the title tag. It would look like this:

<img src="low-light-room-map.webp" title="Map of low-light room and best houseplants for it">


There are two benefits to including a title. The first is that you have a direct way of communicating to the search engines what is inside the image. The second is that the title tag appears as a tooltip atop an image when someone hovers over it. If you feel like your images need more context, this would be useful.

An alternative would be to add a caption below the image. The code would look like this: 

```html
<figure>
  <img src="low-light-room-map.webp" width="600" height="650">
  <figcaption>Map of low-light room and the best houseplants for four different kinds of low light</figcaption>
</figure>

To include a caption, you’ll need to place your image within a <figure> element.

6. Include Alt Text

Alternate text (or alt text for short) is another way to share more details about the most important images on our website.

There’s no need to add alt text to decorative images, generic stock photos or anything else that isn’t rankable or unique. However, if you have a beautifully designed or super descriptive image on your page, then alt text is a must.

You’ll add it to the <img> HTML like this:

<img src="low-light-room-map.webp" alt="An illustrated map entitled ‘TYPES OF INDOOR LIGHT’. The map points out 4 types of low light: 1 is Bright Direct Light at a window. 2 is Bright Indirect Light below or in front of a window. 3 is Medium Light that’s close to a natural light source but not within its path. 4 is Low Light which is nowhere near a natural light source.">

Alt text comes in handy for two reasons.

The first is because it clearly describes the details of an image. When an image plays an integral role in the narrative of a page, then the alt text gives us a way to translate the visuals into text for search engines.

Alt text is also useful when it comes to screen reading technology. For users who are visually impaired, the alt text is read out loud so that they don’t miss critical details.

This is why it’s important to only add alt text for descriptive images. There’s no need to use it to describe a woman laughing while she drinks coffee by a potted plant or to endlessly describe every detail about a potted bonsai tree. It does little to improve the visitors’ comprehension of what’s on the page.

7. Use Structured Data

Structured data is another way in which we convey more details about our content to search engines. However, unlike file data which improves comprehension about an image, structured data can actually improve the chances of your images appearing in more places in search results. They can also enhance search engine results with additional details.

To add structured data, you need to familiarize yourself with the schema markup vocabulary. We add this markup on top of the HTML.

Let’s use our basic indoor plants example.

<img src="indoor-plants.png" width="800" height="500">

We want to apply the ImageObject type to our image file. Here’s how we’d do it:

<div itemscope itemtype="https://schema.org/ImageObject">
  <img src="indoor-plants.png"
  alt="A lanai-enclosed sunroom full of green plants in a variety of colored pots."
  itemprop="contentUrl" />
  </div>

Google requires you to add at least one additional property along with contentUrl when using the ImageObject type. You can choose from:

• creator
• credittext
• copyrightNotice
• license

Here’s how it would look if we added the creator’s name:

<div itemscope itemtype="https://schema.org/ImageObject">
  <img src="indoor-plants.png"
  alt="A lanai-enclosed sunroom full of green plants in a variety of colored pots."
  itemprop="contentUrl" 
  <span itemprop="creator" itemtype="https://schema.org/Person" itemscope>
        <meta itemprop="name" content="Mandy Mowers" />
  </span>
</div>

There are other properties and attributes you can add. For example, let’s say you’ve taken a photo of a beautiful sunset over the Ocean Beach Pier in San Diego. You could add location markup to the image, which would improve your chances of showing up in related location-based or “near me” Google Images searches.

By the way, if you’ve added your website to Google Search Console (GSC), you’ll be able to see details about:

• Which pages are indexed and which are not (and why)
• When your pages were indexed
• Their HTTP status
• If breadcrumbs are present
• How many videos were discovered
• Eligibility for Google’s rich results

The URL inspection tool in GSC is helpful if you’ve added structured data to your page or images. It’s a quick and easy way to confirm that the information was sent through and can now possibly be used by Google to enhance your search presence.

For example, here’s the data that Google has gleaned from my homepage:

Google has discovered image-specific markup associated with the page that shows my author photo as well as my brand logo. You can use this same tool to confirm that your structured data has been received. It’s on the URL Inspection screen. Enter the URL for the page you want to examine. Then open the Sitelinks searchbox tab.

8. Create an Image Sitemap

Every website has an XML sitemap, even if you don’t create it by hand. Regardless, it’s important to submit a sitemap via GSC so that Google has the latest and greatest version of it.

By default, most websites have a single sitemap. It usually resides here:

https://yourdomainname.com/sitemap_index.html

However, if you’ve spent a lot of time creating high-quality images, optimizing them for search and adding all the right information to them, you should create a separate sitemap for your images.

Here’s what that file would look like:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://yourdomainname.com/</loc>
<image:image>
<image:loc>https://yourdomainname.com/uploads/hotel-hallway.png</image:loc>
</image:image>
<image:image>
<image:loc>https://yourdomainname.com/uploads/nervous-woman.png</image:loc>
</image:image>
</url>
<url>
<loc>https://yourdomainname.com/about-us/</loc>
<image:image>
<image:loc>https://yourdomainname.com/uploads/security-first-graphic.png</image:loc>
</image:image>
</url>
</urlset>

If you don’t want to write the sitemap out by hand, you can use mysitemapgenerator to create it for you. You can then modify the XML file, stripping out or adding any details you want before saving and then submitting to GSC.

Similar to alt text, you only need to do this if you have really valuable visual content on your website. And lots of it. This way, Google won’t have to try to figure out which items are worth crawling since you’ve provided the search engine with a direct map to the images worth indexing and ranking.

9. Implement Lazy Loading

With lazy loading, your page only loads images that your visitors scroll to. This way, if you have a long page, your browser won’t process the HTTP requests for all of those images before fully displaying the webpage.

According to HTTP Archive, you can shave off a little bit of your page weight and speed up your loading speeds by implementing lazy loading.

On desktop, you’ll save about 2.8 KB per page, while on mobile you’ll save 46.4 KB.

This is another one of those optimization strategies that has less to do with image ranking and more to do with performance optimization. Though the two are ultimately connected.

Because, just as Google looks at loading speeds to determine how to rank pages in search, it also references that data when recommending images in relevant searches.

That’s because Google doesn’t want to send its users to websites they get frustrated with or immediately bounce away from. They want users to keep relying on the search engine, which means they need to provide high-quality page recommendations. Pages that load faster get greater priority.

Wrapping Up

Images don’t just make a website look more attractive. They can also improve visitor comprehension of what your site is all about, visually describe or summarize concepts, and provide more context.

With image search engine optimization, you accomplish a few objectives.

The first is that the images don’t hamper the performance of your webpage. The second is that you improve the overall usability and accessibility of your website. Lastly, you make it easy for search engines to find your high-quality visuals and then rank them in relevant search results.

Internationalization, often abbreviated as i18n (where 18 represents the number of omitted letters between “i” and “n”), is the process of designing and developing an application in a way that allows for easy localization to different languages, regions and cultural contexts. It involves separating the user interface and content from the application’s codebase to facilitate easy translation and adaptation.

In a previous article, we discussed the importance of internationalization in web applications and some important steps one can take to get there.

In today’s article, we’ll go through a more practical tutorial of adding internationalization to a small React application with the help of the react-intl library.

React-Intl

React-intl, part of FormatJS, is a popular library used to internationalize React applications. It provides React components and an API to format dates, numbers and strings, including pluralization and handling translations.

It also supports both singular and plural message translation, string substitution and rich text formatting, among other things.

In a React application, we can start by first installing the react-intl library:

npm install react-intl

# or

yarn add react-intl

Defining the Language Messages

To begin introducing internationalization to our app, we’ll first need to define our language messages. This is usually done in JSON format and each language is defined in a separate file.

We’ll create a locales/ folder in the src/ directory. Inside locales/, we’ll create three files: en.json, es.json and fr.json to represent the English, Spanish and French languages.

src/locales/en.json

{
  "app.greeting": "Hello, User!",
  "app.description": "This is a simple react application"
}

src/locales/es.json

{
  "app.greeting": "¡Hola, Usuario!",
  "app.description": "Esta es una simple aplicación de react"
}

src/locales/fr.json

{
  "app.greeting": "Bonjour, Utilisateur !",
  "app.description": "C'est une simple application React"
}

These files will act as our dictionaries, mapping message IDs (like app.greeting and app.description) to the message in the respective language.

Configuring React-Intl

Now, we can set up our application to use react-intl. In our main app file (App.js), we’ll import the necessary components from react-intl as well as the different language message dictionaries we’ve just created.

import { IntlProvider, FormattedMessage } from "react-intl";

import messages_en from "./locales/en.json";
import messages_es from "./locales/es.json";
import messages_fr from "./locales/fr.json";

We’ll then create an object to store all our dictionaries:

const messages = {
  en: messages_en,
  es: messages_es,
  fr: messages_fr,
};

Next, we’ll wrap our app in the <IntlProvider /> component, provided by react-intl, which will provide i18n context to all the components in our app. The <IntlProvider /> component requires two props: locale and messages.

• locale is a string value that represents the language locale we want to use in our application.
• messages is an object that contains the actual text messages (strings) that we want to display in our application.

To start, we’ll default the locale to English ('en') and reference the english message dictionary we’ve created.

export default function App() {
  const locale = "en"; // default locale

  return (
    <IntlProvider locale={locale} messages={messages[locale]}>
      {/* rest of our app goes here */}
    </IntlProvider>
  );
}

Using Messages

With react-intl now configured, we can use it in our app. We can use the FormattedMessage component from react-intl to display text.

export default function App() {
  const locale = "en";

  return (
    <IntlProvider locale={locale} messages={messages[locale]}>
      <FormattedMessage id="app.greeting" />
      <br />
      <br />
      <FormattedMessage id="app.description" />
    </IntlProvider>
  );
}

When saving our changes, we’ll be presented with “Hello, User! This is a simple react application” in the browser, as we’re currently using the English locale.

If we were to change the value of the locale variable to a different language like French:

export default function App() {
  const locale = "fr";

  // ...
}

We would be presented with the same “Hello, User! …” message but in French.

Changing Languages

We’ll want to provide the end user the capability to switch between different languages. To achieve this, we can consider storing the locale in our <App /> component’s state.

import { useState } from "react";
// ...

export default function App() {
  const [locale, setLocale] = useState("en");

  // ...
}

We can then add buttons to our app that lets the user switch between the English, Spanish and French locales.

import { useState } from "react";
// ...

export default function App() {
  const [locale, setLocale] = useState("en");

  return (
    <IntlProvider locale={locale} messages={messages[locale]}>
      <FormattedMessage id="app.greeting" />
      <FormattedMessage id="app.description" />
      <div>
        <button onClick={() => setLocale("en")}>English</button>
        <button onClick={() => setLocale("es")}>Español</button>
        <button onClick={() => setLocale("fr")}>Français</button>
      </div>
    </IntlProvider>
  );
}

When we click on a certain button, the locale state of our app updates to the selected locale, triggering a re-render of the IntlProvider component with the new locale value and data. Consequently, the text in our application that’s managed by the react-intl library updates to reflect the chosen language.

You can see the running application in the following CodeSandbox link.

The user now has a dynamic way to switch between different languages without having to refresh the entire page!

Conclusion

In today’s article, we showed a simple example of introducing internationalization to a React application. There are are more advanced features to explore in react-intl, including handling more complex string translations, number formatting, date and time formatting, and handling plurals and genders, which are important aspects in many languages.

Building an app with internationalization in mind from the outset is generally easier than trying to retrofit it later. So even if you’re only targeting a single language region to begin with, it’s worth considering from the start.

Looking to build with i18n baked into your components? The Internationalization package from Progress KendoReact applies the desired cultures by providing services and pipes for the parsing and formatting of dates and numbers.

When we’re assessing the user experience of a website or application, what exactly are we looking for? What makes a site especially usable—or especially difficult to use? One of the most common models for breaking down this question into a more easily quantifiable and measurable system is Jakob Nielsen’s 10 Usability Heuristics.

The word “heuristic” simply refers to an approach or strategy that works more as a rule of thumb—not necessarily scientifically tested or 100% accurate all the time, but rather a good mental shortcut or helpful generalization. By nature, that also means that there will be exceptions to the rules; a site that “violates” one or two of the heuristics in this list isn’t automatically a bad or unusable site. However, we can feel pretty safe in saying that when when the criteria isn’t met for many or most of these, there’s probably a usability issue (or several) that needs to be examined.

Nielsen’s heuristics were originally created in 1990, then refined down to 10 in 1994. In 2020, they were reexamined and adjusted slightly for clarity—however, the 10 heuristics themselves did not change. As Nielsen says: “When something has remained true for 26 years, it will likely apply to future generations of user interfaces as well.”

That being said, let’s take a look at what these include:

1. Visibility of System Status

Users always need to know what’s happening and what the current state of the website or application is. Imagine you’ve just completed a form and hit the “Submit” button—but there’s no confirmation dialog or other visual change. Did it go through? Did your internet connection lapse? Do you have an error that needs correcting? Should you resubmit, or will that cause an error?

When users interact with elements and see no change in the system, it can be unsettling and confusing. In Designing Interfaces: Patterns for Effective Interaction Design, the authors describe the user interface as our way of having a conversation with the user—similar to the way that a receptionist might help a user in person at a hotel front desk. If you were to check in at a hotel and make a request for a wake-up call, but were met with total silence … it would be pretty weird, right? You’d wonder if they’d heard you at all or whether you were at risk of oversleeping your morning meeting.

In the same way, we need to make sure that our interfaces include active feedback to keep the user apprised of everything happening “behind the scenes.”

2. Match Between System and Real World

The language, layout and approach that we use within a website or application should always align with the user’s real-world experience. That means that everything from where elements are on a page to the words we use we describe things should be user-centric and tailored to the way that they move through the world. That sounds obvious, but can actually be very challenging—mostly because our own lived experience is often very different from that of our users, and when we design and develop we’re always doing so from the basis (and bias) of our own experience.

It’s very easy to make assumptions about what users know, how they think and what experiences they will have had. Of course users will know what a widget is, that’s a common term … right? Of course users will be able to identify that icon as a drag and drop symbol, that’s an industry standard … right?

The answer, of course, is that it depends entirely on your user base. A younger, more technically-savvy user base might not have any issues with those examples, but an older user base could struggle more. It’s our responsibility to conduct user research and gain an understanding of the people who use our applications and websites in order to more accurately tailor the content and layout to them.

However, it’s crucial to keep in mind that users are not a monolith. You’ll likely have users of many different capability levels, experiences, backgrounds, etc. using your product. It’s often a good idea to build in multiple ways of accomplishing tasks, so users have flexibility in choosing the approach that works best for them. We’ll talk more about this in heuristic #7.

3. User Control and Freedom

Users are not going to get everything right the first time—that’s just a fact. No matter how wonderful or intuitive our UI is, there will still be folks who make mistakes, forget things and have to go back, or need to undo an action.

Part of what makes users feel comfortable and engaged with a piece of software is the knowledge that they can freely experiment and know that the stakes are low. That means that the consequences for simple actions should be minimal: clicks can be unclicked, navigation can move backward and forward without getting lost, choices aren’t permanent. Changed the color to red—oops, didn’t like that!—click undo. This is referred to as safe exploration, and it’s an important way for users to learn the application interface and functions.

Obviously, there are some situations where users do need to make important, permanent decisions: placing an order, deleting an account or similar. In those situations, we need to clearly communicate to users 1) at which point there’s no turning back, and 2) what exactly will happen afterward. Always allow users an “escape route” or a way back—all the way up until the point at which that’s no longer possible.

4. Consistency and Standards

This one has two main interpretations:

1. Consistency with a user’s wider experience using the web and software in general
2. Consistency between pages in a website / applications in a suite / other connected digital experiences

Both have to do with the concept of mental models. A user’s mental model is the understanding they build and the assumptions they make about their current experience, based on the similar experiences they’ve had up until now. For example, most websites have a logo in the top left corner that will take the user back to the home page when clicked. Linked text in a webpage is underlined. Right-clicking will open a contextual action menu.

When these things don’t happen—or worse, when something else unexpected happens—it throws us off. Our mental models no longer line up and now we have to both learn a new system and remember that the system is different for this particular website / piece of software. That increases a user’s cognitive load, or the amount of mental effort and energy that it takes to complete a task.

By meeting the wider standards of web and application design, we allow our users to carry over everything they’ve learned and all the behaviors that have become second-nature to them from years of tech use. Things “just work” because we’re not forcing them to go against the grain and learn something new in order to use our product.

Mental models also can be (and are) constructed on a product-by-product basis. Maybe our application uses a specific color system to designate different types of information, or maybe our navigation menus are organized in a certain way. If that were to differ between applications in a shared product suite, we’d be disrupting our users’ mental models—and creating a higher cognitive load for the users who have to switch back and forth between those systems regularly.

5. Error Prevention

Errors are inevitable. Whether it’s a system bug, a user mistake or some combination, it’s important that we prepare for the reality of errors in our software. However, even better than error mitigation is error prevention. By making smart choices during the design and development process, we can create products that reduce the likelihood of errors happening in the first place.

For example, users on mobile devices are more likely to misclick or “fat finger” something, especially in a compact page layout. We can help prevent that error by making the clickable areas—or target sizes—larger and more forgiving. We can also be smart about where we place interactive elements on the page, and how much empty space we build in when we need to place them close to each other. Finally, if a user does misclick, we can make it easy for them to go back, undo or otherwise negate the unintentional action (as we discussed in heuristic #2).

This combination of preventative measures means less stress for the user—and for us.

6. Recognition Rather Than Recall

Users have a lot going on, and our software is a comparatively small part of that. Schedules, grocery lists, work to-dos, personal tasks—the details of our particular UI tends to be pretty low on that list. As someone uses the interface more often, over time it will stick in their memory, but that takes time. We can help reduce that time and reduce the amount of effort it takes to use the UI by working based on the assumption that our users won’t remember it.

Practically, that means surfacing relevant information as needed, in the context of the task, rather than expecting our users to recall all the details. It might be visually efficient to just use icons in our menu, but that means we’re placing the burden on our users to remember what they all mean. That burden might be pretty low for common icons, like a house for “home” or a gear for “settings” … but it could also be more difficult. Does a light bulb icon mean “see a tip” or “toggle on light mode”?

Those things could make perfect sense to an established user, but new users will have to wrack their brains to remember, over and over again until it sticks. By adding a label to the icon, we reduce the cognitive load required to use the application.

7. Flexibility and Efficiency of Use

Remember when I said we’d talk more about the whole “multiple ways of accomplishing tasks” thing, way back in heuristic #2? Well, now it’s time! “Flexibility and Efficiency of Use” is all about creating flexible paths and processes, so that users of different experiences and capabilities can all feel comfortable using your product.

A great example of this is a well-designed and prioritized keyboard navigation experience. Keyboard nav benefits a wide variety of users: from experienced “power users” who appreciate the speed and ease, to visually impaired users who require it for accessibility purposes. By enabling useful keyboard shortcuts and well-designed keyboard navigation, we can allow those users to engage with the software in the method that’s most comfortable to them.

Consider the use case of filling out a long form. A new user might work through the form more slowly, clicking on each input box with their mouse and considering their response. An experienced user (who has filled out this form a hundred times before) might tab between the input boxes and copy/paste the content without ever touching the mouse. A visually impaired user will make use of a screenreader in combination with their keyboard to complete the form. If we’ve built the form to be flexible, all three of these example users will be able to complete it in their preferred way, using their preferred tools.

8. Aesthetic and Minimal Design

This is a heuristic with a name that can be a little misleading at first, because “minimalism” can also refer to a very specific, sparse visual style. However, that’s not what we’re talking about here. In this case, “minimal” simply means that every element on the page serves a purpose.

Think of it kind of like the Marie Kondo method—she doesn’t say that you need get rid of everything in your house, she simply asks you to question its purpose and whether it “sparks joy” and discard the things that don't. We should approach the elements in our user interfaces with the same curiosity: What purpose is this serving? Is it making the website or application a better place for the user? If not, can we remove it? 

We can vastly improve the user experience by creating designs that are a) visually appealing, and b) not cluttered with elements that don’t further the user’s goals. Every time we place a new element into a layout, we should think: “What is this helping the user achieve?” When we have too many items on one page, it becomes distracting; it makes it more challenging for the user to parse what’s needed vs. what isn’t in order for them to complete a particular task. Often, users refer to this kind of design as “clean”—it feels straightforward, intuitive and easy to understand at first glance.

9. Help Users Recognize, Diagnose and Recover from Errors

As wonderful as it would be if we could simply prevent all errors by using the guidance provided in the error prevention heuristic, there will still be cases in which errors do happen. When they do, it’s our job to make sure that users can see that they’ve happened, understand why they’ve happened and know what the next step is.

Recognizing an error means that a user knows the error has happened in the first place. That might seem like common sense, but remember that some errors happen on the system side—bugs, unexpected inputs, connection failures and other things not necessarily related to a user’s mistake. Many times, those errors happen “behind the scenes” but still have implications for the user experience—anything from longer-than-expected load screens to full crashes. Regardless of how the error came to be, we need to make sure the user is aware that something went wrong.

Diagnosing an error means that a user knows why the error occurred. Again, this might be due to their mistake (such as a form validation error) or a system issue (dropped connection). This should always be communicated in user-friendly language, so avoid using overly technical terms or error codes that won’t be meaningful to them.

Finally, recovering from errors means that a user knows what they’re supposed to do next. This could be simply an acknowledgement that the error happened and communication that no action is needed from the user, a prompt for the user to try the action again, instructions on how the user should revise their input, or possibly just the right language for a user to effectively communicate their issue to a help desk. No matter what the follow-up action is, we want to make sure we don’t leave them hanging, unsure of how to resolve the problem.

10. Help and Documentation

We talk a lot about intuitive user interfaces as the ideal—wouldn’t it be wonderful if all of the products we created were so crystal clear that you could simply look at them and immediately understand everything? However, that’s not always realistic. Sometimes the systems we build are, by nature, complex systems meant to solve complex problems. Advanced video or photo editing software, applications for banking or money management, specialized healthcare websites—all of these are examples of situations where even the best, most intuitive visual design can only get us so far. Sometimes the necessary complexity of the software calls for written instructions and additional explanation.

When this is the case, we need to make sure our documentation is as thoughtful and intentional as the website or application itself. That means good search capabilities, well-organized content, easy-to-understand language and straightforward steps that users can follow to accomplish tasks.

Putting the Heuristics to Work

Now that you have this list of heuristics, how are you supposed to use them? A great way to leverage this knowledge is to use the heuristics as a kind of checklist for internal review. While it’s always ideal to put work in front of users to get their feedback, we can often catch a lot of easy mistakes or UX shortcomings by using these heuristics to evaluate the product ourselves, first.

This also saves time and money—usability testing takes a lot of organization and effort, so you don’t want to “waste” that on catching the obvious mistakes. Ideally, you want user feedback to be the kind of nuanced, contextual, experience-informed stuff that you won’t be able to mimic with an internal review. By using these heuristics to make sure you’ve checked all the low-level boxes, you can concentrate your user interviews on higher-level, more insightful feedback.

Try using this list as a basis for internal review—you might be surprised how much you’re able to improve the product before it’s ever touched by a user!

Caution: This article aims to provoke you to ask yourself, your colleague, your manager or your team some accessibility-related questions that could be crucial for your project. This article wants to make you look at your websites and applications from a different perspective and take action before it is too late.

To make it more interesting, let’s look at the following article as if it is a movie. That special genre of movies where we jump from one scene to another and there is not an obvious relation between each situation, but somehow you know there is. Usually, in these movies, we receive some hints about the further movie development in the form of questions. Sometimes the key is in the text we see. One thing is sure here—everything is revealed at the end of the movie, and we can make a truly informed life-changing decision.

So here starts our story.

Introduction

Today, everyone is focused on aligning their websites/applications with the Section 508 and WAI-ARIA accessibility rules. The accessibility tests are already a “must-have” in almost every enterprise and non-enterprise company. Many people test their products on different screen readers. There are even businesses that test their applications on all screen readers ever released on the market.

The storyteller: “Meet George, who has a task to make the application he is working on fully accessible. He knows that all of the above is 100% correct, but, still, there is something that bothers him.”

And this is the place where the “rising action” of our story starts building.

Part One: ‘The Accessibility Dilemma’

Imperceptibly, the first life-changing question in the movie pops and the main character asks himself:

“Is my application accessible if I am covering the Section 508 and WAI-ARIA rules?”

The narration continues…

For some people, the accessibility story completes when your product meets the above-mentioned accessibility rules. For the other part of the companies or developers, to say that a given project is accessible, it should also work on different screen sizes and device types. Although it is not a must-have feature,

“The components’ adaptiveness is already becoming an industry standard when talking about accessibility, usability and general user experience on all devices.”

For those of you who still don’t think that an adaptive design should be implemented in an application, take your phone, open a link with a complex form inside it in “desktop” mode, and try to fill the form in. Now open the same link in “mobile” mode and repeat the previous action. Don’t tell us what your experience was. We know the answer.

Part Two: ‘I Can Do Everything by Myself’

We are already close to the climax of the story and our character asks the next fundamental question:

“OK, we need adaptive rendering. I am starting the implementation!”

To make the scene more intriguing, suddenly George finds himself in the past remembering a conversation with an ex-colleague who shares insights, steps and efforts he had to make to implement adaptive rendering in that application back then.

A “short” to-do list of prerequisites and implementation tasks appears on the screen:

1. Brief a designer and create a design the clients will see on a mobile phone.
2. Brief a designer and create a design the clients will see on a tablet.
3. Decide specifics about how each of the components will behave when used in adaptive mode.
4. Handle the WAI-ARIA/Section 508 accessibility requirements for each adaptive design.
5. Take necessary steps to implement.
6. Test the adaptive rendering features and make sure everything works as expected.

To build the tension, the narrator continues:

“The above list can surely be improved, but think about the project management time, the design hours, the development time and, finally, what the financial cost of the whole implementation process will be.”

Part Three: ‘The Decision’

We are about to go through the turning point of our story. This part is very short but very important. Our character feels confused. He starts doubting himself if the decision about the adaptive rendering is correct and worth it.

1. Should I implement adaptive rendering in my next project?
2. Is it worth implementing the adaptive rendering all by myself?

The scene ends.

Part Four: ‘The Alternative Revealed’

We see George, who tests the usability of a project with some colleagues while discussing what a good decision it was to use Progress Kendo UI for Vue. From the conversation, we understand that there weren’t very specific requirements for their application, and this is how they decided to use the Kendo UI for Vue DropDowns for their adaptive scenarios.

The story continues with a scene where George is awarded for his decision and presents the features of the Kendo UI for Vue DropDown components to other fellow developers:

“The adaptive mode of the ComboBox, DropDownList, MultiSelect, DropDownTree and MultiSelectTree components is easy to configure by using the adaptive and adaptiveTitle properties of each component.”

The presentation continues…

The adaptive property accepts true or false as values and based on this configuration the components will or won’t automatically activate their adaptive design on different screens. The adaptiveTitle property defines the text that will be rendered in the header of the component when it operates in adaptive mode.

When the adaptive mode is active, each of the listed above components has three rendering states:

• Default (not adaptive) – This is the default rendering of the components. This mode is activated when the screen size on which the component is used has a width bigger than 768 pixels.
• Medium screen size – This state of the components’ rendering is activated when the display size is between 500 and 768 pixels.
• Small screen size – This is activated when the display size is below 500 pixels.

“Here is a demo of the DropDownList’s Adaptive Rendering. We can see each rendering state of the component.”

For more details about the adaptive rendering of the DropDownList and how it can be configured to work also with grouped data, check this documentation article.

And this is how the presentation continues …

… Stepping into the ComboBox, here is what its Adaptive Mode looks like. The component works both with regular and grouped data in all its rendering modes.

The Adaptive Rendering documentation of the ComboBox provides additional details related to its configuration.

… Here is the MultiSelect Adaptive Mode. This is what its medium screen size rendering looks like:

Details about the adaptive rendering of the MultiSelect and its configuration can be found here.

… Talking about components that handle tree-like data structure, the DropDownTree and MultiSelectTree have their Adaptive Mode options. Here is what the DropDownTree looks like in Adaptive Mode:

… And this is the MultiSelectTree in middle-sized screens:

The documentation of the components reveals more details about each of them. Check it here for the DropDownTree and here for the MultiSelectTree.

The presentation ends with a standing ovation.

Part Five: ‘The Conclusion’

We enter the final scene. Everyone is happy and the character makes a recap of the struggles and pains he passed through. The conclusions he summarizes are:

1. Yes, our websites and applications should be accessible.
2. Yes, a more accessible site or application is one whose rendering adapts to the screen size it is rendered on.
3. Yes, the user experience and usability of a site or application will be boosted, and the adaptive rendering will guide the end users how to achieve their desired actions smoothly.
4. Yes, we can implement the adaptive rendering on our own—but is it worth it?

“No. We don’t need to implement custom solutions.”

… appears on the screen and this is how our story ends.

Someone will ask here, “And what about the dilemma mentioned in the topic?” Well, the moral of the story is that the adaptive dilemma is not a dilemma if you use the Kendo UI for Vue Native DropDowns in your applications. The character saved hours of project management, design, development and testing time just by using the Vue DropDown components.

As a final side note, I would add here that the next time you start a project, put yourself in the shoes of our character. If you want your project to be fully accessible and support multiple devices, ask yourself the questions he went through. If you are honest with yourself and don’t have special project requirements, use the Kendo UI for Vue DropDowns and save time, effort and money—both for you and your company.

The above article is a result of our continuous effort to maintain the high level of accessibility and usability in the different Kendo UI for Vue components. More accessibility improvements and usability features are coming. Stay tuned!

Try It for Yourself

Be the hero in your own story: Try Kendo UI for Vue free for 30 days!