DEV Community: Daniel Marin

What's up with Heavy Duty Builders and Bulldozer.

Daniel Marin — Fri, 15 Oct 2021 19:44:40 +0000

TLDR;

Heavy Duty Builders is looking to become a DAO of Solana builders that creates open-source tools. Bulldozer is the first tool, a low-code platform to create Anchor-based programs in Solana.

Intro

Building software is hard af. I mean it, it really is. That's why we, as builders too, are committed to creating the dopest power tools so other builders can focus on what matters, their projects.

Heavy Duty Builders aims to become a DAO, where developers can join and help build the tools of the future. Bulldozer is our first tool, a low-code platform for creating Anchor workspaces in Solana.

We're not VC funded. Right now, we're just two builders working on Bulldozer. We're still on the first stages, but we have been getting a good response from the community. We've noticed other builders interested in a tool such as Bulldozer.

We want to stay open source and that's why we want to be a DAO. One of our top priorities is to figure out a way to give rewards for issues and features, maybe an NFT-powered medal system. This way builders can use medals as proof that they are not just any other builder, they are Heavy Duty Builders.

There's a lot to figure out. But we'll keep y'all posted.

Now if you're a builder and want to read a bit more about the nitty-gritty details behind Bulldozer, keep reading.

Overview

The system aims to make it easier for developers to write Solana programs. A program is some code that processes transactions in Solana runtime. For web2 developers, that's like a serverless cloud function.

This is how I see it, when you configure an instruction in Solana, more specifically with Anchor, you define how this "cloud function" will behave when called. There's way more to it, but that's a simplification I like to use.

Instruction

Bulldozer enables builders to configure an instruction through a client. The declarative nature of Anchor made it possible to create this configuration tool in a short time. Instructions take arguments that you can define in Bulldozer, and also, they take Accounts.

An account is, well, a very important concept you must know, but let's see it as a "file" that lives in Solana. Solana programs are stateless, meaning that when you want to use an account's data inside a program, you need to provide the account to the instruction when calling it.

But no worries, Bulldozer lets you specify the accounts.

There's also a very simple code editor that allows you to create the body of your instruction's handler.

Collection

Accounts in Solana have data that you have to de-serialize to use. You can think of a collection as the "schema" of your account. Bulldozer allows builders to create collections and add attributes.

Applications

An application maps to a Solana program, it consolidates a set of instructions and makes them available to the program.

Workspace

It's common to have applications that need to communicate with each other, in that case, it's good if they all live together. A workspace gives builders the chance of grouping their applications.

All the information is stored on-chain. We want to give builders the ability to collaborate in real-time powered by Solana. Although, this isn't a feature yet, we have an idea of how to approach it with Anchor events and subscriptions.

Architecture

We decided to go for a monorepo because we're planning to keep adding more tools. We chose Nx for managing the monorepo, it's not fully integrated with Rust build system which is kinda PITA, and that's something we're looking forward to fixing.

Since we're generating Anchor based programs, we went the same road with our code. As of now, there's a single program to do it all, but we're open to the idea of splitting it into multiple subprograms.

The client is built using Angular. I know it's weird to see a Dapp without React, but who knew, right? It's actually doable! It uses the @solana/wallet-adapter library for connecting to wallets. The @project-serum/anchor TS library powers all the requests to Solana.

Status

There's a CRUD for applications, collections, collection attributes, instructions, instruction arguments, instruction accounts, and instruction relations. The UI can perform all the management operations.

So far, we covered some Anchor features. We have a list of features we want to add ASAP. Improving the template engine is one of our top priorities, as well, as hiding some gory details when creating attributes and arguments.

The code is open source, so you can also go there and take a look at it yourself. You can find the code for bulldozer here

What's next

We're planning on working full-time in Bulldozer and see how far it can go. We already have a roadmap of what want to achieve:

Manage workspace and allow grouping of applications.
Improve Anchor integrations.
Enable real-time updates through events.
Enhance usability across the whole process.
Improve template engine.
Set up continuous integration for internal development.
Git integration for versioning of workspaces.
CLI to list, build and deploy workspaces and applications.
Plugin-support for community utilities.
Cross program invocation between applications in a workspace.

Thanks for reading, if you want to stay tuned, follow us on Twitter or join the Discord. You can also subscribe to our mailing list.

Peace.

Locally run Stackblitz project with Typescript and RxJs

Daniel Marin — Thu, 19 Nov 2020 16:22:58 +0000

Yoyoyo, what's up guys?

OMG, it's been a while since my last article. A lot going on, thankfully good stuff (:

I use Stackblitz a lot. Like A LOT. Today I created a new Typescript/RxJs project, once done, I was trying to export it and run it locally. Long story short, it wasn't running locally out-of-the-box.

Lucky us, my friend Tomek Sułkowski got us covered, all it took was to reach out and ask him:

Hey Tomek, how do you locally run a Stackblitz project with Typescript and RxJs?

NOTE: If you don't follow Tomek on Twitter already, you should.

All you gotta do is:

Export the project from Stackblitz.
Extract the project into the folder of your preference.
Go to the project's directory using a terminal.
Run npm i -D parcel.

With parcel it's easy to spin up a server that properly serves the index.html file. Before continuing, add your .ts files as scripts in the index.html file.

<!-- Your HTML code -->

<script src="index.ts"></script>

NOTE: If you have more than one .ts file, you may need to inject them all.

The last thing we're going to do is adding a new script to the package.json to serve the application.

{
  "name": "<your_project_name>",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    ...
    "serve": "parcel index.html"
  },
  "dependencies": {
    ...
  },
  "devDependencies": {
    ...
  }
}

You made it! Now call npm run serve and go to http://localhost:1234 in your browser.

NOTE: This guide is for simple projects, if you find issues trying to follow it, drop me a comment down below.

Accessible Tabs in Angular

Daniel Marin — Wed, 06 May 2020 23:38:59 +0000

Accessible Tabs in Angular

I have written this article to guide you through the process of building a Tab interface that complies with the WAI-ARIA 1.1 Specification. I know that sounds scary, but it's much more approachable than it sounds.

The Problem

When we are working with a user interface, we often have too much content for the space available.

The Solution

We could solve the problem by dividing the big chunk of info into smaller pieces. Then, we can show a single chunk at a time, and allow users to jump between the different chunks available. Then, voila! Suddenly, we need to build a tab interface.

The Implementation

If you've been reading the Make it Accessible series, you probably know the first step. If you don't, just go to this page WAI-ARIA Practices, which is a an amazing resource for learning how to make your apps more accessible. That site is going to be your best friend from now on.

As you can see, it lists a bunch of common widgets for user interfaces. The one we're looking for is Tabs , which is under the number 3.22 , or accessed directly at Tabs Section of the WAI-ARIA Practices.

The first thing to notice is that they describe the terms used:

Tabs or Tabbed Interface: A set of tab elements and their associated tab panels.
Tab List: A set of tab elements contained in a tablist element.
Tab: An element in the tab list that serves as a label for one of the tab panels and can be activated to display that panel.
Tabpanel: The element that contains the content associated with a tab.

There's also a list of Keyboard Interactions , and a few examples. Sadly, all the examples in the WAI-ARIA specification are in plain HTML + Javascript. That's why I decided to start writing an article for each of the available widgets built with Angular.

Enough talk

Let's start by generating a new application. You can do that by using the Angular CLI. For this project, I'm using the version 9.0.5. Just open your terminal of choice, and type ng new ng-tabs, and the Angular CLI will take care of creating all the files you'll need for your application.

Next, we are going to generate the first module named SharedModule. For this, we'll go back to the Angular CLI. While in your terminal of choice, go to the project's folder, and type ng g module shared. It will generate the module for you. You'll then need to import it in your src/app/app.module.ts file like this:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { SharedModule } from './shared/shared.module';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, AppRoutingModule, SharedModule],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {}

Thanks to the SharedModule, now we can create and export any component, and use it across the application. Let's create a component for each of the core concepts behind tabs- one for a tab (I'll call this tab trigger from now on), and one for a tabpanel.

Tab Trigger

We'll need a new component to hold each tab trigger's logic. This way, we can abstract some of the implementation details, and make it easier to use later on. To creat this component, we're going to use the Angular CLI again. Using your terminal, go to the project folder, and type ng g component shared/components/tab-trigger --style=scss --export --inlineTemplate. With that command, a new component will be generated, and will be automatically exported in the SharedModule.

Now, let's customize the new component. Open the src/app/shared/components/tab-trigger/tab-trigger.component.ts:

import { Component, Input } from '@angular/core';

@Component({
  selector: 'app-tab-trigger',
  template: `
    <button
      [id]="triggerId"
      role="tab"
      [attr.aria-controls]="panelId"
      [attr.aria-selected]="isActive"
      tabindex="-1"
    >
      <ng-content></ng-content>
    </button>
  `,
  styleUrls: ['./tab-trigger.component.scss']
})
export class TabTriggerComponent {
  @Input() isActive: boolean;
  @Input() triggerId: string;
  @Input() panelId: string;
}

And now, let's integrate the styles. Open the src/app/shared/components/tab-trigger/tab-trigger.component.scss:

button {
  position: relative;
  margin: 0;
  padding: 0.3em 0.5em 0.4em;
  border: 1px solid hsl(219, 1%, 72%);
  border-radius: 0.2em 0.2em 0 0;
  box-shadow: 0 0 0.2em hsl(219, 1%, 72%);
  overflow: visible;
  font-family: inherit;
  font-size: inherit;
  background: hsl(220, 20%, 94%);

  &:hover::before,
  &:focus::before,
  &[aria-selected='true']::before {
    position: absolute;
    bottom: 100%;
    right: -1px;
    left: -1px;
    border-radius: 0.2em 0.2em 0 0;
    border-top: 3px solid hsl(20, 96%, 48%);
    content: '';
  }

  &[aria-selected='true'] {
    border-radius: 0;
    background: hsl(220, 43%, 99%);
    outline: 0;
  }

  &[aria-selected='true']:not(:focus):not(:hover)::before {
    border-top: 5px solid hsl(218, 96%, 48%);
  }

  &[aria-selected='true']::after {
    position: absolute;
    z-index: 3;
    bottom: -1px;
    right: 0;
    left: 0;
    height: 0.3em;
    background: hsl(220, 43%, 99%);
    box-shadow: none;
    content: '';
  }

  &:hover,
  &:focus,
  &:active {
    outline: 0;
    border-radius: 0;
    color: inherit;
  }

  &:hover::before,
  &:focus::before {
    border-color: hsl(20, 96%, 48%);
  }
}

Tab Panel

We'll need a new component to hold each tab's panel, just like with the triggers. This way, we can abstract some of the implementation details, and make it easier to use later on. To create this component we're, going to use the Angular CLI again. Using your terminal, go to the project folder, and type ng g component shared/components/tab-panel --style=scss --export --inlineTemplate. With that command, a new component will be generated, and automatically exported in the SharedModule.

Now, let's customize the new component, open the src/app/shared/components/tab-panel/tab-panel.component.ts:

import { Component, Input } from '@angular/core';

@Component({
  selector: 'app-tab-panel',
  template: `
    <div
      [id]="panelId"
      role="tabpanel"
      [attr.aria-labelledby]="triggerId"
      tabindex="0"
    >
      <ng-content></ng-content>
    </div>
  `,
  styleUrls: ['./tab-panel.component.scss']
})
export class TabPanelComponent {
  @Input() panelId: string;
  @Input() triggerId: string;
}

And now, let's integrate the styles. Open the src/app/shared/components/tab-panel/tab-panel.component.scss:

[role='tabpanel'] {
  position: relative;
  z-index: 2;
  padding: 0.5em 0.5em 0.7em;
  border: 1px solid hsl(219, 1%, 72%);
  border-radius: 0 0.2em 0.2em 0.2em;
  box-shadow: 0 0 0.2em hsl(219, 1%, 72%);
  background: hsl(220, 43%, 99%);
}

[role='tabpanel']:focus {
  border-color: hsl(20, 96%, 48%);
  box-shadow: 0 0 0.2em hsl(20, 96%, 48%);
  outline: 0;
}

[role='tabpanel']:focus::after {
  position: absolute;
  bottom: 0;
  right: -1px;
  left: -1px;
  border-bottom: 3px solid hsl(20, 96%, 48%);
  border-radius: 0 0 0.2em 0.2em;
  content: '';
}

[role='tabpanel'] p {
  margin: 0;
}

[role='tabpanel'] * + p {
  margin-top: 1em;
}

Finish it

All we have left is to use our new components, since this is an example I will use it directly in the AppComponent, go to src/app/app.component.ts:

import {
  Component,
  ViewChildren,
  QueryList,
  ElementRef,
  AfterViewInit
} from '@angular/core';
import { TabTriggerComponent } from './shared/components/tab-trigger/tab-trigger.component';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent implements AfterViewInit {
  @ViewChildren(TabTriggerComponent, { read: ElementRef })
  tabElements: QueryList<ElementRef>;
  tabs: ElementRef[];
  activated = 0;
  focused = 0;

  ngAfterViewInit() {
    this.tabs = this.tabElements.toArray();
    this.tabElements.first.nativeElement.firstChild.tabIndex = '0';
  }

  activatePanel(index: number) {
    this.tabs.forEach(tab => (tab.nativeElement.firstChild.tabIndex = -1));
    this.tabs[index].nativeElement.firstChild.tabIndex = index.toString();
    this.focused = index;
    this.activated = index;
  }

  focusPanel(index: number) {
    this.focused = index;
    this.tabs[this.focused].nativeElement.firstChild.focus();
  }

  handleKeyUp(event: KeyboardEvent) {
    switch (event.key) {
      case 'ArrowLeft':
        this.focusPanel(this.focused ? this.focused - 1 : this.tabs.length - 1);
        break;
      case 'ArrowRight':
        this.focusPanel((this.focused + 1) % this.tabs.length);
        break;
    }
  }

  handleKeyDown(event: KeyboardEvent) {
    switch (event.key) {
      case 'Home':
        event.preventDefault();
        this.focusPanel(0);
        break;
      case 'End':
        event.preventDefault();
        this.focusPanel(this.tabElements.length - 1);
        break;
    }
  }
}

Let walk through this component:

We're using @ViewChildren to get all the TabTriggerComponent instances.
Using the AfterViewInit life cycle, I get a clone of the component instances, and set tabindex=0 to the first one.
A method activatePanel, used when any of the triggers is clicked.
A method focusPanel, triggering the focus in the Button Element.
A method handleKeyUp and handleKeyDown. We separate them because Home and End keys have a default behavior that needs to be prevented.

Now, open the template in src/app/app.component.html:

<main>
  <div class="tabs">
    <div
      role="tablist"
      aria-label="options"
      (keyup)="handleKeyUp($event)"
      (keydown)="handleKeyDown($event)"
    >
      <app-tab-trigger
        triggerId="trigger-a"
        panelId="panel-a"
        [isActive]="activated === 0"
        (click)="activatePanel(0)"
      >
        Panel A
      </app-tab-trigger>
      <app-tab-trigger
        triggerId="trigger-b"
        panelId="panel-b"
        [isActive]="activated === 1"
        (click)="activatePanel(1)"
      >
        Panel B
      </app-tab-trigger>
      <app-tab-trigger
        triggerId="trigger-c"
        panelId="panel-c"
        [isActive]="activated === 2"
        (click)="activatePanel(2)"
      >
        Panel C
      </app-tab-trigger>
    </div>

    <app-tab-panel
      *ngIf="activated === 0"
      panelId="panel-a"
      triggerId="trigger-a"
    >
      <p>Panel A</p>
    </app-tab-panel>
    <app-tab-panel
      *ngIf="activated === 1"
      panelId="panel-b"
      triggerId="trigger-b"
    >
      <p>Panel B</p>
    </app-tab-panel>
    <app-tab-panel
      *ngIf="activated === 2"
      panelId="panel-c"
      triggerId="trigger-c"
    >
      <p>Panel C</p>
    </app-tab-panel>
  </div>
</main>

And now, the final styles to the AppComponent! Open src/app/app.component.scss:

.tabs {
  width: 20em;
}

[role='tablist'] {
  margin: 0 0 -0.1em;
  overflow: visible;
}

Conclusion

After a few quick steps, we were able to replicate the WAI-ARIA spec for Tabs, using a component oriented approach with Angular's help. I heavily based my implementation on the one found in the spec. My goal was primarily to show how easy it is to use Angular concepts to build such a feature. If you encounter any issues while trying to do this, drop a comment below.

This Dot Labs is a modern web consultancy focused on helping companies realize their digital transformation efforts. For expert architectural guidance, training, or consulting in React, Angular, Vue, Web Components, GraphQL, Node, Bazel, or Polymer, visit [thisdotlabs.com]((https://www.thisdotlabs.com).

This Dot Media is focused on creating an inclusive and educational web for all. We keep you up to date with advancements in the modern web through events, podcasts, and free content. To learn, visit thisdot.co.

Loading Components Dynamically in Angular 9 with Ivy

Daniel Marin — Fri, 27 Mar 2020 14:48:43 +0000

Loading Components Dynamically in Angular 9 with Ivy

This article will show you how to start loading components dynamically using Angular 9 with Ivy. This is not exactly new and exclusive to Angular 9, but now we can have components without a module, and by making them load dynamically, we get the benefits of lazy loading.

Making the story short, we'll reduce the main bundle size by loading only the components we need.

Imagine you have a huge module that consists of multiple components. Every user has unique needs, meaning that they will only use a subset of all the available components. The goal of this article is to explore a possible solution for addressing it.

To make it easier, I decided to work on a use case that I know.

If you want to skip ahead, and go straight to the code, I created this repository with the finished version of the app. It looks like this:

The Problem

Let's say that we have this application, with which users can log in and perform some actions. Regardless of whether the user is a guest, or a registered user, they both have a profile page. Each kind of user has different actions that they can perform.

Solution

One way to solve this problem would be to use conditionals with the help of the ngIf structural directive. This allows us to have a different layout for each. It works, but is it the best solution? Remember that now both users have to download the entire component and actions, whether or not they use them.

I want to clarify, I have used the ngIf strategy in applications that have been in production for years.

Let's do something different this time. Let's create a component for each kind of user, and dynamically load them. This way, the main bundle won't have any of them, and they will be downloaded on demand.

Implementation

It's time to have fun. Before we start, make sure you have installed the Angular CLI v9. If you need help on this step, just drop a comment below. Once you have the right version of the Angular CLI installed, follow these steps:

Open your terminal of choice.
Run the command ng new {your-app-name}
Open the new project in your editor of choice.

Let's start with the loading of components. We are going to create a new service AppService. Once you've created it, open it in your editor src/app/app.service.ts and paste this:

import {
  Injectable,
  ComponentFactoryResolver,
  ViewContainerRef
} from '@angular/core';
import { from } from 'rxjs';
import { map } from 'rxjs/operators';

export interface ComponentLoader {
  loadChildren: () => Promise<any>;
}

@Injectable({
  providedIn: 'root'
})
export class AppService {
  constructor(private cfr: ComponentFactoryResolver) {}

  forChild(vcr: ViewContainerRef, cl: ComponentLoader) {
    return from(cl.loadChildren()).pipe(
      map((component: any) => this.cfr.resolveComponentFactory(component)),
      map(componentFactory => vcr.createComponent(componentFactory))
    );
  }
}

At first glance, you see ComponentFactoryResolver, ViewContainerRef, ComponentLoader, and think:

What kind of sorcery is this?

It's simpler than you think. It's just that there are a few new things. We are injecting the ComponentFactoryResolver, which, given a Component, returns a Factory that can be used to create new instances of it. The ViewContainerRef is a pointer to an element in which we are going to insert the newly instantiated component. The ComponentLoader is a simple interface. It holds a loadChildren function that returns a Promise. This promise, once resolved, returns a Component.

And finally, we are just putting everything together. Using the from function from rxjs, I'm able to transform the promise into an observable. Then, I'm mapping this component into a factory, and finally I will inject the component, and return the instance.

Now, let's create another service named ProfileService that will use the AppService to load the respective component. It also holds the loggedIn state. Create a file in src/app/profile/profile.service.ts:

import { Injectable, ViewContainerRef } from '@angular/core';
import { BehaviorSubject } from 'rxjs';
import { AppService } from '../app.service';

@Injectable({ providedIn: 'root' })
export class ProfileService {
  private isLoggedIn = new BehaviorSubject(false);
  isLoggedIn$ = this.isLoggedIn.asObservable();

  constructor(private appService: AppService) {}

  private guestProfile() {
    return () =>
      import('./guest-profile/guest-profile.component').then(
        m => m.GuestProfileComponent
      );
  }

  private clientProfile() {
    return () =>
      import('./client-profile/client-profile.component').then(
        m => m.ClientProfileComponent
      );
  }

  login() {
    this.isLoggedIn.next(true);
  }

  logout() {
    this.isLoggedIn.next(false);
  }

  loadComponent(vcr: ViewContainerRef, isLoggedIn: boolean) {
    vcr.clear();

    return this.appService.forChild(vcr, {
      loadChildren: isLoggedIn ? this.clientProfile() : this.guestProfile()
    });
  }
}

This service is way easier to understand. We created a Subject to manage the isLoggedIn state, and two methods to many events into the subject. We created two private methods that return a function that returns a Promise of a Component.

Yes, just like the ComponentLoader interface.

And finally, a magical method: loadComponent takes a ViewContainerRef and the isLoggedIn state. Clears the ViewContainerRef, emptying it entirely. Then, it calls the forChild method from AppService with the ViewContainerRef we just cleaned, and for the ComponentLoader, it has a ternary expression that determines which Component to load.

In order to make the loading of the components easier, we are going to create a directive that will help with that. Create a file src/app/profile/profile-host.directive.ts:

import { Directive, ViewContainerRef } from '@angular/core';

@Directive({ selector: '[appProfileHost]' })
export class ProfileHostDirective {
  constructor(public viewContainerRef: ViewContainerRef) {}
}

This is just a trick to make it easier to get the ViewContainerRef we're looking for. Now create a file src/app/profile/profile.component.ts:

import { Component, OnInit, OnDestroy, ViewChild } from '@angular/core';
import { ProfileHostDirective } from './profile-host.directive';
import { ProfileService } from './profile.service';
import { mergeMap, takeUntil } from 'rxjs/operators';
import { Subject } from 'rxjs';

@Component({
  selector: 'app-profile-container',
  template: `
    <ng-template appProfileHost></ng-template>
  `
})
export class ProfileComponent implements OnInit, OnDestroy {
  @ViewChild(ProfileHostDirective, { static: true })
  profileHost: ProfileHostDirective;
  private destroySubject = new Subject();

  constructor(private profileService: ProfileService) {}

  ngOnInit() {
    const viewContainerRef = this.profileHost.viewContainerRef;

    this.profileService.isLoggedIn$
      .pipe(
        takeUntil(this.destroySubject),
        mergeMap(isLoggedIn =>
          this.profileService.loadComponent(viewContainerRef, isLoggedIn)
        )
      )
      .subscribe();
  }

  ngOnDestroy() {
    this.destroySubject.next();
    this.destroySubject.complete();
  }
}

All we are doing here is creating a simple ng-template in which we attach the ProfileHostDirective, so we can use the ViewChild decorator, and get the viewContainerRef. OnInit we are getting the viewContainerRef, and using the isLoggedIn$ observable from ProfileService to know everytime the isLoggedIn state changes. Then, using the mergeMap operator, I call the loadComponent function that is doing the real magic.

If you take a look at src/app/profile/profile.service.ts, you'll notice I'm referencing a GuestProfileComponent, and a ClientProfileComponent. Now it's time to create them.

First, go to the src/styles.scss, and include this:

html,
body {
  margin: 0;
  padding: 0;
}

To make the styling easier, I created a folder style inside the assets folder, in which I have 2 scss files:

_variables.scss
_mixins.scss

They hold all the shared styles, to make everything easier to maintain:

// _variables.scss
$card-width: 400px;
$avatar-width: 80px;
$container-margin: 20px;

// _mixins.scss
@import './variables.scss';

@mixin button($color) {
  display: inline-block;
  padding: 0.5rem 1rem;
  border: 1px solid $color;
  border-bottom-color: darken($color, 10);
  border-radius: 5px;
  background: linear-gradient(180deg, $color, darken($color, 10));
  color: white;
  cursor: pointer;
  font-family: Arial, Helvetica, sans-serif;
  box-shadow: 1px 2px 4px rgba(0, 0, 0, 0.2);
  font-size: 1rem;

  &:hover {
    background: $color;
    box-shadow: 1px 4px 6px rgba(0, 0, 0, 0.2);
  }

  &:active {
    background: darken($color, 10);
  }
}

@mixin card {
  box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
  border: 1px solid #eee;
  width: $card-width;
  padding: 1rem;
}

I also created a folder images, and included an image named profile.png. You can have any image as long as it's a square.

Let's create the GuestProfileComponent. For this, we'll need three files; a template, a stylesheet, and a typescript file. Let's start with the template: create a file src/app/profile/guest-profile/guest-profile.component.html

<section class="card">
  <div class="card__avatar">
    <div class="card __avatar__ head"></div>
    <div class="card __avatar__ body"></div>
  </div>

  <div class="container">
    <h2 class="card__title">Guest Profile</h2>

    <p class="card__subtitle">
      Thank you for visiting us. If you want to take your experience to the next
      level, all you need is to log in.
    </p>

    <div class="card__toolbar">
      <button (click)="login()">Login</button>
    </div>
  </div>
</section>

Now let's create the stylesheet in src/app/profile/guest-profile/guest-profile.component.scss:

@import '~src/assets/styles/mixins.scss';

.card {
  display: flex;
  @include card();

  &__title {
    margin: 0 0 0.5rem 0;
  }

  &__subtitle {
    margin: 0 0 0.5rem 0;
  }

  &__toolbar button {
    @include button(#145092);
  }

  &__avatar {
    height: 80px;
    width: $avatar-width;
    border: 2px solid #bbb;
    background: #666;
    position: relative;
    overflow: hidden;

    &__head {
      position: absolute;
      border-radius: 50%;
      background: #bbb;
      width: 35px;
      height: 35px;
      top: 15px;
      left: 22px;
    }

    &__body {
      position: absolute;
      border-radius: 50%;
      background: #bbb;
      width: 70px;
      height: 50px;
      top: 55px;
      left: 5px;
    }
  }
}

.container {
  width: $card-width - $avatar-width - $container-margin;
  margin: 0 $container-margin;
}

And finally, the typescript file in src/app/profile/guest-profile/guest-profile.component.ts:

import { Component } from '@angular/core';
import { ProfileService } from '../profile.service';

@Component({
  selector: 'app-guest-profile',
  templateUrl: './guest-profile.component.html',
  styleUrls: ['./guest-profile.component.scss']
})
export class GuestProfileComponent {
  constructor(private profileService: ProfileService) {}

  login() {
    this.profileService.login();
  }
}

That's great! All we need to do now is create the ClientProfileComponent. We'll need the same files from the GuestProfileComponent. Let's start with the template src/app/profile/client-profile/client-profile.component.html

<section class="card">
  <figure class="card__avatar">
    <img src="assets/images/profile.png" />
  </figure>

  <h2 class="card__title" contenteditable="true">Daniel Marin</h2>

  <p class="card__subtitle" contenteditable="true">
    Senior Software Engineer at This Dot Labs, a company specializing in Modern
    Web Technologies, designing, and developing software to help companies
    maximize efficiency in their processes.
  </p>

  <div class="card__toolbar">
    <button (click)="logout()">Logout</button>
  </div>
</section>

Now, let's create the stylesheet in src/app/profile/client-profile/client-profile.component.scss:

@import '~src/assets/styles/mixins.scss';

.card {
  @include card();

  &__avatar {
    height: $avatar-width;
    width: $avatar-width;
    margin: 0 auto;
    border-radius: 50%;
    overflow: hidden;

    img {
      width: 100%;
      height: 100%;
      object-fit: cover;
    }
  }

  &__title {
    margin: 1rem 0 0.5rem 0;
    text-align: center;
  }

  &__subtitle {
    margin: 0 0 1rem 0;
    text-align: center;
  }

  &__toolbar {
    display: flex;
    justify-content: center;

    button {
      @include button(#a80000);
    }
  }
}

And finally, the typescript file in src/app/profile/client-profile/client-profile.component.ts:

import { Component } from '@angular/core';
import { ProfileService } from '../profile.service';

@Component({
  selector: 'app-client-profile',
  templateUrl: './client-profile.component.html',
  styleUrls: ['./client-profile.component.scss']
})
export class ClientProfileComponent {
  constructor(private profileService: ProfileService) {}

  logout() {
    this.profileService.logout();
  }
}

Now, all we have to do is update the AppComponent. Go to src/app/app.component.html, remove all its content, and put this instead:

<h1 class="header">Dynamic components</h1>
<main class="container">
  <app-profile-container></app-profile-container>
</main>

Then, go to src/app/app.component.scss, and include this:

.header {
  background: #ddd;
  border-bottom: 1px solid #ccc;
  margin: 0;
  padding: 1rem;
  box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
}

.container {
  display: flex;
  justify-content: center;
  margin-top: 2rem;
}

Now, the only thing we cannot forget to do is add ProfileComponent, and ProfileHostDirective, to the AppModule declarations array. Go to src/app/app.module.ts:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { ProfileHostDirective } from './profile/profile-host.directive';
import { ProfileComponent } from './profile/profile.component';

@NgModule({
  declarations: [AppComponent, ProfileHostDirective, ProfileComponent],
  imports: [BrowserModule, AppRoutingModule],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {}

And we are done.

Conclusion

I hope that you had as much fun coding this as I did while writing this code. Now you know how to dynamically load components with lazy loading. With this knowledge, you can reduce the main bundle size, and make the experience better for your users. If you are having any problems, feel free to reach out to me via Twitter.

Truly Accessible Custom Components in Angular

Daniel Marin — Wed, 25 Mar 2020 16:07:39 +0000

Truly Accessible Custom Components in Angular

For the first time in my "Make it Accessible" series, I'm going to work on building a component that meets the requirements specified in the WAI-ARIA Authoring Practices. We'll even do the optional stuff! When I was looking for a good example, I saw that most of the examples out there cover things like a radio button. I wanted to pursue this concept even further, so we're building an Accordion Component.

Exciting right? Let's do this!

Before we start, here you can access the source code of the accordion

The Problem

When we are building an Angular application, native HTML Elements can be used. And even though this is what I always recommend, there are cases that need something unique. An Accordion is not that unique, but it's certainly custom, and no native elements are required to build it.

The Solution

In this case, I'm going to stick to the specification instead of making all of the decisions myself. Instead, I'm going to the WAI-ARIA Authoring Practices, and will paste all we need to be compliant here.

I want to explicitly state that I'm not taking any credit for the specification.

1. Structure

An accordion is a vertically stacked set of interactive headings that each contain a title, content snippet, or thumbnail, representing a section of content. The headings function as controls that enable users to reveal or hide their associated sections of content. Accordions are commonly used to reduce the need to scroll when presenting multiple sections of content on a single page.

Terms for understanding accordions include:

1.1. Accordion Header

Label for our thumbnail, representing a section of content that also serves as a control for showing, and in some implementations, hiding the section of content.

1.2. Accordion Panel

Section of content associated with an accordion header.

In some accordions, there are additional elements that are always seen adjacent to the accordion header. For instance, a menu button may accompany each accordion header to provide access to actions that apply to that section. And, in some cases, a snippet of the hidden content may also be visually persistent.

2. Keyboard Interaction

2.1. Enter or Space

When focus is on the accordion header for a collapsed panel, expands the associated panel. If the implementation allows only one panel to be expanded, and if another panel is expanded, collapses that panel.
When focus is on the accordion header for an expanded panel, collapse the panel if the implementation supports collapsing. Some implementations require one panel to be expanded at all times, and allow only one panel to be expanded; so, they do not support a collapse function.

2.2. Tab

Moves focus to the next focusable element; all focusable elements in the accordion are included in the page Tab sequence.

2.3. Shift + Tab

Moves focus to the previous focusable element; all focusable elements in the accordion are included in the page Tab sequence.

2.4. Down Arrow (Optional):

If focus is on an accordion header, moves focus to the next accordion header. If focus is on the last accordion header, either does nothing or moves focus to the first accordion header.

2.5. Up Arrow (Optional):

If focus is on an accordion header, moves focus to the previous accordion header. If focus is on the first accordion header, either does nothing or moves focus to the last accordion header.

2.6. Home (Optional):

When focus is on an accordion header, moves focus to the first accordion header.

2.7. End (Optional):

When focus is on an accordion header, moves focus to the last accordion header.

3. WAI-ARIA Roles, States, and Properties

3.1. Accordion Header Title

The title of each accordion header is contained in an element with role button.

3.2. Level of Accordion Header

Each accordion header button is wrapped in an element with role heading that has a value set for aria-level that is appropriate for the information architecture of the page.

If the native host language has an element with an implicit heading and aria-level, such as an HTML heading tag, a native host language element may be used.
The button element is the only element inside the heading element. That is, if there are other visually persistent elements, they are not included inside the heading element.

3.3. Update aria-expanded accordingly

If the accordion panel associated with an accordion header is visible, the header button element has aria-expanded set to true. If the panel is not visible, aria-expanded is set to false.

3.4. Use aria-control respectively

The accordion header button element has aria-controls set to the ID of the element containing the accordion panel content.

3.5. Update aria-disabled accordingly

If the accordion panel associated with an accordion header is visible, and if the accordion does not permit the panel to be collapsed, the header button element has aria-disabled set to true.

3.6. Usage of aria regions

Optionally, each element that serves as a container for panel content has role region and aria-labelledby with a value that refers to the button that controls display of the panel.

Avoid using the region role in circumstances that create landmark region proliferation, e.g., in an accordion that contains more than approximately 6 panels that can be expanded at the same time.
Role region is especially helpful for the perception of structure by screen reader users when panels contain heading elements or a nested accordion.

Implementation

If you want to code along the way, I created a repository that has a branch with a starter accordion. Clone that repository, and let's do this together.

You dont have to care about the structure, the code I just gave you already has that. Our focus will be in the Keyboard Interactions, and the WAI-ARIA Roles, States, and Properties.

2. Keyboard Interactions

2.1. Enter or Space

I decided to allow users to collapse an expanded panel, so there's only one thing to do. We need to call the toggle method when clicking a header, with Enter or Space, when focused. Thankfully I decided to use a native HTML button, which comes out of the box with keyboard support.

2.2. Tab

The Tab funcionality comes out of the box too, as long as we make items tabbable. Since the headers are buttons, that's already true. One thing to keep in mind is that a panel's content shouldnt be tabbable when collapsed, but if you read 5 Tips to Make your Angular Apps more Accessible you will know that the ngIf directive removes the all of the content so we don't have to do anything else.

2.3. Shift + Tab

The same logic for 2.2 applies here.

The other interactions

We are getting closer to the fun stuff.

We'll need to listen to keyup events, if the pressed key is equal to any of the ones, required by WAI-ARIA, that we will act upon. Basically we need a keyup handler, a goToNext and goToPrevious methods. Let's jump on the code and do that:

Go to src/app.component.ts and do this:

// ...
const ARROW_DOWN = 'ArrowDown';
const ARROW_UP = 'ArrowUp';
const HOME = 'Home';
const END = 'End';

@Component(/* */)
export class AppComponent implements AfterViewInit {
  // ...
  @ViewChildren(AccordionHeaderComponent) accordionHeaders: QueryList<
    ElementRef
  >;
  private panelQuantity: number;

  ngAfterViewInit() {
    this.panelQuantity = this.accordionHeaders.length;
  }

  private goToNext() {
    this.currentlyFocused = (this.currentlyFocused + 1) % this.panelQuantity;
  }

  private goToPrevious() {
    if (this.currentlyFocused === 0) {
      this.currentlyFocused = this.panelQuantity - 1;
    } else {
      this.currentlyFocused = this.currentlyFocused - 1;
    }
  }

  // ...

  handleKeyUp(event: KeyboardEvent) {
    switch (event.key) {
      case ARROW_DOWN:
        this.goToNext();
        break;
      case ARROW_UP:
        this.goToPrevious();
        break;
      case HOME:
        this.currentlyFocused = 0;
        return;
      case END:
        this.currentlyFocused = this.panelQuantity - 1;
        return;
      default:
        break;
    }
  }
}

Let's break it down. We are using the AfterViewInit hook to get the number of headers the accordion has. This will be useful for the Arrow support. That way, if the user presses the Up Arrow in the first item, the focus is sent to the last header, and the opposite for Down Arrow. Home and End are way easier, since the currentlyFocused is the mechanism we are using in order to know which one is currently focused in an imperative way, we just need to update it to first or the last, respectively.

Just to recap, we have successfully integrated keyboard support to our custom widget following WAI-ARIA spec.

3. WAI-ARIA Roles, States, and Properties

Now it's time to go a little deeper, and work with aria-* attributes, roles and properties.

I don't know how many times I've said this, but I'll keep saying it. If you think about accessibility from the design stage, you will dramatically reduce longterm development costs. Since I read the specs before starting, I made a few decisions in the starter code, so the two first things in the aria part are already done; the headers are buttons, and they contain a heading with a level.

3.3. Update aria-expanded accordingly

This one is extremely simple, since we already have the isOpen category in the AccordionHeader component, we just need to wire its value to the aria-expanded property in the button element. For this, you have to go to src/app/shared/components/accordion-header/accordion-header.component.html

<h2 class="header" [ngClass]="{ 'is-open': isOpen }">
  <button ... [attr.aria-expanded]="isOpen">
    <!-- ... -->
  </button>
</h2>

<!-- ... -->

3.4. Use aria-control respectively

This one is a bit trickier because we need a way to wire the button with the panel. For this, we'll need to use the index input property. With it, we'll assign a unique id to the panel, and will use the same value for the aria-controls. For this, you have to go to src/app/shared/components/accordion-header/accordion-header.component.html

<h2 class="header" [ngClass]="{ 'is-open': isOpen }">
  <button ... [attr.aria-controls]="'panel-' + index">
    <!-- ... -->
  </button>
</h2>

<div [id]="'panel-' + index">
  <!-- ... -->
</div>

In this case, we dont care about updating the aria-disabled property, because I decided to allow users to collapse expanded panels.

3.6. Usage of aria regions

This one is easier, but is also easy to forget. Right now, the panel is not a region. Without it, the panels are just containers for html, but they do not provide any extra information to Screen Reader users. That's why this is such an important step. For this, you have to go to src/app/shared/components/accordion-header/accordion-header.component.html

<!-- ... -->
<div ... [attr.aria-labelledby]="'accordion-' + index" role="region">
  <!-- ... -->
</div>

That's it!

The accordion header template will end up looking like this:

<h2 class="header" [ngClass]="{ 'is-open': isOpen }">
  <button
    [id]="'accordion-' + index"
    class="header__trigger"
    [appFocusable]="isFocused"
    (click)="togglePanel()"
    (focus)="setFocus()"
    (blur)="setBlur()"
    [attr.aria-expanded]="isOpen"
    [attr.aria-controls]="'panel-' + index"
  >
    <div class="header__title">
      <span>{{ headerTitle }}</span>
      <fa-icon [icon]="faAngleUp"></fa-icon>
    </div>
  </button>
</h2>

<div
  [id]="'panel-' + index"
  [attr.aria-labelledby]="'accordion-' + index"
  role="region"
>
  <ng-content *ngIf="isOpen"></ng-content>
</div>

Conclusion

I know this one was a little longer than the usual Make it Accessible articles, but it had to be done. We definetely needed to go into detail, and build a custom component that was totally compliant with the specs. Just as a reminder, make sure you have unique ids. Even though what I just gave you isn't reusable (we are not building an open source library), it can definitely give you more understanding of how to do this on your own.

In my free time, I'm currently working on building a small library that includes all the concepts I dive into in this series. If you would like to help me, feel free to drop a comment, or message me on Twitter.

Make it Accessible: Dealing with Form Errors in Angular

Daniel Marin — Mon, 02 Mar 2020 16:57:44 +0000

Make it Accessible: Dealing with Form Errors in Angular

This article's intention is to show you how to handle errors in forms from the a11y angle. Forms are key in any web application. If we want to make truly inclusive apps, it's mandatory to make sure that the forms can be used with Screen Readers.

In one of my previous articles, I talk about focus, usage of labels, and more tips to make your ReactiveForms more accessible, but in this one, we are going to talk only about error handling. We'll start with a simple form, and will also take a look at error handling. You can access this repository with the base form I'll be using.

The Problem

When doing applications for users with Screen Readers, things change a lot because we can't rely on visual cues, colors, sizes. Implementing a good error handling strategy can be challenging and on top of that, making it accessible? Sounds like a good challenge. A very common pattern is to show a text describing the error right below each input, usually in the color red. That is okay, unless you want to make it understandable for Screen Reader users. In this instance, you would have to have a way to audibally announce all the errors found to the user.

The Solution

The first thing is to have the errors formatted in a way that's easy for us to display later. The next thing to figure out, will be how to announce to the user that there were errors. If I put it this way, it sounds approachable, right?

Implementation

Let's start by opening src/app/app.component.ts and getting the errors from the form, and formatting them in a way that's easier for us later.

//...
export class AppComponent {
  errors = null;
  //...

  onSubmit() {
    //...
    if (this.form.invalid) {
      this.errors = {
        firstName: this.form.get('firstName').errors,
        lastName: this.form.get('lastName').errors,
        email: this.form.get('email').errors
      };
    } else {
      this.errors = null;
    }
  }
}

What I just did was simply create a new property named errors, and updated the onSubmit method, so now, if the form is valid, it will clean up the errors. Otherwise, it will add all the errors found in the form to the errors property we just created.

Now let's go to src/app/app.component.html and let's show those errors to the user!

<div class="form-errors" [ngClass]="{ active: submitted && errors }">
  <ng-container *ngIf="submitted && errors">
    There were errors found in the form.

    <ul class="form-errors-list" *ngIf="errors">
      <li *ngIf="errors.firstName?.required">First name is required</li>
      <li *ngIf="errors.lastName?.required">Last name is required</li>
      <li *ngIf="errors.email?.required">Email is required</li>
      <li *ngIf="errors.email?.email">Email has to be properly formatted</li>
    </ul>
  </ng-container>
</div>

We just created all we need to display the errors, you can put this piece of code anywhere in src/app/app.component.html.

Now, there's only one thing left to do- announce it to the user. If you want to announce something to the user, you can use aria-live. This attribute tells the Screen Readers that it has to announce to the users when its content changes. For aria-live you can use either pollite or assertive. The difference is very simple. Pollite waits until every other announcement finishes before announcing its content change, while assertive announces it as soon as possible.

This is all we need to do in src/app/app.component.html:

<div
  class="form-errors"
  [ngClass]="{ active: submitted && errors }"
  aria-live="assertive"
>
  <!-- ... -->
</div>

There's a problem with our solution. Now, Screen Readers announce the errors, but is it easy to use?

Let's try to imagine we are trying to use the app without looking at it. We hear the announcement. Now what? Press Tab? This will get you to the reset button. Press Shift + Tab? We could, but that means we have to remember where they were in the form. It would be better if we could navigate through the errors, and when interacting with them, move focus to the input that had the error.

We can change our current solution in src/app/app.component.html like this:

<div
  class="form-errors"
  [ngClass]="{ active: submitted && errors }"
  aria-live="assertive"
>
  <ng-container *ngIf="submitted && errors">
    There were errors found in the form.

    <ul class="form-errors-list" *ngIf="errors">
      <li *ngIf="errors.firstName?.required">
        <a href="#first-name-control">First name is required</a>
      </li>
      <li *ngIf="errors.lastName?.required">
        <a href="#last-name-control">Last name is required</a>
      </li>
      <li *ngIf="errors.email?.required">
        <a href="#email-control">Email is required</a>
      </li>
      <li *ngIf="errors.email?.email">
        <a href="#email-control">Email has to be properly formatted</a>
      </li>
    </ul>
  </ng-container>
</div>

If you are wondering about the magic behind focusing an input with an anchor, you can use the hash strategy to link to items in the current page by using its ID. That's why all the inputs in the base form have unique ids.

But there's more. After we get the announcement, we still have to tab through until we get to the errors element. This could mean, in the worst case scenario, going through the whole page to get our hands on the errors links. We can improve this by making the errors element focusable but not tabbable. By using tabindex=-1, we cannot tab to the element, but we can force the focus using Javascript. If we want to focus the element from the component, we'll need to have a reference to it, thankfully we can use a template reference variable and the ViewChild decorator for this.

All we need to do now is go to src/app/app.component.ts and do this:

import { Component, ViewChild, ElementRef } from '@angular/core';
// ...

export class AppComponent {
  @ViewChild('errorsSection', { static: true }) errorsSection: ElementRef;
  // ...

  onSubmit() {
    // ...
    if (this.form.invalid) {
      //...
      this.errorsSection.nativeElement.focus();
    } else {
      this.errors = null;
    }
  }
}

And now, go to src/app/app.component.html, and do this:

<div
  class="form-errors"
  #errorsSection
  tabindex="-1"
  [ngClass]="{ active: submitted && errors }"
>
  <!-- ... -->
</div>

NOTE: The key reason for not binding the form errors directly in the template, is to make it easier for users with Screen Readers. When things change in real time, it's harder to keep track of what's going on. By creating another errors property, I can update only onSubmit. That way, it is easier to know what's going on.

Conclusion

After just a few minutes, we dramatically improved the user experience for Screen Reader users, and also for users that rely on their keyboards. I personally love the way I can navigate through the errors to reach the respective input, making it very clear which is the input with the error. I like putting the errors at the beginning of the form. That way, when I tab in the last error, I get to the first input instead of out of the form.

Here's a full working version of the code, in case you didn't follow along, and you want to see it in action.

This is why you should go Angular 9 today

Daniel Marin — Wed, 26 Feb 2020 21:04:02 +0000

I followed almost all of the events around the Angular 9 release. After reading the Angular 9 cheatsheet, reading the Angular next docs, and watching the official release party, I chose to write this article about why you should start using v9 today.

This isn't just a new release, the Angular Team did way more than that. We finally have Ivy, and from now on, it's the recommended option for view rendering. This was a big challenge for them, having so many changes and improvements could make Angular apps feel different, making it harder for developers to adapt. One of the top priorities was making sure the number of breaking changes were the least possible.

Before diving into Ivy and why it is so cool, we are gonna talk about how easy it is to update your Angular to v9.

Update has never been this easy

The Angular Team did their best to reduce the manual changes you have to do. There were new schematics created for ng update to automate the migrations for you.

In some cases, it's as simple as running ng update @angular/core @angular/cli, and you're done. If you want a more in depth, step by step guide, I recommend you to visit the Update Angular Site or you could also check out this Angular Update Guide by Brian Love.

If you came from AngularJS, you know how hard updates have been until now. I personally got stuck in AngularJS until Angular 5, just because I thought there were too many breaking changes. But now, it feels more approachable.

You'll need Typescript version 3.7.

What's up with Ivy?

Ivy is the new view rendering engine. If you are like me, you may be thinking, Wait, what?

I won't dive into it, but we can probably rephrase the claim above, for clarity, by saying Ivy is a new way to manage the templates and projections. I know that isn't much simpler. Luckily, you don't have to care.

Now, you may be scratching your head. As I said, the Angular Team focused on respecting the way Angular works now. They wanted to do this huge change without us noticing it.

The change is under the hood, and we have the same API. This means that there are no changes for you!

What I can tell you is why they did this incredible number of changes

Smaller bundle.
Better runtime performance.
Template type checking.

Having a smaller bundle is one incredibly valuable to users. We get an improved UX by responding quicker, but not only that, we also get an SEO boost by being able to serve users faster. By this, I don't mean that Ivy comes with something specific to boost your SEO, but smaller bundle helps with that. If you want to take your SEO score to the next level, you'll need to explore other options like SSG with Scully or SSR with Angular Universal.

Even though Ivy changes the way templates are rendered, your old DOM selection queries in your e2e tests won't be affected.

The improved runtime performance is just perfect because now it's possible to have AOT enabled even in dev mode. According to members of the Angular Team, this is one of the best things about this new update. I don't know how many times I've forgotten to build the application with AOT enabled before pushing my code, leading to errors down the pipeline that could've been captured.

In order to enhance runtime performance, a lot of things had to change. All querying decorators like ViewChild, ViewChildren, and so on, had several changes to make them more predictable. The team is currently discussing better ways to query, but again, without us noticing it.

Template Type-checking is a game changer. Now, Angular can help you make the templates type safe. This is a major improvement, because now you can have fewer tests, and rely more on the platform. If you want to enforce this in your project, do this in the tsconfig.json file:

{
  // your options,
  "angularCompilerOptions": {
    // your angular compiler options,
    "fullTemplateTypeCheck": true,
    "strictTemplates": true
  }
}

This way, Angular will tell you if you're breaking any typing inside a template at compilation time. But let's see it in action. If you have a component like this:

import { Component, Input } from "@angular/core";

@Component({
  selector: "app-sample",
  templateUrl: "./sample.component.html",
  styleUrls: ["./sample.component.scss"]
})
export class SampleComponent {
  @Input() number: number;
}

And you use it like this:

<app-sample [number]="'text'"></app-sample>

You'll get this error when compiling the application:

TS2322: Type 'string' is not assignable to type 'number'.

Very cool, right?

Working without NgModules is possible, even when compiling a single component, leading to faster unit tests. The Angular Team didn't remove the NgModules to avoid changing the way Angular currently works. They have no plans of stopping their support of NgModules any time soon, but there’s a chance that components and core building blocks will be preferred over modules.

This even makes it possible to access lazy loaded components in a simpler way. If you want to learn more about this, you definitely have to check out Angular 9: Lazy Loading Components by John Papa.

ViewChild now, by default, has { static: false }. Remember that you use static true if you want to access the ElementRef before change detection occurs (ngOnInit).

There’s a new version of TestBed, with the new compiler, that improved the entire pipeline. Time of execution can be reduced up to 40%. In a future release, we’ll be able to use AOT compiled components for unit testing. If you have already updated, feel free to share your statistics.

A few things were removed. Now you can't use Renderer, and you have to start using Renderer2. Thankfully, the ng update schematic takes care of this. The ngForm element selector has been removed, and now can only be called by using ng-form.

Thinking ahead of time

If you are making heavy use of entryComponents, you won't need to do it anymore thanks to Ivy. In v9, its deprecation was announced. Also, we can forget about TestBed.get, and start using TestBed.inject, which has the same behavior, but is type safe.

Ivy unlocks the possibility of making internationalization way better and easier to do, but it isn't there yet. We'll need to keep waiting for a more robust i18n integration into the Angular platform.

We should be moving from ts-lint to es-lint. Sadly, for the case of very large apps, it tends to be slower. Nevertheless, there are people currently working to make it better and faster.

I heard people saying that zone.js was about to die, but that's simply not true. Though it's not included as a part of the browser standard, we still need zone.js for the change detection.

What can you do to help?

Update today!
Create issues with reproduction
If you can help solve an issue, go ahead and join the discussion

References

Conclusion

The Angular Team put a lot of effort into this update, by not only including Ivy, but by also making the ng update schematic even better and easier to use. Now, it's our chance to help them. Let's start using Angular v9 today! Let's all create issues with reproducible repositories that can dramatically help speed up things.

Multiple Users using the same Form in Real Time. Nx, NestJs and Angular

Daniel Marin — Tue, 04 Feb 2020 21:07:00 +0000

If you don't have time to go through the tutorial, here's a final version of the code

In this article I wanted to explore something I've been asked to build several times for different use cases. With distributed and remote teams, real time cooperation is key for success. Whenever we hear about Real Time applications we always see the same example, a Chat. Although chats and cool and important, there's a simpler thing that can help teams maximize cooperation; Forms that can be edited by multiple users concurrently.

It seems challenging, and of course, depending on the use case it can be harder and more expensive. It can get expensive simply because it means more data being sent back and forward. If your application is running on a VPS or a dedicated server you may be able to do this without any extra expenses, but if you are doing serverless this means more money you'll spend at the end of the month.

In a traditional form implementation, every client has its own state and it sends a request only when the form is submitted. In this case, things are more complex, every time a client updates the form, all the other clients should receive this information. If you are planning to use this feature in apps with just a few users, its Okay, but if you are planning to have 1,000 users concurrently changing the form, you have to take into account that each change will send data to all the 1,000 users.

In this case I'm gonna focus on doing a very simple implementation to get you started, this is by no means a production ready application.

The Problem

Let's say you have multiple users that have to work together towards a goal, you want to reduce friction as much as possible. Having a mechanism to work on the same task together in real time can be really useful.

The Solution

There should be a service responsible for tracking the current state of the task and sending updates to all the connected clients. The Web Client that will be used by the clients, should display the connected clients and a form that can be changed by user interaction or by updates coming from the service.

Since there's a big chance of concurrency, we have to choose a strategy that helps us with that. I'm personally a fan of Redux, so I based my implementation on it but adjusted it according to my needs. Since this is a very small app, I used pure RxJs for my state management implementation. The actions that can occur are:

Init: It sets the initial state of the web client, its triggered when each client loads.
ClientConnected: Everytime a client connects to the service, all the clients receive an updated list of the currently connected clients.
Data: Whenever a client is connected, the service responds with the current form state.
PatchValue: When a client updates the form by directly interacting with it, it sends the changes to the service.
ValuePatched: When the service receives a change to the state, it broadcasts it to all the other clients.

For this sample the form data is very simple and it only consists of a title and description, both of type string.

Implementation

First thing is to choose the technologies we want to use. I'm a proud Angular Developer, so I choose to use Angular for the Web Client. Since NestJs is so cool, I decided to use it for the service responsible for synchronization. Finally since the Web Client and the service are going to be communicating in real time, Nx can be really helpful to reduce duplication and ensure the messages passing through are type safe using shared interfaces.

NOTE: For the Web Client you can use any JS framework or even plain Javascript. Same thing with the service, you can use Node or whatever you want as long as you have a Socket.IO implementation. I used Nx just because I like it but you can also skip that part.

We'll start by generating the Nx workspace.

Run the command npx create-nx-workspace@latest realtime-form
Choose angular-nest workspace in the prompt options
Type web-client as the Application name
Select your preferred stylesheet format (I always use SASS)
Go to the realtime-form directory

One of the cool things about using Nx with NestJs and Angular is the possibility to share things between them. Let's take advantage of it and create the FormData interface and ActionTypes enum.

Go to /libs/api-interfaces/src/lib/api-interfaces.ts and change its content to this:



export enum ActionTypes {
  Data = '[Socket] Data',
  ClientConnected = '[Socket] Client Connected',
  ValuePatched = '[Socket] Value Patched',
  PatchValue = '[Form] Patch Value',
  Init = '[Init] Init'
}

export interface FormData {
  title: string;
  description: string;
}

Now we are able to use them from the service and the web client, since its shared it works as a contract between the two of them.

We're going to start with the service:

Run npm i --save @nestjs/websockets @nestjs/platform-socket.io
Run npm i --save-dev @types/socket.io
Go to the directory /apps/api/src/app
Create a new directory called events and move to that directory
Create a file named events.gateway.ts
Create a file named events.module.ts

And next you just have to write the new file's content.

Go to /apps/api/src/app/events/events.gateway.ts:



import {
  SubscribeMessage,
  WebSocketGateway,
  WebSocketServer
} from '@nestjs/websockets';
import { Server, Socket } from 'socket.io';
import { Logger } from '@nestjs/common';

import { ActionTypes, FormData } from '@realtime-form/api-interfaces';

@WebSocketGateway()
export class EventsGateway {
  connectedClients = [];
  data = {};
  @WebSocketServer()
  server: Server;
  private logger: Logger = new Logger('EventsGateway');

  handleConnection(client: Socket) {
    this.connectedClients = [...this.connectedClients, client.id];
    this.logger.log(
      `Client connected: ${client.id} - ${this.connectedClients.length} connected clients.`
    );
    this.server.emit(ActionTypes.ClientConnected, this.connectedClients);
    client.emit(ActionTypes.Data, this.data);
  }

  handleDisconnect(client: Socket) {
    this.connectedClients = this.connectedClients.filter(
      connectedClient => connectedClient !== client.id
    );
    this.logger.log(
      `Client disconnected: ${client.id} - ${this.connectedClients.length} connected clients.`
    );
    this.server.emit(ActionTypes.ClientConnected, this.connectedClients);
  }

  @SubscribeMessage(ActionTypes.PatchValue)
  patchValue(client: Socket, payload: Partial<FormData>) {
    this.data = { ...this.data, ...payload };
    this.logger.log(`Patch value: ${JSON.stringify(payload)}.`);
    client.broadcast.emit(ActionTypes.ValuePatched, payload);
  }
}

If you are scratching your head with that code snippet, don't worry, we are trusting NestJs to do all the heavy lifting. You can think of each method as the response to an event; connection, disconnection and patch value.

Connection: Update the list of connected clients, log to the service the event occurred, emit the new connectedClients list to all the currently connected clients and emit to the client the current state of the form.
Disconnection: Update the list of connected clients, log to the service the event occurred, emit the new connectedClients list to all the currently connected clients.
PatchValue: Update the current state of the form, log to the service the event occurred, broadcast the new state to all the currently connected clients.

NOTE: The difference between this.server.emit and client.broadcast.emit, is that the first sends the message to all the clients while the second sends the message to all BUT the sender.

Now lets update the /apps/api/src/app/events/events.module.ts file:



import { Module } from '@nestjs/common';
import { EventsGateway } from './events.gateway';

@Module({
  providers: [EventsGateway]
})
export class EventsModule {}

And the /apps/api/src/app/app.module.ts file:



import { Module } from '@nestjs/common';
import { EventsModule } from './events/events.module';

@Module({
  imports: [EventsModule]
})
export class AppModule {}

I also removed the AppController and AppService files. And also updated the apps/api/src/main.ts file with this:



import { NestFactory } from '@nestjs/core';
import { AppModule } from './app/app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  const port = 3000;
  await app.listen(port, () => {
    console.log('Listening at http://localhost:' + port);
  });
}

bootstrap();

Now it's time to get started with the web client, go to apps/web-client/src/app/app.component.html:



<header>
  <h1>Realtime Form</h1>
</header>

<main>
  <form [formGroup]="form">
    <fieldset>
      <label class="form-control">
        <span>Title: </span>
        <input formControlName="title" />
      </label>

      <label class="form-control">
        <span>Description: </span>
        <textarea formControlName="description" rows="5"></textarea>
      </label>
    </fieldset>
  </form>

  <ng-container *ngIf="connectedClients$ | async as clients">
    <h2>Clients ({{ clients.length }})</h2>
    <ul>
      <li *ngFor="let client of clients">{{ client }}</li>
    </ul>
  </ng-container>
</main>

Just to make sure it looks just like what I showed at the beginning, Go to /apps/web-client/src/app/app.component.scss and replace its content with this:



form {
  width: 100%;
  padding: 0.5rem;
  max-width: 600px;

  .form-control {
    display: flex;
    margin-bottom: 1rem;

    & > span {
      flex-basis: 20%;
    }

    & > input,
    & > textarea {
      flex-grow: 1;
    }
  }
}

Install the Socket IO package for Angular by using the command npm install --save ngx-socket-io

Don't forget to inject ReactiveFormsModule and SocketIoModule in the AppModule of the Web Client. Go to /apps/web-client/src/app/app.module.ts:



import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { ReactiveFormsModule } from '@angular/forms';

import { AppComponent } from './app.component';

import { SocketIoModule, SocketIoConfig } from 'ngx-socket-io';

const config: SocketIoConfig = {
  url: 'http://192.168.1.2:3000',
  options: {}
};

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, ReactiveFormsModule, SocketIoModule.forRoot(config)],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {}

Next go to apps/web-client/src/app/app.component.ts:



import { Component, OnInit } from '@angular/core';
import { BehaviorSubject, merge } from 'rxjs';
import { scan, map } from 'rxjs/operators';
import { FormBuilder } from '@angular/forms';
import { Socket } from 'ngx-socket-io';

import { ActionTypes, FormData } from '@realtime-form/api-interfaces';
import { State, reducer } from './core/state';
import {
  ClientConnected,
  Data,
  ValuePatched,
  Action,
  Init
} from './core/actions';
import {
  getPatchValueEffect,
  getValuePatchedEffect,
  getFormChangesEffect
} from './core/effects';

@Component({
  selector: 'realtime-form-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent implements OnInit {
  // 1: Action dispatcher
  private dispatcher = new BehaviorSubject<Action>(new Init());
  actions$ = this.dispatcher.asObservable();
  // 2: State stream
  store$ = this.actions$.pipe(
    scan((state: State, action: Action) => reducer(state, action))
  );
  // 3: Define all the selectors
  connectedClients$ = this.store$.pipe(
    map((state: State) => state.connectedClients)
  );
  data$ = this.store$.pipe(map((state: State) => state.data));
  title$ = this.data$.pipe(map((state: Partial<FormData>) => state.title));
  description$ = this.data$.pipe(
    map((state: Partial<FormData>) => state.description)
  );

  // 4: Initialize the form
  form = this.fb.group({
    title: [''],
    description: ['']
  });

  constructor(private socket: Socket, private fb: FormBuilder) {}

  ngOnInit() {
    // 5: Connect to all the socket events
    this.socket.on(ActionTypes.ClientConnected, (payload: string[]) => {
      this.dispatcher.next(new ClientConnected(payload));
    });

    this.socket.on(ActionTypes.Data, (payload: Partial<FormData>) => {
      this.dispatcher.next(new Data(payload));
    });

    this.socket.on(ActionTypes.ValuePatched, (payload: Partial<FormData>) => {
      this.dispatcher.next(new ValuePatched(payload));
    });

    // 6: Subscribe to all the effects
    merge(
      getPatchValueEffect(this.socket, this.actions$),
      getValuePatchedEffect(this.form, this.actions$),
      getFormChangesEffect(this.form, this.dispatcher)
    ).subscribe();
  }
}

Let's go through each of the things I just did right there:

1: Action dispatcher

I start by creating an action dispatcher and an observable from the stream of actions going through, I use RxJs BehaviorSubject with an initial action that looks like this:



// apps/web-client/src/app/core/actions/init.action.ts
import { ActionTypes } from '@realtime-form/api-interfaces';

export class Init {
  type = ActionTypes.Init;
  payload = null;
}

I also created an Action type inside a barrel import to make it easier to use:



// apps/web-client/src/app/core/actions/index.ts
import { Init } from './init.action';

export type Action = Init;
export { Init };

2: State stream

By using the scan operator we can take every emission of an observable, keep an internal state that gets updated by the return of its callback. With a reducer function that takes a state and action, and returns a state in an inmutable way we can have a stream of the current state in a safer way.

I created a reducer that looks like this:



// apps/web-client/src/app/core/state/state.reducer.ts
import { ActionTypes } from '@realtime-form/api-interfaces';
import { State } from './state.interface';
import { Action } from '../actions';
import { initialState } from './initial-state.const';

export const reducer = (state: State, action: Action): State => {
  switch (action.type) {
    case ActionTypes.Init:
      return { ...initialState };
    case ActionTypes.ClientConnected:
      return {
        ...state,
        connectedClients: action.payload
      };
    case ActionTypes.Data:
      return { ...state, data: action.payload };
    case ActionTypes.PatchValue:
      return { ...state, data: { ...state.data, ...action.payload } };
    default:
      return { ...state };
  }
};

A brief description of the actions:

Init: Set the state to the initialState const.
ClientConnected: Update the connectedClients in the state with the updated list.
Data: Set the data of the state to the value returned upon connection.
PatchValue: Patch the data with the changes from the payload.

The State interface looks like this:



// apps/web-client/src/app/core/state/state.interface.ts
import { FormData } from '@realtime-form/api-interfaces';

export interface State {
  connectedClients: string[];
  data: Partial<FormData>;
}

The initialState const looks like this:



// apps/web-client/src/app/core/state/initial-state.const.ts
import { State } from './state.interface';

export const initialState = {
  connectedClients: [],
  data: {}
} as State;

I also created a barrel import here, I kinda love them.



export { initialState } from './initial-state.const';
export { State } from './state.interface';
export { reducer } from './state.reducer';

3: Define all the selectors

In order to make it easy to access the values in the store, I created an extra set of observables that are basically mapping the state to sub states, it works like a projection.

4: Initialize the form

I just created a very VERY simple form using ReactiveForms, if you want to learn more about them you can take a look at my ReactiveForms series.

5: Connect to all the socket events

As we just saw, there are three events that can be emitted by our service, in this step we are listening to those events and responding accordingly. To make it cleaner I created some action creator classes.



// apps/web-client/src/app/core/actions/client-connected.action.ts
import { ActionTypes } from '@realtime-form/api-interfaces';

export class ClientConnected {
  type = ActionTypes.ClientConnected;

  constructor(public payload: string[]) {}
}



// apps/web-client/src/app/core/actions/data.action.ts
import { ActionTypes, FormData } from '@realtime-form/api-interfaces';

export class Data {
  type = ActionTypes.Data;

  constructor(public payload: Partial<FormData>) {}
}



// apps/web-client/src/app/core/actions/value-patched.action.ts
import { ActionTypes, FormData } from '@realtime-form/api-interfaces';

export class ValuePatched {
  type = ActionTypes.ValuePatched;

  constructor(public payload: Partial<FormData>) {}
}

And do not forget to update the barrel import



// apps/web-client/src/app/core/actions/index.ts
import { Init } from './init.action';
import { Data } from './data.action';
import { ClientConnected } from './client-connected.action';
import { ValuePatched } from './value-patched.action';

export type Action = Init | Data | ClientConnected | ValuePatched;
export { Init, Data, ClientConnected, ValuePatched };

6: Subscribe to all the effects

The only thing left are the side effects. Let's go through each:

When the user updates the form, the changes have to be broadcasted to all the other clients, for this we need to emit to the service. We can achieve that doing this:



// apps/web-client/src/app/core/effects/patch-value.effect.ts
import { Action } from '../actions';
import { Observable, asyncScheduler } from 'rxjs';
import { observeOn, filter, tap } from 'rxjs/operators';
import { ActionTypes } from '@realtime-form/api-interfaces';
import { Socket } from 'ngx-socket-io';

export const getPatchValueEffect = (
  socket: Socket,
  actions: Observable<Action>
) => {
  return actions.pipe(
    observeOn(asyncScheduler),
    filter(action => action.type === ActionTypes.PatchValue),
    tap(action => socket.emit(ActionTypes.PatchValue, action.payload))
  );
};

NOTE: I use the asyncScheduler only because I want to ensure that the reducer is always first.

When the service emits that the value has changed or it sends the current form state upon connection, we have to respond accordingly. We are already mapping the socket event to an action in both cases, now we just need an effect that updates the form locally for each client.



// apps/web-client/src/app/core/effects/value-patched.effect.ts
import { Action } from '../actions';
import { Observable, asyncScheduler } from 'rxjs';
import { observeOn, filter, tap } from 'rxjs/operators';
import { ActionTypes } from '@realtime-form/api-interfaces';
import { FormGroup } from '@angular/forms';

export const getValuePatchedEffect = (
  form: FormGroup,
  actions: Observable<Action>
) => {
  return actions.pipe(
    observeOn(asyncScheduler),
    filter(
      action =>
        action.type === ActionTypes.ValuePatched ||
        action.type === ActionTypes.Data
    ),
    tap(action => form.patchValue(action.payload, { emitEvent: false }))
  );
};

And finally, whenever a client interacts with the form we want to emit a message to the service that will propagate this change across all the connected clients.



// apps/web-client/src/app/core/effects/form-changes.effect.ts
import { Action, PatchValue } from '../actions';
import { merge, BehaviorSubject } from 'rxjs';
import { debounceTime, map, tap } from 'rxjs/operators';
import { FormGroup } from '@angular/forms';
import { FormData } from '@realtime-form/api-interfaces';

export const getFormChangesEffect = (
  form: FormGroup,
  dispatcher: BehaviorSubject<Action>
) => {
  const title$ = form
    .get('title')
    .valueChanges.pipe(map((title: string) => ({ title })));

  const description$ = form
    .get('description')
    .valueChanges.pipe(map((description: string) => ({ description })));

  return merge(title$, description$).pipe(
    debounceTime(300),
    tap((payload: Partial<FormData>) =>
      dispatcher.next(new PatchValue(payload))
    )
  );
};

You probably noticed a new PatchValue action, so let's create it:



// apps/web-client/src/app/core/actions/patch-value.action.ts
import { ActionTypes, FormData } from '@realtime-form/api-interfaces';

export class PatchValue {
  type = ActionTypes.PatchValue;

  constructor(public payload: Partial<FormData>) {}
}

And also update the barrel import:



// apps/web-client/src/app/core/actions/index.ts
import { Init } from './init.action';
import { Data } from './data.action';
import { ClientConnected } from './client-connected.action';
import { ValuePatched } from './value-patched.action';
import { PatchValue } from './patch-value.action';

export type Action = Init | Data | ClientConnected | ValuePatched | PatchValue;
export { Init, Data, ClientConnected, ValuePatched, PatchValue };

Since I love barrel imports I created another one for the effects:



// apps/web-client/src/app/core/effects/index.ts
export { getFormChangesEffect } from './form-changes.effect';
export { getPatchValueEffect } from './patch-value.effect';
export { getValuePatchedEffect } from './value-patched.effect';

Now you just have to run the services, each in a different terminal while in the main directory of the application:

Run the command ng serve
Run the command ng serve api

Conclusion

And that was it. The first time I had to do this was really challenging, so I tried to be as explicit as I could with each step, hoping you don't get lost. As I mentioned before this is not a production ready implementation but a really good point of start. Now that you know how to solve this problem, don't forget that sometimes the solution can be worse and in some cases this could increase infrastructure costs.

Icons made by itim2101 from Flaticon

Make It Accessible: Headings in Angular

Daniel Marin — Tue, 28 Jan 2020 22:26:31 +0000

Intro

Everyday, accessibility gets more awareness, and yet a few weeks back, I was a total ignorant about it. I was assigned to a client project with the intent to improve their overall accessibility, and to comply with WCAG 2.1's category AA. This was an incredible challenge, and I had to learn a lot in order to effectively meet the deadline.

My intent, with this article, as well as all the others from Make it accessible, is to walk you through the challenges I faced. This project was in Angular, so I'll be going through accessibility from an Angular Developer's point of view. That being said, all the knowledge found here can be easily applied to other Javascript frameworks, and I learned that the best way to improve accessibility is to use semantic HTML.

For this article, I decided to focus on Headings, since they are one of the key mechanisms that visually impaired users rely on. At the beginning of my a11y journey, I had to make a first diagnosis of the status of the application when used with a screen reader. After installing NVDA, I was able to go through the main flow of it blindfolded, since I already knew how the application behaved.

Yes, I was blindfolded while in a call with the project leader. It was a bold move, even though it worked out. It was a false positive, because if I didn't have first hand knowledge of the app, it would have been impossible to use effectively. After a long call, we decided that in order for us to continue, we needed to know how do blind users actually use the screen readers.

After spending sometime online, I found some really good resources to help developers understand how blind people use applications. At the end of the article, I have the links to the videos. It turns out that for these users, the headings are key. Before we continue, let's define a heading.

Headings

HTML defines six levels of headings. A heading element implies all the font changes, paragraph breaks before and after, and any white space necessary to render the heading. The heading elements are H1, H2, H3, H4, H5, and H6 with H1 being the highest (or most important) level and H6 the least.
w3c Organization.

If you have ever done any HTML code, you probably have seen them already. They can be used in HTML like this <h1>Main heading</h1>. I used to think that they were just for aesthetic purposes- that their job was just to show text with a different format to attract the attention of the users.

Although I was partly right, it wasn't its only purpose. If you take a look at its definition from the accessibility point of view, you'll find some differences.

Headings communicate the organization of the content on the page. Web browsers, plug-ins, and assistive technologies can use them to provide in-page navigation.
w3c Organization - WAI ARIA.

You may now have more questions than answers, but that's okay, because we are going to get there. It turns out that headings have two main roles: the one I already mentioned, and secondly, allowing AT users in-page navigation.

Screen Readers

In the previous section, I mentioned the fact that headings provide AT users with in-page navigation. Let's dive into that a bit. It turns out, that when blind users are navigating, they rely on screen reader functionalities, and there's one in every major product that allows users to see all headings, and jump directly to them.

I started wondering, is this really how people use this? It made no sense to me. But after searching, a lot I found videos of blind users using the common sites we all know: Twitter, Gmail, etc... And guess what! It's very common to see users rely on the navigation tool provided in their screen reader of choice.

I decided it was time to give my project a second chance, and use the navigation tool from NVDA. But it turns out that someone decided that <span> tags were more appropriate for headings, and when I opened it, the heading list was empty. Screen readers cannot infer that by themselves. That's why you have to use HTML.

Believe it or not, here I go again: Use semantic HTML.

By doing so, assistive technology users will be capable of using your apps- or at least reading and understanding them.

NOTE: Blind users know how to use screen readers. They tend to create a mental map of the application by going through the headings. If you don't provide the basic tools, your app will not be accessible.

Proper Headings

Imagine that you can't rely on colors, sizes, borders, etc... To denote relationships between the parts of your app. You may think that will make the apps boring, but it's the only way to make your app usable by visually impaired people. They see apps in a very different way, we have to give them alternatives to know the relationships between the elements. But this elemental relationship is a whole topic by itself. I just want to mention it.

Headings are a way to denote relationships or even better, groupings. I like to think of it as trees.

Well, anyway. Imagine the first <h1> is the root node of our application, just like in trees, there's a single root (node). All the consequent <h2> are treated as children of the root or <h1>.

Now comes the tricky part, suppose you are writing content right below one of the <h2>'s, and you want to create a new heading. There are two possible scenarios:

You want the heading to be a child of the root.
Solution: Use <h2>.
You want the heading to be a child of one of the <h2>.
Solution: Use <h3>.

By now, you should understand the idea. But there's one new problem: What about reusable components?

Reusable Components

After realizing that we had no headings, I rushed to the project leader and told him about it. We agreed that it was one of our main concerns now, and that we had to do something.

Some days later, I noticed that, for same cases, it was straightforward. But suddenly, I encountered a roadblock. We had reusable components being used at different hierarchical levels, and it was impossible to just pick one heading level.

NOTE: If you design your application having accessibility as a first class citizen, you can easily avoid this situation by creating the right components from the beginning.

I wasn't authorized to create more components because that meant making maintainability harder. So, I had a new task ahead- creating a component that could, by itself, know which heading to use according to the place where it is placed in the DOM.

I highly encourage you to avoid this, and instead, redesign from the ground up, with accessibility in mind for all the design decisions.

Solution

I started by creating a simple component I named HeadingComponent that looks like this.

@Component({
  selector: 'app-heading',
  template: `
    <div
      appHeading
      [headingId]="headingId"
      [parentHeadingId]="parentHeadingId"
      [text]="text"
    ></div>
  `
})
export class HeadingComponent {
  @Input() headingId: string;
  @Input() parentHeadingId: string;
  @Input() text: string;
}

The Heading Component can take input values:

HeadingId: Identifier that allows querying the DOM to find a specific heading.
ParentHeadingId: Identifier that allows querying the DOM to find a specific heading, it's the headingId of the parent heading.
Text: The text content that will be displayed inside the heading tag.

As you can see, I used an inline template because we only use a single HTML element. I created this component because I didn't want users to attach it directly to the span. In my opinion, it looks more self explanatory this way.

In order to do DOM manipulations, Angular Docs state that you should use directives. So let's create a directive that introduces the heading inside of our component with the right hierarchy.

import { Directive, ElementRef, AfterViewInit, Input } from '@angular/core';

@Directive({
  selector: '[appHeading]'
})
export class HeadingDirective implements AfterViewInit {
  @Input() headingId: string;
  @Input() text: string;
  @Input() parentHeadingId: string;

  constructor(private el: ElementRef) {}

  ngAfterViewInit() {
    this.el.nativeElement.innerHTML = this.wrapText(
      this.headingId || 'root',
      this.getTag(this.getHierarchy(this.headingId, this.parentHeadingId)),
      this.text
    );
  }

  private getHierarchy(headingId: string, parentHeadingId: string) {
    if (!headingId) {
      return 1;
    } else if (!parentHeadingId) {
      return 2;
    } else {
      const parentHeading = document.querySelector(`#${parentHeadingId}`);
      const parentHierarchy = parseInt(parentHeading.tagName[1], 10);
      return parentHierarchy === 6 ? 6 : parentHierarchy + 1;
    }
  }

  private getTag(hierarchy: number) {
    return `h${hierarchy}`;
  }

  private wrapText(id: string, tag: string, text: string) {
    return `<${tag} id=${id}>${text}</${tag}>`;
  }
}

The Heading Directive has multiple methods to get the job done:

getTag: Given a hierarchy it returns the proper heading tag.
wrapText: Given an id, tag and text, it creates the html tag for the heading.
getHierarchy: Given a headingId and parentId, it infers the hierarchy of the current element.

And that's it. If you want to go ahead and take a look at this working, you can take a look at this repository to see it in action. In their repo there are multiple samples showing how it works.

Conclusion

Use Semantic HTML

This is the third time you have read that in this article. When you start trying to make applications accessible, you quickly realize that HTML5 is your best friend. In this case, we focused on headings, but this idea applies to almost all the native elements. If you asked me how do I make my application accessible, I would ask, are you sure you are using the right semantic HTML?

This Dot Inc. is a consulting company which contains two branches : the media stream, and labs stream. This Dot Media is the portion responsible for keeping developers up to date with advancements in the web platform. This Dot Labs provides teams with web platform expertise, using methods such as mentoring and training.

5 tips to make your Angular application more accessible

Daniel Marin — Tue, 28 Jan 2020 22:02:45 +0000

This article's intent is to give the reader a few tips to follow when building accessible Angular applications. This is by no means an exhaustive list, or a cheatsheet of all the things you have to do in order to be WCAG compliant. I'm not going to talk about A, AA, Section 508, or any of that. The idea is to give you the basic ideas so you can start from there.

I wanted to make it fun, so I decided to create an Angular app that has multiple accessibility problems that we will identify together. For each of those problems, there's going to be a solution. These aren't production-ready solutions, but they are a good starting point.

I created this repository for the article, which has multiple branches. Each tip has two branches- one for the problem, and one for the solution. Each of those branches can be easily configured locally by following these steps:

git clone the repository
cd to the directory with your command line tool
run the command npm install
run the command npm run start

The application will run on the port 4200 , and you can access it with the browser of choice.

#1: Hide elements from the DOM using ngIf

Angular is here to help us improve the developer experience. It provides us with multiple features that make our lives easier, but sometimes, we want to feel smarter and try to do things on our own. If you want an example of the problem, access this branch with the first tip problem.

One good example of this is the ngIf directive. I've seen projects where they prefer to use something like this in their styles:

.hide {
  width: 0;
  height: 0;
  opacity: 0;
}

In combination with this in the template:

<div [ngClass]="{ 'hide': hide }">
  <h2>SAMPLE</div>
  <button>Click me!</button>
</div>

Although that will hide the element, it's still there. Any focusable element inside a hidden element with the above technique will still be focusable even if its not visible. By that, I mean we can focus the button without it being visible.

This issue can be easily solved using the ngIf directive instead of creating a new class, and conditionally adding it to the element. It can be used like this:

<div *ngIf="!hide">
  <h2>SAMPLE</div>
  <button>Click me!</button>
</div>

In case you are wondering how to solve it for the branch I gave you, I have provided access to the solution of the first tip.

#2: Use semantic HTML

If you have been following my other a11y articles, you are probably aware of this, but I still have to make sure to remind everybody. So, it turns out that Html actually helps us a lot. If we use the semantic Html, the browser can properly provide us with out-of-the-box functionality that makes it way easier for you. In case you want an example of the problem, access this branch with the second tip problem.

If you run it locally, you will notice that it looks exactly the same, but if you try to tab through the elements, you'll see that the buttons are not focusable. That can be fixed by doing:

<div tabindex="1">Im focusable</div>

But buttons also provide us with keyboard support, and they can be activated through the keyboard by typing either ENTER or SPACE. This can also be achieved by creating a custom directive that listens to keyUp events, and activates the button that's currently focused. As you can see, a lot of work can be easily achieved by doing this instead:

<button>Im focusable</button>

BOOM ---> We achieved the same with almost no code.

If you are wondering what this has to with Angular, it doesn't, at least directly. The issue is that, since Angular allows you to create components easily, we tend to think that we'd rather build our own button component. My advice is to extend the button element instead.

In case you are wondering how to solve it for the branch I gave you, you can access the solution of the second tip.

#3: Headings are important

I even created an article about this. When I started my journey into a11y, I realized how important headings are for screen reader users. If you are interested in learning more about this topic, you can read my article Headings in Angular.

Headings are similar to buttons in this respect. Given how easy its to create a custom component, sometimes instead of using a heading element (h1, h2, ...) we create a span, give to it some custom styles, and use it as a title.

Given the simplicity of this tip, and that there's a whole article already for it, im gonna skip the creation of the branches.

#4: Focus flow has to be logical

I'm a fan of using CSS as much as I can to help me during the development process of any user interface. But sometimes, that can be a little dangerous; for example, when you use flex and you decide to use flex-direction: column-reverse or flex-direction: row-reverse, it seems nice to be able to change the order in which items are laid out from CSS, but it has an incredible weakness.

What happens if the elements inside the flex layout contain focusable elements?

If you said that the focus will be affected, you were totally right. If you want to see that in action, you can access this branch with the forth tip problem.

From the code, you'll see that the article's focus order is in the opposite direction, now it goes from right to left. That's clearly making it harder for the majority of the users, so we have to avoid using the reversed directions from flex and instead, set the order programatically inside the component by using Typescript. That way, you can rely on Angular's ngFor to place the elements without messing up the focus order.

If you are wondering what I mean by that, this commit diff of the forth tip solution will clear things up.

#5: You can trust CSS

Maybe, after the last tip, you are a bit skeptical, thinking, Okay I'll never trust CSS again. But it was just to give you some awareness. CSS is actually very helpful. Let's say that you want to display a string as Upper Case in your template. If you are a seasoned Angular developer, you'll say, "That's easy! Let's use a pipe."

Even though it works, its not what you want. When screen readers find strings in Upper Case, it spells it to the user, making it hard to understand, so in this case, you better use text-transform: uppercase that will make it uppercase only for visual purposes.

Conclusion

This is not an exhaustive list of all the things you have to do to be WCAG 2.1 AA compliant but a fun article to read to give developers some insights about my latest research. If you have more tips to add to this list, just send a comment, and will add it. I would love if we, as Angular Developer, can have a list of tips to ensure our apps come out more accessible.

Make it Accessible: No More Walls of Text in Angular

Daniel Marin — Mon, 27 Jan 2020 21:40:34 +0000

In this article, we are going to cover text rendering using HTML, and how easy it is to create blocks of non accessible text with Angular. This is part of a series that I'm continuously writing to share the things I've been learning about accessibility.

At my last talk about a11y in Angular, I met a few colleagues, and they asked me, "how do you deal with a text that has multiple paragraphs?" My first thought was, well, multiple <p> tags, one for each paragraph. But let's face it, how common it is to have the static text in an Angular app? How probable is it that you will know the number of required paragraphs beforehand?

I ended up saying, "You know what? I'm gonna do this at home!" and, VOILA! This post was born. Let's get started by analyzing the problem.

The Problem

Content in an Angular Application usually comes from some kind of service, and for that reason, we are almost never sure of how long the content is, and how many paragraphs it has. I used to do something like <p>{{someTextContent}}</p> but this means we always have a single paragraph, that leads us to a single wall of text making it impossible for screen reader users to navigate through paragraphs.

We could say that the problem is that there's no built-in mechanism to display the content divided by the paragraph in an Angular Template.

The Hypothesis

First thing to do is to create a shared component that will get the text content, split it by the line breaks (\n) and wrap each entry in the resulting array of paragraphs with <p> tag using the ngFor directive.

If we are rendering the <p> tags inside a component, Angular's view encapsulation will prohibit us from customizing them. We'll need to have some sort of mechanism for dynamically attaching styles to our <p> tags. For this we can use the ngTemplateOutlet directive.

The Implementation

In order to visualize the problem and to proof the hypothesis I wrote a super small app that displays the same block of text inside 2 different articles. We have to end up with one having default styling and another one having custom styles. The text we'll use for testing consists of 4 paragraphs with a placeholder data, after running the app you'll see that all paragraphs get concatenated.

We'll start by creating the TextComponent that will transform the raw text into actual paragraphs. I created a repository and it has a branch with the base state of the project, go ahead a clone that branch so we can do this together.

1. The Text Component

First we need to generate the component, as usual I'll let Angular CLI do it for me. You can do that by following these steps:

Go to project's directory
Execute ng generate component --name=shared/components/text --export

That easily, you have the new component. We could create a SharedModule, and declare the component there, but I wanted to keep it short and focused on the actual problem - making better texts.

Go to the src/app/shared/components/text/text.component.ts file and change it to this:

import { Component, Input } from '@angular/core';
import { BehaviorSubject } from 'rxjs';
import { map } from 'rxjs/operators';

@Component({
  selector: 'app-text',
  templateUrl: './text.component.html',
  styleUrls: ['./text.component.scss']
})
export class TextComponent {
  private text$ = new BehaviorSubject('');

  // Observable that emits a text content split
  // by paragraph.
  paragraphs$ = this.text$.asObservable().pipe(
    map((content: string) =>
      content
        .split('\n')
        .map((line: string) => line.trim())
        .filter((line: string) => line)
    )
  );

  // Input that receives the content, and emits it to the
  // Subject every time it changes.
  @Input() set innerContent(text: string) {
    this.text$.next(text);
  }
}

Now we have to make sure we render the paragraphs properly by using a combination of the ngFor directive, and the async pipe. Go to the src/app/shared/components/text/text.component.html and do this:

<p *ngFor="let paragraph of paragraphs$ | async">{{ paragraph }}</p>

With that in place, it's just a matter of using our new component! Go to the src/app/app.component.html, and do this:

<header>
  <h1>Accessible Text</h1>
</header>

<main>
  <article class="card">
    <h2>Simple text</h2>
    <app-text [innerContent]="simpleText"></app-text>
  </article>

  <article class="card">
    <h2>Custom Text</h2>
    <app-text [innerContent]="simpleText"></app-text>
  </article>
</main>

2. It's time for customization

Now that our text is divided into paragraphs, someone could say we've got what we wanted. But if you are like me, then you probably want more power over this. How can we make that more customizable? The answer is ... DRUMS ... - ngTemplateOutlet directive!

This can get tricky, I'm not going into details about ngTemplateOutlet, if you think that the article is about it would be useful - just drop a comment below.

Being extremely brief, what ngTemplateOutlet allows you is to attach a TemplateRef to an element and give you the mechanism to provide it a context variable. In our case we'll add the <ng-template> inside the TextComponent, then we can access it using the ContentChild decorator.

Let's start by creating our first custom <p>. I want to do something fancy, so I'm gonna split the card content into two columns, and will make the first letter of the first paragraph larger and change its style. That means we will need something like this in our template:

<p class="paragraph" [ngClass]="{ first: first }">
  {{ paragraph }}
</p>

Accompanied by some styles:

.paragraph {
  background-color: #222233;
  color: #aaccff;
  margin: 0;
  margin-bottom: 2rem;
  text-align: justify;
  text-indent: 2rem;
  line-height: 2;

  &.first {
    &::first-letter {
      font-size: 200%;
      font-family: 'Times New Roman', Times, serif;
      color: #bbddff;
    }
  }
}

We want to use this new element in our text, but if we do this directly in the TextComponent, all the instances are going to be affected, we could make the .paragraph class conditional and that would work but what if we want another style? We don't want to create another class that will also be conditional.

At this point we could pass the styles to the component as an @Input property, but what about the ::first-letter pseudo-element? We cannot assign it using inline style, nor with the ngStyle directive.

We somehow need to be able to give the template to the TextComponent that will be used to render each paragraph. That way, each paragraph can have custom paragraphs. One thing to have in mind is that I still want to provide a clean <p> tag as a default behavior.

Let's start by modifying the way we use the TextComponent in the AppComponent, so go ahead and change src/app/app.component.html:

<main>
  <!-- ... -->
  <article class="card custom">
    <h2 class="custom__title">Custom Text</h2>
    <app-text [innerContent]="simpleText">
      <ng-template #paragraphTemplate let-ctx>
        <p class="custom__paragraph" [ngClass]="{ first: ctx.first }">
          {{ ctx.paragraph }}
        </p>
      </ng-template>
    </app-text>
  </article>
  <!-- ... -->
</main>

The actual change was that we added this to the content of the TextComponent:

<ng-template #paragraphTemplate let-ctx>
  <p class="custom__paragraph" [ngClass]="{ first: ctx.first }">
    {{ ctx.paragraph }}
  </p>
</ng-template>

Here, I'm creating a new template - you can hydrate the template with an information through the let-ctx attribute. Note that the ctx part is up to you, I just like using that name. When we use this template with the ngTemplateOutlet, we are able to dynamically assign the value to ctx.

Also, I've included the paragraph styles and some customizations into the .custom class in src/app/app.component.scss:

.custom {
  font-family: Verdana, Geneva, Tahoma, sans-serif;
  background-color: #111122;
  color: #cceeff;
  column-count: 2;
  column-gap: 40px;
  column-rule-style: solid;
  column-rule-color: #cceeff;

  &__title {
    column-span: all;
    text-align: center;
  }

  &__paragraph {
    background-color: #222233;
    color: #aaccff;
    margin: 0;
    margin-bottom: 2rem;
    text-align: justify;
    text-indent: 2rem;
    line-height: 2;

    &.first {
      &::first-letter {
        font-size: 200%;
        font-family: 'Times New Roman', Times, serif;
        color: #bbddff;
      }
    }
  }
}

If you try it right now, you'll notice that nothing has changed, and the styles are not being applied. We need to give the TextComponent the ability to access the template inside its content via paragraphTemplate reference variable, and then using it with the ngTemplateOutlet directive.

We'll start with the src/app/shared/components/text/text.component.ts:

import { /* ... */ ContentChild, TemplateRef } from '@angular/core';

// ...
export class TextComponent {
  @ContentChild('paragraphTemplate', { static: true })
  paragraphTemplateRef: TemplateRef<any>;
  // ...
}

To access a template that's part of the component's content, you can use the ContentChild decorator. It will populate paragraphTemplate variable with the reference to the actual template.

Now that we have all in place, it's time to use it. Go to src/app/shared/components/text/text.component.html:

<!-- Default template, in case it wasn't provided -->
<ng-template #defaultParagraphTemplate let-ctx>
  <p>{{ ctx.paragraph }}</p>
</ng-template>

<!-- The actual rendering of the paragraphs -->
<ng-container
  *ngFor="let paragraph of paragraphs$ | async; let first = first"
  [ngTemplateOutlet]="paragraphTemplateRef || defaultParagraphTemplate"
  [ngTemplateOutletContext]="{
    $implicit: { first: first, paragraph: paragraph }
  }"
>
</ng-container>

The first time I saw something like this, I was a bit confused, so lets go piece-by-piece. the ngTemplateOutlet directive allows you to provide a template that will be rendered, so we are assigning the provided paragraphTemplateRef. Since we want to have a default presentation I created a second template variable reference that's used when the user doesn't provide a custom template.

The other thing to notice is the ngTemplateOutletContext, that's the mechanism provided by the Angular team to hydrate templates with data. The { first: first, paragraph: paragraph } will be assigned to ctx in the template.

Conclusion

You just did it, now you have a way to make sure your texts aren't super boring walls of text, even if they come from the server. And as a bonus, we made it highly customizable so you can reuse the strategy in any of your projects. If you want to learn more about ngTemplateOutlet, you definitely have to watch this talk about ngTemplateOutlet by Stephen Cooper, all the techniques with ngTemplateOutlet I used, came from that talk.

Icons made by Smashicons from Flaticon

Make it accessible: Navigation in Angular

Daniel Marin — Mon, 20 Jan 2020 23:18:54 +0000

Make it Accessible: Navigation in Angular

Today, we are gonna 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 to which url it has to redirect the user 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 gonna have to face this.

We are gonna 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 which 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 changing 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 Unsighted 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 on which page they are, no matter their condition. We are almost there to make a more inclusive navigation.

Manage focus and scroll

Lets 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