It has been a year since I became a software developer, joined ThoughtWorks, and most importantly, being in a position of power and learning to use it as responsibly as possible day to day.
This post is a short reflection of an aspect that I have internalised and practised this past year – digital accessibility (or shortened as a11y).
A11y for me is a practice of not disabling users due to bad design (or code). Good design is invisible and inclusive, but bad design actively disables people.
A short detour
Before this, I want to take a small detour to mention my mum.
A few years ago, she revealed that there is a risk for her to develop macular degeneration. Despite her casualness towards the situation, I was deeply shaken. The condition is, as far as we now know, an age-related issue and nothing that could be done medically to prevent or cure it.
How does one, in her 70 years of being a sighted person, get used to not having clear vision anymore, if and when that happens? Getting by the day to day aside, how about some of the things that she does for leisure – the things that give her meaning and sense of connection, such as connecting with her friends and family (including me who is six thousand miles away) on WhatsApp?
I probably had been secretly panicking ever since, although thankfully her vision hasn’t gotten worse either.
a11y in my daily life as a developer
Back to now.
Day to day, I develop a customer-facing website at the client’s. It is a new product, and digital accessibility is baked into it since day one.
The designs we work with have good colour contrasts, font sizes, and clear user interactions. We make sure screen readers work well on the website when viewed on mobiles and desktops, use automated accessibility testing tools on unit and functional tests level, and check keyboard navigation on all pages.
We rarely think twice about this process during delivery. It is as necessary as things such as writing automated tests and making sure PIIs are not logged.
Me using the rest of the internet
Nowadays when I browse the net as a normal user, I am surprised at the number of websites that don’t give the same convenience that an accessible website does. I cannot use keyboard navigation (which I do a lot) or zoom in without losing focus. Sometimes I visit websites on a mobile device, try to make manual adjustments (zoom in/out, change orientation) in order to make it legible to no avail and give up (perhaps just like the 4 million people mentioned on the Click Away Pound survey in 2016).
What made me sad is that many of these websites had important messages. They are websites of artists, local businesses, charities and activists. And I don’t blame them. What did I know about a11y when I built websites using WordPress and Squarespace in my previous career? Even if I did I probably had more pressing issues to think about.
Despite its promise, there is still a long way to go where the internet is accessible to everyone.
A year on
All of us at the client project – the product owners, designers, developers and QAs – took a11y seriously and continue to do so.
Recently the designers, developers and QA in our team got together to discuss how we test and continue to improve accessibility. It was a short workshop format and the discussion was lively and engaging. The programme teams are also due to go on digital a11y training imminently.
This month we revisited a feature to improve its accessibility for screenreader users. This feature was one of the firsts that were developed, and now armed with better patterns and knowledge, we went back to do some refactoring. At showcase, we demonstrated how a screenreader user would use this feature and resonated very well from the client leadership.
Closing
a11y being a business-as-usual aspect at the client project, I am immensely proud of the outcome thus far. And I know if my mum were to use this website (and hopefully any of the websites or apps that I build in the future), she would be able to do so regardless of the condition of her vision.