In this episode of The Digital Accessibility Podcast, Joe is joined by Tanya Van Workum and Jan Jaap De Groot of ABRA, a mobile accessibility consultancy based in the Netherlands.

With deep experience across iOS and Android accessibility, Tanya and Jan Jaap share how their backgrounds in design, development, and lived experience have shaped ABRA’s mission to make mobile apps genuinely usable for everyone.

Together, we explore what good mobile accessibility really looks like in practice, why it’s still so often overlooked, and how teams can move beyond compliance toward meaningful inclusion.

We discuss:

1. Building ABRA: How Tanya and Jan Jaap came together to form a mobile-first accessibility consultancy, and why they chose to specialise exclusively in iOS and Android.
2. Why mobile accessibility is different: The unique challenges of touch interfaces, gestures, screen readers, and platform-specific behaviours that are often misunderstood by teams.
3. From audits to empowerment: Why accessibility audits alone aren’t enough, and how education, collaboration, and developer confidence are key to long-term impact.
4. Designers, developers, and responsibility: Where accessibility ownership should sit, and how cross-functional teams can work better together.
5. The human side of accessibility: How working closely with disabled users changes perspectives, priorities, and product decisions.
6. Common myths and mistakes: Including a few surprising misconceptions about mobile accessibility that Tanya and Jan Jaap see time and time again.

We also touch on how organisations can embed accessibility earlier in the product lifecycle, what “good enough” really means in mobile accessibility, and why curiosity and humility matter just as much as technical knowledge.

Follow ABRA:

Website: https://www.abra.ai

Connect with the guests:

Tanya Van Workum (LinkedIn): https://www.linkedin.com/in/tanya-van-workum/

Jan Jaap De Groot (LinkedIn): https://www.linkedin.com/in/jan-jaap/

Follow Joe James:

LinkedIn: https://www.linkedin.com/in/joeajames/

Twitter (X): https://twitter.com/A11yJoe

YouTube: https://www.youtube.com/@PCRDigital

Visit PCR Digital:

https://www.pcrdigital.com/

Welcome back to the Digital Accessibility Podcast.

If you're looking to learn more about the field of

accessibility, how to implement it within your role

or your company, or to get advice on where to start or

see how others have navigated complex issues that you may

find along the way, then you're in the right place.

I'm honored to be able to share these insightful

chats with thought leaders, advocates, and practitioners

of digital accessibility throughout this podcast,

and I hope you'll find it a useful resource.

As always, thank you so much for listening, and I

hope you enjoy the chat.

Today's episode brings the Digital Accessibility

Podcast full circle.

Early listeners may remember Paul Van Wer discussing

mobile app accessibility and the early days of

what would become ABRA.

Fast forward to today and ABRA has grown into

a company helping global organizations build, test,

and maintain accessible mobile apps at scale.

I'm joined by two of the team at ABRA, co-founder

and mobile accessibility specialist, Jan Jaap de Groot

and accessibility and product consultant, Tanya van Work We

get into why accessibility, mobile accessibility

still lags behind the web where automation helps and

where it can fall short.

How the European Accessibility Act is shifting priorities

and why mindset and culture matter just as much as the

tooling that's being used.

It's a grounded, practical conversation around what

actually moves the needle in accessibility and why fixing

things after the fact is never really usually enough.

Welcome to the podcast, Tanya and Jan Jaap.

Thanks, Joe.

Thank you.

Nice to be a guest here.

Very pleased to have you here.

and I guess we'll start at the beginning and, some

listeners, long-term listeners will remember

Paul van Workum who's also a co-founder of ABRA.

he was an early guest on the podcast.

We talked about the APT Foundation and the early

efforts to make app accessibility more measurable.

So I guess now that we have you both here, Tanya, would

you be able to sort of talk us through how ABRA has evolved

from the earlier days and how pieces like training,

audits and your product work have come together?

Yes.

Sure.

Thank you for the question.

Well, as you, mentioned, if we look back, at ABRA, it

really started with the accessibility, knowledge.

About the mobile apps and it started, with, ABRA

I think it's fair to say that, Jan Jaap and Paul,

were pioneers in the mobile apps accessibility knowledge

and put this great resource together which is still

is being used by many users across the world.

And from knowledge about the mobile

accessibility and the app?

Yeah, it, we moved a step, step further because of

course, if you have that much knowledge, you want

to use it in practice.

So we started to look into the accessibility of the

mobile apps of the clients to perform the audits for

our clients and added our own approach and our own tooling

reporting tooling, which we are still using, internally.

And that's how we got insight or we got we

learned about what do the companies do inside about

mobile accessibility.

And there was always, that vision that mobile

accessibility should be automated as much as possible.

So, and the testing should be as easy as possible.

So that's why and not, not many companies are doing that.

Back then but still you will not find a lot of

companies that offer tooling on or software

that tests mobile apps on accessibility automatically.

So we saw opportunity on the market and that's why we spent

the past two, three years on research and development

and development on our own tooling on the automated

and semi-automated testing.

At the same time we continued helping companies without its

and what we saw is that, the tooling alone is not enough.

The external help with the testing is not

enough that there is also a gap in the area of

accessibility knowledge.

So actually you must know things about mobile

accessibility in order to perform tests or in order to,

use the, automated tooling.

So that's why we added another component ABRA Academy.

And we recorded some, online trainings that we

share with the companies.

We also do in-company trainings.

And we put actually besides, besides that we put all

our knowledge, on paper in our ABRA documentation.

Created our own rules with the, with the solutions

and explanation of what you need to test, how we need

to test and that's, how we ended where we are now.

we still believe that in order to succeed with the

accessibility with the mobile accessibility within the

company need actually three three elements knowledge,

tooling and skills.

And we try to combine these three components

in in our offering.

It sounds fantastic and yeah, rightly so.

And the documentation is obviously a key part of

that as well, in, in terms of having that available.

I think that from my perspective, from

the beginning when I was first introduced

to ABRA, Very much.

And this, this community in general in accessibility

is a lot of sharing.

And I can see that from your side as well.

It's an awful lot that you give out to the, industry for

free to sort of help further things, in this space.

but I'll bring things over to, to JJ as you're also known as.

I just wanted to ask from your perspective as well,

so what, were there any specific gaps that you saw

in the industry that made you focus entirely on the

mobile side of accessibility and then start building

the technology behind ABRA?

And thanks for the question.

And for me, like my background's just in,

in computer science, software engineering, so

I was really interested in, in building apps when

smartphones came out.

So around 15 years ago, by now.

So I've had Android and then iPhone, and, I was really

fascinated with ideas.

You could write applications or apps as they're known, and

now, you have to do something on a physical device.

So really writing sofa, sort of a portable device,

that felt like magic to me.

So when I had the opportunity to, study, I, I, yeah,

chose computer science.

and, and yeah, really started there.

and sort of whenever I learned more about programming.

I really want to put it in practice and started

building apps to learn more about the knowledge or the

courses that I, that I took.

and yeah, basically from there I, yeah went through

the field of accessibility and that's when I really found out

myself that there's just not a lot of resources out there.

and I sort of became fascinated with this

topic about, yeah, mobile app accessibility,

and I. It a little bit disappointing, to be honest.

Just 'cause a lot.

Yeah.

even for some, yeah, some easy issues.

There are just not really solutions available.

So that's when I eventually decided, so to get with

Paul to, yeah, make this knowledge base, because

you have to just wasn't, was nothing there.

So mostly it was out of need.

I guess.

We also saw opportunity there that potentially,

you know, could turn into some kind of business, but

mostly it started out of need and also for myself.

'cause sometimes I just wanted to make my apps more

accessible for, for my users.

I just didn't really know how, how to do it because

there is no, resources there.

Yeah.

Interesting.

And that nicely brings us into the next sort of segment,

on this in terms of the differences, between sort of.

Website or websites, accessibility and, there's a

still a perception that that accessibility is something

that mostly applies to the web and mobile is somehow

secondary or it's already got built in features

and things like that.

So, a question for both of you, I suppose.

I know that obviously jj, you are more on the technical

perspective, but, Tanya, when you are sort of performing

the audits, ABRA for mobile apps or training teams, are

there any key differences to share that stand out compared

to the web and, and why would mobile need its own sort

of set of rules and things?

Yes, I think it's a great question.

And from my perspective you know if you look at the mobile

development in general if you want to develop a mobile

app then you go to the team of the mobile developers.

So it's, it's a rare case that you would find a full

stack developer like Jan Jaap, it's more an exception.

Most of the time you have either IO centric developer

or Android developer.

And even more often you will find like a flatter

developer or react native.

So depending on the technology or on the on the platform,

and this is for the reason.

For the reason, because, you know, mobile developers

cannot, will not develop a website and web developers

are not able to develop IOS or Android Web.

And it comes because the that the concept, the

development concepts and the concept of the product

is really different.

So when it comes to the mobile teams, I get more

questions, which are going.

In depth already, because they do understand

that web and mobile development, are different.

but if we look at it, it starts very simple.

think about where the mobile apps are used.

It's, on the mobile devices and the mobile devices

are small or portable.

you are using it, closer to the face.

You are using, with a touch navigation instead

of the mouse most often.

So, the whole principles, how you navigate, how you use

the mobile apps are different.

that's one.

And from the technical side, the websites are,

built, based on HTML.

and when it comes to the mobile apps, there is no.

unified manner, how you develop, an app.

and when we test, for example, with our automated

tooling, I come to the conclusion that the app

development is sort of, state of art because it's

every time and developers come to the new ways to build

the components together.

And then, yeah, it's, surprised me every time.

And when we look to the interpretation of the,

guidelines, for example, that are in most cases,

that were written for the, websites, websites, then

we see the biggest, the biggest, differences.

And then where it comes to a lot of questions

and, interpretations.

I would, name one example, of, target

size, for example, it's a criterion from the 2.2.

and basically it says that, there should be, there are

two criteria, criteria for the minimum and enhanced,

target size, that there should be the, if we look

at the minimum target size, then there should be minimum

size of the target that you use with your, pointer.

If you use a desktop or your laptop, you will be most

probably using your mouse.

And if you are using your phone, you will be using your,

fingers and touch gestures.

So if you look at the minimum criterion, it says

that it should be 24 by 24 CSS pixels, which first,

is not used the size.

points are not used in the mobile development, so

you should interpret it.

How, what will we, which, units will we use in

the Android and IUS apps because it's also different.

And secondly, if you use 24 by 24, it's so small in

the mobile space that you will barely fail it ever

because, even IS and Android guidelines, they give a

much higher recommendation.

So, you cannot apply it.

Literally, it doesn't, it just doesn't make sense.

so when it comes, to the key differences, then, we

always, look very closely to the definitions because

some of the definitions are not applicable or should be

used with some, exceptions or with, some notes and some,

criteria from the guidelines.

They also will be either not applicable, or,

should have some, some additions or some extra.

Interpretation.

yeah, it's fascinating and it's, it's really

interesting hearing it from that perspective because

I, you would, I mean, a lot of the conversations

I have are around the fact that the WCAG are

guidelines, so it's, it's not

written law or legislation, it's something that you

have to interpret and use common sense, I guess.

But it's a shame that not every developer will

have the w ag criterion as their set standards.

but yeah, that scalability of between the web and and mobile

and how, how that differs is really, really interesting.

I can imagine if I'm trying to click on a very

specific point on my mobile screen, I probably miss

it quite a lot, just because of my fat fingers.

but so jj, from a technical perspective, in, in from

your own perspective as well, so what makes, mobile

accessibility distinct, things like native

components, so gestures or platform behavior, how,

how is that complexity influencing how ABRA

specifically is approaching automation and testing?

Yep.

Thanks.

It's, yeah, I think, I think one of the biggest differences

is yeah, what Tanya mentioned, and it's also something we

are now focusing on in the Mobile CS PT task force.

Are we trying to interpret and apply a, provide

guidance on how, you know, how, how do we map book

act to mobile applications?

And it's mostly about the definition.

So of course, in a success criteria and also in the

guidelines and principles, that's just text.

And then within those text are words, and

then certain words mean different things to people.

so that's why it's very important that certain words

are, are defined and that it's understood by everyone.

I used it in the same way in that sort of.

What you see is the more you know, the less you know.

'cause at first we felt we, we knew everything.

And then we start diving into some definitions that in the

past we just, you know, do our own interpretation and we

felt that we understood it.

And then now with a, with a larger group, there's

yeah, more input, more interpretations, and

then you sort of try to find common ground.

And sometimes that's different than how we have done it in

our audits, for example, or even in, in our automation.

that's a di difficulty.

And it's also that there's two platforms.

So on the web there's locally one worldwide web.

Of course there are sort of interpretations by

different browsers, which sometimes from a technical

perspective, your website can look different in different

browsers or might not work.

but at least the standards of how things are supposed to be

are sort of the definitions.

Yeah, those are are written by one organization and

that really helps a lot.

and it's also of differences from recommendations

from Apple and Google.

but mostly they, they are, they are somewhat aligned.

But you have to add on what Tanya was saying, that 24

or 44 is, is in wac, either on minimum or enhanced.

And then on Android we have 48 dp, so that's the Android

unit density, independent pixels and iOS, you have

actually the same 44 in wca, but then it's just

points and not CSS points, which is sort of iOS points.

you can already see some differences there.

And that's, yeah, for automation, the problem

that you have to make rules, this is sort of your

source of truth and define how am I testing this?

And then for each rule you would have sort of a, a

testing procedure and have certain steps to go through.

I guess what we found out when making those rules, that

it's also different how you would test manually versus

how you test automated.

Like sometimes with manual testing you might have more

or less information compared to testing automatically.

So those steps are not always exactly the same.

I think one will make difference in sort of, yeah,

out, think manually and automated is just manually,

you just sort of look at your screen and you can, when

you've done a few outlet, you can spot some issues or you

sort of look at a component or at an icon and, and see

that it's missing a name or missing a role, and then

sort of go to the next item.

but for automated testing, you sort of have the rules.

So you just have one rule that just checks every image

for certain text, so it it's not going through the

screen in, in the same way.

And also for automated testing, you would

like to read, sort of, yeah, reuse some of the

logic, for example, to determine all interactive

elements on the screen.

'cause it's needed for checking the name, checking

the role, checking the values.

You're sort of reusing the same logic.

So the testing steps are, are, are very different

sometimes from manual testing.

that's one of the biggest challenges we have and that's

where I get more jealous now with the, what we see.

'cause they have lot of different working groups

and different task forces and other initiatives that

are, try to solve very similar problems on the web.

And some of them they already solved.

Like one example is, the accessibility

conformance testing a CT.

So they already have a lot of tests where they just

provide some source codes or either some html, sometimes

use as JavaScript and.

Basically have testing procedures and just tell

you, okay, I have this, these are my three source files.

When you load those and you, execute this test procedure,

this should be the outcome.

so it should either be fill or pass or, you know, give

some other kind of outputs.

and you can just basically make your rule engine and

just get all that input data and check your outputs

and you get a score.

And it also helps for, for people that are in the

market to buy switch tooling.

'cause they're able to then check how well are

each tool's, scoring on these a CT, checks.

And that's all, all missing in apps.

It's, yeah, just all, all companies in the automated

testing, solutions are, are just making their own rules.

And so it becomes harder to compare and harder to check,

what they're testing against.

So that's, you know, a, a big gap that still exists

in, in sort of the yeah.

Mobile automation space.

A lot of blurred lines, I suppose.

and that's always gonna be a difficult thing to overcome

when you are trying to get to a final sort of solution.

because to one company, they may feel, yeah, we've, we've

hit the nail on the head, everything's accessible until

someone else comes along and says that only to your own

guidelines or only to your own sort of set of set standards.

So, yeah, tricky and, Hopefully things will become a

bit more aligned in the mobile space as I think that they're

starting to with, with, with web and, and the w Ag.

I know that a lot of the mobile guidelines are built

from WA as well, we're trying to interpret and,

sort of port them across.

But, yeah, hopefully it'll be a bit more of a globalized,

standardized procedure.

Ideal world, you know, we can always dream.

That would be great.

awesome.

So, bringing that on to, what ABER is doing and, and

comprehensive set of solutions that blends technology

and human expertise.

If you, as you've mentioned, earlier,

jj can you tell us about how the automated

side came together?

I guess it's of, very much related to what you

were just saying, how ABRAs tooling works or

what makes it different.

and are there any other sort of differences or, or, or

challenges, that you've experienced when putting

together your own, sort of automated side of things?

Yes, thanks.

Yeah.

Love to talk about this part.

I think for us mostly, yeah, just, it really started

from, from the services we're providing, from the

audits and we learned a lot from those audits 'cause

we knew what issues were happening in those apps.

And we also learned, which is issues developers were

able to solve and which ones they got stuck with.

And the same from, our apps foundation.

So the nonprofit side, we had sort of a hotline where users

could also report issues.

So from that side, we also had a hundred of

reports from users with.

Various kinds of disabilities, and they were just telling

us which barriers they have.

So we sort of combined this data to really know

sort of which success criteria or which issues

were were most common.

So both from sort of legislation side, from all

its and, and from users.

From there, we really started looking in.

so the result is, this one that we are still working on,

like we have just launched this for Android and I'm

now working on the final bits and pieces for iOS.

So it's for, name rule value and states.

And that's something that surprisingly we saw both from

users as well, from audits.

That is really one of the most common issues we are seeing.

so a lot of users are just reporting that

there's maybe an app, with a pin code screen.

Then it has a lot of numbers, like zero all the way to nine.

but each button would just read or announce something

like button, button button, button, button

if the rule would be set.

But sometimes there's not even a rule.

So then you would basically just hear nothing or maybe

hear something like image, image, image or just, yeah,

don't hear anything at all.

so we sort of tried to figure out how can we solve this?

And from our audits, we also knew that some of

the unsolvable issues were many times for

cross-platform frameworks.

A lot of times if people had built an app using fluter

via native or submarine, that Maui, those are some of

the larger and more popular frameworks that sometimes they

would get stuck in our audit.

So we do a re-audit and they just, were not

able to fix some issues.

And I think that also influenced our decision

for our tooling to really go native.

it also makes made sense for us, given my own background

as a native Android developer, native iOS developer.

yeah, do we do it natively but also meant that we have Yeah.

Two different, solutions.

So we sort of have our product for Android

that we're building.

So we're doing this in Copeland and then

we have iOS in Swift.

So we have two different platforms, two different

programming languages.

that's, yeah.

That way we are just able to dive as deep as

possible in the opening system and basically get

the data that we need.

'cause that's what we are seeing.

And I think it's true for any kind of automated tooling,

but also for the web.

Just the more data you have, the better results

you can get in the more sort of rules you can build.

And by doing native, you're just able to get just a

little bit more data than if you would do, using

some cross-platform tooling.

and most that's interesting also for us, that we knew

from our clients, which tooling they were using.

A lot of people were also using native

automation framework.

So we knew there was sort of a market there

to get started there.

And we also moved into sort of the, the cross-platform

tools like Appium is, is a big, big one that can be used

on both Android, iOS from sort of one testing script.

but internally it's also using the Android automation

framework and the iOS automation framework.

'cause there's basically just no other, other way

that Apple and Google are providing to do automation.

so we're doing native, it allows us to sort

of build first for, for native first applications.

And if needed we can also expand to all the

frameworks because they are internally also using

those same frameworks.

but it's, it's a lot of work.

Like Diane mentioned, it's like three years that we're

doing this, a lot of research and then, yeah, more than

two years now actually building the product and.

There's just so many, many exceptions you have

to deal with, different devices sometimes give

different results.

it's just a mix of so many variables, like,

the manufacturer of the phone has it been made

by Samsung or like Google Y or some other vendor.

and even on, on Apple side of things, we see differences

between, different iPhones, even if they're running

the same operating systems.

And sometimes there are some apparently FL

statements in there based on, on device models.

well, interesting one.

We also got that someone was using an iPhone in,

in China and the wifi or so the Internet's

connection work differently compared to Europe.

So we, we are seeing a lot of differences there.

I think one of the biggest issues there is sort of

reproducing those issues.

'cause we don't have every single device or every

single manufacturer on every different operating

system, so sometimes becomes difficult for us

to reproduce those results.

That's why we now finally have a solution where we can

basically have a snapshot from our clients and then we sort

of able to load this snapshot into our system and sort of

reproduce this exact, yeah.

How the screen is looking for them at that moment and

how it's sort of behaving.

there was a, yeah, one of the issues that

we, we have to solve.

It's a really, again, so super interesting because

it's something that I think is quite widely overlooked

is the device and it's, you know, or the access and,

Yeah, 'cause you would just think, okay, well it's an

operating system so we'll do a certain set of rules

for this operating system and then that should work.

But there's so many other variables that just makes

this, that much more complex.

is that sort of, just to double up on that question,

jj, is that sort of, purely a mobile accessibility side of

things or mobile automation?

or would you see similar depending on what kind

of, desktop or laptop someone's using for a

web app or, or a website?

Yeah, I think it, it could definitely

be be similar there.

I think maybe on mobile there's maybe a bigger

chance in, in apps 'cause the sort of native APIs can

maybe behave differently.

but, but interesting.

Some people don't.

Truly realize this.

In the end, the browser is also just an app.

So, if you have Safari or Firebox or Chrome on

your Android IX device, it's also an app.

So potentially those native APIs are also

running on there.

And then it renders the web content.

So technically speaking it was, browsers are always sort

of hybrid apps 'cause they have partly native features

and that sort of a web, web view or like their own sort

of way of rendering the web.

so they, I guess maybe have the worst of both worlds

'cause they have to deal with both the native parts and also

the web parts in, in one app.

yeah, I think it can definitely happen on the

web with, with devices and I think that's also what, what

they are seeing there that is just, difficult to reproduce.

But I think one benefit the web has is that it's sort

of more open in nature.

So we can sort of, for every web page, just see HTML or

the CSS and the JavaScript.

And download those.

And that's sort of your, your snapshots.

Like of course there's some nuances there, but in an

app, you, you basically just see visually what's

there and what's Yeah.

Behind it running it, you Yeah.

Have very limited access, so it's immediately a

lot harder to, to check.

Yeah.

Oh, amazing.

Okay.

Well, I mean, good thing that we've got people like

yourself working on that.

and, so Tanya, so through the audit and training and

side of things, you must see areas where, I think we've

discussed this as well, where automation isn't quite enough

so that human interpretation and understanding is still

very essential to achieving accessible outcomes.

So how much of that is also ingrained in what ABRA is

doing, what you are doing with a, a, in terms of actual

sort of working with disabled users or the human element

of, of the manual testing side of things as well.

Yes.

I think if we look in the, comparison between,

automated and manual testing, and if you look at how many

issues, different issues, can you find with the automated

testing comparably to, to manual testing, if you

would like to come to 100%.

If we take, for example, a waac, guideline as a, as

a basis, because if you, conduct an audit, of course

you need to have a checklist that the issues were the

basis, the basis, basic standards that you apply.

Then it would be probably 2080.

So 20% of the issues if the app.

Depending on the type of the app, then would

be found automatically an 80%, manually.

And, automated testing is always a great way to,

to start with, testing on accessibility.

And if you continuously have to test a lot of screens

on the basic, issues that, that appear frequently,

like name, role, value, state, and it's a great

way to identify a lot of issues on a lot of screens.

So it saves really a lot of time.

And if you have a tooling that can report it and, tell you

how you can solve it, then it, it really saves a lot of time.

But a lot of times when you, yeah, when you want to

come to 100% and you need to dive deeper, you need to

check the screen to check the situation, to analyze

the context, and it can be different, in each situation.

So.

It's hard to automate it because automation

programming, it's about, zeros and ones, and when there

are a lot of exceptions, then you start to automating all

the exceptions, and that's not, that's not, feasible.

and what, what we see is, yeah, the downside of course,

of the manual testing is that, you have to have a

lot of knowledge, again, but also for automated testing.

What we see is that, sometimes, the results,

of automated testing can be different from

what you test manually.

Sometimes it drives me really crazy, but, it's because,

how the app is built.

So when you look at the code, I will, I

will, make an example.

so with, with our new, feature of the snapshot,

testing, you can see the, yeah, accessibility

tree, the hierarchy of how the elements are built

and the accessibility properties of the elements.

And if I, for example, have a visually a button log in

and I test it with a screen reader and I hear, log in,

then I will reject it based on that the button doesn't have

a role that the screen reader doesn't announce a role.

If I make an automated test, then probably this

element has a two sub elements text component

and interactive component, and then a text component

would be, focusable.

But it would not have a role.

And then the other component, interactive

component will not have a label, but will have a role.

So the same element, it would give a success on

the same button because programmatically it

has a role, but the, accessibility focus is put

on the different element.

And yeah, the question is always how do you report it?

How do you report it to, to the developers?

and if you have of course, a little bit, of accessibility

knowledge, then you are able to understand the differences

and to, to interpret it in the correct, way.

so this is, yeah, sometimes, sometimes it's,

challenging and what, what, what I also see in the

practice, yeah, because the developers sometimes

are being very creative then, yeah, the, the result.

It's really difficult.

It's, it's more like exist, existential, question.

What would you reject?

Like is it on the, what is programmatically

correct or incorrect or what the users hear and

what they actually need?

If the button, if, if at all, if the buttons, name, role,

value and state, sometimes developers put all of them

in the name of the element, but our tests will give, an

error that the element doesn't have a role, state and value.

And programmatically it is also that way.

But is it correct to reject it?

Because the users, they will hear, they'll probably

be able to, to use the app, because they.

All the needed information with the screen reader.

So, but if you combine both, then you are able

to pick up the best of the book, both worlds and to

really solve the issues, on a very, deep, level.

yeah, I think that's, that's quite funny.

But it's not funny that it's not being done correctly,

but you kind of don't want to tell the developers off

because they've clearly tried, they've just got

it the wrong way around.

So you don't wanna be like, no, you are wrong.

This is bad.

It's like, you know, it's that reeducation,

it's the knowledge piece that you, you've, you've

mentioned as well.

So, but that's quite an interesting one to

come across, but it must drive you crazy, if

it happens too often.

but brilliant and now really exciting question,

I suppose.

So the.

The European Accessibility Act or Ian 3 0 1 5 4 9.

and the sort of updates to, to that regulation

legislation starting to reshape a lot of conversations

around accessibility and especially for, for mobile,

but also I guess hardware, devices and, and other

things as well, kiosks.

so Tanya, are you seeing a shift in, in how organizations

you work with approach accessibility now that the

EAA is here, it's on the horizon, are they becoming

more proactive or are they still very much reactive?

I suppose what we've spoken about today has been sort

of reacting to issues that have already been

built into existing, apps and, and, and services.

But are you starting to see people put things in place

for breeding that culture of accessibility into their

products and services?

Yeah, we do see, we do see a shift or different, but

mostly within the larger organizations because of

course, the bigger their organization is, the bigger

the chance that it'll will be, checked by the authorities.

so we see that the, larger organization that

they, start conversations about accessibility, about

mobile accessibility.

They come to us to conduct an audit and to make a

accessibility statement or a vpe statement.

And then of course you need to make a plan and to make steps.

what we also see, of course the part of the big challenge

is if you already have an app or several apps within a large

organization and you have these apps already for years,

if they are not accessible and then you start to.

Working on accessibility.

It costs a lot of time and a lot of money.

And it's basically, yeah, it's probably cheaper

to build a new app, that is, accessible.

but,

These are, this is the challenge, but with

the small steps, of course, you can relatively

fast, make a big change.

what we see, at the smaller organizations, there

was a peak around, in, in the summer when the

European Accessibility Act, went official.

But, yeah, of course it means also extra budget

and extra efforts for the smaller organizations.

So, Often if the organization has a accessibility champion,

so someone who is passionate about accessibility himself

or herself, then they will bring this change also within

the small organization.

If this person leaves, then it, it, it dies basically.

So, this is, very sad, to see.

And also what we see is that, implementing

accessibility within the organization independently,

large or small, it's a part of, organizational change.

So we can offer all the tooling, we can offer all

the knowledge, but it's the people inside the

organization who should do it.

And this is often a very slow process, that

requires a lot of internal changes and, it's often a

bottleneck, unfortunately.

but still, we see that, yeah, again, a large

organization, they pick up it as a, as a project.

So they, are interested in online trainings, and

implementing, of course the tooling in their, processes,

and doing regular audits.

yeah, it's approximately on the same level, how it was.

and, and as for the legislation, yeah, there

is maybe good to mention that, there is a, a new

version of an standards that is now being, let's

say approved or, that will also refer to the VAC 2.2.

So the latest, version and to the vac to ICT, what's

applicable to the mobile apps and VAC to ICT has

made also a new version or updated version, uh

which is also now being, approved and discussed.

So we see that the, there are a couple of changes within

the standards, coming, but they are also more harmonized.

So the VAC Act to ICT, if we talk, if we're talking

about mobile apps, VAC Act to ICT and AM standard,

they talk to each other.

So the things that they changed, they also, they

actually, harmonized.

So it's, it's, it's a good step, ahead.

yeah, yeah, definitely.

I think it's a continuous work in progress as well, isn't it?

I think.

yeah.

But great to see that those things are happening.

And throughout what you were saying there about you can

provide all of the tooling, the software, the advice, it,

it reminds me of the analogy, I dunno if it's the same in

the Netherlands, but you can lead a horse to water, but

you can't force it to drink.

so you can give people everything that they

could need, but.

It's on them really, isn't it, to sort of have that,

the push and the desire to get things right or to

change things for the better, but, hopefully it's making

a big difference anyway.

and jj so from a standards perspective, your work

with the W three C mobile accessibility task force, how

does that sort of tie into this and have you been, I'm

assuming that you've been very much involved with some of

these changes and amendments to, WCA two ICT, but how

does that work influence, future legislation, or

global best practice?

Yeah.

yeah, so I've been involved with the Mobile

Acceptability Task Force for around four years now.

So first two years just as an, invited expert as it's

called, which is participating in the group, giving feedback.

And then two years ago I was asked, which

will be interested to become the facilitator.

So facilitators to sort of organizing all the

meetings and sort of leading the task force.

And yeah, I, I decided to do that 'cause I, I saw

some opportunities where we, we improve and find

more people that were willing to contribute.

'cause in the past it was sort of a smaller

group and now it's, I guess more medium sized.

And then I think around a year ago, Tanya also,

joined, the task force.

Yeah.

'cause a lot of times I was really discussing

with her some of the.

yeah, meeting minutes and, and insights and then

it made sense for her to also join, the meetings

and give her perspective.

'cause yeah, since two years or so, I've mostly

been involved to sit in the software development part.

Her company and Tanya has been doing the audits when the

past, I was on actually doing the audits together with Paul.

And then, yeah, now Paul and Tanya are mostly doing the

audits and then, yeah, I'm doing the software development

together with, with Mike.

So it's the, the two of us on the software and

then the two of us more on the server side and also,

yeah, some mix in there.

yeah, but I think I've, what we learned that I've already

been there four years now, is that first of all, it's a

slow process and that's not necessarily a bad thing, but

yeah, it's not, and things are not changing very quickly.

And it's mostly because in numbers we see, I

think in most standard places you would like to.

Get a broad perspective and have many experts

contributing, but you're also looking really closely at

sort of every letter that's written and looking really

closely at those definitions.

And then the combination of all those words to see how

it's gonna be interpreted and give supplemental guidance.

So it's a lot of work and also a lot of work to

have everyone agreeing.

but what I've personally, like one example I have from the

EM standard is what I found out is that, like page titled

was currently not applicable to mobile applications.

so this success criteria for website is really

important 'cause it, it tells you to basically

have the title attributes.

So basically in, in a web browser, every d is showing a

title and technically that's the title attribute that's

being used on a webpage.

So Success Criterion is really easy on, on web where

every, webpage is basically able to set this attribute

and then you can check it, but then it becomes more

difficult in apps where there's no search attribute

on, on an app and there's two different platforms.

but yeah.

How would you interpret this?

Would it be the title attribute on a navigation bar?

Because that's what is visually used to

showing the title.

Some apps don't have this navigation bar, but they do

have a title in a sense that it's maybe larger or bold.

So do we need to look at semantics or characteristics?

but what I found actually in EM standards, 'cause it's

still humans making it, that they, they actually made a

mistake there 'cause they, expected that it was part of

the sets of webpages calls.

That's sort of in a set of webpages.

It has to have certain requirements.

But for page title, actually looking at a single webpage,

so they actually marked it void incorrectly.

'cause it's, yeah, it's not about multiple webpage,

about a single webpage.

But this is where I think a little bit more

in depth with what, what was done in look to ICT.

So that's what's now in, in the legislation, not only in

the Ian standard, but also in section 5 0 8 and other.

Standards or legislation is that they basically

replace webpage.

So from a single page, which is sort of part of

a website, they replace it with applications.

So they're looking at the whole application.

So where it reads normally set of webpage, it now

reads sets of applications.

So it's becomes sort of a set of software.

So like you have Microsoft offers and, word and other

applications that sort of form a suite suite.

and then it becomes very different to, to interpreter

success criterion.

But yeah, I, I raised an issue there.

So you actually, Etsy actually has a GitLab,

which is public, and you can actually just raise

an issue there and people will take a look at it.

So I just raised this issue, page title that actually

it, it could be applied, but just to the title of the

application so that basically it would read that every

app needs to have a title.

But then you basically cannot feel it because

you cannot publish an app with an empty title.

'cause you've never seen an app on your phone that

doesn't have a title.

Like, well actually maybe it could have a space which

has one character, or maybe it's a visible, but then

we go to a discussion.

Okay.

But in a webpage you can actually just set

a title that that tells you about this webpage.

But in an app it's not, yeah, it's different.

It's not about the call it of the app.

It can just be a brand name.

And a brand can be trademarked and a trademark could end

potentially be, be an issue because maybe it's not

descriptive, but it's just the name of the company.

So we gotta do some description there.

and in the end, it's no long, no longer void.

but, it does just have a note there that, it's recommended

in applications to have, titles for each page, but

there's not really clear that so page that there, there are

still some, some flaws there.

And those are just not gonna be solved in Wak two.

And that's basically a realization that, yeah,

Wak two, it's not perfect, especially for mobile

applications or for any kind of non-web, ICT.

and then it is going to be fixed, but not in version two.

So WC three is supposed to solve all those issues,

but it's already been in development for, for 10 years

and it's gonna take another five to 10 years realistically

before that's finished.

So in the meantime, we're still sort of left hanging

with, you know, making interpretations, and what

we're doing as a group mobile task force, and also book to

ICT Task Force data are just now yeah, giving feedback

to the WAC three, work and sort of, yeah, fill those

gaps and make sure that this version will be better.

but yeah, like I said, it, it'll take many years before

it's finished and then by the time it's finished,

it'll take many more years before it'll actually be

adopted in any legislation.

So, until then.

Yeah, we sort of stuck on two and that's, I guess, what

motivates Tanya and me to do, to do the work for Hook

Ag two Mobile, which is a document that we're working

on in the mobile task force to, yeah, until some of those

issues are solved, we just trying our best to sort of

make informative guidance.

How do we as a group expert interpret certain, criteria.

Brilliant.

And do you think, it's such a tricky topic, isn't it?

I was gonna ask about anticipation rather than

interpretation as well.

So if you're anticipating things to change and sort

of looking forward, is there anything in your own guidance

that would say, well, actually this isn't quite right, but

you should be doing this.

Be, and then companies may be ready for when that has

changed in legislation or in, in the guidelines, but,

or do you think we need to still just say, no, get this.

As is for now with this interpretation, and then

hopefully it will meet that new criterion or or new

interpretation of that ruling.

Yeah.

Maybe I can start, but maybe Tanya also has some, probably

ideas there, but one of, one item that comes to mind

for me is with orientation.

Like it's one of the requirements.

So 1.3 0.4 orientation that you need to support landscape

mode as well as portrait mode.

at least that's how we have interpreted on mobile devices.

Like it's different on, on websites that's more about

sort of responsive design.

'cause you're not gonna physically sort of rotate

your, your monitor most of the times that some people

might, might do that.

And then, yeah, a lot of times when, when companies,

especially during audits, yeah, they, Very often

fill 1.3 0.4 orientation on, on landscape.

So they only support portraits.

so we've always told them, Hey, you should also

support, support landscape.

But, it's sort of a chicken and egg problem there.

'cause a lot of apps don't support landscape.

A lot of users are not using apps in landscape at, I

mean, some apps are sort of made for landscape, right?

Some sort of, if you're watching

videos, it makes sense.

And there's other, apps maybe if you have, like one

example is like a piano app.

If you are, you know, making app to where to

recreate piano keys, that makes more sense to use the

wider, view port of your phone and sort of portraits.

but yeah, what we've seen there in this criteria is

that we have always suggested people don't anticipate

on this or whatever.

They're building a new screen.

maybe you cannot fix it in your current space.

For the new screens you're building, just

make sure those support landscape and portraits.

'cause then by the time you maybe have finished all

other issues in your app and you are starting to work on

orientation on those older screens, then yeah you don't

have to worry about the new screens 'cause you already

solve, that issue there.

So that's maybe one example we have.

I think it's always good to go beyond wc.

Like we know, yeah, from our AB foundation as well

with our statistics that there's so many people using,

accessibility features.

But a lot of those accessibility features are

not really covered in any success criteria from WAC two.

Or sometimes they are covered within aaa.

So I think that's also something that we tell clients

that, hey, if you maybe are now compliant with doa, maybe

have a look at, at aaa, maybe have a look at Whatt mentioned

the target size one, but then the enhanced version.

'cause on apps that's.

And maybe actually the minimum you should be doing.

So they just, yeah, pick some of those triple A criteria

and, and start doing some work on those to make your

app even more, accessible.

Yeah, I like that.

The beyond work ag as well.

I think that's something that is often forgotten.

'cause we are so focused on guidelines

or checklists as well.

It's like, it's not a checklist, it's something

that, you know, needs to be bred into every

part of, of an app or, or a website or product.

amazing.

Well, so I, before we go to sort of final thoughts

on things, I just wanted to ask you both, to maybe

become even more of a seer than you already are.

but talking about the future of mobile accessibility, it

does feel like we're at a bit of an inflection point at the

moment between automation, artificial intelligence or

machine learning, but also the growing recognition that

accessibility does need to be built in from day one.

so what's exciting you about.

Where technology's heading in this space.

I guess in terms of testing and standards, JJ and, and

Tanya, what would you see as the next big opportunity for

the education and culture change side of things

utilizing new technologies?

I dunno, Tanya, I feel like me and JJ have been talking

for a while, so I dunno if you wanted to go first and

then we'll bring JJ in after.

yes, sure.

Well, I think, I still think that, the biggest opportunity

is, Is a mindset, of course.

So we need to shift the mindset from fixing things

to make it accessible to building apps accessible

in the first way.

So I hope that, in a terms of time, in the future,

that it'll be a standard.

So, you know, you, you, if when you are learn how

to become a developer, that accessibility

will be part of it.

So you just build things accessible and that's it.

and that will solve the problem in the

future, of course.

and I think that, what we see now, and the mobile space

is of course relatively new.

It's not relatively new, but, those who are developing

mobile apps, they are not yet.

Like old enough to experience the need of using accessible

apps themselves, or probably that generation is just

starting to, to, to experience like, oh, it's helpful if

I can actually use the app with a enlarged text size.

So when you understand that, okay, I'm dependent

on the mobile device and on the mobile apps, so

probably I should develop the access accessible apps

now so that I can, pass it to the next generation and

use it myself in the future.

So I think that it's a biggest, change.

And of course with the legislation, the, in

the future, I hope that, with the change.

That we are also, doing within the mobile task force,

that the guidelines that they, will become more unified.

And also personally, I hope that more people with

disabilities will be involved in shaping those standards

for mobile apps specifically because, I sometimes feel

that we lack that knowledge a little bit when we

talk about the standard.

Then you should also test it with the, with the end users.

And of course they are involved somehow.

But yeah, still it's a, it's a big black box to me sometimes.

it's not always that if you follow the word of

standard that it's helpful for the users, maybe in

some cases it's otherwise.

and then, yeah.

When it comes to organization, I just, hope that, it'll

be more often included in the definition of done.

It'll be offered as a standard package of the

educational trainings within the organizations,

and that the certifications will be, required or more

desired by the organization who hire, developers.

So when it becomes a part of the, of the routine, of

the definition of done, then yeah, it's much less effort.

and of course, building from the beginning in

accessible way saves a lot of time at the end.

I agree.

And it's just sort of paving that way for people so that

there's guardrails, right?

So then people can just sort of, if you guide them in

the right direction, then hopefully it just makes

everyone's life a bit easier.

But I love that.

Yeah.

The mention of obviously bringing in more people

with lived experience of, of different disabilities

or impairments.

absolutely.

Because we've spoken an awful lot about, standards

and guidelines, but it's not always a hundred percent as

much as we'd like it to be.

and then, so JJ, on the, on your side of, on the more

technical side, where do you see technology heading?

Is it down the automated route?

I know we've said that there needs to be a mixture of

both, but it's very helpful in terms of, reducing the

amount of human hours, I suppose, on audits and things

to have the automated tools.

But what, what excites you about the future

of accessibility in the mobile space?

Yeah, thanks.

I, I guess I'm mostly enthusiastic about the

opportunities sort of for automation now.

I guess with ai, machine learning, all those

technologies, we're sort of able to go beyond what

we're able to do nowadays.

I think it also helps automation, like ideally you

basically need zero knowledge and you can just hit a button

and it just tells you what issues you have and also

tells you how to solve it.

because I think that's a big difference with, with manual

testing, like Diane mentioned, that you need a lot of

knowledge to even get started and to interpret those results

and deal with all those different interpretations,

all different frameworks and different criteria, and

then different standards.

I think that's really something that automation

can do if it's used in the right way, that it can just

tell you, with certainty that this is an issue.

But ideally also tell you how to fix it, and then ideally do

this for multiple frameworks, including the one that the

developer itself is using.

so I do feel things like AI can help to create more

code samples or to even transform code samples.

Like if you know how something works on native

Android or native iOS, you're sometimes able to

make a plugin for those close platform frameworks.

Maybe now with AI you can actually tell them, okay, this

is how I can do it to Android.

I have this code snippet that works, that maybe was

written by a human back.

Then how would I be able to port this to maybe

flitter or, or react native?

So I think that's opportunity there for developers.

And I think the same opportunity exists for

things like training where maybe not everyone

is an English speaker.

So potentially you can use AI to make a new version of

your training materials to offer it in more languages.

so I, I, I see opportunities there, but I think very

important remains that yes, you know, AI has

hallucinations or can come across as being

very confident, but maybe it's, it's not correct.

So there are still challenges there, especially 'cause we

know on average the, the, the app developers don't

have that much knowledge about accessibility.

So they're not able to sort of fact check the results.

I think that can.

Dangerous where maybe they are not.

Yeah, maybe sometimes making, fixing something

that wasn't an issue before.

And then also for the sort of AI generated fixes or

code samples, there's also a challenge there that maybe it

also breaks things or maybe is not an actual back practice.

So there are some challenges there, but I think at the

rate we're seeing AI and, and machine learning and

all those technologies evolve now, I think we,

well, we'll benefit there.

And I do wonder if at some point, this also being

discussed heavily though, to see if we are seeing maybe

a shift where now developers have to solve those things.

We're maybe seeing that assistive technologies can

potentially fix things.

But yeah, I think that's also slippery slope if

you say, oh, maybe this assistive technology, maybe

this screener is able to automatically generate

all text or images, or maybe it's being able

to automatically detect.

S or the names of buttons and, and those things, but

maybe another user doesn't have this exact technology,

so not everyone has access to the same technology.

So there's also some, some danger there.

but all in all, I'm optimistic about the opportunities and

yeah, excited to see, see what's possible and how we

can truly just make from both perspectives and just ensure

users, like that's what it's about, that they can actually

just use the app and achieve whatever task they yeah.

Would like to do within this app.

Yeah, agreed.

I was gonna about, I was about to sort of expand on

that slightly, but then I think, feel like I would

put a negative spin on it, so I don't wanna do it.

It was just purely around, I'm not gonna do it.

It's not, it's fine.

I've, what I'm gonna do is something more positive.

'cause there has been an awful lot of, of,

positive discussion in this episode and, and.

Especially, you know, obviously talking about

what, what yourselves and ABRA and the task force

are doing, and it's just amazing to know how much of

an impact you are having.

So, before we wrap up the episode, I just wanted to ask

if, if you both individually had a, a message you'd like

to, for listeners to take away, anything or something

that you wish that every designer, developer, or

tester, anyone in this sort of space would remember when it

comes to mobile accessibility?

Tanya, I dunno if you wanna go first.

Yes.

yes, I, use this, metaphor, often comparing accessibility

with the brushing, teeth.

If I tell you that, brushing your teeth once

a year, once a year.

Helps to keep them healthy.

You would say time ridiculous.

And that's correct, because it's not possible, but

that's often what companies do with, relation to

mobile accessibility.

Make a audit one time per year and then forget about it.

so if you, and if you look at it a little bit closer,

then, yeah, you understand that having an electric

toothbrush will not brush your teeth automatically.

So if you have a tooling but you don't have a knowledge,

it'll not be helpful.

But having.

All the knowledge about how to brush it teeth, but not

have a, having a toothbrush will not help either,

because then you will have to do it with your finger.

So knowledge without the tooling is not helpful either.

And if you never go to the dentist or use the

floss or the mirror, then you will not know whether

you are doing a good job.

So, if you don't go and check with a, with an auditor, or

someone, an accessibility expert, you'll not know

whether you do a good job.

So, like brushing, when you think about mobile

accessibility, think about brushing your teeth

and it works when it's, part of your routine.

Just daily, two times a day, just brush your teeth

and then make it a habit, and then it, it works.

I love that.

That's just absolutely brilliant.

I'm gonna have to clip that so when we edit this

episode, it will, we'll be using that as a, as a video.

So thank you for sharing that.

And Yna, sorry, hard to, hard to top that, but

have you got a message?

I was trying to say, it's hard to, to top this.

We should edit it, already.

No, I think for, for me, I, I would just like to say, yeah,

take a look at, at websites, I think they're still ahead

in terms of accessibility.

So see what you can learn there and really look at

maybe responsive design.

Like it's really common now in, in a website.

Nobody's building, you know, desktop only websites

anymore, and everyone's building responsive

or even mobile first.

And I think people should also do that more

for apps, especially.

I think people that are sort of buying apps, they should

tell, Hey, my app should only, not only be working

on mobile devices like an iPhone or an Android, phone,

but also on, on Android tablets and on iPads and

maybe other form factors.

Like now we have sort of those devices you can fold.

So you just want your app to work on all those different

devices and make sure all users have a good experience.

yeah, and that includes landscape mode.

And by doing landscape mode and by doing responsible

design, you usually also fix other accessibility

barriers like tech scaling.

'cause if you already an and yeah, just make sure you can

maybe do one column or two columns or three columns.

Then if you start supporting larger tech size, maybe

you're also able to support that better.

'cause you already know that maybe not every

row, every column will have the same size.

yeah.

So that's what I just want to say.

Yeah, just yeah.

Responsive design is not only for web, but

also Yeah, for apps.

Nice.

I think that we could caveat that with, just do it.

Just, just do accessibility.

Just think about it, brush your teeth.

thank you both so much for, for joining me on the episode.

what you are doing in the space is, is is not unnoticed

over many conversations here in the UK and, and, with

people around the globe that, that know what you're doing.

And I'm always sort of pushing people your way to say, look,

this is, you know, in the mobile space, look no further.

So, yeah, thank you for everything that you're

doing, not just from me, but from everyone

that you are benefiting.

it's incredible work and yeah, just really appreciate

your time today and I hope that we can work together

more in the future.

Thank you.

Yeah, thanks a lot Joe.

Thanks for those, motivational words and

thanks for having us on.