Accessibility does not only benefit disabled users

I have spoken several times about accessibility, both internally at Netcentric and externally, since 2015.

And I realize that many developers find it very difficult and painful to implement it, so unless there is a business requirement, they just don't.

Maybe if we could finally come to realize that accessibility is all about a great user experience and the possibility of including more users, we'll give a little bit of extra care.

What users with disabilities benefit from web accessibility?

The World Health Organization says that 15% of the world's population deals with some sort of disability, from severe to mild.

There are physical disabilities related to sight, hearing, motor, cognitive (like dyslexia or autism). Obviously people with these conditions benefit the most when it comes to accessible apps, but there are a lot more beneficiaries of accessibility...

You and I! We can all benefit from inclusive design.

There is a staggering 1 billion people in the world who have a disability that may require they use assistive technologies to navigate an app or site. But there are also people who are not part of that segment, and still can leverage an accessible interface.

You may have tired eyes after a long day at work, your mouse may be out of batteries, you may have an acute carpian tunnel inflammation...You get to the office to realise you forgot your glasses at home!

So many reasons!

Levels of conformance

Ok, so I convinced you. You want to make your apps accessible. Where do you start? You start by knowing the levels of compliance.

The three of them: A, AA, AAA, that indicate how perceivable, operable, understandable and robust a UI and its content are.

Add structure

For content to be understandable, a rule of thumb is to provide your views or pages with organised structure by using <main>, <section>, <header>, <footer>, or <aside>, instead of generic <div> elements, and use landmark roles when not implicit.

Those elements mentioned above have implicit landmark roles, but if you use a <div> instead, you have to explicitly assign it.

Define a hierarchy

It is also very important to define a hierarchy for content using headlines, from <h1> to <h6>`

One very important things Angular developers should do when composing their Angular views, is to check how the bootstrapped components play together!

How the structure looks like when the components are in place nested in one another or as siblings to other components.

The Accessibility Tree

And why is structure and hierarchy, as we mentioned, so important?

Because, depending on their order and the hierarchy of content, it is how the browser will generate both your graphic user interface AND the accessibility tree. This tree will be used by assistive technologies, like screenreaders, to navigate a page or view.

A best practice is to put HTML elements exactly in the order they should appear in the page, trying not to modify their order with CSS or JavaScript.

For that, the browser also needs you to always provide text alternatives to controls and graphics.

Use native HTML elements instead of repurposing

The WCAG also recommends to always use the dedicated HTML native element, when available, ie. <button> for buttons

Synthetic controls

When you focus an element, ALL keyboard controls are transferred to that item, including synthetic input events. If you use the proper button element for example, instead of just a <div> or an anchor, if you add an event listener on click, it will automatically work when you focus it and hit enter in the keyboard.

You get a lot for free when you use native elements.

Tabindex

Let's suppose we have a specific requirement for which it is useful to infer the focus to an element that is not natively focusable, like a <div>, we can achieve that with the use of the tabindex attribute.

It is a best practice to use only 0 and -1 as indices, since any other positive value, can lead to a very bad user experience.

I made the mistake of adding incremental positive values to an unordered list once to control the order of navigation, and it ended up very, very bad. Because the positive values will have more precedence, and results will be very unexpected when there are natively focusable elements in the mix...

Keep an eye in the contrast ratios

One very important factor to make content understandable and perceivable, is the color's scheme used. A very common problem is the lack of sufficient contrast between background and foreground colors.

In this example we see 2 buttons with different ratios. There is obviously a great difference for certain users with reduced sight abilities, to understand the first.

UI and UX designs may not be under your control, but you can still review them to identify problems before you start the technical implementation.

Keep in mind that while a good user experience is paramount to accessibility, designers may not be aware of a11y specs.

Read part 2 coming soon, to learn how to implement WAI-ARIA, and get your A11y checklist, for when you're developing your app!