Multiple studies suggest that around 15-20% of the population are living with a disability of some kind. In comparison, that number is higher than any single browser demographic currently, other than Chrome2. Not considering those users when developing an application means excluding a large number of people from being able to use it comfortable or at all.
Some people are unable to use the mouse, view a screen, see low contrast text, Hear dialogue or music and some people having difficulty to understanding the complex language.This kind of people needed the support like Keyboard support, screen reader support, high contrast text, captions and transcripts and Plain language support. This disability may change the from permanent to the situation.
-
Semantic Markup - Allows the application to be understood on a more general level rather than just details of whats being rendered
-
Keyboard Accessibility - Applications must still be usable when using only a keyboard
-
Visual Assistance - color contrast, focus of elements and text representations of audio and events
If you’re creating custom element directives, Web Components or HTML in general, use native elements wherever possible to utilize built-in events and properties. Alternatively, use ARIA to communicate semantic meaning.
HTML tags have attributes that providers extra context on what’s being displayed on the browser. For example, the img tag’s alt attribute lets the reader know what is being shown using a short description.However, native tags don’t cover all cases. This is where ARIA fits in. ARIA attributes can provide context on what roles specific elements have in the application or on how elements within the document relate to each other.
A modal component can be given the role of dialog or alertdialog to let the browser know that that component is acting as a modal. The modal component template can use the ARIA attributes aria-labelledby and aria-described to describe to readers what the title and purpose of the modal is.
@Component({
selector: 'ngc2-app',
template: `
<ngc2-notification-button
message="Hello!"
label="Greeting"
role="button">
</ngc2-notification-button>
<ngc2-modal
[title]="modal.title"
[description]="modal.description"
[visible]="modal.visible"
(close)="modal.close()">
</ngc2-modal>
`
})
export class AppComponent {
constructor(private modal: ModalService) { }
}notification-button.component.ts
@Component({
selector: 'ngc2-modal',
template: `
<div
role="dialog"
aria-labelledby="modal-title"
aria-describedby="modal-description">
<div id="modal-title">{{title}}</div>
<p id="modal-description">{{description}}</p>
<button (click)="close.emit()">OK</button>
</div>
`
})
export class ModalComponent {
...
}Keyboard accessibility is the ability of your application to be interacted with using just a keyboard. The more streamlined the site can be used this way, the more keyboard accessible it is. Keyboard accessibility is one of the largest aspects of web accessibility since it targets:
-
those with motor disabilities who can’t use a mouse
-
users who rely on screen readers and other assistive technology, which require keyboard navigation
-
those who prefer not to use a mouse
Keyboard interaction is driven by something called focus. In web applications, only one element on a document has focus at a time, and keypresses will activate whatever function is bound to that element. Focus element border can be styled with CSS using the outline property, but it should not be removed. Elements can also be styled using the :focus psuedo-selector.
The most common way of moving focus along the page is through the tab key. Elements will be traversed in the order they appear in the document outline - so that order must be carefully considered during development. There is way change the default behaviour or tab order. This can be done through the tabindex attribute. The tabindex can be given the values: * less than zero - to let readers know that an element should be focusable but not keyboard accessible * 0 - to let readers know that that element should be accessible by keyboard * greater than zero - to let readers know the order in which the focusable element should be reached using the keyboard. Order is calculated from lowest to highest.
The majority of transitions that happen in an Angular application will not involve a page reload. This means that developers will need to carefully manage what happens to focus in these cases.
For example:
@Component({
selector: 'ngc2-modal',
template: `
<div
role="dialog"
aria-labelledby="modal-title"
aria-describedby="modal-description">
<div id="modal-title">{{title}}</div>
<p id="modal-description">{{description}}</p>
<button (click)="close.emit()">OK</button>
</div>
`,
})
export class ModalComponent {
constructor(private modal: ModalService, private element: ElementRef) { }
ngOnInit() {
this.modal.visible$.subscribe(visible => {
if(visible) {
setTimeout(() => {
this.element.nativeElement.querySelector('button').focus();
}, 0);
}
})
}
}One large category of disability is visual impairment. This includes not just the blind, but those who are color blind or partially sighted, and require some additional consideration.
When choosing colors for text or elements on a website, the contrast between them needs to be considered. For WCAG 2.0 AA, this means that the contrast ratio for text or visual representations of text needs to be at least 4.5:1. There are tools online to measure the contrast ratio such as this color contrast checker from WebAIM or be checked with using automation tests.
Color can help a user’s understanding of information, but it should never be the only way to convey information to a user. For example, a user with red/green color-blindness may have trouble discerning at a glance if an alert is informing them of success or failure.
The a11y package provides a number of tools to improve accessibility. Import
import { A11yModule } from '@angular/cdk/a11y';ListKeyManager manages the active option in a list of items based on keyboard interaction. Intended to be used with components that correspond to a role="menu" or role="listbox" pattern . Any component that uses a ListKeyManager will generally do three things:
-
Create a
@ViewChildrenquery for the options being managed. -
Initialize the
ListKeyManager, passing in the options. -
Forward keyboard events from the managed component to the
ListKeyManager.
Each option should implement the ListKeyManagerOption interface:
interface ListKeyManagerOption {
disabled?: boolean;
getLabel?(): string;
}Used when options will directly receive browser focus. Each item managed must implement the FocusableOption interface:
interface FocusableOption extends ListKeyManagerOption {
focus(): void;
}Used when options will be marked as active via aria-activedescendant. Each item managed must implement the Highlightable interface:
interface Highlightable extends ListKeyManagerOption {
setActiveStyles(): void;
setInactiveStyles(): void;
}Each item must also have an ID bound to the listbox’s or menu’s aria-activedescendant.
The cdkTrapFocus directive traps Tab key focus within an element. This is intended to be used to create accessible experience for components like modal dialogs, where focus must be constrained. This directive is declared in A11yModule.
This directive will not prevent focus from moving out of the trapped region due to mouse interaction.
For example:
<div class="my-inner-dialog-content" cdkTrapFocus>
<!-- Tab and Shift + Tab will not leave this element. -->
</div>Regions can be declared explicitly with an initial focus element by using the cdkFocusRegionStart, cdkFocusRegionEnd and cdkFocusInitial DOM attributes. When using the tab key, focus will move through this region and wrap around on either end.
For example:
<a mat-list-item routerLink cdkFocusRegionStart>Focus region start</a>
<a mat-list-item routerLink>Link</a>
<a mat-list-item routerLink cdkFocusInitial>Initially focused</a>
<a mat-list-item routerLink cdkFocusRegionEnd>Focus region end</a>InteractivityChecker is used to check the interactivity of an element, capturing disabled, visible, tabbable, and focusable states for accessibility purposes.
LiveAnnouncer is used to announce messages for screen-reader users using an aria-live region.
For example:
@Component({...})
export class MyComponent {
constructor(liveAnnouncer: LiveAnnouncer) {
liveAnnouncer.announce("Hey Google");
}
}