Meet the team: Ian Lloyd

Posted on Wednesday, 1 October 2025 in Meet the team

Meet Ian Lloyd, or Lloydi to you and me. He's a creative soul at heart with a wide range of hobbies and, of course, a deep-rooted enthusiasm for accessibility, which has extended into books, blogs, tools, and working with us!

He’s been involved with accessibility and web standards since the early 2000s, back when the Web Standards Project (WaSP) and its Accessibility Task Force were encouraging companies like Macromedia and Adobe to produce tools that generated standards-based, accessible code. At the same time, he was a front-end developer with a habit of talking about accessibility to anyone who would listen.

Lloydi also wrote a book called Build Your Own Website the Right Way Using HTML & CSS, which went on to become a SitePoint bestseller since it was first published almost 20 years ago.

A family man at heart, Lloydi has been married for almost 20 years, raising twins who are, in his words, “two peas from two entirely different plant species’ pods.” His family lives among his old DJ kit and the odd vinyl record released in his name from years ago. The household is completed with two furry friends: Roxy, the Cairn Terrier, and Rambo, a tiny dog of indeterminate breed.

Music has always been a constant, ever since the early days. Before his full-time shift into accessibility in 2019 (when he joined Apple’s UK accessibility team as a contractor), he’d already had a sideline as a DJ and producer, releasing records on vinyl and even landing The Prodigy (Warning: there is strobe lighting on page load) their first magazine front cover back in the 90s (sadly, the physical proof was lost when the magazine got left behind in a house move but this doesn't make it any less true)!

After five years at TPGi as a Principal Accessibility Engineer, Lloydi joined TetraLogical as a Principal Accessibility Specialist. Here, he puts his web development background to use by building prototypes for complex accessibility challenges and creating tools to spot issues that off-the-shelf testing software might miss. He continues to speak at conferences, contribute to books, and is always looking for ways to make accessibility more practical and effective.

When he’s not doing that, you might find him out on his childhood BMX (a 1984 Haro Freestyler for those in the know), or edging back into photography after blaming the iPhone for years of laziness. He’s fully aware that becoming “camera guy” again could be dangerous for the bank balance, but that’s all part of the fun.

All told, whether he’s unpicking accessibility conundrums, producing music, or bombing around on his BMX, Lloydi brings the same mix of persistence, creativity, and slightly mischievous enthusiasm.

What’s the one thing you wish you’d known when you started learning about accessibility?

That one day it'd take over my life?

Seriously, though, when I first started to learn about this stuff back in the early 2000s, everything was much simpler as far as accessibility was concerned. There were very few resources available at the time, other than the early Web Accessibility Initiative (WAI) and Web Content Accessibility Initiative (WCAG) documentation (which was also much simpler - or less comprehensive, if you like) and HTML standards.

Had I known how the web would change, and how we develop for it, I might have chosen to become a welder, park ranger or something else entirely different. The absolute bloated mess that is produced by so many of the current frameworks, production and publishing processes has made the task of creating accessible content so much more difficult. So, practically speaking, I wish that I could have been more involved in the early days of the development of some of these tech stacks. It would have been wonderful to have contributed to the code base early doors and avoid a lot of the issues that are now just wrapped up in what they generate, with limited ability to change them. Having had a few opportunities to provide accessibility feedback and advice on code and markup used in design systems before they are used in production, it's clear how much of a difference this can make to the end product.

When developers are using frameworks like React, it's so much more difficult for people who are providing assessments and consultancy to say, "just fix this HTML here", because the chances are the developers have touched about as much raw HTML as the amount of steel plates I've welded (which is none). So, if you ever have the opportunity to contribute to such things from the outset to head off issues further down the line, I'd definitely encourage doing that!

What’s your top accessibility tip?

This is very much aimed at developers: don't try to be too clever!

Actually, that also applies to UX and designers. It seems like there are plenty of people who will strive to make an interface do something cool, new, or interesting, dismissing years of research, convention, and learned behaviours. We used to see that all the time with Flash-based sites, but Flash is dead, so that's progress of sorts!

It's so important for people from all walks of life to get access to proposed designs before a single line of code has been written. Does the interface look a bit ... funky? Is it obvious what needs to happen here? If the warning bells are starting to sound, there's a chance to put things right. And that's not limited just to accessibility specialists having their say, I should clarify. A designer can't know everything, and along with accessibility issues that they might unwittingly introduce, there may be cultural missteps, confusing language, and who knows what else? The broader the audience who get early access, the better it is for everyone.

What’s your top accessibility resource?

The pages that I refer to most are the WCAG Understanding docs. The normative docs don't really give you the details, they just give you the basic 'what it is'. The understanding docs really help to explain what this means in practice, and they are updated when confusion arises (albeit after some very lengthy and sometimes fraught discussions ... at this point I look in Patrick's direction expecting a knowing nod).

After that, the pages that I reference the most are those that cover patterns for more complex widgets such as the ARIA Authoring Practice Guidelines.

If I may be so cheeky, I'll add one other, which is my own site: a11y-tools.com - mainly for the bookmarklets.

Very much following the 'eat your own dog food' mantra, I use these tools all the time. I often find that while page and site scanning tools like Axe, ARC Toolkit, and Wave provide broad coverage, the way they display issues isn’t always useful. For me, the challenge is "how can I show this in a way that makes sense to the developer who needs to fix it?".

So I create tools and visualisers that expose accessibility issues in a way that makes sense to me, that lend themselves well to a screenshot when filing an issue or sharing with teams. I share these tools with others because I suspect I'm not alone in wanting to visualise issues in this way. I literally use them every day while carrying out assessments, it's definitely a top resource for me (and by me).

Next steps

Find out more about TetraLogical, the team, our principles and our community.