YT YouTube2Text

YouTube2Text → Transcripts → Building for a new next billion users I Axe-con 2026

Building for a new next billion users I Axe-con 2026 — Transcript

by Deque Systems · 6,810 words · 1,033 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Thank you so much, Josh. Um, so good
0:03morning, afternoon, evening, wherever
0:06you are. For me, it's currently actually
0:088:00 PM, so probably going to go to bed
0:10after this, but really excited to be
0:13giving my first talk at Axcon, actually.
0:15And as um Josh mentioned, I'm going to
0:18be talking to you about building for a
0:20new next billion users.
0:26So, I want to start this by going back
0:2810 years ago. And I know there's
0:31actually been a whole 2016 throwback
0:34trend online. And don't worry, I'm not
0:37actually trying to bring back 2016. I
0:40remember that there were also some
0:41pretty crazy things that happened that
0:43year. But, um, yeah, going back to 2016,
0:46um, for me personally, I was about a
0:49couple years out of my master's degree
0:51in law. And when I graduated, I was
0:54going through something of uh or
0:55somewhat of a career crisis trying to
0:57decide if I would, you know, continue
0:59with law or go for my passion, which was
1:01web development. Luckily, I chose the
1:03latter, obviously. Um I moved back to
1:06Nigeria after I was studying abroad in
1:09the UK and I started working as a
1:11software engineer
1:13and luckily for me, things were actually
1:15starting to go well. Um I was uh
1:18recognized by Google as like the first
1:20female web technologies expert in
1:22Nigeria and I started working for a
1:24company called Big Cabal Media as their
1:27head of technology and Big Cabal was
1:30essentially like the Buzzfeed for Africa
1:32and they had a number of publications
1:34that were targeted at the mass market
1:38and as the company started to grow we
1:40would start to get complaints that
1:42certain parts of the website weren't
1:44working. So, for example, we would have
1:45a quiz like, I don't know, which Afro
1:47beats artist are you? And it just
1:50wouldn't work. It wouldn't submit for
1:51some people or like the layout started
1:53to look a bit janky.
1:56And then I went to check the analytics
1:57and saw like something like maybe 25% of
2:01users were browsing with Opera Mini. And
2:04I was like, okay, what is Opera Mini? Up
2:08until this point, I hadn't actually ever
2:10used it or even heard of it.
2:12And in case you don't know, Opera Mini
2:14is essentially like the low-end sibling
2:16to the Opera mobile web browser, and it
2:19comes with a few key features. So,
2:21first, um, Opera Mini requests web pages
2:24through their compression proxy server.
2:27And this server, um, compresses all the
2:29requested web pages before actually
2:31sending them to the mobile phone. And
2:33that means that there's actually no
2:35client side processing of JavaScript. So
2:37obviously if you were, you know, trying
2:39to take the which Afro beats artists are
2:42you survey and you try to click submit,
2:44it just wouldn't work because there's no
2:47client side processing of JavaScript.
2:50Um there was also very limited support
2:52for a lot of modern HTML CSS features
2:55like CSS grid. There's basically no
2:58custom font styling. You couldn't, you
3:00know, have the app font face um or
3:03things like that. And this was actually
3:04quite shocking to me because I was
3:07starting to wonder. I had been
3:08developing for a while like why nobody
3:10else seemed to really be talking about
3:12this or nobody else seemed to know about
3:14it.
3:15And after doing some digging, it started
3:17to make some sense because like in a lot
3:20of regions like Europe and North
3:21America, the usage of Opera Mini was
3:24only something like 2 to 4%. But in
3:26countries like Nigeria, which is where I
3:29was, um this went up to something like
3:3173%. So massive, massive difference.
3:35And then my next question obviously was
3:37like why why would anybody be using this
3:39browser that was clearly breaking
3:41everything? And obviously as a
3:44relatively young developer
3:46>> [snorts]
3:46>> um my first instinct was like okay well
3:48the people are wrong like why are they
3:50using this browser? Um instead of
3:52thinking oh there must be a reason. And
3:55basically to answer the question of why
3:56were so many people using this we kind
3:58of need to look back at the state of the
4:00web back in 2016.
4:03So at the time only about 47% of the
4:06world's population was online meaning
4:08that 53% more than half were still
4:11offline and of that 53% the vast
4:15majority so like 91% came from less
4:18developed countries like Nigeria.
4:22And if you look at why this was the
4:24case, it largely came down to two
4:26reasons. So low coverage, although it
4:29was expanding, 3G hadn't really reached
4:31a significant portion of the global
4:33population yet, especially when it came
4:35to a lot of the more rural areas. And
4:38then secondly, the high cost. And there
4:40were two barriers um with respect to
4:43high cost. So first, like just the cost
4:45of the devices themselves. um feature
4:48phones were still a majority in this
4:50region just because of the high cost of
4:52you know the latest iPhone and things
4:54like that and of course phones like this
4:56didn't really have the capability to
4:58handle a lot of the modern features
5:02and then with these like less developed
5:04countries the average cost of um about
5:07500 megabyte of a prepaid mobile data
5:09plan ended up being about 6.5% of
5:13average income. So, if you think about
5:15that, like having to spend almost like a
5:18sixth of your monthly income on just 500
5:20megabytes, of course, you'd be very
5:22cautious about every single megabytes
5:25that you're trying to spend.
5:28But then if we looked at, you know,
5:30places like Europe, North America, the
5:32story was the opposite. Connectivity
5:35near perfect and costs were relatively
5:37low. like a lot of people were able to
5:40afford um smartphones and higherend
5:42devices and then the cost of data was
5:44quite insignificant
5:47and it's basically this set of users
5:49that digital products were primarily
5:51built for cuz think about it um most
5:54people building these products were
5:55already in these countries so it made
5:57sense that they would build for
5:58themselves but what was ironic in my
6:01case was that you know I had been
6:03brought up in Nigeria but I was still
6:05somehow building for this demographic
6:07that was outside of you know the people
6:10around me and this is obviously because
6:12I was even though I was physically in
6:15the country I was still in a relatively
6:17privileged 1% who actually had access to
6:21you know the latest iPhone and computers
6:24to build websites using you know the
6:26latest JavaScript features and all of
6:28that
6:31and it was basically in this context
6:33that Google initiated what they called
6:35the next billion users project which was
6:38all about creating a more inclusive
6:40internet by addressing the specific
6:42challenges that were faced by users in
6:44frontier markets. So the concept was
6:47simple. There's going to be over a
6:49billion new users coming online over the
6:51next decade. We need to make sure that
6:54digital products are accessible to them.
6:57And Google's initiative kind of focused
7:00on these four areas. So first like
7:02connectivity solutions they developed um
7:05products like the progressive web apps
7:07that work offline and then even like for
7:10connectivity and services like YouTube
7:12go for just better YouTube video
7:15experiences with lower data
7:19um to provide more affordable devices.
7:21They continued the efforts with things
7:23like Android one to like partner with
7:25manufacturers to create more budget
7:27smartphones
7:29for localization. They worked on, you
7:31know, adapting products for local
7:32languages, cultures, contexts.
7:35And then finally, they really went full
7:37on with mobile first design because they
7:39recognized that most new users that um
7:42are trying to access the internet for
7:44the first time are doing it through
7:45smartphone. So they really emphasized on
7:47designing for mobile.
7:51So with a focus on these four areas, um
7:53the goal was to ensure a smooth
7:56onboarding for the next billion users
7:58that are coming online over the next 10
8:00years.
8:02So here we are 10 years later. Uh let's
8:05see what the world is like. Um in some
8:07ways the world is similar. I'm also a
8:10recent graduate again. This time I
8:12graduated from an MBA INSEAD. I hope
8:15this would be my last degree. But in
8:18other ways the world has actually
8:20changed a lot and in a lot of ways for
8:23the positive. So um things like
8:26connectivity has improved quite
8:28drastically. Um we now have a lot more
8:30people online um than we had before.
8:33About 68% are now online.
8:38And then we're seeing that for most
8:40people both coverage and connect and
8:43costs have actually improved. Although
8:45we're um we're seeing that there is an
8:48improvement, we are still seeing that
8:51there is um a divide between you know
8:53the poorest countries and the richest
8:54countries. So it's like higher coverage,
8:56lower cost but not necessarily
8:59completely solving the entire problem.
9:02And of course now we have new problems
9:06because as technology progresses there's
9:08going to be opportunities for bias and
9:11we see this very clearly of course with
9:13AI.
9:16Um, so we have a huge bias problem with
9:18AI because we see that over 90% of
9:21training data is in English even though
9:24just about 20% of the world had is
9:27speaking English as their first
9:28language. And we're also seeing
9:31overwhelming representation of US and
9:34European data, minimal African and Asian
9:37representation. And this has like a real
9:39effect. The result is that when these
9:42models are then being applied to these
9:43minority groups, we see up to a 40% drop
9:47in accuracy, which is really crazy to
9:49think about because just think about the
9:51context in which these agents are being
9:53used like medical or diagnostic settings
9:56and such a drastic difference in
9:58accuracy has the potential to do real
10:01real damage.
10:05And there's also a whole subset of
10:08problems that the original next billion
10:10users didn't actually take into account,
10:12which is the billions of users that
10:15historically and are currently still
10:17being locked out by poor design and
10:19digital um and inaccessible digital
10:22patterns. So it turns out that to reach
10:25this next billion users, we actually
10:27need to take into account a whole lot
10:29more than just those four key areas. We
10:32have to look, you know, deeper into
10:33internationalization and representation,
10:36just the usability, so many other
10:39things. And the overall theme here is,
10:41of course, just accessibility.
10:45And broadly speaking, we can define
10:47digital accessibility as the inclusive
10:50practice of ensuring there are no
10:51barriers that prevent access to
10:53technology. And the key point here is
10:56the removal of barriers to access. And
10:59although this does apply to everyone,
11:01when we talk about barriers of access to
11:04technology, it's sometimes helpful to
11:06look at three groups of people because
11:09they have quite specific access needs.
11:12So, first is people with physical or um
11:15permanent disabilities. And this is
11:17typically what we think about when it
11:18comes to accessibility. So, people that
11:21might have visual impairments or
11:22auditory impairments.
11:25But we also have the concept of
11:26situational disabilities. And this is
11:29looking at how in practice um there are
11:32people that may not have an actual
11:34permanent disability, but just due to
11:36the situation they're in, they might
11:38have similar access needs um to someone
11:41who does have a permanent disability. So
11:44classic example is just someone who
11:46either maybe they've broken their arm or
11:49they are holding a baby and so they can
11:51only actually access technology with one
11:53hand even though you know in theory they
11:55have two capable hands. Um, in practice,
11:58they're going to be functionally similar
12:00to somebody who only has one capable
12:02hand.
12:04And accessibility also relates to how
12:06people with socioeconomic restrictions
12:09can have access to technology. So, for
12:11example, as we've shown, someone who's
12:13extremely data conscious may not be able
12:15to access websites that will require
12:17them to download like 5 megabytes of
12:20data just to view the website.
12:24But all in all, accessibility is about
12:26having like an inclusion first mindset.
12:29And in today's world, um the digital
12:31sphere is really as vital as the
12:33physical [clears throat] one. So the
12:36same way that we think about people
12:38requiring access to physical buildings,
12:42we should also be thinking that people
12:44also require access to the digital
12:46sphere.
12:48And by making products that are
12:50accessible to these three groups that
12:52we've talked about, we actually create a
12:53product that works better for everyone
12:56even outside of these groups.
12:58So in this context, I want to share what
13:00I think are the five pillars for digital
13:03accessibility. And these pillars do
13:06apply to digital platforms as a whole,
13:09but my personal background is in the
13:11web. So a lot of the examples I'll show
13:13are a bit more related to the web
13:15platform.
13:17So these are the five pillars and let's
13:20start with performance because we all
13:22know that performance is important um
13:24but we often think about it in terms of
13:27like milliseconds saved for a user on a
13:29fast connection but for the next billion
13:32user performance is measured in sorry
13:36let me just take a drink
13:43sorry if I get cough
13:51Um so for the next billion users
13:54performance is measured in real money
13:57and time lost.
13:59So I did mention before that data costs
14:01have improved but still today in
14:04subsaharan Africa for 1 GBTE of data is
14:07still going to cost about four to 5% of
14:11average monthly income which is actually
14:12double the UN's affordability targets
14:16and to add to this um users typically
14:18aren't on you know unlimited monthly PS
14:21they're on prepaid pay as you go so if
14:25you know the data runs out the internet
14:26is just going to stop and this creates a
14:29real data scarcity mindset. So users are
14:32going to disable images, avoid video, or
14:35use browsers like Opera Mini that are
14:38going to optimize every megabyte.
14:44So this means that your website or
14:46application
14:47needs to be as lean as possible and this
14:50applies to every aspect of your
14:52development pipeline.
14:55So starting with frameworks now we of
14:57course know that frameworks offer
14:59incredible developer productivity but
15:01they also come at a cost. Every
15:04framework no matter how optimized is
15:06going to add a baseline level of
15:08JavaScript that the user needs to
15:09download, parse and execute before your
15:12application can become interactive.
15:15So in this world of data scarcity this
15:18initial cost can actually be a
15:19significant barrier.
15:22So it is worth asking yourself you know
15:24before starting any projects do you
15:26really need to use that single page
15:28application framework for your website
15:31because if we compare the size of a
15:33simple application we can see quite a
15:35stark difference and this was an example
15:39it's like a calculator application I
15:41believe that was created to um compare
15:43the different JS frameworks and you can
15:47see that using a heavier framework like
15:48angular it's like 140 kilobytes we use a
15:52lighter framework, things are better.
15:53But of course, nothing beats vanilla
15:56JavaScript. And the point of this isn't
15:59to say that you shouldn't use frameworks
16:01at all because of course there's going
16:03to be cases where it is far more
16:05efficient to do so, but it's more about
16:08looking at your particular use case to
16:10assess because the different tools we
16:12have are going to have a direct
16:14financial impact on our users. So
16:18taking the mindset of choosing the
16:19leanest tool possible that will still
16:22get the job done is the best approach.
16:26Now JavaScript is only one part of the
16:28story because more often than not the
16:31biggest culprits with performance are
16:33actually like unoptimized media assets.
16:35So like images, video, custom fonts.
16:38These can all easily dwarf the size of
16:40your code and can actually be like the
16:44most expensive resources for your users
16:46to download.
16:52So looking at images as an example, you
16:55can save a lot just by using modern
16:57formats like AIF and um WEBP. They
17:00offer, you know, a lot more superior
17:02compressions to traditional JPEG and
17:05PNG. and then using like the picture
17:08element to provide fallbacks.
17:12Sorry, one second.
17:23Um, so it's also not just about how long
17:26it takes to download everything.
17:30Sorry, excuse me.
17:32Let me just uh clear my throat.
18:18Okay, sorry I am back really fighting a
18:21cough here. Um, but yes, so it's also
18:24not just about how long it takes
18:26everything to download, also about how
18:28long it takes your users to actually see
18:30something useful on the screen.
18:34So if you look at the path towards how a
18:36web page is built and rendered, we can
18:39see how you know your HTML, your CSS and
18:41JavaScript used together to form the
18:43render tree. And then after a few more
18:45steps, we end up with what is being
18:47painted on the screen.
18:50And the resources that are going to
18:51block your render are going to be any
18:53CSS that you have in the head and also
18:56any JavaScript that you have in the
18:57head. So having a lot of these resources
19:00are going to lead to, you know, the
19:02dreaded blank white screen that your
19:05users will see before the page can load
19:07at all.
19:09So you want to do things like, you know,
19:11inlining any critical CSS and loading um
19:14non-critical CSS asynchronously.
19:18And then for JavaScript, you just want
19:19to eliminate or limit any JavaScript in
19:21the head if possible.
19:24And then pulling on from this, lazy
19:26loading assets is, you know, another key
19:29thing to be looking at. Simple principle
19:32here is just don't load what the user
19:34doesn't need because a significant
19:36portion of your web page is going to be
19:38below the fold and most users might not
19:40even get to it. So
19:43having the principle of not loading it
19:45until it kind of comes into view will
19:48mean that users are not going to pay for
19:50things that they don't actually um
19:52consume or see in the first place.
19:56So ultimately when it comes to
19:58performance you want to be as lean as
20:00possible from end to end.
20:04So next user experience and this can be
20:07a make or break for users.
20:12So for a first-time internet user, a
20:15confusing interface isn't just it's more
20:18than just frustrating. It can be really
20:20intimidating and completely erode the
20:22confidence that they need to engage in
20:24this new digital world. And then for a
20:28screen reader user, for example, an
20:31interface that is not semantic is
20:33basically just like a blank screen. or
20:35if you don't have proper headings and
20:36structure, it's basically just a
20:39confusing stream of content with no
20:41context.
20:43And the thing is, most platforms, the
20:45web included of course, are actually
20:47accessible by default. And our job as
20:50developers is to make sure that that
20:52content remains accessible.
20:57And we can do this by working with the
20:59platform, not against it.
21:03The first step is using the correct
21:05elements for the right purposes. And I
21:08always like to use the example of, you
21:09know, a classic button.
21:12Just by using the right HTML button
21:14element, we get something that's
21:16accessibly styled and we have all the
21:19appropriate features. So it can be
21:21interacted with by all types of input
21:24devices whether that's keyboard or like
21:27the mouse um or anybody navigating with
21:30other types of alternative input
21:32devices. And we basically get all of
21:34this for free.
21:37But if we wanted to use something like a
21:39div instead of a button, which for
21:42whatever reason still happens at times,
21:45if we want to try to replicate this
21:47level of accessibility, it would take a
21:50lot more work to achieve. you'd have to,
21:52you know, ensure you have the correct
21:54roll. Make the element focusable
21:57um by the different input devices. Make
21:59sure that you're handling all the
22:00different types of key presses. Make
22:02sure it's styled so that it can be
22:04visible um if you know somebody tabs
22:07into it instead of using a mouse. And so
22:10many things come into that. So
22:13ultimately, it really is just easier to
22:14work with the platform instead of trying
22:17to I guess recreate something from the
22:19ground up yourself.
22:22And if we do want to make changes and
22:25which is to say um which is not to say
22:27we shouldn't try to make changes because
22:28there's many ways that we can actually
22:30do it in a way that is additive and not
22:33subtractive. So although you know by
22:36default the platform is generally
22:37accessible it can't be the best case
22:40scenario for your particular website or
22:42application because it's a broad
22:44default. So that means there are
22:46actually many ways that we can improve
22:48on the default browser behavior.
22:51I uh recently came across this Reddit
22:54thread in the r/blind community.
22:58Um it asked screen reader users for like
23:00some of their biggest pet peeves.
23:03The top comments by far was actually all
23:06the popups that modern websites now have
23:08which I think we can all relate to even
23:10as cited users.
23:13But another common theme was screen
23:15reader users wanting websites to be more
23:18customizable to their preferences. So
23:19things like having dark mode or reduce
23:22transparency and that's something we can
23:25actually offer um with modern CSS
23:27nowadays. So we can adapt the web page
23:29to user preferences or you know reduce
23:32data or reduce motion um color scheme.
23:36So dark mode, light mode, um contrast,
23:41reduce transparency. And this is a way
23:43that we can actually improve on the
23:45default browser behavior.
23:57So one key thing to remember when
23:59developing is that not everyone is going
24:01to be using the same mode of interaction
24:03with the website.
24:05So we tend to think of people either,
24:08you know, on a laptop with a keyboard
24:09and a mouse or on their phone, you know,
24:12tapping with their fingers. But there
24:13are many more ways of interacting with
24:15technology.
24:18So for example, we have screen readers,
24:21alternative pointing devices and so much
24:24more. But ultimately what we have to
24:27remember is text is actually king here
24:30because if all of your um content is
24:33represented in a structured text form,
24:35then people with different modes will be
24:37able to access it.
24:40And that's why it's very key to if you
24:42have anything that's not represented in
24:44text form. any media like images or
24:47video then having text alternatives so
24:50that it is accessible to people no
24:52matter what mode of interaction they are
24:54using.
24:57So ultimately working with the platform
24:59is about making sure that the code we
25:01write adheres to
25:03best practices and doesn't undo the
25:05default accessibility of the platform.
25:12So following on from this, we have
25:15robustness. And this is the principle of
25:18building a resilient web that works for
25:20everyone regardless of their device,
25:23network condition or browser
25:24capabilities.
25:27It's basically an acknowledgement that
25:29you know the pristine conditions that we
25:31develop in you know with the latest
25:32hardware fastest internet etc
25:36were not really the reality for most of
25:38the world. So a robust application is
25:40one that's going to work the same on
25:42like a 5year-old Android phone with I
25:46don't know intermittent 3G connection as
25:48it does on like the latest iPhone with
25:505G.
25:54And this is achieved through progressive
25:56enhancement.
26:03>> So on the web, this is basically about
26:05starting with a solid universally
26:07acceptable HTML foundation and then
26:10layering on CSS for design and
26:12JavaScript for interaction.
26:15I always like to use the analogy of a
26:17cake here. So um the HTML is the core of
26:20the cake. Um, your CSS is like your
26:22icing. Then your JavaScript is like all
26:24the designs that you put on it. And the
26:28key thing here is that the CSS and your
26:31JavaScript is not going to detract from
26:33the core, which is the HTML cake. And
26:36um, they're good additions to have, but
26:39they don't take away from like the cake
26:41doesn't not exist because you've added
26:43CSS and JavaScript.
26:51And um this applies to more than just
26:53CSS and JavaScript. So we can look at
26:56even connectivity as a feature to be
26:58progressively enhanced.
27:02And we see this with um you know using
27:04service workers. It's a tool that we can
27:06use to make websites work even offline
27:08because they're able to sit between you
27:10know the web page and the network. And
27:12if there for some reason a user can't
27:15connect directly to the network, they
27:17can still receive the information of the
27:20web page from the service worker.
27:22But ultimately, progressive enhancement
27:24is about looking at um everything as an
27:27enhancement, right? And just developing
27:28with the mindset that anything you add
27:31shouldn't be destructive to what was
27:33there before.
27:36Now, in the age of AI, the content we
27:38create has a new and profound
27:40significance. It is no longer just um
27:44you know for human consumption. It's now
27:46the raw material that's going to train
27:48the next generation of LLMs.
27:52And I remember speaking about something
27:55similar back in 2019 um you know before
27:58LLMs were where they are today. And I
28:00showed this video of the soap dispenser
28:02where you know someone with light skin
28:05um puts their hand under the soap
28:07dispenser and it works. That's normal.
28:08But someone with darker skin, the soap
28:11just never comes out. And um even when
28:14the person uses a piece of tissue, which
28:17is obviously white, to put under the
28:19soap dispenser, then the soap comes out.
28:22But then again, if the person of darker
28:25skin puts just their hand underneath it,
28:27no soap comes out. And it just shows how
28:32um if the content we produce is not
28:34globally representative, it's not
28:36accessible. If it doesn't if it only
28:39reflects like a narrow slice of the
28:41world, then the AI that we build from it
28:43will inherit and amplify those biases at
28:46like a much larger scale. So whatever,
28:49you know, biases you put into the AI is
28:51what is going to come out on like a much
28:54much much larger scale than we've
28:57probably ever seen before.
29:00So nowadays, more than ever, we really
29:02need to be conscious of what content
29:04we're publishing.
29:06This of course applies to the actual
29:09website content. So you know if you're
29:11working in a media publication um the
29:14articles that are being published, the
29:17language you use could really inform how
29:20AI understands complex social issues and
29:23creating inclusive content is actually
29:26now an act of building perhaps a more
29:28equitable future AI.
29:31But crucially, it also applies to, you
29:34know, us as developers and what content
29:36we put out there. So things like um non
29:39the text descriptions of nonext content
29:42could actually be used to inform what AI
29:47um how AI understands this non-ext
29:49content.
29:51So, for example, um if we were to um
29:55caption an image of a white man as just
29:58doctor, but then we had a black female
30:00doctor and then we caption it as black
30:02female doctor, then the AI learns that
30:05one of these is the default and one of
30:06these is the exception. So we need to be
30:10more conscious of things like this to
30:12understand that this information could
30:14be used to um train or for future AI to
30:19understand what is the default of a
30:22doctor.
30:24Um but critically this also applies to
30:27the code that we publish as developers
30:30because the coding LLMs they're scraping
30:32the web they're scraping you know open
30:35code repositories.
30:39And this is how they are learning how to
30:41develop themselves. So if our code
30:43doesn't take into account accessibility
30:47then these agents will also not take
30:48into account accessibility.
30:51And nowadays um software engineering is
30:54you know starting to move towards being
30:56more about guiding the agents rather
30:58than developing ourselves. So we have to
31:02be really conscious of the patterns that
31:04we are encouraging and ensuring that
31:06even in our guiding and directing of
31:09these agents we're keeping accessibility
31:11in mind
31:13and it can be quite scary to think that
31:16you know everything we put out there can
31:18have such consequences but unfortunately
31:21I think that is the reality of the world
31:22that we're living today. So we need to
31:25be ever more conscious of you know what
31:27we are publishing and putting out there.
31:31So finally empathy and this is um the
31:34engine I guess that drives all the other
31:36pillars because it's the practice of
31:39putting ourselves in the shoes of our
31:41users and understanding that you know
31:43their experience of technology may be
31:45vastly different from our own and
31:47without empathy accessibility just
31:49becomes a very technical checklist. And
31:53it reminds me of this project which was
31:56to essentially create a
31:59a website that is actually completely
32:01inaccessible but will still get 100% on
32:05um Lighthouse and other you know tools
32:08other similar tools. And
32:11he achieved this by you know doing a few
32:13different things like he made the
32:14website have CSS as a dependency. So um
32:18if CSS was not for whatever reason
32:22enabled in the browser like the website
32:24just wouldn't be visible. He did the
32:26same for JavaScript as well. Um
32:30he then made sure that screen readers
32:32wouldn't be able to access the page. I
32:34think he put area hidden is true on the
32:36entire body. And he also ensured that
32:40you know if you were trying to navigate
32:41with a keyboard you just wouldn't be
32:43able to because he just put prevent
32:44default for all like key presses.
32:48And with this and a lot more he was
32:51still able to get 100% accessibility
32:53score on Lighthouse. And this wasn't you
32:56know a disparagement of Lighthouse in
32:58particular. Um a lot of similar tools
33:01would pass something like this. But this
33:04is why empathy is so important because
33:07if we treat accessibility just as a
33:09checklist, it's very easy to have
33:11something very inaccessible, but you
33:14still are able to, you know, mark it up
33:16and say, "Okay, I've got 100%."
33:20So the only way to approach this is to
33:22really test as much as possible in many
33:25environments as possible with as many
33:26people as possible.
33:30The gold standard of course is to test
33:32with real users. So, this involves going
33:34out, finding people using your product,
33:36seeing how they use it, getting feedback
33:38on what works for them, what doesn't,
33:41witnessing the different ways people use
33:43your product. Um, but of course, if
33:46testing with real users is um not
33:49possible or not as accessible to you,
33:51the next best thing is of course to test
33:53yourself.
33:54And you can do this very simply. I mean
33:57you can for example try navigating your
34:00website or application only with your
34:02keyboard to see if you can find any
34:05issues with you know like trapped focus
34:07or inaccessible areas of the page. You
34:10can try a screen reader yourself. I
34:12believe um most computers it now comes
34:15in built in for free anyways. And for me
34:18personally, doing this for the first
34:20time really did change my perspective on
34:22how I structure my web pages because I
34:24realized how important it was to have
34:27the right structure of okay, this is my
34:29H1, this is the H2 for this, everything
34:31is like sequential so that it's much
34:34easier to be able to navigate the page
34:36having it being structured that way.
34:39And uh nowadays it's also very easy to
34:41simulate different network environments.
34:43You can do it straight from your
34:44browser.
34:47And testing yourself is great and should
34:49definitely always be done.
34:51[clears throat]
34:52But to help automate the process, we can
34:55also make use of different tools.
34:58Um, we know that there's a vast array of
35:00tools are our disposal.
35:08Um, of course, AX Dev Tools by Deck,
35:11highly trusted and widely used.
35:13Lighthouse, Wave, there's so many
35:16different ones you can use. So,
35:17honestly, it's basically just up to what
35:19works for you and your team.
35:22Um, but again, just a reminder that to
35:24take all these tools with a grain of
35:26salt because as we've seen, they
35:28[snorts] do have their limitations
35:31and they shouldn't be used in isolation
35:32of, you know, testing yourself.
35:35or having real other users to test with.
35:40And uh finally, you want to create a
35:42culture in the organization where
35:44accessibility is is
35:47a part of everyone's job. So, you know,
35:49from project management to design,
35:51engineering, QA, everything.
35:53Accessibility really needs to be a part
35:56of the product journey from start to
35:57finish because accessibility only
36:00becomes difficult when it's an
36:02afterthought and it's done last.
36:06So these are what I call you know the
36:07five pillars of digital accessibility.
36:10They're just broad ways of thinking and
36:12practicing that I think can be applied
36:15um as we develop basically any
36:16technology. It's not limited to web
36:19development. And like I said, I think
36:21the most important way to go about this
36:23is to integrate it into your development
36:25or your product development as early as
36:28possible cuz again accessibility only
36:31becomes difficult when it's done, you
36:33know, at the very end and it something
36:35that you have to go back and rework
36:38everything that you've done before.
36:41So that is it. Thank you.
36:45Eray, that was wonderful. Uh amazing
36:49topic. I This is something that I'm uh
36:51also really passionate about and um
36:55there there are so many questions in the
36:57chat and uh Q&A. So we're we're going to
37:01kind of roll through a few of these. Um
37:02first of all, love the cake analogy. Um
37:06I think we have uh a number of folks who
37:08who love that. My thought on that is
37:10less is more, right? And when you have
37:14too much icing, it actually makes the
37:16cake hard to eat, right? So CSS, too
37:20much JavaScript, it just at some point
37:22becomes detractive from the main event.
37:25I love how you put that analogy.
37:27>> Thank you. Thank you.
37:29>> Yeah. So um let's uh let let's go
37:33through some of these Q&A questions. We
37:35we have one um uh uh do you think we'll
37:39soon see Africade uh digital products uh
37:43adapted on a global scale? uh
37:46Africanmade digital products on a global
37:48scale.
37:50>> Yes, 100%. I think I mean I see it
37:53happening all the time. Um I myself was
37:57involved in a startup that was you know
37:59Africa first but a global product and
38:02I've seen so many other similar products
38:04also be successful and I think you know
38:07as we um progress and of course Africa
38:11is a very young um continent so we have
38:15a lot of innovation and we have a lot of
38:18um people trying to solve all the
38:21problems. So I think we will be able to
38:24see a lot more products that are built
38:25from Africa um and are able to you know
38:29be adapted globally.
38:31>> Yeah, absolutely. I um I think that's a
38:35great question and that's that really
38:37speaks to the the you know I guess the
38:41wonder of the internet, right? Anybody
38:43from anywhere can create and distribute
38:46content and and uh yeah definitely a
38:49very cool thing. Um so one of our next
38:53questions here uh what's your recommend
38:56recommendation for working with CMS?
38:58Normally CMS uh has its own way to load
39:01resources and we don't really have a way
39:03to control it.
39:06Hm. Yeah, this is a very important um
39:09topic and it actually calls back to an
39:12interview I did a few years ago actually
39:16where I was kind of asked like what I
39:17think is the highest impact way to
39:21improve accessibility
39:25and um I've always been of the opinion
39:28that I think it's the frameworks and you
39:30know the CMS
39:32they're the ones that need to really um
39:36they're the ones that I think have the
39:38highest impact. So if we're able to make
39:41sure that you know all the CMSs and all
39:43the popular CMSs, all the popular
39:45frameworks are at a baseline level of
39:48accessibility then that is so much more
39:50impactful than trying to convince every
39:52individual developer to build with
39:55accessibility in mind.
39:57So I think if you are using a CMS um I
40:01always say you know try to do a bit of
40:04research when you're picking to say okay
40:06is this is this setting me up for
40:08success is this like the right defaults
40:10so that I as like an individual
40:12developer don't necessarily need to go
40:15and try to fix things or go and it's
40:17like making the job easier for yourself
40:19right so I always think that you know we
40:22need to really um encourage the
40:24different frameworks and you know CMS
40:26providers to ensure that they're
40:28providing a good default in the same way
40:30that the browser provides a good
40:32default. Um I think if there's a tool
40:34that so many people are using, we need
40:36to ensure that this tool is accessible.
40:39Otherwise,
40:40it's so much more difficult to convince
40:42every individual developer using that
40:44tool to then go and fix the whatever
40:46issues that it might have.
40:49>> Yes. Fantastic. All right, we got
40:52another one from Christina. Um, what are
40:55your thoughts on the Chrome extension
40:57reader mode? Would that help with data
41:00or what other factors uh are there to be
41:03considered?
41:06Um my um I personally don't don't like
41:11to use readable that much, but I think
41:14it's been a um a good way for
41:18for um users who want to try and access
41:22a sites that isn't very accessible to be
41:24able to still have access to whatever
41:27content. So I think it is a generally
41:30good tool. Um, but I don't think that
41:33should be, you know, an out for the
41:35developer to say, "Oh, well, you can
41:37access it via red mode, so I don't then
41:39need to make the content truly
41:41accessible."
41:45>> All right, one one last question here.
41:48Uh, how would you approach advocating
41:50for quality video captions from a
41:53robustness point of view? Uh, it seems
41:56people are hoping that users will use
41:59Google's live transcription instead of
42:01adding quality caption files to their
42:04videos.
42:07>> Yeah, this is this is another um I guess
42:10a difficult one because there's so many
42:13people who just, you know, upload a
42:14video. I've done this myself as well
42:16without necessarily um uploading my own
42:20captions.
42:21But I think I'll fall back to, you know,
42:23my previous answer. Maybe that's
42:25cheating a bit, but
42:27>> um I think that um the tools that we're
42:30using, so for example, I make videos on
42:32Tik Tok at times and it has pretty good
42:34captions and they've done it in a way
42:36that it is easy to use. And so it's a
42:40way for people who may not even really
42:42be thinking about, you know, trying to
42:44make a more accessible video, but
42:45because it's so easy to use. Um, it's
42:49something that, you know, people can
42:50just very easily enable and it makes the
42:53video better for not only people who
42:55need it, but also people myself who
42:57maybe I just don't want to have, you
42:59know, the audio allowed there. So, I
43:02think I'll fall back and say that I
43:04think the tools should improve to the
43:06point that people don't necessarily all
43:08need to individually upload their own um
43:11captions. But if you are putting
43:14something out there that is, you know,
43:16important. I would also say this is
43:19something that, you know, falls on the
43:20creator to consider and look at, okay,
43:25is if I'm not using something like Tik
43:27Tok that's going to already provide
43:28captions, what other tool could I use to
43:31um make this a part of the video?
43:34>> Yeah, that's fantastic.
43:39All right. Well, uh I think that's all
43:41of our Q&A questions. Um uh really want
43:46to welcome uh uh thank everybody for
43:49joining this session and uh specifically
43:53thank you so much for this amazing
43:55content and uh uh great presentation
43:59really uh thought thoughtprovoking
44:01um uh so also thank you so much to our
44:05interpreters uh y'all are amazing we
44:07really appreciate it
44:10so
44:10>> thank you so much for having me Yeah.
44:13Yeah. Well, we uh uh we'd love to to
44:18continue having more sessions with you.
44:20So, uh next year, everybody uh hopefully
44:23expect a back. Uh we'll we'll uh
44:26hopefully see you next year. But
44:28>> yes.
44:30>> Yeah. Uh all right. Well, I guess that
44:32concludes this session. Thank you so
44:34much again. Uh I hope everybody enjoys
44:37Axecon.

About this transcript

This page contains the full transcript of Building for a new next billion users I Axe-con 2026 by Deque Systems, generated from the public captions YouTube serves with the video. The transcript has 6,810 words across 1,033 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.