Design Systems e Acessibilidade: Retrospectiva de 2024

Quais foram as discussões e sugestões propostas pela comunidade internacional (falante do inglês) em 2024?

Muitos designers e desenvolvedores se importam com a acessibilidade em produtos digitais, como apontou a Forrester na análise do Config 2024. O desejo existe, mas nem sempre é possível implementar acessibilidade na prática cotidiana de forma sistemática e escalável. Por quê? Nos falta tempo, estudo e sobra muito conteúdo para consumir.

Em 2024, mais de 40 materiais sobre Acessibilidade em Design Systems foram publicados em inglês, somando mais de 12 horas de vídeos e podcasts. Esse volume não é por acaso: criar interfaces acessíveis e escaláveis é um desafio que já ultrapassa o debate convencional sobre acessibilidade digital. Estão sendo feitas perguntas profundas, como: O que significa, de fato, acessibilidade escalável em produtos digitais? O que é Shift Left e como se pode evoluir um DS acessível? É possível ter controle em uma equipe e documentar todos os testes de acessibilidade em um DS?

Quem consegue absorver tanto conteúdo sem se perder no caminho? A verdade é que, ao tentar acompanhar tanta informação, acabamos consumindo só uma fração, não conseguindo ter uma visão panorâmica dos principais debates. Foi pensando nisso que resolvi criar essa retrospectiva, analisando todos esses materiais para identificar os principais insights e debates que marcaram o último ano.

A ideia é simples: oferecer um panorama que ajude a entender o que está na pauta mais recente quando falamos de acessibilidade em Design Systems. Quais foram os avanços? Quais as questões ainda em aberto? Onde podemos nos aprofundar sobre tópicos específicos?

Este texto é um convite para essa conversa — menos sobre o que já sabemos e mais sobre o que ainda estamos descobrindo como comunidade. Sinta-se à vontade para entrar em contato comigo pelo meu LinkedIn para qualquer tipo de feedback.

­

Índice

1. Metodologia
2. Por que Design Systems para Acessibilidade?
3. O que é acessibilidade em Design Systems?
4. Como se evolui um Design System Acessível?
5. Como testar um Design System Acessível?
6. Como organizar os testes de acessibilidade?
7. Como documentar os testes?

­

1. Metodologia

Antes de entrar nas discussões em si, vamos olhar como foi realizada a metodologia desse estudo para compreender o que foi dito na comunidade internacional sobre Acessibilidade e Design Systems em 2024?

Se você não quiser ver isso agora, pule direto para a próxima seção para ver o resultado da pesquisa. Mas, se você tem interesse nessa parte, fique à vontade para ver o passo a passo e entender como foram gerados esses dados.

Toda a coleta de dados foi gerada por uma revisão sistemática de materiais didáticos publicados sobre dois assuntos interseccionados: “Design Systems” e “Acessibilidade”.

Antes de partir para a coleta de materiais, toda revisão sistemática delimita um objetivo. E o objetivo desta retrospectiva era entender quais foram os debates em torno dos desafios de construir produtos digitais acessíveis, particularmente com Design Systems. Esse é um assunto específico da área de UX Design e desenvolvimento que gera muito material todos os anos, permitindo que sejam feitas retrospectivas para entender que discussões particulares foram feitas durante um período grande como um ano.

Qualquer revisão retrospectiva precisa deixar transparente como realizou a sua coleta e análise de dados para não privilegiar certos documentos em detrimento de outros. Aqui, exponho os critérios básicos de inclusão e de exclusão dos materiais que foram coletados:

1. A produção tinha que ser obrigatoriamente publicada em 2024.
2. O conteúdo precisava estar em inglês, uma vez que o objetivo era fazer uma retrospectiva do cenário internacional mais abrangente possível.
3. O material deveria ter caráter educacional para recuperar esses desafios expostos à nossa comunidade. Aqui, entendo como materiais educacionais: artigos (informais e de caráter não acadêmico), podcasts ou vídeos que foram criados/disponibilizados por especialistas da área que abordam o tema. Por isso, esse artigo em si não faz uma revisão de outros tipos de materiais, como documentações sobre acessibilidade em Design Systems que foram publicadas em 2024. Se você quer entender melhor que tipo de documentação é essa, acesse o exemplo do Carbon Design System. Apesar de fundamentais como pontos de referências, essas documentações são muito específicas para criar diretrizes para uma organização, não fornecendo esse debate entre profissionais que é encontrado nessa esfera de publicações de caráter educacional.
4. Materiais livres de restrições de acesso. Por questões de direitos autorais, não foram analisados e nem expostos materiais educacionais pagos — como conteúdos de cursos ou artigos que não possuem livre acesso. Ainda, deixo evidente que esse tipo de material não foi encontrado com abundância nas buscas realizadas.

Com esses critérios, os termos usados na busca foram “Design System” e “Accessibility” (Design System e Acessibilidade na tradução ao português) nas principais ferramentas de busca semelhantes ao Google. Foi feita uma análise exploratória com outros termos, como “Design System” e “Blindness” (cegueira) ou “Design System” e “Neurodivergency” (neurodivergência), e não foram recuperados materiais suficientes para 2024 com esses termos de busca. Assim, entendi que não era necessário buscar por mais termos específicos além de acessibilidade para entender a discussão retrospectiva.

E, para finalizar, você pode ver com transparência todos os materiais coletados no final nas referências do artigo, sendo que os maiores destaques foram citados com links ao longo do texto. Alguns não foram mencionados explicitamente no artigo, mas eles foram coletados e analisados, corroborando para argumentos gerais encontrados em vários materiais simultaneamente.

Ficou claro como essa revisão toda foi feita com cuidado para não perdermos nada desse assunto? Então vamos à síntese do debate.

­

2. Por que Design Systems para Acessibilidade?

Antes de mergulharmos nos detalhes, vale a pena uma pausa para pensar: por que, afinal, Design Systems têm sido apontados como um caminho eficaz para melhorar a acessibilidade de produtos digitais? A resposta começa com três palavras: velocidade, consistência e precisão técnica.

Em um cenário onde interfaces digitais estão cada vez mais complexas, um Design System bem estruturado é como uma bússola que mantém a acessibilidade no rumo certo. Tyler Hawkins, software engineer da Webflow, resume bem essa ideia: cada componente precisa atender a uma série de critérios técnicos para ser acessível a diferentes públicos. Sem uma base sólida e centralizada, isso pode virar um caos, especialmente em empresas que gerenciam vários produtos simultaneamente.

Essa escalabilidade também é discutida para a criação de plataformas mais personalizáveis. Vários materiais argumentam que plataformas construídas com Design Tokens auxiliam na criação de temas específicos para certas comunidades com algum tipo de deficiência. Um exemplo disso se encontra no texto de Georgi Georgiev (designer da PROS na Bulgária) sobre a criação de modos de contraste elevado (High Contrast Modes) a partir de Design Systems — um tema escuro que se diferencia do Dark Mode comum por ser destinado a usuários com algum tipo de deficiência visual ou fotofobia (sensibilidade à luz).

Como esperado devido aos debates das últimas décadas, essa escalabilidade é amplamente defendida com a aplicação da Web Content Accessibility Guidelines (WCAG) como diretriz internacional. Isso porque a WCAG oferece requisitos baseados em pesquisa que devem ser atendidos por critérios objetivos e mensuráveis para avaliar o sucesso ou fracasso na criação de um produto digital acessível. Muitos profissionais ressaltaram o papel histórico da WCAG na criação de uma linguagem comum capaz de padronizar internacionalmente as exigências legais de acessibilidade digital — reflexo da transição da acessibilidade digital de recomendação para obrigação em muitos países nessa última década. Em 2024, diversos DSs governamentais avançaram em seus processos de conformidade com as diretrizes da WCAG, impulsionados por exigências legais nacionais — como o United States Web Design System (USWDS), dos Estados Unidos, e o NL Design System, do governo holandês.

Porém, um desafio para alcançar essa padronização é discutido por Amy Cole (Digital Accessibility Lead da USWDS): muitos designers e desenvolvedores temem a WCAG por ser uma linguagem bastante técnica. Esse receio aparece como um dos principais dificultadores, sendo quase hegemônico o discurso sobre a necessidade de materiais educacionais mais acessíveis ou grupos de estudo em acessibilidade para a promoção do assunto numa organização. Não é trivial que, com a WCAG, sempre sejam citadas ferramentas suplementares que auxiliam nesse desafio, como o IBM Equal Access Toolkit, o Microsoft’s Inclusive Design Toolkit, The A11y Project e o Deque Systems.

Por isso, ter um DS também auxilia no processo dessa conformação, uma vez que a equipe pode criar processos em cascata que saem de especialistas e chegam de forma mais tranquila em profissionais não especializados em acessibilidade.

Mas tudo isso depende do que se entende por acessibilidade e por conformidade técnica…

­

3. O que é acessibilidade em Design Systems?

Daniel Henderson-Ede (Accessibility Specialist da Pinterest) traz uma reflexão importante: acessibilidade vai além de garantir que um componente esteja em conformidade técnica com a WCAG. Ele explica que, embora componentes acessíveis sejam peças fundamentais para começar uma interface acessível de forma adequada, o quebra-cabeça completo só se forma quando a experiência como um todo é considerada. Um exemplo clássico disso é a ordem do foco em uma interface: se os componentes não estão organizados de maneira lógica, a navegação por teclado se torna frustrante, mesmo que cada peça isoladamente atenda aos padrões.

Por isso, um dos maiores debates que permeia toda construção de um DS acessível é sobre o entendimento do que é realmente acessibilidade. Cintia Romero (designer do Pinterest) descreve que essa acessibilidade ligada às diretrizes da WCAG é apenas uma conformidade técnica inicial. Isso não implica em dizer que a conformidade não é essencial, mas ela pontua algo importante trazido por muitos profissionais em 2024: somente conformação aos padrões não necessariamente implica em satisfação das reais necessidades desses grupos de usuários.

É por esse motivo que ela menciona, como complemento à conformidade técnica, o Design Inclusivo aplicado no contexto de Design Systems para que se tenha uma abordagem mais humana e holística nos testes das interfaces. Aqui, a acessibilidade é aplicada no contexto das metodologias do Design Centrado no Usuário onde se consideram múltiplos cenários de uso por pessoas diversas. Como complemento a essa visão, Hidde de Vries (Accessibility Specialist do NLDS da Holanda) propõe que, em vez de tratar a deficiência como uma limitação pessoal a ser mitigada — o que seria um modelo médico de pensamento —, devemos adotar o modelo social de acessibilidade, o que nos faz considerar um todo social em volta da pessoa que possui alguma deficiência.

Para entender como se aproximar dessa responsabilidade social, Greg Weinstein (designer da CVS Health) nos ajuda ao mencionar que um Design System Inclusivo também está ligado aos marcadores interseccionais das pessoas — um conceito emprestado de autoras como Kimberlé Crenshaw (1989). Esse conceito é usado para mostrar que diferentes características (como raça, classe, sexualidade — ou mesmo diferentes tipos de deficiências concomitantes) se sobrepõem e interagem, criando experiências particulares. Logo, não é apenas o leitor de tela (ou qualquer outra tecnologia) que precisa funcionar bem nessa perspectiva mais holística! Pode ser preciso pensar no idoso com baixa visão que precisa de interfaces simples devido à sua idade. Ou, como outro exemplo, pode ser necessário considerar o usuário de classe baixa que tem perda auditiva e que enfrenta dificuldades financeiras para comprar dispositivos modernos.

No fim das contas, essa conversa mostra que um Design System vai além de garantir conformidade perfeita em componentes isolados. Ele oferece as bases para alcançar essa conformidade de forma sistemática, mas seu verdadeiro valor está em permitir que ela se aprofunde e se amplie ao longo do tempo. É sobre testar soluções em contextos reais, com pessoas reais. É um processo de evolução contínua, onde a técnica se encontra, inevitavelmente, com a humanidade.

­

4. Como se evolui um Design System Acessível?

Talvez você já tenha ouvido que acessibilidade só funciona de verdade quando é considerada desde o início do processo — uma abordagem conhecida como Shift Left.

Simon Mateljan (Design Manager da Atlassian) faz uma analogia simples e eficaz: criar acessibilidade em um Design System é como adicionar ovos a uma receita de bolo. Se você esquecer esse ingrediente no começo, o resultado nunca sai como o esperado. Essa lógica faz sentido, já que garantir acessibilidade desde o início ajuda a permeá-la por todas as etapas do desenvolvimento. Mas os debates de 2024 mostraram que essa jornada está longe de ser linear! Não existe um ponto de partida perfeito — o processo é contínuo e cheio de ajustes.

O artigo de Sophie Beaumont (Design System Team Lead da BBC) mostra como o Shift Left pode acontecer na avaliação da reutilização de componentes em vários contextos. Ela relata um caso em que a equipe da BBC tentou reaproveitar um componente existente para criar uma timeline de conteúdo. Embora o Design System já contasse com um componente visualmente semelhante ao que a equipe havia projetado, ele não atendia aos requisitos de acessibilidade no novo contexto. Após discussões internas e avaliações técnicas, a equipe concluiu que forçar o uso do componente antigo prejudicaria a experiência de usuários com deficiência.

Essa decisão levou a BBC a reforçar um processo de trabalho que prioriza a funcionalidade acima da aparência na avaliação de uso dos componentes. Esse processo de trabalho é fundamental para evitar que um Design System crie engessamento, dificultando a acessibilidade ao invés de melhorá-la. Como complemento disso, Feli Bernutz (iOS Developer do Spotify) expõe “The Game Plan” (timestamp: 16:55) — uma metodologia de trabalho que avalia quando se pode usar uma solução pronta e quando se deve sair da caixa para criar algo mais personalizável.

Ainda, os imprevistos podem gerar necessidades inesperadas, que vão além da simples criação de novos componentes. Um exemplo disso é o Pinterest, que permite aos próprios usuários inserir textos alternativos (Alt Text) ao criar Pins. Esse modelo de conteúdo aberto e colaborativo apresenta desafios únicos para a acessibilidade, já que muitos usuários não produzem descrições ou produzem Alt Text de má qualidade.

Devido à proposta da plataforma, o Pinterest não pode simplesmente impor limitações rígidas para garantir a consistência do Alt Text. Em vez disso, a equipe investe em educar os usuários, oferecendo instruções claras por meio de componentes na interface sobre como criar descrições úteis e contextualizadas. Esse processo demonstra que, em certos casos, é preciso adaptar as diretrizes técnicas da WCAG às especificidades de cada serviço digital.

Por isso, muitas falas de 2024 reforçaram que o erro faz parte do processo de criação de Design Systems, principalmente em contextos onde as necessidades variam conforme o amadurecimento do produto. Mesmo no Encore Design System da Spotify (um produto de enorme escala), a abordagem é iterativa: em vez de perseguir uma solução perfeita desde o início, a equipe busca melhorias progressivas a cada etapa, subindo um degrau por vez. No UXCon de Vienna, Join Wendy relata que a construção de DSs inacessíveis no início não significa o fim do processo — pode ser, na verdade, o começo do entendimento de desafios particulares.

Então, como equilibrar tudo isso? De um lado, o Shift Left sugere que a acessibilidade deve ser uma preocupação desde o primeiro momento. Por outro lado, o processo contínuo de discovery revela necessidades específicas que exigem ajustes e adaptações. No fim das contas, construir um Design System acessível é menos sobre alcançar um estado perfeito e mais sobre manter-se aberto para aprender, testar e melhorar constantemente.

­

5. Como testar um Design System Acessível?

Por causa de tudo o que foi dito até aqui, fica claro que um Design System acessível não nasce pronto — ele é uma construção contínua, lapidada com o tempo e, principalmente, com muitos testes. Mas, diante da complexidade de criar interfaces verdadeiramente inclusivas, surge a pergunta: que tipo de teste precisa ser feito para alcançar esse objetivo?

Em 2024, o debate sobre acessibilidade em produtos digitais mostra a importância dos testes automatizados (e o uso possível da IA), especialmente em Design Systems já implementados ao nível de código. Ferramentas como Axe, Lighthouse e outras soluções automatizadas vêm ganhando espaço como grandes aliadas nesse processo. E, de fato, seria ingênuo subestimar sua importância: elas oferecem rapidez para identificar erros comuns, ajudando as equipes a alcançar padrões de conformidade.

Ainda, em uma live do Figma, Luis Ouriach (Designer Advocate do Figma) e Daniel Henderson-Ede (Accessibility Specialist do Pinterest) destacaram que apps nativos, como aqueles desenvolvidos para iOS e Android, apresentam desafios únicos. Diferente da web, onde padrões como HTML e ARIA oferecem uma base consolidada, as plataformas nativas possuem kits de ferramentas específicos, como UIKit no iOS e Jetpack Compose no Android. Essa fragmentação exige que as equipes adaptem suas práticas para garantir acessibilidade em diferentes ambientes.

Daniel também pontuou que as ferramentas de validação para apps nativos são menos integradas ao fluxo de desenvolvimento. Enquanto soluções como Axe e Lighthouse funcionam diretamente na web, apps móveis dependem de ferramentas como Xcode Accessibility Inspector ou Accessibility Scanner, que, apesar de úteis, têm limitações e não se conectam facilmente ao processo contínuo de desenvolvimento. Para contornar essas dificuldades, a recomendação é incluir testes específicos para cada plataforma, treinar as equipes sobre as particularidades de cada tecnologia — o que demanda a construção de processos de testagem e de documentação específicos em um Design System.

No entanto, há limites claros nesse tipo de abordagem, como nos lembra o artigo da WebFlow, que mostrou que testes automatizados conseguem identificar apenas cerca de 30% dos problemas de acessibilidade. Essa limitação nos leva a um ponto crucial mencionado pela grande maioria dos materiais de 2024: a automatização não substitui o olhar humano. Testes manuais e, principalmente, a interação com usuários reais são indispensáveis para entender a experiência prática — algo que os relatórios automatizados não conseguem capturar.

Dito isso, fica evidente por que tantos materiais se dedicam a explicar como criar testes de acessibilidade, destacando também os desafios de desenvolver uma documentação adequada para acompanhar e controlar esse processo contínuo de evolução.

­

6. Como organizar os testes de acessibilidade?

Para testar acessibilidade em um Design System, muitos materiais sugerem começar pela adoção ou criação de checklists. Dependendo do conteúdo em questão, os checklists podem ser preenchidos após testes manuais ou testes automatizados. Aqui, o debate é menos sobre a técnica de testagem e mais sobre como sistematizar a organização destes testes em uma equipe.

Amy Cole, do US Web Design System (USWDS), vê os checklists como pontes entre o que está nos manuais (como a WCAG) e o que realmente acontece quando um usuário navega por um produto. Esses guias funcionam como roteiros que permitem que até equipes menos especializadas se envolvam em testes práticos com usuários reais. Assim, o checklist é debatido aqui não só como uma ferramenta de sistematização de testes, mas como um processo de inclusão de quem se sente afastado dos critérios da WCAG devido à sua linguagem técnica. Por isso, a equipe do USWDS sugere perguntas como:

• “O botão pode ser acionado com a tecla Enter ou a barra de espaço?”
• “O foco é claramente visível em todos os estados do botão?”

A sugestão é criar essas perguntas com várias equipes, incluindo especialistas e permitindo uma visão colaborativa e multidisciplinar. Aqui, o material da USWDS destaca a importância de haver um controle por documentação para entender quais critérios da WCAG já foram considerados com cada uma das perguntas sugeridas.

Wendy Fox, na UXCon Vienna, complementa essa visão ao debater a importância de fazer auditorias para ir além de checklists genéricas que serviriam para qualquer cenário. Um link em um carrossel dinâmico, por exemplo, não pode ser avaliado da mesma forma que um link estático em um texto. Por isso, ela defende checklists personalizados que levem em consideração as singularidades de cada componente: para um botão, isso pode significar verificar se há estados de foco visíveis; para um modal, garantir que a navegação por teclado flua de forma natural. São critérios que não apenas garantem conformidade, mas tornam a experiência mais fluida e respeitosa para quem depende de tecnologias assistivas.

Amy Hupe e Geri Reid, do Government Digital Service (GDS) do Reino Unido, reforçam que esses checklists precisam considerar as ferramentas que os usuários utilizam. Aqui, são sugeridos a aplicação de diferentes testes, como: 1) acesso pelo teclado; 2) zoom/magnificação; 3) leitores de telas como NVDA e JAWS; 4) rastreadores oculares. Isso é sugerido pelas designers como um guia para que se possa entender a acessibilidade para além de um conceito genérico e geral, podendo incluir tipo de tecnologia por device. Como existem muitas deficiências e contextos diferentes para serem considerados, os testes podem indicar quais são as tecnologias assistivas com mais suporte no Design System e quais ainda podem evoluir para criar uma experiência melhor.

Além disso, é importante dizer que a maioria dos materiais indica a importância de falar com usuários reais em pesquisa qualitativa. Ainda, saliento que é o debate menos aprofundado em todos os materiais de 2024, uma vez que ainda se reflete muito sobre as peças do Design System e menos sobre testes sobre o quebra-cabeças montado e já ofertado a usuários finais.

­

7. Como documentar os testes?

Um dos maiores desafios de todos se refere à documentação dos testes de acessibilidade que permitem a evolução de um Design System acessível. Não é banal que alguns dos materiais de 2024 detalham a fundo os desafios da construção e da manutenção desses testes ao longo do tempo.

É possível trabalhar tanto com a documentação de acessibilidade no design (utilizando o Figma como espaço de registro) quanto com a documentação de testes gerais realizados nas interfaces já desenvolvidas, que normalmente ocorre em planilhas de Excel, no GitHub ou em sites próprios do Design System. Não há um consenso sobre qual dessas documentações é a mais relevante, mas diferentes profissionais defendem as propostas, considerando suas diferentes finalidades.

No Gestalt do Pinterest, Cintia Romero expôs que existe uma integração de checklists diretamente no Figma como uma forma de aproximar o designer da prática de acessibilidade. De acordo com um estudo de caso da Deque, 67% dos problemas de acessibilidade ocorrem devido a erros produzidos nos protótipos de design! Esse dado desmistifica a ideia de que os testes e a própria documentação de acessibilidade devem ocorrer apenas ao nível de desenvolvimento. Por isso, algumas plataformas possuem essa documentação no próprio Figma para que o handoff dos produtos esteja conforme padrões de acessibilidade antes de seguir para testes ao nível de código.

Essa documentação muitas vezes é transferida posteriormente à página do componente no site do Design System, como podemos ver a seguir no caso do Gestalt.

Essa é uma proposta de documentação mais sucinta. Outros projetos apostam em documentações bem mais robustas e detalhadas, contendo critérios de sucesso e tipo de teste realizado (incluindo qual a tecnologia assistiva em questão). É o desafio exposto pela equipe do USWDS que organiza os dados de testes (manuais e automatizados) de todos os componentes do Design System. Para isso, a equipe utiliza uma planilha que contém:

1. Nome do Componente: O nome do componente que está sendo auditado.
2. Critério de Sucesso do WCAG: O critério específico que está sendo testado, como “1.4.4 Resize Text” ou “2.1.1 Keyboard Accessibility”.
3. Nível de Conformidade: O nível de conformidade do WCAG (A, AA ou AAA).
4. Tipo de Teste: Se o teste é relacionado a teclado, zoom, leitores de tela, design ou outro aspecto.
5. Status do Teste: Se o teste foi aprovado, reprovado ou passou com exceções.
6. Descrição Adicional: Detalhes sobre como o teste foi conduzido e o que o desenvolvedor deve observar. Existem três colunas chamadas “When you”, “And” e “This Happens” que permitem explicar um caso de sucesso ou erro do teste realizado.
7. Prompt do Teste Automatizado (se aplicável): Exposição do prompt do teste para controle de como foi realizada a testagem.
8. Data da Auditoria: A data em que o teste foi realizado e revalidado para que haja controle dos resultados e de possíveis atualizações da WCAG.
9. Outras colunas para Notas e Falhas Comuns: Observações sobre problemas comuns encontrados durante os testes, incluindo contribuições relatadas através do GitHub do projeto.

Em ambos os casos, existem desafios muito importantes expostos nesses materiais. No caso da USWDS, Amy Cole explica que re-auditorias dos componentes são realizadas regularmente para entender se é necessário considerar novos cenários — como, por exemplo, mudanças em navegadores no caso de componentes da Web. Ainda, pode haver mudança na tecnologia assistiva que se utiliza por um grupo de pessoas, sendo preciso realizar novos testes sem perder as documentações antigas.

Outro ponto de atenção é sobre testes que vão além dos componentes em si, como a Fable comenta em um artigo sobre diferentes níveis de testagem da acessibilidade em um Design System. Se verificarmos erros na relação entre componentes (apesar de os componentes em si estarem em conformidade), onde e como posso documentar esses problemas? Ou, ainda, se um usuário com deficiência trouxer uma visão que vai além do que entendemos por acessibilidade com a WCAG, onde consigo espaço para dar voz a esse público?

Acredito que sejam esses desafios que, como comunidade, ainda estamos descobrindo.

Gostou de acessar o conteúdo dessa retrospectiva? Fique à vontade para entrar em contato comigo através do meu LinkedIn para qualquer tipo de feedback.

Referências

APPFORCE. Designing APIs: How to ensure Accessibility in Design System components. AppForce, YouTube.

BEAUMONT, Sophie. Shifting left: how introducing accessibility earlier helps the BBC’s design system.

BEDASSE, Kristen. Design System Accessibility — UX Case Study: Accessibility improvements to an existing design system.

BHAWALKAR, Gina. My Takeaways From Config 2024: Impacts On Design Systems, Storytelling, And Accessibility. Forrester, 2024. .

BIKKANI, Aditya. A guide to accessible design system. AELData, 2024.

CODE AND THEORY. 3 Principles to Build an Engineered Design System that Improves Speed, Consistency, and Accessibility. Medium, 2024.

CODE AND THEORY. How to create an accessible design system in 60 days. Medium, 2024.

CONVEYUX. Greg Weinstein — Inclusive user research to build an accessible design system. ConveyUX, YouTube, 2024.

CUELLO, Javier. Accessible Components. Design Good Practices, 2024.

DEQUE SYSTEMS. Making Pinterest more inclusive through design systems — axe-con 2023. Deque Systems, YouTube, 2024.

DIGITALGOV. Component-based accessibility tests for the U.S. Web Design System. DigitalGov, YouTube, 2024.

FABLE. Power up your design system with accessibility testing. Fable, 2024.

FIGMA. In the file: Design Systems and Accessibility | Figma. Figma, YouTube, 2024.

FRONTEND ENGINEERING & DESIGN SOUTH AFRICA (FEDSA). The NL Design System And Why Accessibility Matters — Hidde de Vries. FEDSA, YouTube, 2024.

GEORGIEV, Georgi. The importance of high contrast mode in a design system. Pros, 2024.

GET STARK. How to use your design system colors to fix accessibility issues with Stark in Figma and the browser. Get Stark, 2024.

HAWKINS, Tyler. Scaling accessibility at Webflow. Webflow, 2024.

HI INTERACTIVE. UX and design systems in retail: inclusivity, accessibility, and innovation — Hi Talks #10. Hi Interactive, YouTube, 2024.

INTO DESIGN SYSTEMS. Design systems accessibility meetup — Component review. Into Design Systems, YouTube, 2024.

INTO DESIGN SYSTEMS. Design tokens sets for accessibility needs — Marcelo Paiva at Into Design Systems Conference. Into Design Systems, YouTube, 2024.

JOER, Jairus. Develop design systems with accessibility in mind. Aggregata, 2024.

KNAPSACK. Making design systems inclusive with accessibility specialist Daniel Henderson-Ede. Knapsack, Youtube, 2024.

KORNOVSKA, Diyana. Building accessibility into design systems. Resolute Software, 2024.

LAGO, Ernesto. Accessibility Best Practices for Design Systems. LinkedIn, 2024.

LAGO, Ernesto. An Intro to Accessibility in Design Systems. LinkedIn, 2024. .

LAMBATE, Fahad. Designing for inclusivity: the Shift Left approach towards accessible design systems (ADS). Barrier Break, 2024.

LYNN, Jamie. Accessible design systems. Jamie Lynn Design, 2024.

MILLER, Lindsay. The importance of accessibility in design systems. Font Awesome, 2024.

NL DESIGN SYSTEM. Using USWDS accessibility tests to improve accessibility — Amy Cole — Design Systems Week 2024. NL Design System, YouTube, 2024.

ROMERO, Cintia. Accessibility in design systems: a comprehensive approach through documentation and assets. Supernova, 2024.

STANKOVIC, Darko. Accessibility in Design Systems. Balkan Bros, 2024.

TESTDEVLAB. QualityForge: Speaker #5: Adrián Bolonio — Design systems and how to use them in an accessible way. TestDevLab, YouTube, 2024.

UNIVERSAL DESIGN THEORY. Creating an accessible design system. Universal Design Theory, 2024.

UXCAMP AUSTRALIA. Simon Mateljan | Baking accessibility into your design system. UXCamp Australia, YouTube, 2024.

UXCON VIENNA. (In)accessible design systems: doing things wrong to get it right — Wendy Fox — uxcon Vienna 2023. UxCon Vienna, YouTube, 2024.

VAUGHAN, Maggie. Essential principles of accessible design systems. Dubbot, 2024.

WEBAIM. Homer Gaines: Improving accessibility through design systems. WebAIM, YouTube, 2024.

ZEROHEIGHT. Back to school with Amy Hupe & Geri Reid: Accessibility and design systems. Zeroheight, YouTube, 2024.

Design Systems e Acessibilidade: Retrospectiva de 2024 was originally published in UX Collective