Picture the scene: your team has spent months building a global, user-facing application. The major features are all ready and you’re eager to get the application into production. Then you discover the accessibility score is too low and the application wouldn’t be usable for an extensive set of users.

Boom! We can’t release the app and the go-to-market timeline takes a big hit. 

This is actually a really common problem when we don’t give enough importance to non-functional requirements (NFRs) such as accessibility. Let’s look at how we can shift left accessibility testing to the unit level, by leveraging some good practice and widely available tools. 

ByRole query in React testing library 

We often try to use an escape hatch by adding test IDs to the HTML elements and using getByTestID query to get hold of elements in the unit tests. For example, we might have an inaccessible form where inputs aren’t tied with label: 

Since we are adding testIDs, it’s very easy to add the unit test for this inaccessible form: 

Even the div with click listener, which behaves like a button to submit the form, works as expected but is totally inaccessible. 

To overcome this problem, React Testing Library does provide byRole queries to get the elements by their accessible role. This means that the same form with proper accessible role should use the accessible role to get hold of the element. 

The test will fail if we: 

• Remove the htmlfor attribute from label, or event ids from the input elements
• Use any other element other than a button with the name submit to submit the form 
• Change the heading level of the welcome message  

Taking these steps makes the form more accessible by checking it at the unit level only.  

UserEvent catches what fireEvent misses

User-event is a companion library for the testing library that simulates user interactions by dispatching the events that would happen if the interaction took place in a browser. 

The browser usually does more than just trigger one event for one interaction. For example, when a user types into a text box, the element has to be focused, and then keyboard and input events are fired and the selection and value on the element are manipulated as they type. 

fireEvent dispatches DOM events, whereas user-event simulates full interactions, which may fire multiple events and do additional checks along the way. It therefore adds visibility and interactivity checks along the way – manipulating the DOM in the same way that a user interaction in a browser would. 

An interesting example of an accessibility error caught by userEvent that’s missed by fireEvent is pointer-events: none CSS property. If you try to click a button that has this CSS property using userEvents, the test will fail – but this would not be the case when using fireEvent.click. 

Use packages to add accessibility assertions 

Plugins like jest-axe or vite-axe (a custom Jest matcher for testing accessibility with axe) help to run automated tests at unit level. Simply wrap the container inside the axe utility provided by the package to check for any accessibility issues. 

If the input doesn’t have a label, the tests will produce an error. 

What else could we do to check accessibility? 

It’s important to remember that around 30% of access barriers are missed by accessibility tools. We need to do more than simply rely on automated tests. Some other things to consider: 

• Include accessibility checks in automation pipelines and use the lighthouse score for accessibility as a check with every build 
• Test your interface with assistive technologies like Voice Over in Mac etc. 
• Always test for keyboard access and manual accessibility testing
• Involve people with disabilities in your accessibility testing

Accessibility is a very important part of any successful product. We need to make sure we’re testing for it early in the software development lifecycle, rather than making accessibility something we only think about at the end of the process.

When it comes to managing a team and getting jobs done, Agile development helps our software teams to streamline processes and deliver products for clients faster. But you might be surprised to learn how useful the sometimes tricky principles of Agile can be in life outside the world of technology.

I started working as a Recruitment Consultant for Equal Experts in 2016  and just before the pandemic was helping set up our Berlin office. When the pandemic hit – worried that recruitment would take some time to recover – I decided to try a completely different challenge of running my own pub. The Mermaid Inn is a Shepherd Neame tenanted traditional inn, located in a small Kent village called Bishopsbourne. The pub was originally built in the 1860s as a tap house for local estate workers and still remains an integral part of the local community.

Working alongside developers and consultants meant I learned a lot about Agile techniques, by osmosis. I was also lucky in my early Equal Experts days to work closely with some great business analysts who helped me to get a better understanding of how they used Agile practices to improve and manage the work they did with our clients.

When I started running my own pub, it seemed only logical to try to apply some of those Agile techniques in this new environment. Not only has Agile helped me in running the Mermaid Inn, it also enabled me to save enough time that I’ve been able to return to Equal Experts to work part-time as a consultant.

When I first started the job, I did everything from sorting the menu to cleaning the lines. But Agile has helped me to hire and build a team that I know I can leave to get on with things, and they’ll do a great job. So, what Agile principles have I found most useful in running my own hospitality business?

Agile Principle 1: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

The hospitality industry is renowned for being hierarchical, and you’ll often find bar staff, shift managers, deputy managers, bar managers and so on. When I arrived at the pub, there were supervisors for each team, not to mention the assistant manager and manager.

My first big decision was to remove the hierarchy. We do always have a manager on-site, but the remaining staff work equally, with everyone encouraged to take responsibility for meeting customer expectations. This is based on the Agile principle that we should build projects around motivated individuals, give them the support they need, and trust them to get the job done.

Having a flat structure makes a far bigger difference than you realise. After about a year, we hired an assistant manager and the role really went to her head, and it changed the whole atmosphere. Even the customers commented and could sense that something wasn’t right.

Agile Principle 2: The best architectures, requirements, and designs emerge from self-organising teams.

One of the most important lessons I’ve learned from working at Equal Experts is that your team functions best when people are doing the things they want to do.

In the early days of running the pub, I organised a whiteboard session and wrote down all the jobs and tasks on it. Then I invited all the team members to choose the things they were best at. This allowed me to assign jobs people felt were suited to their individual strengths and nobody felt they were having to do things they aren’t good at. If someone isn’t great at dealing with the technical side of the tills, it’s no problem, because that will be someone else’s strength.

Agile Principle 3: Business people and developers must work together daily throughout the project.

I was introduced to Trello while working at Equal Experts, and I am obsessed with it to the point that I honestly can’t imagine how I’d organise my work without it.

I use Trello daily with my manager, and we’ll add tasks and track them, so we can ensure that each person knows what tasks need to be done, what has been assigned and when they are completed. Even if we’re working different shifts, we can communicate daily, and that’s important in a hospitality business. It’s helpful to know that we won’t overlook important tasks like staff shift changes, customer bookings and deposits and regular visits from the brewery, deliveries and maintenance tasks.

Trello also means we have very clear communication around priorities, activity, roles and responsibilities without creating lots of paperwork. Wherever possible, we don’t have paperwork in the running of the business, we save that for the EHO (Environmental Health Office).

Agile Principle 4: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The great thing about working in hospitality is that getting feedback from customers is pretty easy. My customers will soon complain if the beer doesn’t taste right, or a meal takes too long to arrive. We encourage all of our staff to be receptive to, and act quickly on feedback.

We also have regular staff meetings every quarter or every month during busier periods like summer or Christmas. It’s a chance to share feedback with the whole team and invite staff members to make suggestions on improving the customer experience. I think it’s really important that everyone has a voice, and there is no issue with someone raising an area where improvements could be made.

Working with Equal Experts has been instrumental in how I approach the pub business. My understanding of Agile makes complete sense in a non-IT setting and it’s helped me to build a team where people work independently, and they’re not overloaded with documents and processes. As well as giving my punters the best product possible, it’s also freed up enough time for me to have two careers.