The ASOS Tech Blog
Published in

The ASOS Tech Blog

A journey towards sustainable accessibility

Empower your teams to embrace inclusivity in their everyday work.

With an estimated 15% of the global population living with some sort of a disability, digital accessibility should be a no brainer. Yet in this day and age we are still largely talking about it as an added benefit rather than a necessary part of the digital product lifecycle. More often than not, this tends to come as a result of the general lack of knowledge surrounding accessibility — even when companies want to make their products more accessible, they often don’t know where to begin, and when they do manage to get started teams often get stuck in the process of scaling their efforts.

This article was motivated by a shared goal we have at ASOS to provide our customers with a truly accessible fashion ecommerce experience, and the problems and learnings we’ve faced while working towards it. Over the past few years at ASOS Tech we have put many hours into making changes to our platforms to allow all customers equal access to our products and services. Along the way we have recognised that to succeed in making the ASOS experience truly accessible we need to change much more than just our code. This is why we started shifting our aim towards a more sustainable accessibility approach, one where we are growing our inclusivity efforts organically until they simply become part of our everyday work.

I would like to use this opportunity to highlight some of the approaches we have been taking at ASOS towards tackling accessibility sustainably. It’s an ongoing journey for us and I am sharing these in the hope that they may contribute to the discussion around accessibility as a process rather than an end goal.

Audit your teams like you audit your code

You can fix as many accessibility bugs as you like and implement all kinds of strategies to tackle new ones but the truth is until each member of your team understands why inclusivity is important you are bound to be creating more accessibility issues. Taking the time to understand the knowledge gaps across your team as well as the particular resources and training that people need is crucial to minimising your inaccessible output.

Awareness sessions are always a good place to start. It’s likely that not everyone in your team will know what accessibility even means and that’s OK — a simple conversation can change that. Do some research and bring some statistics to the table, talk about different disabilities, how different people may be accessing information and why accessibility actually benefits all users. Chances are, especially in bigger teams, that people may be intimidated to ask questions at first but the more you normalise the conversation around disability and accessibility the more you will see people feeling comfortable learning and approaching the subject with more confidence.

At ASOS Tech we run accessibility sessions on a regular basis both inside and outside the tech team. These include awareness sessions, testing and WCAG sessions, screen reader sessions and more specialised sessions for particular teams. We keep a central repository of content which we tweak to the needs of different teams, their technical level and the feedback we get. This allows us greater flexibility when it comes to training everyone at ASOS to feel comfortable knowing how to support our accessibility efforts with their everyday work.

Test, test, test

An added benefit to spending time regularly training your team is that you eventually end up with an army of testers. Not everyone can and should be a WCAG specialist but when people gain a better understanding of the way their everyday work directly affects the accessibility of the final product they become much more mindful and observant.

Breaking up the testing responsibilities is crucial for gradually building up towards a sustainable effort where one person or a single team doesn’t feel like they suddenly have a second job they never asked for. What makes sense to be owned by whom depends on the structure and size of your team but a general rule of thumb can be that engineers and testers should be familiar with screen readers, automated testing tools and keyboard navigation while designers and creatives should be utilising a contrast analyser. As none of these people work in isolation from each other eventually they will start reporting problems to each other and holding each other’s work up to standard. However, that is unlikely to happen on a larger scale until most members of the team feel like they are well trained and owning accessibility in their particular workflow first.

A screenshot of the bag portion of the ASOS iOS app with two products added inside it and Voice Control turned on and showing numbers corresponding to interactive elements on the screen
Regularly testing with various assistive technologies is important

As a natural continuation of this process a number of team members will emerge who are innately more interested and motivated to own accessibility in their area. If you don’t already have an accessibility champions network these people will be the ideal founding members, and if you do they will be your allies when it comes to growing it, so make sure to nurture and support them. At ASOS we are still in the process of growing our internal a11y champs network and we are looking forward to sharing our learnings in the near future.

Document everything

Another important step in growing our inclusivity efforts at ASOS has been documenting accessibility. What we have found is that keeping a record of our accessibility thinking, decisions and implementations makes it easier to cross-reference solutions, analyse and improve our efficiency, and trace back the origin of recent accessibility problems.

A screenshot of a wireframe design from the ASOS website with focus order and screen reader announcements marked up on it
We include accessibility details with our designs in order to keep a record of decisions. This also makes discussions around accessibility during team meetings easier

There are various ways of documenting accessibility, whether that’s creating spreadsheets, writing tickets or starting an accessibility repository somewhere where everyone has access to it. Within our team we use a combination of accessibility epics for past and ongoing issues, accessibility design documentation for new projects and we keep a record of requirements and decisions on individual teams’ pages. As an accessibility specialist, I personally find it useful to also keep track of my conversations with people, with references to tickets, decisions and outcomes so I can quickly revisit them if a question arises or if I can’t remember something. All of this is of course a work in progress which changes as our knowledge and experience evolves and we find better ways of documenting until accessibility becomes an integral part of how we do things. As a team we believe that it’s all about the journey rather than getting to that one final destination. The goal of accessibility is not perfection; it’s to care enough to want to change your ways and learn from your mistakes all while making your work a bit more inclusive every time.

Identify changes that should happen first

If you are working on improving the accessibility of an existing website or app, it is likely that alongside growing your efforts internally you will also need to fix some issues. Retrofitting accessibility is a time-consuming process which does not contribute much to the sustainable growth of accessibility within a company but it does teach teams an important lesson about working hard to avoid creating more issues that will require their attention later on. However, there are ways to approach fixing existing issues in a sustainable manner to match the rest of your team’s accessibility work. An obvious first step towards compliance is always resolving issues that act as total blocks for certain user groups, followed by the less severe but still serious bugs. Within those groups there are also ways to identify which problems have a higher priority for your customers depending on factors such as traffic, visibility, etc.

One such example for us at ASOS was identifying that our web navigation is not particularly keyboard friendly. The problem was that we had structured the navigation as a sequence of tabs that auto-expanded both on hover and when a user tabs onto them. There was also a lack of an identifiable relationship between the elements that trigger the expanded content and the content itself as they were placed separately in the DOM. That affected the perception of screen reader users but also meant that keyboard users had to navigate through all the top level content before getting to the expanded navigation. We tried to implement a quick fix (spoiler: those never work as they end up creating more issues in the long run) by adjusting some ARIA and forcing focus to land in the right place but we very quickly realised the proper solution required a restructure of the DOM and utilising semantic HTML components.

A screenshot of the ASOS website navigation where one submenu is selected and expanded
After some essential changes the current iteration of the ASOS web navigation is more accommodating for screen reader and keyboard-only users

While this issue was by no means a deal breaker since users had the alternative of using the search field and there was no actual block for keyboard or screen reader users, we knew this was something we wanted to address as the navigation appears on almost every page and it is meant to make exploring our website easier for everyone. This issue was a prime example of the problems that come with retrofitting accessibility, but it is also now one of the many challenges we are proud to have under our belt as it is a tangible step towards inclusivity.

Everything not mentioned so far

This post is not meant to offer an exhaustive list of what tech teams should do to achieve a good level of accessibility for their products. For example, a few key elements that have not been mentioned so far are user testing and involving users in the accessibility journey, optimising design systems for accessibility, and monitoring progress. These are just some of the accessibility goals we are currently working on at ASOS and we are looking forward to be able to share learnings from our experience soon. In the meantime, we do believe that approaching our accessibility efforts with long-term sustainability in mind will give us a solid foundation to be truly inclusive for our users.

Did you know that ASOS are hiring across a range of roles in Tech? See our open positions here.

Hi there, my name is Tzveta Dinova and I look after digital accessibility at ASOS.com. When I’m not at my laptop fixing bugs and talking about accessibility I like to go around riding anything on two wheels.

--

--

--

A collective effort from ASOS's Tech Team, driven and directed by our writers. Learn about our engineering, our culture, and anything else that's on our mind.

Recommended from Medium

Is Standardization of Digital Design a Threat to Innovation?

Our Services

Self-serve kiosk experience at a movie theater

The Best Pro Tips For Emerging Web Developers and Designers

hire a web developer

How designing for vernacular users increased day 30 retention manifold — a UX case study

Value Sensitive Design for Helsinki

UX Case Study: Professionals Working Remotely

Finding our Bearings: Navigating Inequitable Healthcare with human-centered design

My (immediate) family tree

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tzveta Dinova

Tzveta Dinova

Accessibility Specialist at ASOS.com

More from Medium

A Postmortem on Playtesting: Exploring the Impact of Playtesting on the Critical Reception of…

Remote Learning & Accessibility

Keyboard focus: Helping users navigate The Post without a mouse

A screenshot of The Washington Post website with the search button highlighted with a blue outline

D1 — Aldente: On Demand Chef Service