Does the financial services sector have an accessibility issue?

Episode transcript

Amelia Hi, I'm Amelia.

Paul I'm Paul.

Russ And Russ.

Luke And Luke.

Amelia And this is Fin the Week. So welcome back, everyone, and a new face this week — we're joined by Luke for the first time. How are you doing, Luke?

Luke Yeah, not too bad, thanks.

Amelia And just for anyone who doesn't know, what do you do at Indulge? What's your role?

Luke So I'm a web developer — making websites, basically.

Amelia It's lovely to have you.

Paul Yeah — and Luke will probably play it down, but he's also a huge expert on accessibility. He's got a load of experience, hence his presence today.

Amelia Amazing, well that is going to come in very handy.

Russ I actually thought you were going to say something related to bar billiards then, for some reason.

Paul Yeah, he's also maybe a world-famous bar billiards player.

Luke Didn't quite go that far, but yeah, been known to play.

Amelia Love that, love that. So this week we're returning to our consumer duty teardowns, which you may remember from last month, because when we first looked at them I think it's fair to say we were all quite surprised at the scale of the accessibility issues. So for those who haven't yet heard those episodes — Russ, do you want to give us a recap?

Russ Yeah, we went into the teardowns expecting there to be quite a few accessibility findings. Just from what we know about the landscape of the web generally, a large proportion of websites fail against the Web Content Accessibility Guidelines, which cover all sorts of access needs. So it wasn't a huge surprise that half of what we found in the teardowns were accessibility findings. We published an article this week as well, outlining who those affect, so it'll be good to get into that in a bit more detail and discuss some of the people who are going to be struggling to use these websites — and your average user wouldn't even be aware. And then alongside that, there's the obligation that regulated firms have to make their websites accessible, so that consumers can understand what they're buying and get the support they need throughout the lifecycle of the product.

Paul Before we go into all the findings, is it worth us addressing what the Web Content Accessibility Guidelines actually are? We talk about it all the time internally as a company, but I often think — do people outside the agency and web world really even know what this is? So who wants to give an overview?

Russ Yeah, absolutely. The Web Content Accessibility Guidelines were put in place by W3C — and people might not know what W3C is, so we probably need to backtrack a bit further than that. Essentially, the internet itself was invented by Tim Berners-Lee in 1991 — a long, long time ago, I was ten, which shows my age. He founded W3C, the World Wide Web Consortium, which put in place a set of guidelines and standards. Even if you're not techie, you might have heard of HTML, CSS, or URLs — those were all put in place when the web, the commercial internet, started, by W3C. W3C introduced the Web Content Accessibility Guidelines as a framework to make sure websites are accessible, and there are a number of checks in there — probably around 50 high-level checks — looking at making sure the colour contrast is correct, that you can use a website with a screen reader, that you can navigate a website using a keyboard, and that you can use it in situational needs — for example if you're looking at the screen in bright glare, or you're in a noisy environment without headphones so you need captions on video. All of this was introduced by the consortium who built the commercial internet as we know it today, so it isn't just a random set of guidelines from a third party — this was introduced by W3C. They also more recently introduced a layer on top of that called ARIA, which we might discuss a bit today — it's almost a bit of a hack to make websites accessible by overriding some of the semantic code, so maybe getting a little too technical there. But that's where it came from. That framework, introduced by W3C, has been adopted by the UK government, so most public sector websites conform to WCAG 2.2, the latest set of accessibility guidelines. The FCA also recommends that regulated firms abide by WCAG — or WCAG, as people tend to refer to it.

That's the background — but in terms of the ins and outs of what it actually is, Luke could probably explain in more detail, because he's done accessibility auditing in great detail himself.

Paul A question I wanted to ask you, Luke — quite often we'll read briefs for projects, websites or apps or whatever, and part of the brief will just have a passing comment that it "must comply with WCAG to double-A standard." So the first question is, what do people mean by double-A, as opposed to something else? And the second — is it as simple as treating it as a checkbox exercise, or is my understanding right that the guidelines aren't just a list you can tick off, but more things you apply depending on the context?

Luke So for the first question — there are three tiers of the guidelines: single-A, double-A, and triple-A. Single-A is the weakest set, and most websites will comply with that naturally because it's quite easy to do. Double-A is probably the first tier worth actually trying to achieve, and it's good for the vast majority of sites. Triple-A is the next layer on top of that, and it's very difficult to achieve — but if you've got a lot of users with specific needs, it's perhaps something to try for. Double-A is generally good enough for most sites.

As for the second question — that's definitely how I've always approached it: these are just guidelines, not a strict set of rules, and they don't cover every single scenario. If you actually read through them, you can click into each guideline and there'll be a detailed description, but often with three or four examples of where it applies and where it doesn't — it's very much a context-based thing. Sometimes it'll be applicable, sometimes it won't, and even down to whether it's a minor or major issue depending on the context. On top of that, there are going to be a lot of scenarios that aren't specifically covered by the guidelines at all. So it's worth considering your user base and how they're interacting with the site — even if something isn't technically covered by a guideline, is it still an issue worth solving?

Paul Does that mean it's technically impossible to say definitively that a site complies with double-A, because it can be sliced in different ways?

Luke That's my opinion. There are a lot of people who'll say you can, and they'll get a big tick to say they've passed the double-A standard, but I think in reality it's very difficult to say conclusively that you've passed. There are a number of guidelines, for example, that are content-related — not even down to how the site's been built, but the copy that's been added to the site. The only way to review that is to go through every single page and check whether it complies, so even just that alone is difficult to conclusively pass. And the copy on a lot of sites is constantly evolving too, so unless you're continually checking the site, it's very difficult to say conclusively that it passes.

Amelia And just to recap, for anyone who hasn't yet listened to the teardowns — which you should absolutely do — we scanned 12 financial services websites: three banks, three investment platforms, three mortgage brokers, and three insurers. And this is what came out of it — as I say, accessibility was the main theme through every single episode. Shall we go into a bit more detail about what was actually found?

Russ So in total there were around 600 findings, and half of them were accessibility. We've broken that down into categories too — a huge proportion of people who use screen readers encounter issues across their journeys on these firms' websites, around 83%. And it's not just someone who's blind who uses a screen reader — you could have a learning or cognitive disability and prefer a screen reader because you understand the website better through audio. There were some quite clear technical issues that would jumble up how a screen reader announces the page — missing headings, labelling issues, landmarks, that kind of thing. You could put VoiceOver on and go to these pages and have a really hard time just closing your eyes and trying to navigate. So that was a clear issue — screen readers are obviously the big one that stands out.

Paul Is that a good point for us to ask Luke — what actually is a screen reader? Because I imagine most people listening probably don't even know — they wouldn't be able to name a screen reader or know what it does. So what is a screen reader, what does it do, and what about the kind of issues Russ was alluding to there — reading things in the wrong order and so on? What actually happens, what are we looking for when we talk about that?

Luke There are actually many different types of screen reader, which adds to the challenge of making a site fully accessible, because there are just so many different ways a user can interact with a site. But the basic idea is that a screen reader will look at a page and read out the text. So if you imagine you're completely blind and can't see the website at all, it'll go through step by step and read out the text so you can still consume the page.

There are many different screen readers — one of the more common ones, built into iOS and macOS, is VoiceOver, so that's quite popular. There are a couple of big ones on Windows, and one built into Android as well, and I'm sure there are many others on top of that. In terms of specifics, I don't want to give a conclusive list, but there are a few common things I look at — if I put myself in the mindset of how I'd want to interact with a page if I couldn't see it. There's a mode where you can loop through all the headings on a page — again, thinking in that mindset, you don't want to read the full page top to bottom, because that's not how someone who can see would interact with the site; they'll naturally just scroll down past the header. So that's one way to quickly find the exact point on the page you want. There might be other modes too, like listing out all the links on a page, so you can quickly find the page you actually want to get to, because maybe you're not interested in the homepage. So there are a bunch of different modes that surface specific parts of the page, so you can very quickly navigate to wherever you want — or you can just read the full page, if it's a news article or something where you do want to read everything step by step.

Paul So bringing this back to what you identified, Russ — 83% of the findings highlighted issues in that area. So is that basically saying that, for example, when we talk about landmark issues, a site has been built in such a way that a screen reader user landing on it won't necessarily be able to jump to specific sections, or it might read things in the wrong order? Is that basically what happens?

Russ Yeah, from what I understand — and Luke, you mentioned going through the page — landmarks are how the screen reader knows where to go next.

Luke Landmarks are another really important one, and it does what it sounds like — it describes key sections of the site: this is the header, this is the main content, this is a sidebar, this is the footer. So again, it's just another way of quickly navigating to the section of the site you actually want to read.

Paul I find this whole thing really fascinating, because it's a whole unseen world — if you're looking at a page visually, it might look perfect, but if it hasn't been built with this stuff in mind, it could be a complete disaster for somebody who relies on a screen reader. And that's kind of what we've found, isn't it?

Russ Yeah, and in my article recently I commented that it almost makes websites easier for everybody to use, whether you're disabled or not, because there are so many circumstances where an alt tag, for example, would be useful. If you've got low bandwidth, the alt tag will display instead of the image — so from a situational accessibility perspective, if you're travelling on a train and images aren't loading, you're still understanding what should be displayed, through the alternative text. Alternative text was one of the things we found — we've related that directly to screen readers, because a screen reader wouldn't know what an image is without it. But there are loads of situations where accessible websites are just better for everybody because of the different scenarios you're in, often without even realising it.

It would be a really interesting exercise to do some usability testing — take a website that at first glance didn't have all of this: colour contrast slightly off, maybe the wrong language used, a few labels missing on forms or not written in the right way — and then run the same test on a site that looks very similar but ticks the box for accessibility as closely as possible. Track a few metrics like satisfaction and time to complete tasks. That'd be a great exercise, wouldn't it — I think I've just given myself my next project there.

Amelia Seems like we've got another episode coming on, Russ. So we talked about screen readers — what else did we find specifically?

Russ After that we found that keyboard usage issues were quite high — nearly 10%. This is a really interesting one. I know people with RSI who often need a break from using their mouse, and I had shoulder surgery a couple of years ago — I couldn't use my arm, so I was actually using a keyboard one-handed for a while. That's where the point comes in that a lot of people, at some point in their lives, will need to use websites in a different way. For a period I couldn't use a mouse particularly well, and I was doing keyboard navigation. It's quite an interesting area, because a bit like screen readers, if it's not set up correctly for keyboard navigation you just get completely lost on the page and it's quite frustrating — if you tab through a page and it isn't set up right, it's almost unusable. So we found that.

Maybe that's a good time to ask you too, Luke — is there a difference, technically, between setting up for a screen reader and for a keyboard-only user?

Luke Yes, there is. There's certainly a lot of crossover — if you imagine you're completely blind and using a screen reader, you're not going to be using a mouse, because you have no idea where it is on the screen, so you'll naturally be using a keyboard too. But from a technical standpoint, there are definitely different things you'd apply for keyboard navigation. A common one we see is that you need some kind of visual indicator of what you're selecting with the keyboard — typically an outline or a glow effect around the element — and a really common issue is that it's just not there at all, so even though you can technically navigate with the keyboard, you have no idea what you're actually clicking on, which makes it very difficult to do anything.

The other common issue is that navigation gets stuck somewhere — some script overrides things, maybe for a legitimate reason, but then you're stuck within a particular area with no way to escape it using the keyboard. Again, that makes it completely useless for keyboard navigation.

Going back to your point about accessibility not just being for people with disabilities — I often use keyboard navigation myself. If there's a site I'm using regularly and need to do a repeated task, it's generally a lot quicker to use a keyboard to navigate to what I want. So if you've got a lot of repeat users on a website or web app, it has a lot of value beyond just accessibility.

Paul That's a really good point, isn't it — we've worked with financial regulators who have documentation on their website that legal professionals access day in, day out, and there's a good chance a large number of them rely on exactly what you've just described.

While we're on screen readers and keyboard use — when you come to building a new website, does taking care of this stuff create extra work, or is it more a question of doing things in the right order and taking a bit of extra care? Is it more work, or is it just the right work — I suppose that's the question.

Amelia Great question.

Luke It's a combination of both, I think. Especially with the modern web, it's very easy to make an accessible website — the problem is a lot of developers have learnt to do things the old-fashioned way, which just isn't accessible. HTML is built up using tags, so you can describe what an element is on the page. Historically you'd use basically one tag for everything and just style it differently, but these days there are different tags for different things — I can describe this as specifically a navigation, or a sidebar, or a footer, and using that tag comes with all that information built in. We talked about landmarks before — if I use a footer tag, it's just inherently a footer; I don't need any extra effort to describe it as one later. That goes for a lot of things — we talked about keyboard navigation and having a focus style so you can see where you are on the page — that's there out of the box. The problem is a lot of frameworks, especially older ones, suppressed that, hid it completely, and made it very difficult to add back in. So especially on a legacy website, there's a good chance that's happened, but it's actually more effort to take it away than to just leave it there in the first place.

Then equally there are things that do require a bit of extra effort — if you've got a menu with a dropdown, for example, there'll be some custom script to implement that, and then a bit of extra effort on top to make sure you can navigate it with a screen reader and a keyboard. But generally speaking, as long as you plan it out from the start, it's not that much effort. Where the effort comes in is if you build a site that isn't accessible and then need to retroactively fit all of that in — when it just hasn't been designed for it in the first place. That's where all the effort goes.

Russ On the topic of building — surely now, using AI, you can just ask Claude, or whatever you're using, to make your website fully WCAG 2.2 accessible? It feels like that isn't happening, and that's kind of a real surprise. Going back to the WebAIM report, what always surprises me is that homepages and websites are getting more and more complicated — page elements have increased on average by 22% since last year, and someone with access needs is encountering an error in, on average, one in every 26 elements on the homepage, which is mind-blowing. It doesn't seem to be tapering off — the average rate of accessibility issues found is still really high. You'd have expected that to have tapered off by now if AI development was having a huge impact. Why is it that AI can't fix this in the development process? Is it just that so many people are producing so many websites at bad quality that the average stays high, and the proportion of people actually using AI correctly to deliver them is still such a small percentage?

Luke I think it's a combination of factors. AI can create very accessible sites — the issue is that unless you're actively thinking about accessibility, it's very hit and miss whether it actually does that. It'll probably get the basics, because if you use semantic HTML in the first place it's just inherently accessible, but for more complicated interfaces, unless you explicitly say "make this accessible" and maybe even point it towards specifically what you're trying to implement, it might do it, it might not. Fundamentally, the issue is that a lot of developers just don't consider accessibility, so it's still very hit and miss whether it happens.

I think one of the other issues is that AI has ultimately been trained on all the code that's publicly available, and a lot of that code isn't accessible — so it's learned a lot of bad lessons from existing sites. I think things will probably get better, but it's going to be a little while before you can just prompt Claude to make a website, not consider accessibility at all, and have it just do it for you. At the moment, and for the foreseeable future, you probably do need to put a bit of thought into it.

Amelia So we've spoken about screen readers, we've talked about keyboard — is there anything else that we found within the teardowns worth noting, Russ?

Russ There are a couple more. I think colour contrast is the other big one — going back to WebAIM again, it's the number one problem they find across all those homepages. It's potentially a bit of a grey area, because if you're just under the ratio — I think it's 4.5 to 1 for AA, I'd have to check — it gets flagged as an accessibility failure, even though for most people that'd probably be fine if it was, say, 4.3. But what was surprising when we looked at it is that one site's ratio was down in the threes, and it was their primary brand colour — that stood out because it was this bright red, with white text on it, which I mentioned on a previous podcast. It genuinely burnt your eyes trying to read the white text on the red, across their entire website, and that's a proper major accessibility issue. If it's just under the ratio and gets flagged, it's not too bad — it's only a real problem if there's a big difference. So you do have to take some of these flagged percentages with a pinch of salt.

The other one flagged, at a lower percentage — and bear in mind we're talking about a sample size of 12 here, so it's not really statistically significant; it'd be great to look at 100 or 1,000 sites realistically and see where these common themes sit, and I imagine colour contrast would increase a bit more — was touch targets. Really interesting one. The accessibility guidelines specify how big button targets should be — if you need to tap an icon, say to page between news articles or scroll through a gallery — and websites often get this wrong, making them too small. That's good for everyone: people with lower dexterity, for instance, or if you're travelling on a train or the tube and it's difficult to hit these touch targets because you're being bumped around. That's kind of why the guidelines exist — just to make websites easier to use. So that was another one, and it's not difficult to fix, because you just increase the size of the buttons.

Luke And you can even keep the buttons visually the same size if you want, and just have an invisible click area around them — so you don't necessarily need to change the design to accommodate this.

Amelia For someone who knows absolutely nothing about this, it seems such a simple ask — you'd think anyone looking at it with the naked eye would think that looks a little small. Why does it end up wrong? Is it purely a visual thing, that it looks better a bit smaller? How does it end up like this?

Russ I think fundamentally it's an issue with the design system. From a production process perspective, you'll probably find these sites don't have a proper design system, so there are hundreds of different sizes of buttons and icons — these little things you click on — and it affects a wide proportion of people. We think of ourselves as specialists in the industry and assume people won't understand what we're talking about, but think about how many millions, billions of people are using interfaces today — on social media, or to manage their finances, where they're on their phone clicking on these little navigational elements to open and close accounts or transfer money. It's so widespread, I think people would be really surprised.

To fix it, ultimately you start with a design system — you have your interface elements preset so all the sizes are accessible, and that cascades through your website and your apps. That's what you need to do. I think there's a big shift in the way we're producing websites and apps now — as you mentioned, Luke, because there's more focus on this and we're using AI, you'll probably find this becomes more consistent over the years. But we're still in a bit of a transitional period, with a lot of legacy work out there, a lot of poor-quality work out there, where these issues are found.

Paul One thing that stood out to me through all of this — you mentioned, Russ, that this isn't a huge sample size, only twelve firms. But at the same time, you didn't go looking for issues — you just selected prominent firms. Amongst these were effectively market leaders, challenger brands, and some smaller niche firms too. And yet, without really trying, you uncovered some really fundamental issues, and I suspect a bigger sample would just reconfirm what we've found. It's such a huge, wide-reaching issue, and it doesn't make sense why it doesn't appear to be taken seriously.

Luke, you mentioned that developers maybe just don't learn to take this into account — why do you think that is, and what fixed it for you? I guess you were just conscientious and went and did it — is that the answer?

Luke Like a lot of developers, I just didn't learn about accessibility — that's fundamentally the problem. Then we had a website with specific accessibility requirements, so I learned a lot about it at that point, and ever since then it's sort of opened my mind — it becomes very obvious when you see a site that doesn't have certain things in place. So I'll always go out of my way now to make sure whatever I'm building is accessible.

I think a lot of developers just don't learn accessibility because it fundamentally wasn't taught. It's a little better now, but I think a lot of tutorials still don't really mention accessibility at all — maybe they'll accidentally teach it, but they won't go out of their way to explain why you should do things a certain way. So there's a lot of opportunity for actual accessibility tutorials that explain how to do things correctly in the first place. But with AI, it's easier than ever to figure this stuff out — if you're not sure how to make something accessible, just ask: how do I make this accessible? And generally you'll be pointed in the right direction.

Russ One of the big shifts for me as a designer — because I approach it from that foundational perspective, you design a website and then hand it over to be built — is that when I was younger I had this almost myopic view of my own work: it looks okay to me, so it's probably okay for everyone else. As you grow into your role and get more experience, you start realising you're designing for other people, not yourself — we're actually creating apps and websites for other people to use. As soon as you shift that mindset, so your empathy is with the end user, you naturally start realising you should make websites more accessible, because they need to be used by everybody. People aren't just using your website without access needs — there will be people with access needs using it, so why wouldn't you support them? That's the biggest shift, and you see it time and again in design and every type of digital production — where you're not involving the end user, getting their feedback, or thinking about them at all. It's that user-centric mindset you need when creating anything.

And on the WCAG point — you could tick every box on that list and it still doesn't mean a site is accessible. You still need to test the website with someone with access needs, someone who uses screen reader technology day in, day out, and make sure it works for them — because there are so many ways they might have things set up differently that you haven't tested. So it doesn't just end at the guidelines — that's the mindset shift you need to make.

Amelia We've identified the problems, and perhaps how we're getting here — but why does this all matter, beyond it obviously being the right thing to do?

Russ Like I touched on — we're creating websites, and we shouldn't be isolating groups of people, or people in certain situations, from using these products. From a consumer duty perspective, firms have an obligation to provide evidence that these websites are supporting their customers and that they're easy to understand. It'd be interesting to see — and it would be great to have some influence on this — whether firms are now evidencing accessibility of their digital products. In my opinion, if a board report is looking at a digital journey, it should include accessibility, because that's absolutely fundamental to supporting vulnerable customers, which is part of consumer duty. People have spoken to it being taken very seriously, a standing agenda item in board meetings, but it'd be interesting to see what level of detail the FCA are requiring around digital accessibility going forward when it comes to evidence — because WCAG is a recommendation at the moment, but if they introduce it as a requirement, like 2.2 for the public sector, these firms are going to have a lot of catching up to do.

So as well as being a regulatory recommendation, as we've discussed, the number of people who'll have a better experience using accessible websites is huge, and that seems to be increasing too. With an ageing population — I think we were looking at some RNIB stats that sight loss is expected to double by 2050 — this isn't something that's going away, and accessibility is only going to become more important.

Amelia I think perhaps you've already answered this, but what would we say to a compliance lead who thinks this maybe doesn't apply to them, because they're not disability specialists? Is it just that this is everyone's problem?

Paul The thing that always stands out for me is that something built with accessibility in mind is usually a better experience for everyone. Funnily enough, I was watching a programme the other day — I think I've mentioned it on the podcast before — Professor Hannah Fry, who does a lot of work with the BBC. She visited a building designed for inclusivity, specialising in — I think it was for a charity for blind people. The building was designed with that in mind, so the acoustics made it easy for people to orient themselves and know where they were when they stepped out of the lift, where the big space was. It had walkways that were hard floor, and then as you moved into a zone, say the reception desk, it became carpeted — simple things like that. But the takeaway was that it was a more pleasant building for everybody: people who couldn't see reported it was a much easier building to navigate, there wasn't overwhelming noise reverberating around, and they could work their way around knowing exactly where they were. For Hannah Fry, walking around, her experience was just that this was a really cleanly, smartly designed building. I think the same can be said of web applications and websites — if it's designed with accessibility in mind, everybody appreciates it, I'd argue.

The other thing worth thinking about is how you encourage a compliance lead to experience a website not just visually. Are there simple things — Luke, for example — that you'd say to somebody, like putting yourself in the shoes of someone else and navigating the site with your keyboard? Things like that are what we should be encouraging.

Luke Absolutely. I think the screen reader one is probably the biggest one for me, because as someone who interacts with a website using a keyboard and mouse, it's just such a fundamentally different way of interacting with a site. The more accessibility work and testing I've done, I've got into the habit of literally having the website on a different monitor I'm not even looking at, opening up a screen reader, and just trying to navigate the site — not just going through the checkbox of "are there headings, are there links," and so on, but actually trying to navigate it and noting any issues I keep running into. Like you said, Russ, there are a lot of things that aren't necessarily covered by the guidelines, and that's a good way of picking up on those.

Another simple way of doing this — we touched on landmarks — I can't remember the name of the plugin off the top of my head, and I think some of these might even be built into browser dev tools these days, but there are ways of visualising the landmarks. So even if you don't want to use a screen reader to check whether they're correct, there's a way of putting little boxes on the different landmarks with a label saying "this is the header," "this is the footer," and so on — a nice easy way to check that stuff without going the full mile of using a screen reader. There are a lot of tools out there that help you see things from someone else's point of view. Another good one — we touched on colour contrast — there are plugins that will show you a website as if you were colourblind, with different types depending on which kind of colour blindness, so you can very easily see the issue someone else might be facing, like a link that isn't visible against a particular background.

Russ I don't think it's a huge compliance task, although it depends how broken these websites are — we're finding a lot of issues, and there are a lot of issues. But from a compliance perspective, I'd say look at your key journeys — applying, onboarding, servicing, exiting, finding help and support — and just ask: can someone use this process using a screen reader or a keyboard? If they look at those two, plus colour contrast, for those journeys, that's really just three or four checks — because there's a bit of crossover between screen reader and keyboard usage. If they get that right, and look at colour contrast too, which covers low vision and colourblind users, then just with those three, across the key product lifecycle journeys, they've suddenly made everything a lot more accessible.

I think it can seem a bit overwhelming when people talk about WCAG, and how difficult it is to comply with 100%, so perhaps that isn't the right angle to convince these firms to make their products accessible. Forget about that — think instead about what people are using to access your website, and how you can fix it for them. WCAG can still be the recommended guideline, obviously, but maybe firms need to look at it from a slightly different angle.

Paul Is it a case of reviewing critical journeys first, and then going further if you can and want to? So on an e-commerce site, it'd be about making sure someone can buy something easily — it doesn't necessarily mean they can read the blog. You do it in order, I suppose — maybe that's another pragmatic way to look at it, if firms are concerned about retrofitting this stuff, since a lot of firms have legacy systems and it's just not possible to retrofit everything. I wonder if that's why the FCA don't go further and mandate double-A standard — whether their concern is that it's just too onerous for a lot of companies with historic systems.

Russ It would cost millions of pounds to retrofit a big internet banking platform, for example — it'd be easier to implement on the front end of a mortgage broker's website, say, someone using their mortgage calculator. So there are different scales, and because it'd be an obligation, perhaps you're right, that's why. But taking a softer approach — maybe not a WCAG obligation as such, but just those simple checks on key product lifecycle journeys, or at least where they stand: is the risk low, medium, or high? And now, going into year three, the FCA are asking for evidence and taking action on it, so look at those onboarding journeys, flag them, maybe using something like RAG ratings, and show that they're improving over time. It'd be good to see firms doing that as part of their checks.

Amelia Definitely would — and I think that's probably a good place to leave it for today. I'm sure we'll come back to accessibility in future episodes, but before we go, shall we play some Jargon Busters?

Paul Yeah, let's give it a go.

Russ Yep.

Amelia Luke, do you know how this goes?

Luke I'm vaguely aware, and I probably won't do very well, but I'll give it a go.

Amelia That's all right — so we have a list of industry terms, and each week I put the guys to the test to see if they can explain its meaning. Today's term is AER. What do we reckon — AER?

Paul I don't know what the actual letters stand for, but it's to do with... what's the word I'm looking for — isn't it interest on a loan, or the annual amount that you accrue? I'm explaining this badly — it's something to do with when you take out a loan.

Amelia No, you aren't — you're on the right lines.

Russ Yeah, I think so as well — if you take out a savings product and it matures, you'd get a certain rate. But the actual acronym... annual earning? Is it earning? I can see you smiling, Amelia — I could have it wrong. What is it?

Amelia You got the annual bit right. Luke, any thoughts?

Luke No idea — I'm happy to go along with everyone else on this one.

Russ R for rate, at least.

Amelia Yes, yes it is — it's annual equivalent rate. And you were absolutely on the right lines — it shows what the interest rate would be if paid and compounded each year. So there we go — you didn't quite have it, but...

Paul Do we get a point for that?

Russ Yeah, okay — on the right tracks.

Amelia Maybe half a point, maybe half a point. But of course we'll have more Jargon Busters next week. We'll be back next week, Luke — great to have you on the pod, I'm sure we'll see you again at some point. But yeah, that's it for this week, and we'll see you next Friday.

Russ Thanks — see you.

Paul Cheers, see ya.