Accessibility

As explained in Introduction I had a course about Accessibility in my Uni and here I want to collect some of the most important keynotes.

Screen Reader

A Screen Reader(SR) is a software used by visually handicapped people to describe what you would see on a website. Here it is most needed to make use of the html aria-* attributes by WAI-ARIA, so the SR can make sense on how to correctl traverse the dom.

For example the Select component uses a custom listbox that pops up somewhere in the body when the trigger is clicked. Without certain aria attributes the SR couldn’t make sense of this and simply wouldn’t notify the user about the popped up listbox.

Another example are accessible names for the native html button element. They need the aria-label property defined in order to be correctly announced by the SR.

Aria Attributes for SR are comepletly invisible for the normal user, but urgently necessary for visually impaired people since they can only use the web via a SR.

Tools

There are a lot of awesome tools like Axe DevTools or ARC Toolkit which you can use to detect accessibility errors.

Probably the easiest would be the Lighthouse report which every Chromium based browser can use directly in the devtools without installing anything. There you can generate a report with a score of how accessible (and some more tests) your website is and directly shows you where it finds a error and how to improve it.

Keyboard Handling

In contrast to SR’s, a proper Keyboard handling can benefit anyone and should therefore have a high priority to invest time in. HTML has already keyboard support built-in for its native elements. Components like the Select are highly custom and therefore need its own implementation of keyboard inputs. Luckily WAI-ARIA provides us a list of required keyboard interactions for the listbox role.

Color / Contrast Radio

Contrast can be easily checked by calculating the Contrast Ratio and also plays an important role for visually impaired people.