O custo da acessibilidade em IA — Jemima Abu, CAIS

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The Cost of Accessibility in AI — Jemima Abu, CAIS · Canal: AI Engineer · 09:44 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de prompts e contexto, Engenharia de software com IA

Resumo

Jemima Abu defende que criar produtos acessíveis desde o início pode economizar tempo e dinheiro, inclusive quando o código é produzido por AI agents. Em um experimento pontual, usar uma skill de acessibilidade reduziu em 58% o custo e levou um terço do tempo para concluir a tarefa, embora a palestrante ressalte que isso não comprova uma regra geral. Sem orientações, agents podem reproduzir vieses de bases de código inacessíveis e escrever código desnecessariamente complexo. A palestra apresenta medidas práticas, como definir requisitos, auditar o código existente, usar componentes reutilizáveis e incluir verificações de acessibilidade no workflow.

Pontos-chave

Produtos inacessíveis excluem pessoas e, por isso, deixam de cumprir sua função para parte do público.
No experimento apresentado, a skill de acessibilidade reduziu em 58% o custo e o tempo de execução caiu para um terço.
O experimento foi pontual e não ocorreu em um ambiente controlado; portanto, não serve como prova empírica de uma regra geral.
Agents podem absorver vieses de acessibilidade presentes na base de código e perpetuá-los em novas implementações.
Orientações de acessibilidade podem evitar código verboso e a recriação de funcionalidades já oferecidas por elementos semânticos nativos.
A acessibilidade deve ser considerada desde a ideia e o design até o desenvolvimento e o QA, não adicionada apenas ao final.
Produtos inacessíveis podem afastar clientes, aumentar o retrabalho e gerar consequências legais.
Para orientar agents, é recomendável definir requisitos, auditar e corrigir a base existente, usar componentes reutilizáveis e exigir uma skill de acessibilidade.
O código deve priorizar HTML semântico, usar ARIA apenas quando necessário e permitir que elementos interativos sejam operados pelo teclado.
Skills e ferramentas automatizadas ajudam, mas não substituem testes manuais para avaliar a acessibilidade de um produto.

Capítulos

Início	Capítulo	Resumo
00:00	Acessibilidade também reduz custos	A palestrante define acessibilidade e relata um experimento em que uma skill dedicada reduziu o custo e o tempo de implementação.
02:02	Orientar agents para evitar vieses	A comparação com crianças em uma tarefa mostra como instruções e skills podem ajudar agents a chegar ao resultado pretendido.
03:35	Os custos de desenvolver sem acessibilidade	A falta de orientação pode reproduzir vieses, gerar código verboso e tornar mais trabalhosos os testes e as correções posteriores.
06:07	Consequências para usuários e negócios	Produtos inacessíveis podem excluir clientes, aumentar o retrabalho e expor empresas a consequências legais.
07:08	Como orientar agents a criar produtos acessíveis	A palestra recomenda definir requisitos, auditar o código, reutilizar componentes e verificar práticas como HTML semântico, suporte a teclado e testes manuais.

Citações

Acessibilidade é a qualidade de poder ser usado por qualquer pessoa, independentemente de deficiência. — 00:00

Houve uma redução de 58% no custo ao usar essa skill. — 01:31

Para ser um site acessível, é preciso colocar a acessibilidade em primeiro plano em cada etapa do desenvolvimento. — 05:06

Se você cria um produto que as pessoas não conseguem usar, elas não vão usá-lo. — 06:38

Se um elemento interativo pode ser operado com o mouse, também deve poder ser operado com o teclado. — 09:12

Conceitos e entidades

Jemima Abu (pessoa): Palestrante que apresenta argumentos e práticas para criar produtos digitais acessíveis com apoio de AI agents.
AI Engineer (empresa): Canal do YouTube que publicou a palestra.
CAIS (empresa): Organização mencionada no título original da palestra.
Modern Web Guidance (ferramenta): Skill do Chrome citada como orientação para agents usarem recursos atuais de HTML e CSS em vez de implementações personalizadas em JavaScript.
WebAIM (empresa): Organização associada ao estudo citado sobre problemas de acessibilidade em páginas iniciais de sites.
Americans with Disabilities Act (conceito): Lei dos Estados Unidos citada pela palestrante ao falar de possíveis consequências legais de produtos inacessíveis.
HTML semântico (conceito): Uso de elementos HTML com significado e comportamento nativos para expressar a estrutura e as funções de uma página.
ARIA (conceito): Recursos citados para comunicar informações de acessibilidade quando o HTML semântico não consegue expressar o comportamento necessário.

Tradução completa (pt-BR)

00:00 Olá, pessoal. Meu nome é Rima, e vou falar com vocês sobre o custo da acessibilidade em IA ou, como gosto de chamar, parem de desperdiçar tokens criando produtos que as pessoas não conseguem usar. Porque, no fim das contas, o que é acessibilidade? Acessibilidade é a qualidade de poder ser usada por qualquer pessoa, independentemente de deficiência. Isso significa que, quando você cria um produto inacessível, esse produto é inerentemente inútil, porque as pessoas não conseguem usá-lo. Acho que esta é uma palestra muito pertinente, especialmente nestes dias de vibe coding, engenharia de prompt e IA basicamente escrevendo todo o código para nós. Precisamos garantir que

00:30 mesmo com todo o código sendo escrito por IA, continuemos criando para seres humanos e garantindo que eles consigam usar os produtos que estamos criando. É muito bom fazer vibe coding de cinco aplicativos diferentes em um dia, mas, se as pessoas não conseguem usar esses aplicativos, será que há algum sentido nisso? Um estudo da WebAIM mostra que 96% das páginas iniciais dos 1 milhão de sites mais acessados do mundo têm algum tipo de problema de acessibilidade. Eu sou alguém que fala bastante sobre acessibilidade e, sempre que pergunto por que as pessoas não criam sites acessíveis, geralmente ouço que isso leva tempo demais. Embora eu concorde que

01:00 acessibilidade seja um processo que exige muito trabalho e tempo, acho que, agora que chegamos ao ponto em que a IA escreve a maior parte do nosso código, ficou até mais fácil tornar as coisas acessíveis. Se for para dizer alguma coisa, eu diria que criar sites inacessíveis custa mais tempo e dinheiro. Então, decidi fazer um pequeno experimento usando a base de código do trabalho. Dei este prompt aos agents. É um prompt simples, sem diretrizes: “implemente este design do Figma”. E eles executaram a tarefa duas vezes. Na primeira, sem nenhuma skill de acessibilidade; na segunda, usando a skill que eu havia escrito. E o que percebi foi que não só o agent foi mais rápido ao criar a versão acessível

01:31 usando a skill, como também houve uma redução de 58% no custo ao usá-la. E podemos olhar os dados aqui. Vemos que, além de ter custado menos, levou um terço do tempo para concluir o prompt usando a skill de acessibilidade. Então, para concluir, não podemos afirmar que seja realmente mais barato para agents de IA criarem sites acessíveis. Não podemos afirmar isso, mas não vamos afirmar, porque este foi um experimento isolado e não foi realizado em um ambiente controlado; portanto, não pode servir como dado empírico que comprove o de. Mas, quando analisamos os motivos pelos quais o agent de IA levou muito mais tempo para executar os prompts sem nenhuma skill de acessibilidade, podemos ter uma

02:02 ideia melhor do motivo exato pelo qual é mais rápido criar sites acessíveis. Mas, antes de entrarmos nisso, olá, meu nome é Joreima Abu. Sou engenheira de produto na Case, uma plataforma de investimentos alternativos. Também sou Google Dev Expert, Microsoft MVP e profissional certificada em competências essenciais de acessibilidade. Basicamente, gosto de falar sobre como tornar a web mais acessível. Também vou fazer uma pequena ressalva. Embora muitos dos meus exemplos de acessibilidade sejam relacionados à web, porque essa é minha área de especialidade, isso também pode se aplicar a qualquer plataforma em que você esteja trabalhando, seja mobile, hardware ou qualquer outra coisa. Então, vamos

02:33 voltar ao assunto. Este é o seu agent de IA. Ele é uma ferramenta superinteligente, capaz de fazer quase qualquer coisa no mundo, mas, ao mesmo tempo, tem apenas 3 anos de idade. E, assim como um bebê, a IA é muito influenciável. Se você disser vezes suficientes que o céu é vermelho, eventualmente ela vai começar a aceitar que o céu é vermelho. Isso significa que nós, desenvolvedores responsáveis encarregados dessa tarefa, precisamos garantir que estamos fornecendo as skills e orientações certas para que os agents de IA criem o produto que queremos. Há um programa japonês na Netflix de que gosto, chamado Old Enough. Basicamente, crianças pequenas são enviadas para fazer sua primeira tarefa sozinhas. Pode ser uma criança de 3 anos

03:04 sendo enviada ao supermercado para comprar mantimentos. E uma coisa de que gosto no programa é que sempre dá para ver as etapas que os pais prepararam antes de enviar a criança para essa primeira tarefa. Pode ser que a criança já tenha ido várias vezes ao supermercado com os pais, ou que eles forneçam uma lista bem detalhada, que mostra onde fica o supermercado, o que ela precisa comprar, quais caminhos deve evitar, e isso basicamente facilita muito a realização da tarefa pela criança. Com um agent, acontece a mesma coisa. Quando você dá uma instrução a um agent, como “crie esta página” ou “implemente este design”, se eu fornecer as skills e os prompts certos, fica muito

03:35 mais fácil para esse agent evitar seguir pelo caminho errado e para o produto final ficar parecido com o que eu pretendia. Então, vamos ver o que acontece quando não fornecemos nenhum tipo de orientação aos nossos agents para desenvolver produtos. Primeiro, o preconceito humano se torna preconceito da IA. Há anos, as pessoas desenvolvem sites ou produtos inacessíveis porque, francamente, simplesmente não pensamos dessa forma. Especialmente como desenvolvedores, tendemos a ter a mentalidade de que “funciona para mim”. Então, penso: “isso funciona no meu laptop, funciona do jeito que eu queria e não vou verificar mais nada”. Não me preocupo se funciona com leitores de tela ou em ambientes com pouca luz.

04:05 Estou apenas pensando: “funciona, está pronto, terminei”. Sempre que você cria dessa forma, ou tem uma base de código que reflete esse tipo de mentalidade, quando coloca um agent de IA nessa base de código, ele vai absorver todos os seus preconceitos. Vai dizer: “Ah, não precisamos tornar essas coisas acessíveis, porque isso não foi mencionado antes. Então, vou simplesmente criar as coisas de qualquer jeito”. E, quanto mais você usa esse agent de IA para gerar código, mais cria uma base de código inerentemente inacessível, porque a acessibilidade nunca foi uma exigência desde o começo. Em segundo lugar, e isso foi algo que realmente percebi no experimento, a IA tende a recorrer a muito

04:35 código verboso. Se você não fornecer um prompt específico nem diretrizes ao seu agent, ele vai reinventar a roda quantas vezes quiser. Então, mesmo que você diga apenas “crie um componente de acordeão simples” ou “crie um componente de janela modal”, ele não vai se dar ao trabalho de verificar se já existe um elemento semântico que possa oferecer a mesma funcionalidade. Simplesmente vai criar um do zero. A IA adora escrever código. Então, vai escrever tudo o que quiser. E, como você pode ver aqui, se estiver tentando recriar um elemento semântico, isso exige muito mais tempo e esforço porque, primeiro, você precisa fazer muito mais testes,

05:06 precisa implementar muito mais recursos para reproduzir a funcionalidade nativa, e o processo é simplesmente muito trabalhoso. Então, estas são algumas das coisas em que você deve se concentrar ao fornecer prompts ao seu agent. Uma vez ouvi uma comparação que dizia que um site acessível é como um muffin de mirtilo. Se alguém lhe entrega um muffin simples no qual colocou um monte de mirtilos por cima, como na imagem à direita, isso não é um muffin de mirtilo. Para ser um muffin de mirtilo de verdade, como o da esquerda, os mirtilos precisam ter sido incorporados desde o começo. Com um site acessível, é a mesma coisa. Se você tem um site totalmente pronto e, só depois de concluído, começa a enfiar rótulos ARIA

05:37 lugares diferentes, isso não é um site acessível. Para que seja um site acessível, é preciso colocar a acessibilidade em primeiro plano em todas as etapas do processo de desenvolvimento. E isso não se aplica apenas a desenvolvedores: a acessibilidade é responsabilidade de todos. Então, é preciso garantir que, desde a ideia de negócio até o design e o QA, estejamos considerando a acessibilidade e testando se este produto pode ser usado por todos exatamente da mesma maneira. O problema de esperar até o fim para considerar a acessibilidade é que se perde muito tempo com testes de regressão. Então, se você esperar até que seu site esteja totalmente pronto para começar a testar e voltar para

06:07 corrigir problemas, acaba refatorando e reescrevendo muito mais código do que teria sido necessário se tivesse desenvolvido o site para ser acessível desde o início. E, claro, há consequências para os negócios quando se criam produtos inacessíveis. Às vezes, ouço uma empresa dizer: “Ah, mas não precisamos considerar a acessibilidade porque nenhum dos nossos usuários depende de tecnologias assistivas.” E acho isso muito engraçado, porque é uma espécie de profecia autorrealizável. Não é que seus usuários não dependam de tecnologias assistivas; é que pessoas que usam tecnologias assistivas não conseguem acessar seu site, então simplesmente nunca o visitam. Imagine uma empresa sem porta. Você nunca teria

06:38 clientes. Como eles entrariam no prédio? É a mesma coisa quando se cria um produto inacessível. Se você cria um produto que as pessoas não conseguem usar, elas não vão usá-lo. E, por fim, há consequências jurídicas por não tornar seu site acessível. Nos Estados Unidos, a Americans with Disabilities Act determina que todos os produtos voltados ao público devem ser acessíveis e poder ser usados por pessoas com deficiência, ou você pode estar sujeito a multas e até processos judiciais. Mas, pelo lado positivo, você pode usar este adesivo muito fofo no Microsoft Teams. Então, sabe, avalie suas opções. Com base em tudo isso, podemos ver que, na verdade, é muito mais caro criar produtos que não são acessíveis. Você

07:08 se expõe ao risco de perder dinheiro com clientes e a possíveis processos judiciais, nos quais pode ter que pagar multas, além de gastar mais tempo escrevendo código e refatorando coisas. Então, se você criar seu produto para ser acessível desde o início, tudo será muito mais rápido e barato. Agora que sabemos disso, como podemos garantir que nossos agentes de IA criem coisas acessíveis? Como a base de código de cada pessoa é diferente e podemos trabalhar com tecnologias distintas, vou apresentar uma visão geral de como fazer seus agentes de IA produzirem código acessível. Primeiro, é preciso definir os requisitos de acessibilidade.

07:38 Os requisitos de acessibilidade variam de acordo com a plataforma em que você está trabalhando. Portanto, é preciso pesquisar e garantir que você saiba quais requisitos de acessibilidade deve cumprir para a plataforma para a qual está desenvolvendo. Depois disso, é preciso auditar sua base de código existente. Se você vai introduzir um agente de IA na sua base de código, precisa garantir que não haja problemas preexistentes que o agente de IA possa copiar por achar que representam o melhor comportamento. Você pode usar ferramentas automatizadas para realizar testes de acessibilidade ou até pedir ao seu agente de IA que faça isso. Mas é importante identificar todos os problemas existentes e corrigi-los antes de começar a desenvolver novos

08:10 recursos. Depois, você deve implementar algum tipo de sistema reutilizável. Isso é algo muito bom de se ter, mas, basicamente, se você vai trabalhar com acessibilidade, é muito mais fácil corrigir coisas em um componente usado em vários lugares do que fazer correções nos mesmos componentes em arquivos diferentes. Portanto, ter um sistema de design implementado ou qualquer tipo de biblioteca de componentes reutilizáveis vai economizar muito mais tempo no longo prazo ao tornar as coisas acessíveis. E, por fim, você deve exigir o uso de um skill de acessibilidade. É um skill que seus agentes de IA vão usar sempre que você estiver fazendo algo

08:41 relacionado, por exemplo, à geração de interfaces ou à escrita de código que exija acessibilidade. Um skill que gosto muito de usar é o Modern Web Guidance, do Chrome. Basicamente, ele garante que seu agente use os recursos mais recentes de HTML e CSS, em vez de implementações personalizadas em JavaScript. Você também pode ter uma versão mais simples de um skill de acessibilidade. Acho isso muito importante, especialmente se você estiver fazendo vibe coding ou não estiver trabalhando em uma base de código grande. Você só precisa de algo rápido, ao qual seu agente possa recorrer, sem fazer muita pesquisa aprofundada. É o que eu recomendaria para atender aos requisitos mínimos de acessibilidade. Então, é preciso garantir que você use HTML semântico sempre que possível e recorra ao ARIA apenas quando

09:12 o HTML semântico não conseguir expressar o comportamento. Todo elemento interativo que puder ser operado com o mouse também deve poder ser operado com o teclado. Também é preciso garantir que os elementos estejam devidamente identificados e possam ser lidos por leitores de tela. E, por fim, antes de executar o código, seu agente deve fazer uma auditoria com base em todas essas etapas. É claro que isso não basta para criar um site totalmente acessível. Você ainda precisa fazer muitos testes manuais, porque não é possível que uma única ferramenta torne um site totalmente acessível. Mas ter esses skills implementados já pode ajudar muito mais do que não tê-los. Independentemente do motivo pelo qual você usa IA, na maioria das vezes o objetivo é resolver um

09:44 problema específico. Então, certifique-se de que sua solução seja útil para o maior número possível de pessoas. Portanto, crie coisas acessíveis. E é isso. Muito obrigada por ouvirem minha palestra. Espero que tenham gostado. Se tiverem alguma pergunta, podem entrar em contato comigo online pelo nome Jemima Abu. Estou no LinkedIn, no Twitter e no GitHub. Adoraria falar com vocês. Certo, tchau.

Transcrição original

[00:00] Hi all, my name is Rima, and I’m going to be talking to you about the cost of accessibility in AI, or as I like to call it, stop wasting tokens on building products that people can’t use. Because at the end of the day, what is accessibility? Accessibility is the quality of being able to be used by anyone regardless of disability. So, what this means is that when you build a product that is inaccessible, that product is inherently useless because people cannot use it. I think this is a very prevalent talk, especially in these days of vibe coding and prompt engineering and AI basically writing all the code for us. We need to ensure that

[00:30] even with all the code being written by AI, we’re still building for humans, and we’re ensuring that humans are able to use the products that we are building. It’s all very well and good to vibe good five different apps in one day, but if people can’t use those apps, then is there really any point? A study by WebAIM shows that 96% of the homepages of the top 1 million websites in the world have some form of accessibility issue or another. Now, I’m someone that goes around a lot and speaks about accessibility, and whenever I ask why don’t people build websites to be accessible, I usually hear it takes too long. While I will agree that

[01:00] accessibility is a labor and time-intensive process, I do think that now that we’re at the stage of AI writing most of our code, it’s actually easier to make things accessible. If anything, I would say it costs more time and more money to build inaccessible websites. So, I decided to carry out a little experiment using the code base at work. So, I gave this prompt to the agents. It’s just a simple prompt with no guidelines, implement this design from Figma. And they ran it twice. The first time without any accessibility skill, and the second time by using the skill that I had written. And what I noticed was that not only was it faster for the agent to build the accessible

[01:31] skill, but there was also a 58% reduction in cost when using that skill. And we can take a look at the data here. We see that not only was it cheaper, but it also took a third of the time to finish the prompt while using the accessibility skill. So, in conclusion, we can’t say that it is actually cheaper for AI agents to build accessible websites. We can’t say that, but we won’t say that because this was a one-off experiment, and it was not carried out in a constrained environment, so it cannot serve as empirical data that proves the of But, when we look into the reasons why it took the AI agent much longer to carry out the prompts without any accessibility skills, then we can have a

[02:02] better idea of why exactly it is faster to build accessible websites. But, before we get into that, hi, my name is Joreima Abu. I am a product engineer at Case and an alternative investment platform. I’m also a Google Dev Expert, a Microsoft MVP, and a certified professional in accessibility core competencies. Basically, I like to go around talking about how to make the web a more accessible place. Also, I will give a slight disclaimer. While a lot of my examples relating to accessibility will be web-based because that is my area of expertise, this can also apply regardless of whatever platform you’re working on, whether that’s mobile or hardware or anything at all. So, let’s

[02:33] get back to it. This is your AI agent. Now, it’s a super intelligent tool that can do almost anything in the world, but at the same time, it’s just 3 years old. And much like a baby, AI is very impressionable. If you tell it enough times that the sky is red, eventually it will start to accept that the sky is red. What this means is as the responsible developers in charge, we have to make sure that we’re providing the right skills and guidance for AI agents to build the product that we want them to build. There’s a Japanese show on Netflix that I love called Old Enough. It’s basically about toddlers being sent on their first errand. It can be like a 3-year-old

[03:04] being sent to a supermarket to purchase groceries. And one thing I like about the show is that you can always see the steps that the parents have put in place before they send them on that first errand. So, it could be that the child has gone with their parents to the supermarket multiple times, or they provide a list that’s very clearly detailed that shows them where the supermarket is, what they need to get there, what paths to avoid, and it basically makes it a lot easier for the child to carry out that errand. It’s the same thing with an agent. When you’re given an instruction to an agent, if I’m saying build this webpage or implement this design, if I provide the right skills and prompts, it makes it a lot

[03:35] easier for that agent to avoid going down the wrong path and for the finished product to look like what I intended it to look like. So, let’s take a look at what happens when we don’t provide any form of guidance for our agents in developing products. Firstly, human bias becomes AI bias. For years, humans have been developing websites or products that are inaccessible because frankly we just don’t think that way. Especially as developers, we tend to have a it works for me mindset. So I’m like this thing works on my laptop and it works the way I intended it to work and I’m not going to check anything else. I don’t concern myself with if it works for screen readers or if it works in low light

[04:05] environments. I’m just like it works, it’s built, I’m done. Whenever you build like that or if you have a code base that reflects that kind of mentality, once you put an AI agent in that code base, it’s going to absorb all your biases. It’s going to say, “Oh, we don’t need to make these things accessible because that has not that been mentioned in the past. So I’m just going to build things anyhow.” And then the more you use that AI agent to generate codes, the more you build a code base that is inherently inaccessible because accessibility was never constraint in the first place. Secondly, and this is something that I really noticed in the experiment, AI tends to default to a lot

[04:35] of verbose code. If you don’t provide any particular prompt or guidelines for your agent, it will reinvent the wheel as many times as it wants to. So even if you tell it just build a simple accordion component or build a modal component, it’s not going to bother checking is there already an existing semantic elements that can give me the same functionality? It’s just going to build one from scratch. AI loves to write code. So it’ll go off and write as many things as it wants. And as you can see here, if you are trying to recreate a semantic element, it takes a lot more time and effort because number one, you have to carry out a lot more testing,

[05:06] you have to implement a lot more features to replicate the native functionality, and it’s just a very cumbersome process. So these are some of the things that you want to ensure you’re focusing on when you’re providing prompts to your agent. I saw an analogy once that said an accessible website is like a blueberry muffin. If someone hands you a plain muffin that they’ve shoved a bunch of blueberries on, similar to the picture on the right, that’s not a blueberry muffin. For it to be a proper blueberry muffin like the one on the left, then the blueberries need to have been baked in from the start. It’s the same thing with an accessible website. If you have a fully built website and then once it’s done, you start shoving in area labels in

[05:37] different places, that is not an accessible website. For it to be an accessible website, you need to put accessibility at the forefront at every build process. And this does not just apply to developers, accessibility is the responsibility of everyone. So, you want to make sure that even from the business idea to design to QA, that we’re ensuring that we’re looking for accessibility and testing that can this product be used by everyone in the exact same way. And that issue with waiting till the end to consider accessibility is that you waste a lot of time on regressive testing. So, if you’ve waited until your website is fully built and then you start testing and going back to

[06:07] fix issues, you end up refactoring and rewriting a lot more code than you’d have had to do if you don’t build it to be accessible from the start. And then of course, there are business consequences to building inaccessible products. The thing I hear sometimes is that a business might say, “Oh, but we don’t have to consider accessibility because none of our users rely on assistive technologies.” And I think that’s very funny because it’s sort of a self-fulfilling prophecy. It’s not that your users don’t rely on assistive technologies, it’s that people with assistive technologies cannot use your website in the first place, so they just never go to it. Imagine a business that didn’t have a door. You would never get

[06:38] any customers. How would they get in the building? It’s the same thing with building an inaccessible product. If you build a product that people cannot use, then people will not use it. And then finally, there are legal repercussions to not making your website accessible. In the United States, the Americans with Disabilities Act states that any public-facing products must be accessible and can be used by people with disabilities, or you could face fines and even lawsuits. But on the plus side, you could get to use this really cute sticker on Microsoft Teams, so you know, weigh your options. Based on all this, we can see that it actually is a lot more expensive to be building products that aren’t accessible. You’re

[07:08] exposing yourself to losing money from customers, possible lawsuits where you have to pay fines, you’re spending more time building code and refactoring things. So, if you do build your product to be accessible from the start, it’s going to be a lot faster and a lot cheaper. So, now that we know all that, how can we actually ensure that our AI agents are building things to be accessible? Because everyone’s code base is different and we can be working with different technologies, I’m just going to give an overarching general view of how to get your AI agents to produce accessible code. So firstly, you need to define your accessibility requirements.

[07:38] Accessibility requirements differ based on what platform you’re working on. So, you do need to carry out research and ensure that you know what accessibility requirements you’re supposed to be meeting for the platform you are building for. Once that’s done, you need to audit your existing code base. So, if you’re going to introduce an AI agent into your code base, you need to ensure that you don’t have any pre-existing issues that the AI agent might copy as what it thinks is best behavior. So, you can use automated tools to carry out accessibility testing, or you can even tell your AI agent to do it. But, you want to identify any existing issues and then fix them before you start writing new

[08:10] features. Then, you want to implement some sort of reusable system. This is a very nice to have, but basically, if you’re going to work with accessibility, it’s a lot easier to fix things in one component that is used in multiple places as opposed to making fixes to the same components across different files. So, just having an implemented design system or any form of reusable component library is going to save you a lot more time in the long run when making things accessible. And then finally, you want to enforce a mandatory accessibility skill. This is a skill that your AI agents will basically use anytime you’re running anything

[08:41] related to maybe generating UI or writing code that requires accessibility. One skill that I really like to use is the Modern Web Guidance skill from Chrome. It’s basically a skill that ensures that your agent is using the newest HTML and CSS features as opposed to custom JavaScript implementations. You can also have a lightweight version of an accessibility skill. I think this is very important, especially if you’re like vibe coding or you’re not working in a big code base. You just want something quick that your agent can refer to and not carry out a lot of in-depth research. This is what I would recommend for meeting like bare minimum accessibility requirements. So, you want to make sure that you’re using semantic HTML wherever possible, only reaching for ARIA when

[09:12] semantic HTML can’t express the behavior. Every interactive element, if it can be operated by a mouse, it should also be operated by a keyboard. You also make sure that elements are properly labeled and can be read by screen readers. And then finally, before running the code, your agent should carry out an audit against all those steps. Of course, this is not enough to build a fully accessible website. You still need to carry out a lot of manual testing yourself because it’s not possible for a one tool to make a website fully accessible. But, just having these skills in place can help a lot more than not having them there at all. Regardless of why you use AI, most times the goal is to solve a particular

[09:44] problem. So, just make sure that your solution is useful to as many people as possible. So, build things to be accessible. And that is all. Thank you so much for listening to my talk. I hope you enjoyed it. If you do have any questions, feel free to reach out to me online at Jemima Abu. That’s LinkedIn, Twitter, or GitHub. I would love to hear from you. Okay, bye.