Angular

Make it accessible: Navigation in Angular

Jan 20, 2020

6 min read

Today, we are going to talk about navigation. Let's start from the beginning. What's navigation?

Web navigation refers to the process of navigating a network of information resources in the World Wide Web Wikipedia

In those terms, we could say that when a user clicks a link, a navigation event is triggered, the browser captures this event, and then redirects the user to a new page. In pure HTML, this forces the browser to load the entire html. When you use Angular, things are different. The browser doesn't need to load the whole html again. Instead, by using AJAX, you get only what was changed.

I thought that was a magical thing, and that the benefits were huge in comparison to the way HTML links normally behave. But that's true only until a certain point when you want to make accessible applications, things get more complicated. Why? If you have read my last article, Make it Accessible, you know how important HTML5 semantic elements are.

If you haven't read it. You can access here: Make it Accessible: Headings in Angular

Just like native HTML buttons can help make things more accessible out of the box by providing keyboard support and focus ability, anchors are here to make your life easier.

Anchors to the rescue

In pure HTML, we use anchor elements with the href attribute. That way, we can tell the browser which url it has to redirect the user to upon click. This triggers a full load of the app, BUT there's a benefit to it: its support of web accessibility. Screen reader users are used to the way native HTML navigation works. It helps by reading the title of the new page, and setting the focus to the top of the document, also by having the title of the page change, so the user knows the current location.

So it basically allows:

Sighted users to know the current page by reading the title
Visually impaired users to know the current page from a screen reader announcing the title
Setting focus to the top of the document

If you have used the Angular Router, you know that all the accessibility features just mentioned are lost. So, if you are looking to make your Angular app more accessible, sooner than later, you are going to have to face this.

We are going to solve each of the problems, one at a time. If you want to do all the coding processes on your own, access this broken version of the code, and follow my lead.

Current page for Sighted Users

In this step, we are going to focus on making sure the user has a way to know what the current page is. In the code I just gave you, you'll find a simple app with a header and some navigation. Right now, there's no way for the user to know the current page (besides reading the url, hoping it's as readable as in the example).

This could be solved by having a different color for the currently active link in the header, so let's do that.

First, we'll need to use the routerLinkActive directive in the anchors from the navigation. For this, we need to go to the src/app/app.component.html file and replace the nav element with this one.

<nav class="header__nav">
  <ul>
    <li>
      <a routerLink="/page-a" routerLinkActive="active">Page A</a>
    </li>
    <li>
      <a routerLink="/page-b" routerLinkActive="active">Page B</a>
    </li>
  </ul>
</nav>

So now, Angular will make sure to add the class active to the anchor that's route is currently active. Let's change the color of the active anchor. Go to the file src/app/app.component.scss, and add a color white when it has the active class.

a {
  // ...

  &.active {
    color: white;
  }
}

Make sure to put the &.active selector after all the ones that are already there.

Is the navigation accessible? Well, not really. What about color blind users? We need to give them a way to know. For that, we'll add underline and outline to the active anchor. Let's go back to the src/app/app.component.scss file.

a {
  // ...

  &.active,
  &:hover,
  &:focus {
    color: white;
    outline: 1px solid white;
  }

  &.active {
    text-decoration: underline;
  }
}

Since the hover and focus have the outline and the color that we want, I reorganized the selectors to reduce the duplicated code.

Last thing we have to do is to make sure we update the title of the page for every time the url changes. For this, I followed the instructions from Todd Motto in his article Dynamic page titles in Angular 2 with router events and did some changes to it.

This leads us to change the src/app/app-routing.module.ts

const routes: Routes = [
  {
    path: 'page-a',
    data: { title: 'I am the super Page A' },
    loadChildren: () =>
      import('./page-a/page-a.module').then(m => m.PageAModule)
  },
  {
    path: 'page-b',
    data: { title: 'I am the not that super Page B' },
    loadChildren: () =>
      import('./page-b/page-b.module').then(m => m.PageBModule)
  }
];

The key here is that I included a data property to each route, and gave each a title. Next, we have to update the src/app/app.component.ts file.

//...
import {
  map,
  distinctUntilChanged,
  startWith,
  filter,
  mergeMap
} from 'rxjs/operators';
import { Router, ActivatedRoute, NavigationEnd } from '@angular/router';
import { Title } from '@angular/platform-browser';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  // ...
  title$: Observable<string>;

  constructor(
    private router: Router,
    private activatedRoute: ActivatedRoute,
    private titleService: Title
  ) {}

  ngOnInit() {
    // Get the activated route on Navigation end
    const route$ = this.router.events.pipe(
      filter(event => event instanceof NavigationEnd),
      map(() => this.activatedRoute)
    );

    // Get the first child route AKA the root
    const primaryRoute$ = route$.pipe(
      map(route => {
        while (route.firstChild) route = route.firstChild;
        return route;
      }),
      filter(route => route.outlet === 'primary')
    );

    // Get the first child route AKA the root
    const routeData$ = primaryRoute$.pipe(mergeMap(route => route.data));
    // Get the actual title from the route data
    this.title$ = routeData$.pipe(map(({ title }) => title));

    this.title$.subscribe(title => {
      // Set title to the page
      this.titleService.setTitle(title);
    });
  }
}

Above, I injected the services we need, made a stream from the router events in order to get the current title, and changed it in the browser using the Title service. If you want to learn more of this, you can read Todd Motto's article.

You have just solved the first problem.

Current page for Visually Impaired Users

You are here for accessibility, so it's time for visually impaired users to be taken into account. For this you can use the aria-live attribute.

Simple content changes, which are not interactive, should be marked as live regions. MDN Web Docs

That seems to be our use case- we want to announce to users when there was a page transition. For that we'll create an element with aria-live, containing the title content.

To get started, go to the src/app/app.component.html file, and use Angular's async pipe to render the title.

<div *ngIf="title$ | async as title" aria-live="assertive">
  <span [attr.aria-label]="title"></span>
</div>

If we put the title inside the span, instead of using aria-label, we would need to hide this element from sighted users, this is a little trick I love to do instead. Also, notice that we use the aria-live property with assertive to make sure this gets announced as soon as possible.

NOTE: Normally, I wouldn't use the ngIf in the tag with the aria-live because it will start announcing after it gets instantiated. In this case that's exactly what we need because we dont want to announce the title again on first load.

Now every user using the app will know which page they are on, no matter their condition. We are almost there to make a more inclusive navigation.

Manage focus and scroll

Let's make things even better now. You have probably noticed that whenever an Angular page transition occurs, if its possible, the scroll is retained in the same position, unless the page we have just transitioned to has a height that is less than the current scroll. So the first step would be to set the scroll to the very top on every page transition.

Just go back to the src/app/app.component.ts file and do this:

// ...
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  // ...
  ngOnInit() {
    // ...
    this.title$.subscribe(title => {
      // ...
      // Scroll to top
      window.scrollTo(0, 0);
      // ...
    });
  }
  // ...
}

Add a call to the scrollTo method from window using the parameters (0, 0), that way we tell the browser to scroll to the top of the document.

Whenever a page transition occurs in a pure HTML website, the focus is cleared and set to the first focusable element in the document. It is slightly harder but there's a trick for that, so let's do it together. Go again to the same file, and do this:

import { /* ... */ ViewChild, ElementRef } from '@angular/core';
// ...
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  // ...
  @ViewChild('appHeader', { static: true }) appHeader: ElementRef;

  ngOnInit() {
    // ...
    this.title$.subscribe(title => {
      // ...
      // Set focus to the appHeader
      this.appHeader.nativeElement.focus();
      // ...
    });
  }
  // ...
}

This is almost as easy as the step before, but instead of just calling a method on the window object, we have to create a reference to an element in the DOM. We've used ViewChild decorator for that. So now, we are setting the title, moving the scroll to top and setting the focus to the header in the title$ subscription.

Don't forget to add the template reference in src/app/app.component.ts and making it focusable.

<header class="header" tabindex="-1" #appHeader>
  <!-- ... -->
</header>

We dont want the focus outline in the header, so you can do this:

.header {
  // ...
  &:focus {
    outline: none;
  }
  // ...
}

Conclusion

After playing a little bit with Angular, we were able to make the navigation feel like the native one. It's not the most accessible navigation in the world, but this can get you there and is WAY BETTER than nothing. If you want a finished solution, look at this working version of the app.

Icons made by Freepik from Flaticon

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Improving INP in React and Next.js

Improving INP in React and Next.js In one of my previous articles, I've explained what INP is, how it works, and how it may affect your website. I also promised you to follow up with more concrete advice on how to improve your INP in your favorite framework. This is the follow-up article, where I'll focus on how to improve your INP score in React and Next.js. How to prepare for INP in React and Next.js? The first thing to do is to ensure you're using the latest version of React. The React team has been working on making React more INP-friendly and has already made some improvements in the latest versions. To enhance your INP score, consider fully taking advantage of new features introduced in React 18, such as Concurrent Rendering, Automatic Batching, and Selective Hydration. However, there are also some general areas to focus on, such as SSR and SSG in Next.js, Web Workers, or optimizing your hooks and state management. Concurrent Rendering The Concurrent Mode in React uses an algorithm that breaks rendering down into so-called "fiber nodes" and schedules the renders based on their expiration and priority. This effectively allows the user to interact with the page while the rendering is still in progress. In previous React versions, all updates, such as setState calls were treated as "urgent" and once the re-render had started, there was no way to interrupt it. Concurrent Mode changes this by being able to prioritize the updates and interrupt a non-blocking state update started with startTransition. For a simple explanation of concurrency in React, you can check out Dan Abramov's explanation. As part of the Concurrent Mode, React introduced several lifecycle methods that allow you to prioritize the rendering of certain parts of your UI, such as: - useTransition hook that allows you to update the state without blocking the UI, - useDeferredValue hook that allows you to defer the rendering of certain parts of your UI, - startTransition API that, similarly to the useTransition hook lets you mark a state update as non-blocking. It lacks, however, an indication of whether it's still pending. Automatic Batching Introduced in React 18, Automatic Batching reduces the number of re-renders that happen on state changes even when they happen outside of event handlers, e.g. in a setTimeout or Promise callback. This feature comes out of the box and you don't have to do anything to enable it, and it makes a great argument for upgrading to React 18. Selective Hydration Selective Hydration allows you to take hydration off the main thread by wrapping your components in a Suspense boundary. This way, components can become interactive faster as the browser can do other work on the main thread while the hydration is happening. To fully take advantage of selective hydration, consider the following: - Prioritizing Above-the-Fold Content: Use Suspense boundaries strategically around any parts of your application that may take the server longer to deliver to ensure they don’t block critical content from becoming interactive as soon as possible. - Hydration on Interaction: Implementing hydration upon user interaction for non-critical components can drastically reduce the main thread's workload, enhancing INP. Vercel even has a small case study showing how using selective hydration improved the performance of a Next.js site. Server-Side Rendering (SSR) and Static Site Generation (SSG) in Next.js Not everything has to run client-side. Next.js excels in SSR and SSG capabilities, which can significantly impact INP by delivering content to users faster. Optimizing SSR with techniques like incremental static regeneration (ISR) or leveraging SSG for static pages ensures that users can interact with content faster, improving the perceived performance. Workers Offloading heavy computations to Web Workers can free up the main thread, enhancing the responsiveness of React and Next.js applications. This strategy is especially useful when dealing with third-party scripts. Offloading such scripts in Next.js can be easily done by specifying the "worker" strategy on your Script component. Be aware that this feature is not yet stable and does not work with the app directory, though. If you want to take things one step further, you could use Partytown, which helps you offload any resource-intensive scripts to Web Workers. It comes with a React component that you can use to wrap your third-party scripts and offload them to a Web Worker, and it's compatible with Next.js as well. Hooks and State Management State management in React applications can easily get out of hand, leading to unnecessary re-renders and effectively an increased INP. Sometimes, using a state management library like Redux or MobX can help you consolidate your state and reduce the number of re-renders. However, they are not silver bullets and can also introduce performance issues if not used properly. If you are dealing with a lot of re-renders due to prop changes, make sure you are leveraging memoization. As of now, you may need to work with useMemo and useCallback hooks to memoize your values and functions, respectively. The upcoming React 19’s Forget Compiler, however, will apparently memoize everything under the hood, making these hooks obsolete. Using memoization properly can help you reduce the number of re-renders and improve your INP. To investigate your hook dependencies and re-renders, you can leverage React Developer Tools or use this handy helper hook I found on the internet to trace your re-renders: ` Conclusion Improving INP in React and Next.js is not easy and can require much investigation and fine-tuning. Still, it's worth doing to avoid being penalized by Google in its search results and provide a better experience for your users. Adopting React 18's new features, leveraging SSR and SSG in Next.js, utilizing Web Workers, and optimizing hooks and state management can significantly boost your INP score and deliver a faster application to your users. Remember, INP is just one among many performance metrics emphasizing the need for a comprehensive approach to performance optimization...

Apr 19, 2024

5 mins

Web PerformanceReactNextJSJavaScript

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

End-to-end type-safety with JSON Schema

End-to-end type-safety with JSON Schema I recently wrote an introduction to JSON Schema post. If you’re unfamiliar with it, check out the post, but TLDR: It’s a schema specification that can be used to define the input and output data for your JSON API. In my post, I highlight many fantastic benefits you can reap from defining schemas for your JSON API. One of the more interesting things you can achieve with your schemas is end-to-end type safety from your backend API to your client application(s). In this post, we will explore how this can be accomplished slightly deeper. Overview The basic idea of what we want to achieve is: * a JSON API server that validates input and output data using JSON Schema * The JSON Schema definitions that our API uses transformed into TypeScript types With those pieces in place, we can achieve type safety on our API server and the consuming client application. The server side is pretty straightforward if you’re using a server like Fastify with already enabled JSON Schema support. This post will focus on the concepts more than the actual implementation details though. Here’s a simple diagram illustrating the high-level concept: We can share the schema and type declaration between the client and server. In that case, we can make a request to an endpoint where we know its type and schema, and assuming the server validates the data against the schema before sending it back to the client, our client can be confident about the type of the response data. Marrying JSON Schema and TypeScript There are a couple of different ways to accomplish this: * Generating types from schema definitions using code generation tools * Creating TypeBox definitions that can infer TypeScript types and be compiled to JSON Schema I recommend considering both and figuring out which would better fit your application and workflows. Like anything else, each has its own set of trade-offs. In my experience, I’ve found TypeBox to be the most compelling if you want to go deep with this pattern. Code generation A couple of different packages are available for generating TS types from JSON Schema definitions. * https://github.com/bcherny/json-schema-to-typescript * https://github.com/vega/ts-json-schema-generator They are CLI tools that you can provide a glob path to where your schema files are located and will generate TS declaration files to a specified output path. You can set up an npm hook or a similar type of script that will generate types for your development environment. TypeBox TypeBox is a JSON Schema type builder. With this approach, instead of json files, we define schemas in code using the TypeBox API. The TypeBox definitions infer to TypeScript types directly, which eliminates the code generation step described above. Here’s a simple example from the documentation of a JSON Schema definition declared with TypeBox: ` This can then be inferred as a TypeScript type: ` Aside from schemas and types, TypeBox can do a lot more to help us on our type-safety journey. We will explore it a bit more in upcoming sections. Sharing schemas between client and server applications Sharing our JSON Schema between our server and client app is the main requirement for end-to-end type-safety. There are a couple of different ways to accomplish this, but the simplest would be to set up our codebase as a monorepo that contains both the server and client app. Some popular options for TypeScript monorepos are: PNPM, Turborepo, and NX. If a monorepo is not an option, you can publish your schema and types as a package that can be installed in both projects. However, this setup would require a lot more maintenance work. Ultimately, as long as you can import your schemas and types from the client and server app, you are in good shape. Server-to-client validation and type-safety For the sake of simplicity, let's focus on data flowing from the server to the client for now. Generally speaking, the concepts also apply in reverse, as long as your JSON API server validates your inputs and outputs. We’ll look at the most basic version of having strongly typed data on the client from a request to our server. Type-safe client requests In our server application, if we validate the /users endpoint with a shared schema - on the client side, when we make the request to the endpoint, we know that the response data is validated using the user schema. As long as we are confident of this fact, we can use the generated type from that schema as the return type on our client fetch call. Here’s some pseudocode: ` Our server endpoint would look something like this: ` You could get creative and build out a map that defines all of your endpoints, their metadata, and schemas, and use the map to define your server endpoints and create an API client. Transforming data over the wire Everything looks stellar, but we can still take our efforts a bit further. To this point, we are still limited to serialized JSON data. If we have a created_at field (number or ISO string) tied to our user, and we want it to be a Date object when we get a hold of it on the client side - additional work and consideration are required. There are some different strategies out there for deserializing JSON data. The great thing about having shared schemas between our client and server is that we can encode our type information in the schema without sending additional metadata from our server to the client. Using format to declare type data In my initial JSON Schema blog post, I touched on the format field of the specification. In our schema, if the actual type of our date is a string in ISO8601 format, we can declare our format to be "date-time". We can use this information on the client to transform the field into a proper Date object. ` Transforming serialized JSON Data This can be a little bit tricky; again, there are many ways to accomplish it. To demonstrate the concept, we’ll use TypeBox to define our schemas as discussed above. TypeBox provides a Transform type that you can use to declare, encode, and decode methods for your schema definition. ` It even provides helpers to statically generate the decoded and encoded types for your schema ` If you declare your decode and encode functions for your schemas, you can then use the TypeBox API to handle decoding the serialized values returned from your JSON API. Here’s what the concept looks like in practice fetching a user from our API: ` Nice. You could use a validation library like Zod to achieve a similar result but here we aren’t actually doing any validation on our client side. That happened on the server. We just know the types based on the schema since both ends share them. On the client, we are just transforming our serialized JSON into what we want it to be in our client application. Summary There are a lot of pieces in play to accomplish end-to-end type safety. With the help of JSON Schema and TypeBox though, it feels like light work for a semi-roll-your-own type of solution. Another great thing about it is that it’s flexible and based on pretty core concepts like a JSON API paired with a TypeScript-based client application. The number of benefits that you can reap from defining JSON Schemas for your APIs is really great. If you’re like me and wanna keep it simple by avoiding GraphQL or other similar tools, this is a great approach....

Apr 17, 2024

6 mins

JSONTypeScript

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

Make it accessible: Navigation in Angular

Make it Accessible: Navigation in Angular

Anchors to the rescue

Current page for Sighted Users

Current page for Visually Impaired Users

Manage focus and scroll

Conclusion

You might also like

Improving INP in React and Next.js

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

End-to-end type-safety with JSON Schema

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

Improving INP in React and Next.js

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

End-to-end type-safety with JSON Schema

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal