Use This Checklist to Make Your Angular App Scalable

Years ago I thought accessibility was for 0.1% of people. Working on apps serving millions of users taught me it’s about way more people, who have to be included when building scalable Angular apps.

One of the main goals of us, frontend software engineers, is to make sure the apps we build are accessible to as many people as possible. There are many ways to ensure that, for example having great designs, but also being really focused on how the app works. Testing it in multiple browsers, on multiple resolution, screen orientations and so on.

But the term “accessibility” isn’t really about it, but, as Wikipedia says:

Web accessibility, or eAccessibility,[1] is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed. When sites are correctly designed, developed and edited, more users have equal access to information and functionality. (source)

What we can recognize as the user oriented needs for web accessibility can be grouped into multiple categories:

• visual impairment
• motor / mobility
• auditory
• seizures
• cognitive and intellectual

And we tend to think these issues only affect some minor group. So we apply WCAG rules not always as part of the general process. It’s rather something that is either taken care of to some extend during the whole design and development process, or at some point as a separate task.

By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise Angular applications and in this series I’ll be teaching you how to do it!

Approaches to accessibility depend on many factors, including legal requirements. But from the people perspective, what can be surprising, that actually accessibility isn’t about a narrow group of people.

Just to five some examples. Around 8% of men have what is called congenital red–green color blindness. It means that they can’t to various extend to differentiate some pairs of colors:

1. cyan and gray
2. yellow and neon green
3. black and red
4. red and green

It seems to not affect UI development, until you have a list of alerts and notifications. When alert and notification icons are similar and small, people won’t be able to recognize what is what leading to problems or to considerable inconvenience that will drive them away from your app.

And we’re not talking about some minor group. It’s 8% of men. An inaccessible app in that matter can be a blocker for 8% of potential users. If someone came and said, he can increase adoption by around 8%, he would be called a charlatan, but here accessibility itself can do it without any impact on business and marketing processes if initially the app isn’t accessible in that matter.

Another set of disorders that affects if people can use apps is motor difficulties. For example essential tremor. It’s a motor neurological disorder causing involuntary, rhythmic shaking of hands that affects almost 1% of global population.

People with essential tremor, but also other motor disorders find many difficulties in life, also in the area of digital life where apps that should help them, not always do it. Too small buttons, located too close to each other are only a tip of an iceberg of thigs that can lock out people with disabilities from these areas from your application.

Moving fast forward to intellectual and cognitive conditions, just for selective example, we have around 1% of people affected by intellectual disabilities, and separately and not connected, 10% of global population affected by autism spectrum.

Complex and overloaded interfaces, ambiguous icons, wording, non consistent navigation, jargon or complex language, no clear feedback, poor readability are just some of elements that affect negatively people with intellectual and cognitive conditions.

Again, a quite large proportion of people globally that will find it hard to use your app if it’s not accessible. What’s interesting, especially for MVP driven startups this is essential, because the app shouldn’t only do the one thing that people want, it should also allow them to do it.

As you can see, accessibility isn’t only for few people, it’s for a quite large proportion of all people. Around one of three people has a condition that makes using apps difficult.

Inaccessible app isn’t just an inconvenience and in highly competitive market it’s a deal-breaker. No one will use an app if they can go to competition that allows them to do just what they need to do despite their various conditions.

In terms of scalable Angular apps, it means we should focus on accessibility and treat it as essential process of design and development. I’d say even more, we should sacrifice other design goals if they lower accessibility, because there’s no sense in building pretty things that people can’t use.

The goal of architecting scalable Angular apps is to build ones that are widely used, and prepared for global usage horizontally and vertically. In the process terms a good design system and component library are places where accessibility can be provided organisation-wide.

But it also requires training and including accessibility in all processes affecting user interface, from requirement phase, through design to implementation and maintained, because everyone involved in these processes has to be aligned to reach for the same goal.

That way we don’t build accessibility debt. Compared to technical debt, accessibility debt affects our users every day. Way more people than we think.

I’ve prepared a free checklist how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for free here.

If you have any questions, ask these in the comment section!