Accessible, people-first software
I write about accessibility, developer growth, and building software that works for everyone.
When talking about inclusivity — including accessibility — this insidious argument is often used: exceptions or accommodations will be made if necessary.
It may seem a logical or even fair statement, but it hides an element of injustice: it adds a new requirement for certain people to fulfil.
In user experience, we usually talk about how people perceive and use tools so they can shape how these tools are designed and built.
Some of these ideas and recommendations may seem obvious, but they are important because when we are building a tool there are many goals, and sometimes conflicting ones.
When working on a product, user experience has become a priority. How a person interacts with a product, how useful it is, and how their experience using it is, ends up getting a lot of attention because it will affect their satisfaction and if they keep using it.
The focus is usually put on external end-users, the people using the product who aren’t part of the company making it. They are the measurement of a product’s success. But in most products, there are other types of users.
Accessibility has both a blessing and a curse in the form of comprehensive lists like WCAG.
The blessing is that we have a tool that details several aspects of accessibility that we wouldn’t think of otherwise along with specific recommendations on how to address them, including some check tools to automatically validate the technical implementation of some of them.
If you ever deliver a project based on WordPress to a client where you only created a single user with an administrator role, you may have developed an unbalanced solution.
But for a project to be useful needs to be used, so how it will be used, which user roles will be involved, and how we design the back of our tools do matter.
As of yesterday, I have been working at Volcanic for a year.
I have already shared some aspects of it, like what the culture is like, and how is it to work with the rest of the team.
One thing I love to learn about is accessibility. For me, it is about being inclusive, but there is more to it, like being a competitive advantage or seeing your project from new perspectives.
When I was in design I noticed most designers do not care about accessibility. Very simple things to check like having an appropriate colour contrast — which the default colour palette of the NewDevelopments Block Theme does indeed have— are often dismissed. Now that I transitioned to development, I am disappointed to see how for developers accessibility is rarely a priority or even a concern. Even worse, it is often looked at as a design issue — or being honest, the designer’s problem.
Last year I became a developer. I have been working on web and digital projects for more than twenty years, but never before have I taken on that position. I was excited to do so, but also afraid of change.
The first thing I noticed is no one cares. I was hesitant to call myself a developer, but it was just me. I found out that development is a forgiving and encouraging environment to work in.