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.

Too often, people with disabilities are wrongly perceived as a small minority. In reality, an estimated 1.3 billion people worldwide live with significant disabilities. Here in the UK, almost 1 in 4 working-age adults have at least one disability. These numbers highlight why accessibility cannot be treated as optional.

What makes the Appt findings especially interesting is that assistive technologies are being used far beyond those who depend on them daily. Many people choose accessibility features for convenience, comfort, or to address temporary or situational needs. For example, research by Stagetext in 2021 revealed that 4 out of 5 people aged 18–25 regularly use subtitles; not because they are hard of hearing, but because subtitles make content easier to follow in noisy environments or when multitasking.

This shows that accessibility benefits everyone. Whether it’s larger text for tired eyes, voice control for hands-free use or captions for clarity, for many, assistive technologies are part of everyday life.

Yet, when you enable one of these settings, you quickly discover how inconsistent and fragile the Web can be. Broken functionality, poor support, and inaccessible design are still far too common. As someone who browses the Web with increased text size (according to Appt's research, 26% of people do), this is unfortunately my lived experience.

That’s why it’s essential that we design, build and test apps and websites with accessibility in mind. Accessibility isn’t just about compliance, it’s about creating a web that works for all.

The numbers speak for themselves: accessibility is not a niche concern. It’s the foundation of an inclusive, usable, and resilient web.

The conference

I arrived in Birmingham the night before, ahead of Storm Claudia. Thankfully, I stayed a short distance from the conference venue, the Everyman Cinema, and missed most of Friday's torrential rain. Safely inside the cinema the energy was contagious. This was a very well attended conference and there was a buzz of activity on arrival.

TechMids is a community driven one-day tech conference. There was a wide variety of topics being covered across three separate screens. The quality of the talks was amazing and at times it was difficult to decide which to attend.

Some personal highlights for me:

• Daniel Tallentire’s talk on talking tech to non-technical folk, with some nice use of metaphors
• Guy Barker’s talk on making apps accessible using a game of Patience as an example (it was great to see the room filling up for an accessibility talk)
• Indy Pahal’s talk about leadership and management – he made some great points about balancing personality types within a team
• Oliver Davies’ talk on Nix for PHP developers, this has inspired me to check this out for myself
• Shaun Lawrence’s talk on using .Net to brew beer – I’m not a .Net developer, but it’s great to see people still coding for fun

My talk

Of course, one of the main reasons for my attendance was to get up and speak. A year ago, speaking at a conference wasn’t even on my bucket list; I was quite content talking at ‘local’ meet-ups. That all changed when I was encouraged to submit a talk to Front End North, a Sheffield (therefore super local) conference.

I was selected as a backup speaker for Front End North, and so had a talk prepared and rehearsed. In the end, I wasn’t needed, but attending the conference, and coming close to the opportunity, inspired me to try again.

I submitted my ‘Ulysses versus The Very Hungry Caterpillar’ talk to TechMids and was selected for the conference.

Despite some initial anxiety before the event, when the day arrived that all disappeared. I found myself so engaged with the conference and the talks I was attending that my only fear was forgetting to be in the right screen at the right time!

I deliberately didn’t look at my notes or slides once I was down in Birmingham. I had practiced plenty before and had given the talk at the dotNetSheff meet-up the previous week. I knew my slides. I knew what I wanted to say. I just soaked up the atmosphere and enjoyed the conference for myself.

When it came to my time, I got up and just enjoyed my time in the spotlight. Afterwards, I received lots of fantastic feedback and it was great to hear how my talk had resonated with different people.

The future

The whole experience has been incredible. I have left Birmingham eager to do it all again. I’ve long enjoyed public speaking, but conference speaking hadn’t been on the cards. It is now!

It can be so easy to become isolated in our industry. Community events like this are really important. I’ve learnt a lot from attending TechMids, been inspired, and made some new friends along the way. I’m already looking at which conference I can go to next, whether as a speaker or just an attendee.

Acknowledgements

There’s a few people I want to thank for my experience. Firstly, the TechMids organisers, especially Tom Goodman and James Constantinou for making me feel so welcome (and selecting my talk). Sam Biggins and Katie Fenn for believing in me. Their encouragement has been crucial in getting me here. Finally, my partner Jonathan who’s support throughout the ups-and-downs has been greatly appreciated.

It’s about raising awareness of Keratoconus. It’s not a common eye disease, but one that impacts people all around the world. I am one of those people.

What is Keratoconus?

Keratoconus is an eye disease in which the normally round dome-shaped cornea progressively thins causing a cone-like bulge to develop. It affects the eye's ability to focus resulting in short sightedness, blurred vision and ghosting. Keratoconus can also lead to an increased sensitivity to bright lights.

For me, my vision can be mostly corrected by wearing rigid gas permeable contact lenses. So yes, a lot of the time I can see fairly 'normally'. However, I can't wear my contact lenses all the time. Issues like eye infections, scratched corneas, hay fever and tiredness can often restrict my ability to wear them. Also, I rarely wear them in the evenings.

This means I often experience the world through impaired vision. I have lots of experience of using, and working with, the Web using screen magnification, browser zoom and increased font sizes. Sadly, many websites don’t take into account users with visual impairments.

Digital accessibility

To help people like me, and many others who have impaired sight or aging eyes, it’s important that you test your websites for the following:

• Websites should utilise responsive layouts: ensure you test these by changing the browser’s zoom level (things like popups and sticky components can often get in the way)
• Websites shouldn’t disable zoom: disabling this prevents people with impaired vision from making the content readable
• Websites should use relative units for font sizes: absolute units prevent text from scaling correctly to the user’s font size settings
• Websites should use good colour contrasts for text and interactive components

Keratoconus may be an uncommon eye disease, but over 2 million people in the UK live with sight loss. This is predicted to double by 2050! 1 in 5 will live with sight loss in their lifetime. Creating an accessible Web is really important.

I appreciate there are many ethical and environmental concerns around using AI. However, many organisations are expecting their dev teams to utilise these tools. If we’re going to use AI to generate code, we need to recognise its limitations and why our own ability to write and understand code is still as important as it was in the past.

AI makes mistakes, we need to catch them

When we write code, it can contain bugs, security vulnerabilities, performance issues, or just simply miss project requirements. When we prompt AI to generate code, it’s not infallible, it regularly makes the same mistakes we make (and worse).

It’s important that we verify AI generated code meets our requirements, is issue free, and is understandable. We have an existing process for this in software development: the code review.

Code reviews have been a cornerstone of software development for many years. If we’re using AI to generate code, then reviews become even more critical. In order for us to effectively review code, we need to understand it.

Fixing AI’s mistakes ourselves is often best

We’ve established AI makes mistakes. We’re hopefully catching these when we review the code, but how do we go about fixing these?

If we’re already using AI to generate the code, it can be tempting to get these tools to fix the errors for us. However, each time we prompt AI we introduce new variability. This can create new problems as the AI tools we use today are probabilistic. AI will return the most probable answer from the prompt provided, not necessarily the correct answer. Engaging in a back-and-forth with AI can become unproductive, resulting in new issues arising with each prompt.

Often, it is going to be better and more productive for us to treat AI's response as an early draft and modify the code ourselves. To do this, we need at least some basic understanding of how to write code.

If you're not convinced by the productivity argument, research by METR has found experienced developers take longer to fix issues when using AI:

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts.

Code needs the human touch

AI has never ‘lived’ the human experience. It doesn’t know what it’s like to struggle with accessibility issues or navigate cultural nuances. AI doesn’t understand our frustrations of a poorly created app, or the joys a creatively built website can bring us.

Most of the time, we’re building software for people. That’s why our human insight remains essential.

I advocate for diversity in the workplace. It brings different perspectives to a project and helps us build more inclusive solutions that have the widest reach in terms of users. This is something AI will never be able to truly deliver. It lacks the empathy needed to convert code from pure logic to thoughtful functionality.

Practice makes perfect

It’s perhaps important to note that learning code is not enough to be an effective developer, even in an AI powered world.

Watching Youtube clips, reading books and articles, and studying codebases will not fully equip you to understand code. You need to actually write it.

Programming is a creative process, and like other art forms we can only maintain our existing abilities and expand on them by practicing. We need to be careful that we don't become too dependent on AI to generate code; we need to still be able write it independently.

Writing code is fun!

Finally, beyond all practical reasons why you should still learn to code, there’s still a joy to be found in writing it yourself.

Like many others, I started writing code as a hobby. There's something incredibly satisfying about writing some code and then seeing it in action. Like many crafts, it's that sense of achievement knowing that you've built something yourself. Yes, you can use AI to generate some code for you, but there's a soullessness about the end result. Much of the fun of code comes from the process of figuring out how to achieve something, and writing it in a beautiful way.

Final words

AI might be becoming part of our working process. However, real people are still at the heart of coding. We remain the problem solvers, the creatives, the code reviewers and maintainers. When things fail, it is us that needs to engage with the code.

Learning to code today is as important as it has always been.

I am a regular user of Firefox’s ‘reader mode’. It helps me read articles online when my visual impairment is impacting me most. Reader mode removes the distractions from the page, leaving me with just the article content that I can scale to a size that is comfortable for me to read. I have spoken about this feature in my ‘Magnifying the Web’ talk. It has been a game changer for me.

Frustratingly, the latest version of Firefox on iPadOS has replaced this feature with a new AI summary mode. This is not an equivalent feature. Reader mode allows people to read the whole article content, distraction free and with control over the visuals. The AI page summary reduces the content down to what it thinks are the key points, and annoyingly disables page zoom.

Restoring Reader Mode

The good news, for now at least, is that you can turn off AI summaries and reader mode is restored.

Go to Firefox's Settings, then under 'Page Summaries' disable 'Summarize Pages'. This removes the AI summary feature that appears in the address bar and the reader mode button should start appearing again.

I hope this is not a sign of Firefox removing reader mode. This is a really helpful accessibility feature, and one of the main reasons I choose Firefox as my default browser.

There was an incredibly strong line-up of speakers. I loved how inclusive to the room each talk was.

I was attending the conference as the back up speaker; and whilst in the end I didn’t get an opportunity to speak myself, I really enjoyed each of the talks given and was pleased I got to hear everyone speak. Hopefully next time I will be in the final line-up. 🤞

Here were my key takeaways:

• Get the core right and the resilient code will follow (Andy Bell) - Feedback is an iterative team process, we should be using it constructively to make things better.
• Building Better Webs (Olu Niyi-Awosusi) - The web doesn’t have to be corporate, the more people creating an independent web, the better and more valuable it becomes.
• Unwrapping Web Design (Nils Binder) - We don’t have to create the same boring layouts, we should embrace whitespace and margins in more creative ways. (Also, I loved Nils honest share of his desk space)
• Inclusive by design (Amy Rogers) - We should be using tech for good and recognising the equalities in society.
• An introduction to the World Wide Web for very senior programmers (Salma Alam-Naylor) - This talk was a super fun nostalgia trip into the early days of the Web. Perhaps a subtle reminder of how far we’ve come and some of the mistakes we’ve been making along the way.
• Systems of Harm (Amy Hupe) - It’s really important to have diverse teams to bring different perspectives to a build. Otherwise, despite best intentions we exclude people from the end product.
• If it's not user-centred, it's not accessible (Craig Abbott) - Accessibility talks are often dominated by talk of compliance. Whilst this is important, we need to remember compliance doesn’t mean a good user experience. You can be compliant and still end up with a poor inaccessible user experience.
• Summoning Up Old Tricks: Remaking FFIX in the Browser (Joe Hart) - Have fun and make silly things!

I know the organisers put a huge amount of effort into putting this conference on. It was really appreciated.

Hopefully Front End North will be back.

There’s some interesting up and coming ARIA features worth being aware of. aria-errormessage and aria-description are a couple of new attributes that have sparked my interest.

aria-errormessage will work in combination with aria-invalid="true". If an input is flagged as invalid then the value of aria-errormessage will be announced. This has potential to be useful. However, it would need using with caution. We don’t want to be creating two very different user experiences for those using a screen reader and those who are not.

aria-description will enable us to provide supplementary descriptions to an element. A great use here would be where visually an elements purpose is clear, but lost when announced via a screen-reader. For example, a breadcrumb trail, using aria-description we could describe the final breadcrumb as ‘You are here’ (aria-description="You are here:").

As mentioned, these are up and coming, which means support currently remains limited. It’s still good to be aware of what is coming in the future.

WebAIM have a written a great blog post about Up and Coming ARIA. This includes an evaluation of current support for the new features.

As always with ARIA, if you can implement the functionality natively with HTML then that is preferable.