These current times can seem strange, and sometimes even scary, for our industry. In the last few years AI has become a major disruptor. So it was refreshing to see so many talks demonstrating the power of human creativity and engineering; people from our industry who care about the Web and the people it serves.

It was also great getting to meet so many new and old friends at the conference and evening social. Community is so important. Keeping connected with real people really helps us move forward, and build better.

I’m now super excited about heading to Hull next month for Developers Up North. This should be another great community-led conference. Plus, I’ll be on stage speaking at this event.

Toast notifications may look clean and modern, but they pose serious issues for many people. I believe that making them a default in a popular framework like Laravel is a wrong direction.

Let me explain why this is a poor choice, and why it should matter to you, even if you consider yourself a backend developer.

What’s wrong with Toast notifications?

They can be invisible to screen reader users

If a Toast notification isn’t correctly set up with an ARIA live region, screen reader users will not hear it. Screen readers are used by those who are blind, visually impaired or have other disabilities like dyslexia.

In fairness to Laravel, my initial tests with two screen readers did announce the notifications. I set up a basic Laravel app using the Livewire starter kit and tested the settings page. I tested with the widely used NVDA screen reader and MacOS’s inbuilt VoiceOver.

Whether the Toast notifications remain discoverable to screen readers as an app develops remains unclear.

They disappear before many users can read them

Cognitive impairments are common. They can impact the speed at which someone processes information, or cause attention difficulties. The short-lived nature of Toast notifications means that many users will not have chance to read them.

Once the notification has disappeared, some will be left unaware of the status of the process they’ve just triggered. This leaves the user having to guess, refresh or simply try again.

You don’t have to have a cognitive impairment for this to affect you. If a user is distracted — perhaps a colleague interrupts them or the phone rings — they miss the notification too.

They appear off-screen for screen magnification users

For those with a visual impairment, screen magnification is a commonly used assistive technology. For these users, they typically only see a fraction of the screen at a given time.

Toast notifications typically appear in the corner of the viewport. For screen magnification users, these notifications will often appear off-screen with no indication of any status change.

As someone who regularly needs to use screen magnification, this is a real problem.

They break when users increase text size

Lots of users choose to change their browser’s default text size. A Dutch study has found that 26% of smartphone users increase the text size.

A well-configured app will scale text to support the user’s preferences. This should include Toast notifications.

My quick tests of Laravel’s Toast notifications revealed that they do scale with the browsers text size settings. However, this does reveal another common issue with Toast notifications: the text can overflow the viewport.

When the notification doesn’t fit the viewport, it means some of the text becomes hidden to the user.

Keyboard users should be able to dismiss them

If a user is navigating by keyboard, they should be able to tab to close it as soon as it appears. However, the close button of a Toast notification is often not the next logical focusable element.

My tests with Laravel’s implementation revealed it is possible to dismiss the notification with the keyboard, but navigating to the close button was problematic. It was not the next element in the tab sequence.

The real cost of Toast notifications

When a notification fails to be fully perceived by a user, they lose confidence in your app.

Did a form submit? Was a payment successful? Did the file upload? If the only way to confirm is by refreshing the page and checking for yourself, you have a problem. If this becomes a repeated experience, you lose a user.

Accessibility failures don’t just impact a small group of edge case users. Disabilities affect a large number of people, we just often don’t recognise this.

Accessibility failures can also impact everyone when we find ourselves in situations that affect our workflow: a user that is stressed, distracted or mentally fatigued; or someone that is using a screen in bright sunlight.

When we build applications that work for those with assistive needs, we build for everyone.

Why this is a backend developer’s problem

As backend developers, we often hold a lot of influence over choice of framework and starter kit.

Admin panels and internal tooling are often built entirely by backend engineers; frontend developers and UX specialists often never get involved. It means user experience and accessibility are often forgotten.

Backend developers rarely talk about accessibility. Either through a lack of awareness or a misplaced assumption that it is someone else’s problem. However, our decisions often have a direct impact on the people that need accessibility considerations.

The people that use are apps are real. Many have assistive needs. They deserve to be able to work with the tools we build like everyone else.

When you choose a framework, starter kit or UI component library, you are making an accessibility decision. When you choose to use a default that creates barriers for many users, you are making an accessibility decision. This is your choice, and your responsibility.

The alternative

Instead of using Toast notifications, we should use a more inclusive solution. I would recommend using inline notifications that respect the user’s text sizing preferences; and if you must make them dismissible, let the user decide when they want the message to disappear.

Good notifications should be persistent and visible.

Accessibility is more than a frontend developer or UX specialist’s problem. It’s an engineering problem. We must recognise that the decisions we make have consequences. Enabling Toast notifications by default is one of them.

Sadly, the findings aren’t encouraging. The slow progress made in past years is being undone. Not only are we still failing to get the basics right, things have actually gotten worse since 2025.

Homepages are becoming more complex, and with that complexity comes reduced accessibility. In just one year, the average number of elements on a homepage has increased by 22.5%.

When we don’t take accessibility into account, we inadvertently create barriers that exclude many people from using our sites. Those excluded users are our friends, family and neighbours. They are potential customers unable to complete a purchase. We can and need to do better.

A good starting point is to review your own websites for the six most common issues highlighted by WebAIM’s report. These six account for 96% of all detected errors. Addressing these would make a meaningful difference to your users.

On Sunday, clocks go forward an hour at 1am. In other words, we go from 00:59 to 02:00.

It’s easy for us to write code for the ‘now’ and forget that twice a year we shift timezones. This often trips people up, especially early in their careers. Sometimes, the consequences of this oversight can lead to big headaches the day after the clocks have changed.

What things do you need to check ahead of the switch to summer time at the end of this week? Here are some suggestions.

Scheduled jobs

If you have automated jobs scheduled, do these fall within the skipped hour? What will happen when these fail to run? Similarly, when we fall back to GMT in the autumn, what happens if these jobs run twice?

Third-party integrations

If your code talks to remote APIs, are assumptions made about the timezones in the two systems? If the API uses UTC, but you’re passing local times, then you could be an hour different for the duration of summer time. This is unlikely to be the desired situation.

Displayed dates

Regardless of which timezone you store datetimes in your database (it probably wants to be UTC), your users will most likely expect to see dates and times in their local time. If a customer orders something on an ecommerce store at 11pm next week, what weekday will their account show for when the order was placed?

Are you ready for British Summer Time?

The lost hour of sleep this weekend is unavoidable, but bugs in code relating to the shift don’t have to be.

The statistic was being used to make a fairly bold claim. I hadn’t come across this ‘fact’ before, so decided I’d dig a little deeper.

A bit of searching revealed multiple articles repeating the same claim; some even citing the original research it supposedly came from.

After jumping over a few hurdles, I finally managed to get hold of the original white paper. To my surprise, the statistic didn’t represent what the many articles claimed it did. In fact, it told a very different story.

It turned out that several sites had taken the statistic and skewed its meaning to support their own arguments.

The fact that so many sites repeated the same misinterpretation suggests they hadn’t checked the original research at all. They were simply copying each other, much like a game of Chinese Whispers.

The Internet is rife with misinformation. My time in physics research taught me the importance of verifying sources. As professionals, we need to be confident that what we share is accurate; that means going back to the original evidence whenever we can.

Let’s help break the cycle of misinformation.

When I was younger, my dad used to love the game Trivial Pursuit. My main memory of this game was the frustration of everyone else around the table. My dad would sweep the board collecting the cheese wedges for each category; whilst the rest of us were desperately trying to get a single wedge. The game’s questions might have been trivial to my dad, but they weren’t to the rest of the family.

Trivial is an adjective we use to imply something has little value or importance. We often describe problems as trivial to imply they are easy to solve. Herein lies the danger.

When we use the word ‘trivial’ we make a couple of assumptions: firstly, the knowledge and experience of the recipient; and secondly, their current state of mind. If someone is stressed, the word ‘trivial’ is likely to contribute to their existing state of anxiety.

• ‘Trivial’ can make people feel like imposters if something falls outside their experience
• ‘Trivial’ can over simplify a problem that in the details is actually complex
• ‘Trivial’ can imply something is going to be quick — in Tech, things are rarely quick to implement
• ‘Trivial’ risks bringing a discussion to an abrupt end, preventing questions and considerations of alternative solutions

Our choice of words can make a real impact on those listening to us. Next time I reach to use ‘trivial’ in a sentence I will try and remember those games of Trivial Pursuit and the inbalance in trivial knowledge. Using the word ’trivial’ doesn’t have to be problematic, but the context needs to be considered. Perhaps, alternative language would suit the situation better.

In many regards this site has gotten accessibility right. They’ve generally used good colour contrasts, images have alt text, there are skip links in helpful places and form inputs are labeled. However, visually impaired customers using a screen reader will be getting a very different shopping experience to sighted users.

Every product with sizes has a visually hidden label that reads ‘Variant sold out or unavailable’. That means if you are using a screen reader, it will appear that the store is completely out of stock. Have they really sold out? No, visually all sizes are shown as available and can be added to the cart.

To double check this, I looked for a product on the same site that had reduced availability. I found one where certain sizes were out of stock. Visually these sizes appear crossed out and faded (the colour contrast here is not good). You can still select these out of stock sizes, but can’t add them to the cart. Instead you are presented with a 'Notify me when available' button, a familiar e-commerce design pattern.

So, this website is clearly well stocked if you are a sighted user, but not if you use a screen reader. I'm sure this wasn't the developers intention or the message the business wanted to give.

The developers for this website have clearly cared about accessibility in terms of the build. However, it appears that they haven’t fully tested their approach to ensure it works as intended. As a result the store is potentially losing customers without realising why.

I know from my own accessibility journey, that we can easily start incorporating accessibility considerations into our work without fully understanding the impact. We go off and learn about how we can programmatically make a page accessible, but this is dangerous if not paired with testing. Without both, we risk introducing new barriers.

Accessibility is important. Testing our work is accessible is more so.

Work

Last year, I returned to public speaking after a bit of an extended break. I was eager to continue this and 2025 was full of opportunities.

This year, I delivered talks at Front End Sheffield, Leeds PHP and dot Net Sheffield. I was also invited to speak on a panel about digital accessibility at a11y North.

I attended a couple of tech conferences. First as a backup speaker for Front End North; then later in the year I got my chance to deliver my first conference talk at Tech Mids.

Speaking at a conference hadn’t been on my bucket list at the start of the year. However, I realised I was ready to take public speaking to a larger audience and loved the experience.

I'm excited to see what new speaking opportunities 2026 will bring.

Life

Outside of work, my passion project, Street Art Sheffield, opened up several exciting experiences. Recognised for my knowledge of Sheffield’s street art scene, I was interviewed by ITV News and BBC Radio Sheffield. When I first set up my website, I never anticipated it leading to me featuring in the news.

In 2025, Sheffield hosted its first street art festival; Lick of Paint was organised by a couple of local artists, Peachzz and Alastair Flindall. They invited me to be part of the festival activities, running the official walking tours. I’ve run many tours before, but these felt special. The city buzzed with creativity that weekend and guiding people through the festival sites was unforgettable.

Despite all my personal highs of 2025, at times the world has felt like it’s been in a really dark place. This has impacted my mental health. It’s one of the reasons I have thrown myself into many things this year. Getting out and being part of the community has been really energising.

One other thing I’ve done to combat my anxiety has been to attend lots of live comedy gigs. Being in a room full of people laughing is very uplifting. Highlights have included Rhys Darby, Zoe Lyons, Russell Howard, Angela Barnes and a somewhat chaotic live performance of Johnny Vegas’ Ideal. Attending Sheffield's Crossed Wires podcast festival was also a lot of fun.

2026

2025 has been full of unexpected opportunities. I'm excited to see what 2026 has in store.