Transcript of the podcast

Video version of the podcast is available on YouTube.

Summary

In this episode of focustrap, Tim Damen speaks with Jan Jaap de Groot, a prominent figure in digital accessibility. They discuss Jan Jaap's journey into the field, the mission of the Foundation Appt, and the importance of accessibility in app development. The conversation covers various topics including the differences between Android and iOS accessibility, the role of the Mobile Accessibility Task Force, and the challenges faced in creating accessibility standards. They also delve into the future of accessibility with AI, the impact of the European Accessibility Act, and the necessity for companies to integrate accessibility into their development processes. The episode emphasizes the ongoing nature of accessibility work and the importance of user testing and training.

Automation can help identify accessibility issues but is not a complete solution. - Jan Jaap de Groot

Chapters

About Jan Jaap de Groot

Jan Jaap de Groot is an Accessibility Engineer at Abra, dedicated to making applications accessible for everyone. Based in 's-Hertogenbosch, Netherlands, Jan Jaap contributes to digital accessibility through multiple channels. Beyond his role at Abra helping companies create accessible applications, he shares knowledge freely through the Appt Foundation and serves as an invited expert at the W3C, where he facilitates the Mobile Accessibility Task Force.

Follow him on:

• LinkedIn
• janjaap.com)

Collaboration is key in developing accessibility standards. - Jan Jaap de Groot

Join the Conversation

New episodes will be released regularly!

Ready to join us on this journey? Subscribe to focustrap wherever you get your podcasts and stay tuned for upcoming episodes that will inform, inspire, and help you contribute to a more inclusive digital world.

• focustrap on Spotify
• focustrap on Apple podcast

Together, we can make technology work better for everyone, one conversation at a time.

Transcript

Focus Trap Podcast - March 29, 2025

TD: Hello and welcome at Focus Trap, a digital accessibility podcast. My name is Tim Damen and I'm joined today by Jan Jaap de Groot, chairman at Foundation appt, facilitator of the Mobile Accessibility Task Force at W3C and co-founder and accessibility engineer at Abra. Welcome Jan Jaap in the studio. So nice that you can join us here. Always nice in the studio, of course. We have a lot to discuss, but I want to start with a question to you. That's my signature question by now. What does digital accessibility mean to you?

JJ: Good question. For me, I first started during my studies, so I studied software engineering. In my third year, I had a project about building an app for a company. In my case, it was the Accessibility Foundation in the Netherlands that signed up or actually they sent over the project and I agreed to work with them with fellow students. That was my first encounter with blind people, at least in a sense that they were able to use an app. So at first I didn't know that they would be able to use an app because I felt, oh, it's a touch screen.

JJ: How would someone that's blind use it? Still, when I talk to people now, they are also surprised when I tell them that blind people can use, for example, an iPhone. So then I really saw the challenges that they told me that a lot of apps are not usable for them. So then I really tried in this project, that was the goal, to make an app that was fully accessible for blind users first. And then secondly, for people that are not blind. So it was an interesting perspective. And from there on, I just tried to consider accessibility in my future projects.

TD: You were introduced with the topic when you were studying and came into contact with Stichting Accessibility already. That's nice. They signed up for the project.

JJ: It's nice for me now that it's sort of a full circle moment because I learned from them and now with my own company and foundation, we are working with them and also working at the same university that I studied. So now I'm giving a guest lecture there and workshops to also teach people, students about accessibility there.

TD: So that's nice. Yeah, that's nice. Nice direction they're taking. So there's more room to learn about accessibility as well over there. Which study?

JJ: Nowadays it's called HBO ECT. So it's like a broader ICT direction. And the one direction I chose was called Informatica or like Informatics, I guess, or computer science in English. So now it's called software engineering. And then there's a specialization in the third year and you can choose advanced mobile development and it's still there. So it's almost 10 years ago for me. Yeah, they still provide it and they have part of this class they have accessibility. So that's nice that students that use a project have to do something with accessibility.

TD: Okay, okay, interesting. Actually, today I just, this afternoon I was at the University of Amsterdam, the front end bachelor study as well. And they also do a lot of things with accessibility. So that's really nice to see. Yeah, it's nice. Also an assignment from the bank, I gave them. It was also about accessibility. It even got some vulnerabilities for us from our website. That was nice. Nice feedback for us. Nice. So yeah, I announced you. You're doing a lot of different things. I think a really nice one to start with. Also, maybe when you've spent a lot of time on the foundation apps.

TD: Can you explain maybe a little bit?

JJ: Yes, that's when I started out. My personal goal is to share more knowledge about accessibility of apps. Because when I first started building apps, there was just a lack of knowledge about apps there still. Not many resources about apps. I think apps now with our website apps.org is one of the most visited websites I believe now about accessibility of apps. So that's nice to achieve that. First goal was just basically creating a resource that I was missing myself. Because if you want to make your app accessible, it's just very difficult to find how to do it.

JJ: And so first we started in Dutch with apps.nl. And then I met Paul, Paul van Workum. He's also the also co-founder of the App Foundation and also now working together with me and my company, Abra. So now we're together there as co-owners. And yeah. We made the handbook, free handbook, also sharing those at the universities to help students with accessibility. And I think most people know us for the code samples because we have now over 300 code samples from multiple platforms to really teach developers how to make apps accessible.

TD: That's very nice. Are you more leaning towards Android development or more iOS development?

JJ: A difficult question I started because I was studying with Android. For me, it was also only possible because you need a Mac to start with iOS and then as a student, I couldn't afford the Mac. So eventually later in my third year when I took this subject I mentioned earlier, then I had some money. So I purchased a Macbook and then I started also with iOS. Personally, I think iOS is better accessibility. It's more easy and Apple has had features for a longer time. So I would say I prefer iOS, but Android is catching up and Android has more.

JJ: It's more open system. So sometimes you can achieve things that on iOS you cannot achieve. So it's, uh, I like both probably iOS. I mean, I am more of an Apple user with my MacBook, iPhone, Apple Watch. Yeah.

TD: I'm also fully with you on the iOS side, but I also spoke with someone who told me, gave me another perspective on Android accessibility development as well. Maybe you know his name, Quentin Balson. He's big on Android and he says there's a lot of detailed customizations you can do on Android that you cannot do on iOS. So you can go, if you know it, you can go into more depth with Android.

JJ: Yeah, definitely. I know Quentin is very deep into Android, very knowledgeable. a lot of things you can do on Android that you cannot on iOS. So I think customization, it can be better. And I heard of people that have like severe motor impairments that they prefer Android because it just has more abilities to maybe emulate certain switches or certain actions. So you're customizable.

TD: Yeah. When I think in terms of the default apps, maybe in default accessibility features, I was... Yes, I think most apps from Apple are pretty accessible.

JJ: I mean, not according to the web content accessibility guidelines, but according to their own human interface guidelines, they are following those.

TD: You're also the facilitator of the mobile task force at W3C. How is the facilitating going?

JJ: Yeah, it's going pretty well now. So I first was invited expert working on the documentation. And then I became last year, just a little bit over one year ago, came the facilitator. So I'm sort of in charge of leading the task force. But first it was mostly recruiting some new people because we didn't have many active people. So now we have around 20 active experts contributing. But that's a nice achievement, but it was also challenging how Do I facilitate those meetings? And how do we work together? Which tooling do we use? How do we take decisions?

JJ: How do we go through all the different success criteria? And how do we publish our thoughts? There was a lot of, yeah, first half year, I think, we mostly spent just a little bit struggling. I mean, how to deal with it.

TD: Building this frame framework on how we're going to collaborate together. Yeah.

JJ: Sort of the, I call it the work statement. So sort of decide. What are you going to work on and how are you going to deal with and which tools are you using and when are you meeting? So it also took quite some time to find meeting time because we have experts from all around the world. So how do you deal with time zones and also how do I make it just work for everyone? So now we are meeting, for me it's a very good time. For some people it's very early, for some people it's very late.

JJ: So we're now meeting at 3 p.m. on a Wednesday, so at least the Dutch time. So for some people in the U.S., if they're nine hours behind in the West Coast, it's 6 a.m., so pretty early. And if people are maybe in China, then it's pretty late, like 10 p.m. But it's a time that works for most people. Some people don't join every week, but at least it's always for me during my work hours. So for me, it's a good time. And we have quite a few people now from Europe that are also in the task force.

JJ: So for most people, that's why 3PM works pretty well.

TD: All right. All right. It's actually so nice to hear about so many people from so many different countries collaborating. To me, that's what the internet is about. It's so nice to hear. Solving problems on the internet together over the internet. That's great. And the discussions you guys are basically translating the WCAG standards for app development.

JJ: Yes. Originally, and that's a lot of people, if they know about WCAG to mobile or it was probably called sort of mobile accessory task force guidance. Now the new document will be called WCAG to mobile, which is in line with WCAG to ICT, which is applying WCAG to ICT. So non-web and all kinds of ICT, including apps. What we are doing is WCAG to mobile. It's not specifically for apps. It's more mobile. We are mostly addressing, the challenges are mostly with mobile apps because in a mobile space, if you have mobile web. In the past, it wasn't considered in the normal sort of a larger accessibility guidance working group.

JJ: So the one that makes the web content accessibility guidelines. At first, it wasn't considering responsive design. So they had a specific task force, a mobile accessibility task force to deal with mobile. But now, mobile device are used more than laptops to access the internet. So now they already consider responsive design. So we are not really focusing on mobile web now anymore, since I took the lead. So now we're just mostly focusing on mobile apps, native apps, but also hybrid apps. So if they have a mix of like a web view inside an app, or maybe sort of web apps, those are things that might be a little bit different from normal.

JJ: They have mobile web.

TD: Those are things we are considering. The line drawn using a browser on mobile versus using a native app. Yeah.

JJ: So what we are going to do with sort of mobile applications in the sense that they are applications running on a mobile device. And then mostly it means that they are running standalone. So it's just an app you can download from the Google Play Store or Apple App Store. Then it's an app or mobile app. Otherwise, it's a website or like a web app. They're mostly considering apps that are sort of software, in that sense, not websites. But software can have web content. And that's where it gets challenging because how do you deal with web view or web content inside another piece of software?

JJ: So those are also some things that we are focusing on. Mostly native mobile apps, that's where most guidance is lacking or most deviating from normal pricing.

TD: And the discussions you guys are having, how are these discussions going? So the discussions happen on GitHub?

JJ: GitHub is offline or async as they call it. So people can just always contribute there. We have a weekly meeting that's using Zoom. So it's a one hour meeting. And then during the holidays, we mostly work through GitHub issues. So we have one issue for each success criterion, plus an issue for certain definitions. And from there, we work together. So we're now at a large variation of success criteria. So the ones that deviate the most. But that's also for me the most interesting discussions to see how people feel. And yeah, a lot of different perspectives for different people.

JJ: Sometimes also different perspective depending on sort of the country they live in and which characters they are using. So if you may be using Chinese characters versus sort of English characters, it can also be different how you interpret certain guidance. Or if you read from left to right or right to left. So there's a lot of perspectives there and trying to find common ground. So that's going okay with the long process. That's why, yeah, creating a standard, so we're not creating a standard with more guidance and existing standard, but it's quite a lot of work.

JJ: I think the nice thing is that if you make it happen, a lot of people will adopt it.

TD: Yeah, and You're telling that there's now a group of 20 people and because of these differences you just mentioned, is it also considered during the hiring phase, so to say, of the group?

JJ: We try to be a balanced group, so not only developers, but we also have people that are more the product owner side or manager side and also people that are maybe on UX or design. You have a broader perspective than just sort of the developers. Yeah, that works pretty well. You see a lot of different opinions, so it's working.

TD: Okay, interesting. And what to you was the most problematic one, is maybe not the right word, but the most challenging success criteria?

JJ: I think most challenging that we have had most discussion about are some of the criteria that are excluded in certain guidelines around the world. So for example, in Europe, EN 301 549 is the standard now for governments and the upcoming European Accessibility Act. And they excluded certain success criteria. So not just one, but multiple. So six now.

TD: Do you agree with these?

JJ: Yeah, now I agree. But when I was first, not only first, but when I was already quite into accessibility, I just didn't know the reason why they were excluded. They just felt like, okay, European Union maybe decided that they are not applicable, but why? And now I know why, for example, in the chapter about software, which includes apps, they have replaced in WCAG2ICT, which is used in the European standards, for example, they replaced a webpage with software. So they're going from a single page to like a whole application. And then they also have this class called sets of web pages.

JJ: So it's like multiple websites that are sort of maybe in a set, maybe a collection of web pages or collection of websites. Sorry, collection of web pages is a website, but in apps, it means you have a collection of software. So you have a collection of multiple Software is multiple screens. And then there are some criteria like consistent navigation. So it means you would have consistent identification for icons in all your different applications, which doesn't really make sense sometimes. And the same for navigation, that you need to have consistent navigation between multiple sets of apps.

JJ: And yeah, it just, and bypass blocks, as another example, where you need to maybe skip multiple pieces of content. But that's also really for web because for web you have usually the same navigation bar repeated. So if you have a large website, you can have hundreds of navigation links. So you don't want to use a screen reader and go through 100 every single time. So we have this skip link feature. But in apps, you don't really have skip links because the navigation is usually very small because it's only specific to that screen. So it may be one, two, three options.

JJ: So swiping to the right to skip past is quicker than swiping left and going through the skip link, activating it. So different in apps.

TD: Yeah, I see. And I was wondering, So there's the one that... there is someone at the EU side who came up to skip on these success criteria.

??: Yeah.

TD: Do you know that? Do you know him?

JJ: Yes, but not personally, but now I learned so there's GitLab. So they're using GitLab in the standard. So there's a GitLab which also has issues, sort of open source, publicly available. And from there you can learn about issues for the EN standard and also contributes. You can just make an account there and comment. So I also placed some comments because one of the times actually in this group, sometimes we do new findings and I also found out that they made a small mistake in the EN standard with these six exclusions. So now in the new version, they are going to only exclude five because of the thing that we found in our group.

JJ: So what's now going to be required is page title because page title is in web. A web page should have a title, so we choose the title attributes, like it shows in the tab of a website. But in an app, you would imagine this maps to a screen title, but it doesn't because they replaced a set of web page with a set of screens. But actually they did not, because actually they mapped just a web page to software. So now they are going to make it applicable, so now it will read A piece of software must have a title, but that's just the software.

JJ: So it means the app itself needs to have a name, not the screens. But you cannot publish an app if it has an empty name. So basically we did achieve something that we have now one less requirement that basically every app will pass it because you cannot publish an app without having a title for the app. So it cannot be empty. So basically we did achieve something, but yeah, it's not too much impact. No, so it's really about that's because of this class that they mapped the webpage to software. So now in apps, it's just about.

JJ: At the software level, the software should have a name and the screens are still not required to have a name, but there's also a new thing that WCAG 2.0 has. They have a new version 2.2 and they added also based on our recommendation from our group, a new note with the best practice that in software or non-web ICT, then it's a best practice to have a title for each view or screen. But they don't have the definition yet for view or screen, so they have some, yeah. guidance there, but they haven't made it a strict requirement because they, they tried for many years to find the definition for view that would work for all kinds of non web ICT, but they did not manage to do it because there were always exceptions.

JJ: So they, that's why they decided to then, okay, let's just map it to the whole software. But then as a result, we have some other challenges now.

TD: So I also want to talk about automation, of course. That's I think the main focus point of ABRA. How far are the automation efforts? How much is there to automate for mobile?

JJ: A lot less, unfortunately, compared to web. With web, there's dozens of tools available that can do this. On apps, there's not that much choice. What is nice is that we have Google, which has the accessibility testing framework. which is also available through an app, the Accessibility Scanner app. You can download it from the Play Store. That's something you can use to check. They have, I believe, 14 rules, so 14 types of checks that they are doing. Apple also has this with the Accessibility Inspector, which has, you know, from Xcode. You can launch this and then also check the accessibility of an app.

JJ: So they have seven rules, I believe, seven checks. And since iOS 17, Apple also made this available as an SDK or as an API. So as a developer, you can now in your sort of XE UI testing, that's the testing framework from Apple. You can also now use those seven checks. And from Android, the testing framework you can also use. So that's sort of, What's nice about Android, by the way, it's also open source, so you can actually see what they are doing. Because with Apple, it's just a black box. So you don't know what they're doing.

JJ: What's annoying with Apple is that they have access to certain features that as a third party, you don't have access to. Like they can enlarge the font size using commands, but as a developer, you cannot enlarge the font size. So they have sort of a... Yeah. unfair, not necessarily unfair, maybe unfair in like, you see in Europe, they're sort of closing down on this behavior that they say, okay, you're sort of having a benefit that other people don't have. That's what we're seeing in Apple. in Google. Then you have some commercial properties. One of us is Abra now.

JJ: We have our own automated testing solution. Then there are two other companies and I will name them. So we have Deque and Event. They also have tools for mobile automation and maybe there are more, but those are the two major players that we are seeing, I guess, together with us. We're still a little bit behind, I must say, because we started a little bit later. We're growing but we are, I would say, catching up quickly. And we launched our first product, our desktop in, I think it was August. So that is really a Mac OS app where you can then on your Mac connect your Android phone, your iPhone.

JJ: It detects also Android simulators, iOS simulators. It's just in a drop down, select your device, select your app, press the play button. It installs our testing suite. Then you just press on the scan button. It scans whatever screen is active. So it's really A really easy way to do app testing. So I think we are the easiest tool at this moment for testing, but we must still improve the quality of our testing results because we support the Apple rules, we support the Google rules, so we embed those. And we now also have Abra rules, which I would say will have higher quality and they will also align closer to the web content accessibility guidelines.

JJ: I think that's one problem we have seen that Apple is testing and their own standards and Google is testing against their own standards and not against the web content accessibility guidance, which is part of the legislation. So companies can sort of conform to Apple, conform to Google, but still not conform to So that's something that we are working on and actually also next week we will launch the first Abra rule which is for orientation and shortly after we will be releasing more rules as we were spending a lot of time on architecture. Now that that's there, we have a lot of trial rules and we can just sort of finalize those and start releasing those.

JJ: So looking forward to next week to get the first feedback from there.

TD: I can imagine, it must be an exciting moment, something you're working towards for a long time.

JJ: Yes, a long time. Yeah, we had this idea a very long time. At first, we actually reached out to some of those, well, now competitors to see if we could maybe just sell their product as we know it's a lot of work to create your own SDK and your own rules. A lot of edge cases, most of my work is dealing with edge cases on all different scenarios. But that, yeah, they didn't really have an interesting offer for us. So eventually we just decided, okay, if we would do this ourselves, can we do this? And we felt, yeah, we can do this.

JJ: So we sort of invested our own time and money to achieve this. And now we're at the point that we're growing in size with more employees. And yeah, really satisfied with how it's going, but it's as expected a long road, but even longer than expected. But now it's nice that we have a desktop ready. We have also a dashboard. So dashboard is where the data gets sent to. So we can work together with your team, with your organization, with users. So we have really a lot of enterprise setup there. And then we're now focusing on the SDK.

JJ: For Abra Desktop, it's using SDK. In our internal SDK, and soon we will also be publishing this SDK externally so our clients can integrate this also in their own automated testing so they don't have to use Abra Desktop. They can just run it in their own sort of CI-CD pipelines, whatever. So that's going to be our next product.

TD: Yeah. When a test is run, you get a report about the findings, for example. Yes.

JJ: Yeah, so we SDK, because we're also trying to build for enterprise, sometimes they don't want their data to be sent to an external party. So SDK, we can run it locally. So without internet access, you can just process the results on device or on in your own UI testing. So you just get Basically just call abra.audit and you get a list of results for the screen that's active. Then you can do whatever you like with those results. It has like a result type. Is it successful? Is it a warning? Is it an error? Is it not supported?

JJ: Is it something else? Add a message and you get like a snapshot of the whole hierarchy explanation. So you can post it yourself, but we also have the ability to add a second package, which is our Abra API package. So that's a secondary package you can add. And then it's another one line to do something like API dot upload results. And then you upload the results to our dashboard. And from there we have also the screenshot and just a UI around the data basically. But yeah, you can also use it offline if needed.

TD: Yeah, I can imagine. That's actually a nice feature as well, the sort of monitoring as well. You can decide yourself if you want to upload coming up with new custom rule sets. That's a quite interesting part. Do you use the WCAG for that as well or is it also... Good question.

JJ: That is one of the more difficult things that we had to figure out because for web there was this initiative. I think it was called WAI or the Web Accessibility Initiative and sort of tooling around. So they had a lot of funding from subsidies and grants to work on multiple tool links including they worked on the ACT so accessibility conformance testing rules so those maybe you're familiar with those from web. So those are standardized rules for testing on websites, but And with the rule, you want to be very specific where it applies to. So they are very specific to web.

JJ: So they're really mentioning certain web elements and certain web components and certain web practices. So a lot of them are not applicable directly to apps. What we are doing is we're trying to align our rules with web content accessibility guidelines. We're also trying to adapt or sort of relate to those rules. But because apps are very different and also very different way of testing, especially on Android, you test completely different than iOS with web. We just have, you know, the HTML is the same on every browser. The testing is there much more consistent. So we had to make our own rules and we did this because we are not only providing software, but we're also doing audits and training and a lot of other things.

JJ: So we have a lot of data from our audits that we know what are common failures. So based on that, we are building our rules. So now we have, I believe 75 rules that are based on our audits and on our knowledge of the ACT rules and everything sort of combined. And then we're trying now for those to make as many of them automated. It's just well, testing procedure, right? So we now need to automate those testing procedures.

TD: How much do you think can be automated?

JJ: Yeah, also a good question. I think there has been some research about this. I think for web, I think it's similar to apps or maybe slightly less on apps. So I think around 20, maybe 30% can be automated. It doesn't change if you look at level A, AA or AAA because at AAA you can actually automate more because a lot of those are now for sort of the cognitive target group. And that's something that AI can do pretty well to decide if a work is difficult or not. So that's some of the requirements from AAA.

JJ: So it depends which standard you're looking at with apps, it's still pretty low, 20%, so still 80% needs to be done manually. And that's actually also something we are working on. So it's something we are seeing in our own audits that not really time consuming to find issues. So we can open a screen, we can check landscape mode, check text scaling, we can find lots of issues very quickly, but then reporting those issues, especially uploading, we're doing our audit is also providing a screenshot for every issue. So we need to make of screenshots and then somehow get those from your phone to your laptop and then to your whatever audit tool you're using.

JJ: So now with Avra Desktop we're expanding it also with sort of semi-automated testing as we call it. So then you can just press a button in Avra Desktop, it grabs automatically the screenshot, grabs a lot of data. It has like a drop down with the rules that we create. You just type the description, hit submit and we do an API call to the dashboard. And it's just a lot quicker to download.

TD: Yeah, I can imagine. It's a lot better workflow than what you described earlier. All right, awesome. And that's in the first release as well, or that's already in?

JJ: In the first release, also a lot of things. They're coming together now. So in February, we also released this semi-automated testing feature plus then the orientation rule for Android iOS and also the Academy. So Academy is sort of e-learning how you can actually fix those issues because it's nice to find issues, but it's better to fix issues. So that's what we're doing in our sort of e-learning trainings. Yeah.

TD: Fixing or preventing issues from happening.

JJ: something we also try to do, but yeah, that's the best prevent instead of fixing finding. Yeah, that's the best. All right.

TD: So coming up with new rules is a little bit different than for web, because most of the standards are web based. The ACT rules are more web based. Everything is web.

JJ: Yeah. Yeah. Yeah.

TD: Yeah.

JJ: Everything is web and then you have Google coming up with their own Google interpretations. Yeah. And then Apple coming up with their own app interpretations and they are not working together. So that's a really nice thing about what you see, which I've really can appreciate that they have one organization which is making the standards and they work together with basically all large browsers who have a consistent behavior across websites. And that's something we don't see in apps. So it's not like Google and Apple are really working together to make standardized guidance. They have their own guidance.

JJ: That's something we are sort of trying to do with the App Foundation.

TD: yeah but it's hard if app and google are not joining and they're still going to do their own thing so uh yeah the web doesn't really have shareholders that's the difference yeah yeah we've come to appreciate web more and more yeah yeah i can i can imagine but there are i think also a lot of challenges for web for app uh in that sense.

JJ: I like finding or solving problems and it's nice to do groundbreaking work in the sense that you're doing something new or you're finding new ways to solve certain problems and at web it's a lot easier to find existing solutions so that's something I like but also it can be annoying if you have a certain problem and there's just nowhere on the internet to find a solution. And with the web, it's usually easier to find solutions. So it's positive sides and more negative sides to it.

TD: All right. Coming up is the European Accessibility Act, of course, this year. A lot of companies are busy with, you can imagine. From my experience, I know that we are at least, but also from what I heard around me is that a lot of companies are trying to catch up, making moves. Is that also something that you see?

JJ: You definitely see this happening. I think we see it even more now with the European Accessibility Act compared to sort of the older act for sort of public governments or sort of the web accessibility directive, which is more aimed at governments and the public sector. Less was happening now with commercial companies. Of course, there's also a lot more companies that are affected compared to, like there's many more apps in commercial companies compared to the government. The same applies to websites. So yeah, I think a lot is happening there. We see a lot of clients that come to us because of the European Accessibility Act.

JJ: They want to avoid getting a fine because there's something that happened now with the European Accessibility Act. You cannot only get fined in one country, you can get fined multiple times in all European countries for the same issue. So it's really important to start working on something.

TD: I heard in Ireland, you cannot only get fined, but you can also go to prison. Yeah, that's one of their legislations as well. I just learned this. It's quite interesting. I didn't check it myself. I know a few people told me about it. quite interesting. But yeah, of course, European Union consists of many different countries, also different ways to implement or maybe fine. But what you just said is that in different countries, you can get different fines as well.

JJ: Each country has their own observation in the government that is doing checks if companies are accessible, and especially if there are reports, so if users are reporting that they cannot use an app or a website, then this organization will then check if that's correct and then check if they have like a program in place for accessibility. So what are they doing to solve it already and, or are they willing to solve it? And so it's not really clear yet in the Netherlands and a lot of companies are still setting this up, even though it's, I know like less than six months now.

JJ: So it's still a lot of things are unclear, even though it has been coming for years. But in the next month, it will be more clear. But what I know, yes, you can get fined in every country because they have their own people monitoring. So if you have one app, you're like a global company and you're active in a lot of every European. Yeah, which probably you are. Yeah, they are definitely. Yeah. So

TD: If you were to assess company readiness for the European Accessibility Act, what do you see around you? Do you think a lot of organizations are ready this year? No.

JJ: It depends what ready means. I think for the European Accessibility Act, it's a little bit different from the Web Accessibility Directive. So it's mostly about making progress. So it's not about being fully compliant, which is also not the main goal of the Web Accessibility Directive, but it's sort of the end goal and European Accessibility Act is a little bit more flexible in that sense that it's more about, yeah, just you need to work towards becoming more accessible. If you can show the progress and you can show you're maybe following trainings, maybe you're doing testing, you're doing audits, then you're also showing you're fixing issues, then it's likely you won't get fined.

JJ: So I think companies are now taking those steps. But if you want to be like 100% accessible or fully compliant, I know it doesn't really exist. It exists for a couple minutes, right? So sometimes we do audits, and then you have maybe a lot of failures, then we do a re-audit, you have less issues, then another re-audit, you have couple issues, then final re-audit, then you have zero issues, then we give an audit, okay, no issues, but then the next day another developer pushes another change, and then suddenly it breaks. Accessibility is not ever done, and you cannot really get to 100%.

JJ: I mean, you can get to it in one point of time, but you cannot keep being at 100% all the time. It's just not realistic.

TD: Not realistic, no. Definitely not in a big organization, I would say. Yeah, every minute a new push is to production. That's what you mentioned.

JJ: I think automated tools are very important. There's a lot from people that really want this and a lot of people are using it for web, but not really for apps because there's just less options and options are already expensive. But it really helps if you, yeah, like you said, if you have a comment every couple of minutes or even every minute, then if it can run some automated CI-CD checks to prevent something inaccessible being pushed to production. Yeah, it really, really helps. That's something that we are also trying to contribute to.

TD: I think that's a really good case because also from the top five main issues, I think a lot of them actually can get automated.

JJ: Yeah, it's interesting that like you asked the question earlier, like how many percent can it find? So you can find 20% or something of the total issues. But if you look at the percentage, it can be made maybe 80% because from the 20% that we can find, they are around 80% of all issues that we find in our audits. For example, name rule value, and I guess also state is part of that. It's four, even eight rules that sort of are connected to that because you can say, okay, it has to, the name cannot be empty.

JJ: That's one rule. The second rule can be the name must be correct. The same for role. You can say, okay, the role must not be empty, the role must be correct. So you can basically do already eight checks and you can find so many issues in apps because in our audits, just 4.1.2 is sometimes 50% of all the issues. So if you only find name, role, value, and state issues, you can find like 50% of an audit automatically. Yeah, some of the tools can find a lot of the total issues, but still, the more complex ones you cannot find.

JJ: So still, manual testing is needed, but you can save a lot of time with automation. I think one of the articles by DQ, they also mentioned this in their... Yeah, they have the most amount of data, especially I think their research is mostly always based on web with X. So their product which is also open source and is used by a lot of tools I'm not sure if it's called a problem, a lot of tools exist on the web, but most of them are just a wrapper around X. So in the end, you're getting the same results with a different screen basically.

JJ: That's also part of the project I talked about with the ACT rules. They also made sort of a second engine. It's called Alpha for site improves. We have also Alpha. That's another accessibility engine, also open source to check for issues. So it's sort of a competing engine with X, but X is by far the most popular. I believe they said they have like 1 billion downloads. And of course it gets counted multiple times for projects or something. I'm not sure how it works with those packages, but They have millions of users basically, so it's a lot of impact.

JJ: Even Lighthouse is mostly Oxford. Yeah, basically almost every tool is based on X because they are just the best with the amount of rules. It's really difficult to build yourself.

TD: Now I remember some like two years ago I made a meme. It's terrible to explain a meme of course but there was about this guy floating in space with the astronaut behind him holding the gun to his head and it's always has been all these different tools surrounding him. And then he discovered it's all X-Core. And then he's like, yeah. Yeah. Yeah.

JJ: There's so many different variations.

TD: Yeah, but I think it's good because if you have like linting and you have unit testing and functional testing, integration testing, these are different stages where you can test your software in different contexts. So you actually get better results when you use them all combined in a good way than where you not to do it, for example.

JJ: It's really nice and it's really easy on the web. So basically for every type of project you have, whether you have React Native, or sorry, not React Native, but there's just React on native. But yeah, whatever framework you're using, someone made a wrapper around one of the accessibility engines to make like a one line of code to check accessibility. A lot easier to get started on the web with accessibility, at least the automated part. Yeah, for sure.

TD: Um, a lot of organizations, uh, we discussed it. They are, but I think it's, it's a, the European act. I think it's a good thing because also I think it has the ability already shows that it is doing this, uh, to open the eyes of some big organizations to take it more seriously. And what I hope is that this is the kickstart to where they also keep considering accessibility throughout their development lifecycle, basically create standards around it, create processors around it to preserve the quality. But what do you think is a good accessibility strategy for big organizations?

JJ: Um, I think the main thing that we see with our clients or the larger clients is sort of training as a big issue. You also mentioned it is, uh, yeah, you have maybe 100 or hundreds, or maybe some organizations have thousands of developers working on the same web or you have multiple websites, multiple apps. And then every month or every week there's almost starting a new developer and Most developers haven't learned about accessibility during their studies or during their work. So if they then join an organization that is working on accessibility, they need to be learning.

JJ: So I think training is really important to immediately when they started your company to learn about accessibility. So I think what works best and I'm opinionated, of course, is e-learning. That's why we also are now building e-learning because people can just do it on demand when they start a job, just go to e-learning, earn a certificate and sort of show they have basic or sort of advanced knowledge. So I think that works. And like I mentioned before, I think automation can help too. I think automation is used for a lot of things in already in mobile and in web to catch issues.

JJ: Just accessibility builds all kinds of issues. So it can also help for accessibility to catch issues. And then I think it's really important to also really consider the user custom of companies today. Don't do user testing or render the user testing. They don't specifically do it with users with disabilities, but just people they can find maybe more easily. I think it really helps to do user testing. Find users with disabilities, the broader perspective and see how they are using your app. Because WCAG also is just a technical standard and it doesn't account for a lot of user needs.

JJ: So it's not perfect. So always users can find a lot of things that are wrong with your app that would pass in WCAG.

??: Yeah.

TD: Yeah, indeed. Luckily, a lot of user tests are done at the bank, also with people with disabilities. But these researches are more done by UX designers, I have to say. bridging this gap from doing the research and testing with users, I think it's not really something that a lot of engineers do. But do we maybe have some tips for how to or maybe even how to integrate these reporting results of a research into engineering practices?

JJ: And this was something we are doing with Apt and this also sometimes is mostly to convince the stakeholders or companies to do something with accessibility. Our research was done by Q42 about accessibility settings. So we have on Apt a page with statistics about how many people use certain statistics. So this can get an idea of maybe which tickets or which features should be prioritized because if you see a lot of people are using maybe dark mode and maybe you should consider it. I think that can be a way to sort of get data from users without actually talking to them.

JJ: have to be careful there because it can be sort of sensitive data, right? If you're tracking, if someone is using a screen reader, it's maybe likely to be blind. So I have to be careful there to make sure you get consent or do it in an anonymous way that you cannot track which user has which settings enabled. So I think that can help. You can also do it in your own app, of course, just sort of analytics, but still you get Like we have a percentage, for example, for voiceover, and it's like 0.002% or whatever.

JJ: It gets really, really small. So if you look at those numbers, it's really small. If you calculate 0.02% times in the Netherlands, like 17 million people, it's still, I believe we have like 30,000, 40,000 people that are blind. So in numbers, very high. So don't look blindly at percentages people themselves, even if one user struggles to use your app, it's still worth to sort of improve your app for them. And my recommendation for developers is to go out your comfort zone and maybe join one of those user resource sessions and really learn a lot.

TD: It's not only, I think this was my perception at first as well, but I think also building an accessible app also brings a lot for abled people as well. I think it's a more understandable app overall which comes with a lot of benefits as well.

JJ: Definitely. I think what we're seeing is a lot of features that we are using daily are coming from accessibility needs. For example, dark mode is now no longer under accessibility in the settings. move to now just a sort of normal settings or a screen setting and but originally dark mode was also meant for people that maybe cannot you know be really sensitive to light so they really need a dark mode otherwise you just get a headache really quickly and now it's more common for people that spend a lot of time behind their computers to also use a dark mode for less eye strain, but for some people it's really necessary, but for other people it's just...

JJ: I like it when I can use dark mode, but for me if it's light mode, I can deal with it.

TD: Some people are even arguing that it's environmental caused the dark mode, because some screens now, if they're dark, then the lights turn off completely. So then you spend less energy on dark screens.

JJ: Yeah, that's true. And I think you see it with such a screen spike, the AMOLED or certain types that basically turn off the pixels. Yeah. What we're also seeing is captions, that captions are originally made for people that are hard of hearing or deaf. But now a lot of people just use it for other reasons, because they maybe forgot their headphones, or they are multitasking, or they just find it easier to read text and to process audio. So, yeah, you can really see that I think there was some statistics from Netflix that I think like 50% of all users are using once a month or more captions.

JJ: So there's really, yeah.

TD: I use captions all the time. I love it. Yeah. Because sometimes you just don't, the audio sometimes is talking really loudly, but sometimes not. It's not clear always. Yeah. I have a lot of times also captions on my phone. Yeah. Yeah. Yeah. Yeah. It's great. Great. All right. I think we have great, great conversations, a lot of topics discussed. Are there some topics that you would like to, that we missed maybe that you would like to bring up?

JJ: I think we covered a lot. I did a lot of talking. Do you have any topics or any insights?

TD: Well, maybe about more, let's look a little bit more in the future. How do you think the future of accessibility is going to look like? Do you see some notable trends maybe, maybe some AI? I think AI is promising.

JJ: can really help to sort of enhance the percentage of issues you can find automatically and also sort of fix, like we're seeing now people generate captions automatically. We see people generating transcripts, generating image descriptions. That helps, but still AI can sometimes miss the context or get things wrong, which still needs a human to correct it, but it can be quicker. So it can make more things accessible in less time. So that's why I'm all for that. I think, yeah, I hope the European accessibility act will be like a GDPR. Every company sort of has to think about, okay, privacy, okay, in this case, accessibility.

JJ: How am I going to deal with this? I have to do something with it. Like a lot of companies, they still, you know, don't do much with GDPR, but at first they were really trying, especially the large companies. They are in trouble because they can get fined into smaller companies. They can usually get away with it but the larger companies they have to deal with and they have the most impact. So if those apps that are installed by millions of people are becoming accessible, it's just so much more impact. So I really hope it just affects a lot of people who at least consider accessibility.

JJ: I hope they do something with it. Like everything they do is a win and hope they strive for fully accessible, but that's challenging.

TD: Yeah, same. Same. No, definitely. And I think maybe something nice to share. So I think a lot of companies are now trying to catch up with the EAA, maybe also a little bit of stress. So some people are also trying to take advantage of it a little bit, but I think Taking small steps every day can be daunting, right? Accessibility, a topic many people do not know much about. Well, accessibility, digital accessibility. But just making small efforts every day will get you a long way already. And not seeing it as a project, but seeing it as something you just need to integrate into your way of working, into your development life cycle, into your way of creating software, is I think the most sustainable way to make sure your app will be accessible in the future.

TD: And that's, I think, what the EAA is all about. It's not making these big steps until the end of June but actually more, as you can see more, not as a starting data, but I hope not, but yeah, taking it into the future.

JJ: Yeah, I fully agree with what you said. I think it's just a process. You just have to keep accessibility in your process and it's never ending. Just like other topics that you always have to account for accessibility is, one of them and for some companies it will be new, some it will be maybe more emphasizing accessibility. I think in the future it looks bright. Looking forward to see what will happen. And I think a lot of companies are now, like you mentioned, sort of starting out. I think around June, some companies are finally going to start doing something.

JJ: We saw the same with governments that, oh, it will be accessible. Yeah, it was announced five years ago and yeah. We're finally starting.

TD: I was noticing the same thing, it sort of gets reignited. We see a lot of focus now on the accessibility act.

JJ: We just see a lot of podcasts, we see a lot of companies promoting it. You have to be careful there. We see some sort of the cowboys that are now seeing, oh, there's a business opportunity. So be careful what people promise deliver and if they do have the knowledge or not, because I've seen a lot more companies just popping up and selling accessibility, even though their own website, for example, is far from accessible, even though, you know, I know it cannot be 100%, but you can just see significant flaws and you know what, you shouldn't do business with them.

JJ: want these services, they don't know because they need help. So they don't know how to check if someone is actually credible or not. So that's something will be challenging.

TD: Maybe also a lot of talk about the overlays. Yes, overlays.

JJ: So be careful for overlays and plugins and one line of code and one plugin that sort of make your whole website fully accessible. Not possible. Sometimes they can enhance it, but a lot of times they actually make it worse. Yeah, I don't like them usually.

TD: No, no, me neither. Some of them are always saying it's not fully accessible.

JJ: Especially the marketing around it. They market if it's like a one fix to everything. Because a lot of those companies, they're sort of selling insurance, right? Sometimes they sell the solution and they say, oh, if you get sued, we will cover it. So you're sort of paying insurance as a subscription. So they're sort of insuring you. That's at least in the US what I'm seeing. So that's sort of a tactic they're using there. Look, you can use our overlay, but if it gets too real, just cover up to X amount. So it's sort of like paying for insurance instead of making yourself an accessible website or app.

JJ: So I hope we won't see this in the EU. I know there's already been statements also from Dutch government and also from other parties that overlays are not the solution. It can be a valid first step and if the marketing is valid, it can be useful.

TD: Sometimes they exaggerate what they can achieve. Taking the most sustainable way is I think the way to go. Training, automate as much as possible. Yes and try to take small steps every day and try to really integrate into the way of working and the way the software is created. In each step, try to consider accessibility.

JJ: Yeah. And I really hope people are starting to complain also to maybe the vendors. So we see a lot with websites writing no code. It's now also now coming to apps that use no code. At least you don't write code and they write not in there the greatest codes they're generating, especially not accessibility wise. So I really hope those platforms also now because they sometimes have millions of customers that they start complaining, okay, the result is not accessible because if that platform can make those components accessible, suddenly they can have so many impacts. It can be difficult to reach the right people at those larger organizations.

TD: Yeah, yeah. Also, most of the time these are like big legacy systems that would take a lot of investments to do. So there's also, yeah, I've seen the results of some of these low-code tools as well mostly diffs coming out of it. Yep, same for apps.

JJ: It's just a view and it looks like a button.

TD: Yeah, indeed. All right. Thank you so much for joining us, Jan Jaap. Where can people find you online if they want to follow you or the things that you do?

JJ: Well, easiest is probably my own personal website. It's janjaap.com. Maybe I managed to buy a domain at some point. And our company website for Abra is abra.ai in English or abra.nl for the Dutch version. For appt, we have also English and Dutch, so appt.nl for Dutch and appt.org for the international one, which also is also in Dutch. Yeah, though which we see a global accessibility task force, you can find it there. Also, if you may be interested in contributing there, you can always consider applying as an expert to join. Or maybe if your organization is already part of what you see, you can just ping me there and you can get added straight away to the mobile task force if you are knowledgeable.

JJ: So yeah.

TD: Awesome. Be sure to reach out if you are considering joining or opening a discussion, I think always welcome. Also to the listeners, if you like what we do, please consider subscribing, rating or liking or even commenting. It's always nice to get some feedback. Yeah, much, much appreciated. Thanks for listening. Thanks for joining your app and thanks for all the work you're doing surrounding accessibility. I think it's a very nice big list, which all serves, I think, a really great purpose. Yeah. Yeah, thanks Tim. I hope to have you on another time as well. I think we can go on for a few more hours as well.

TD: I think great topics.

JJ: Thanks for having me. Thanks for the invite and looking forward also to the other episodes.

TD: Yeah, thank you.

Takeaways

• Digital accessibility is crucial for inclusivity.
• Jan Jaap's journey began with a project for blind users.
• Foundation Appt aims to share knowledge about app accessibility.
• Accessibility in apps is often overlooked by developers.
• There are significant differences between Android and iOS accessibility.
• The Mobile Accessibility Task Force is working on WCAG 2 Mobile.
• Collaboration is key in developing accessibility standards.
• Many companies are unprepared for the European Accessibility Act.
• Automation can help identify accessibility issues but is not a complete solution.
• User testing with people with disabilities is essential for effective accessibility.