Melanie Sumner é engenheira de software, especializada em acessibilidade digital. Conversamos sobre a trajetória dela até a engenharia, o design acessível, o Ember.js e a importância de financiar esses esforços.
Esta postagem destaca um especialista da comunidade como parte do Learn Accessibility!
Alexandra Klepper: obrigado por participar! Quem você é e o que faz?
Melanie Sumner: meu nome é Melanie Sumner e sou engenheira de software especializada em acessibilidade digital. Escrevo código para a Web há 25 anos. Minha primeira carreira foi… meio que de espiã. Eu era analista de inteligência na Marinha dos EUA, e programação era meu hobby.
Eu não gostava muito de ser espião. Acontece que eu não gostava da morte. Como a maioria das pessoas não é, quando elas precisam ficar mais perto. Eu precisava decidir o que fazer em seguida, e era hora de transformar meu hobby em carreira. Nos últimos 10 anos, me concentrei muito na engenharia de software no espaço de acessibilidade, especificamente.
Alexandra: Não é comum ouvir: "Ah, primeiro eu era espiã". Tá tudo bem. O que trouxe você para o trabalho de acessibilidade?
Melanie: Eu trabalhava na Universidade da Carolina do Norte [UNC] em Chapel Hill na época, no Departamento de Desenvolvimento. Não se trata de desenvolvimento na Web, mas de desenvolvimento como arrecadação de fundos.
Meu gerente direto tinha deficiência visual e precisava aumentar tudo em 400% para enxergar. Ele era um engenheiro de software fantástico. Provavelmente o melhor gerente que já tive. Mas ele sempre quebrava minhas coisas porque dava zoom para olhar meu trabalho. Se eu não tivesse pensado em criar coisas de forma responsiva, elas não funcionariam.
O chefe do meu gerente era daltônico para a cor azul. Não sei se você sabe como é o azul da UNC, mas é esta cor azul-celeste clara. Eles adoraram usar em branco.
Alexandra: (risos) Ah, não.
Melanie: O chefe dele sempre reclamava que nunca conseguia ver meu trabalho! Tive que desenvolver um conjunto de cores complementares e um esquema de cores para nossos sites. Isso me fez pensar sobre o contraste de cores e como as pessoas daltônicas (ou com deficiência visual) usam a Web.
Como a UNC é uma universidade estadual, há uma exigência federal dos EUA de conformidade com o nível AA de acessibilidade das WCAG. Nosso objetivo era o nível AAA porque é uma instituição de ensino.
À medida que aprendi mais sobre os requisitos estaduais e federais e comecei a ler a especificação de acessibilidade do W3C, pensei: "Tudo isso faz sentido". Pelo que pude ver, a maior parte da Web não estava em conformidade. É claro que as pessoas trabalham com acessibilidade na Web desde que ela existe. Às vezes, os engenheiros de JavaScript (em particular) demoram um pouco para entender a acessibilidade digital.
Chamo a acessibilidade de a fronteira final da Web. Muitas pessoas boas trabalham na automação para acessibilidade, e precisamos trabalhar em soluções da mesma forma que abordamos outros problemas difíceis, como desempenho e segurança.
Alexandra: você provavelmente leu muitos documentos longos e complexos na Marinha e na UNC. Você achou difícil entender a especificação?
Melanie: precisei ler umas cinco vezes antes de entender, e já tinha lido outras especificações antes. Sempre digo às pessoas: não se sintam mal se não entenderem, porque eu precisei ler a especificação cinco vezes! Não tô brincando.
Leva muito tempo para se acostumar com a linguagem de especificação. E se você não interpretar corretamente, poderá fazer a coisa errada. Também é importante entender que grande parte da linguagem da especificação é destinada a desenvolvedores de navegadores. Procure "os autores devem", porque essa é uma referência a desenvolvedores da Web.
Alexandra: muita coisa na Web poderia ser melhor se mais desenvolvedores soubessem como decifrar as especificações.
Melanie: Há muito a dizer sobre sites que fazem essa interpretação para você. Eu criei o a11y-automation.dev, e esse site é como um filho, meu projeto paralelo. Tento detalhar cada violação de acessibilidade e vincular aos critérios de sucesso da WCAG em questão. Se houver automação para evitar o erro, vou oferecer essa solução.
Você pode se familiarizar com a lista de possíveis violações, mas o mais importante é aprender a corrigir. Para correções automatizadas que não existem, talvez você se inspire para escrever um linter ou um modelo, ou até mesmo algum tipo de teste.
Prefiro trabalhar em código aberto porque você pode interagir com outras pessoas, oferecer uma melhoria (às vezes uma melhoria, às vezes não, mas todos tentamos fazer o melhor). Nós construímos com base no trabalho uns dos outros e acabamos tendo um resultado muito bom para a Web.
Como financiar a acessibilidade
Alexandra: gostei muito do pleasefunda11y.com. É muito importante que os desenvolvedores aprendam a criar sites acessíveis, mas nem sempre eles têm os recursos necessários sem o financiamento e a aprovação da liderança executiva. Por que você decidiu criar este site?
Melanie: fiquei frustrada porque a acessibilidade recebe poucos recursos. Todo o financiamento de código aberto parece continuar indo para o CSS. E eu adoro CSS, podemos fazer muito com ele.
Criei o site porque Addy Osmani, um gerente de engenharia de software do Chrome, entrou em contato e disse que viu que eu estava pedindo financiamento para acessibilidade, mas queria saber que tipo de trabalho específico poderia ser financiado. Esse é um grande problema: os financiadores de código aberto querem dar dinheiro para projetos específicos, não para ideias gerais que não têm um resultado determinado. Reservei um tempo para escrever algumas iniciativas específicas, o que é necessário e como elas vão ajudar a tornar os sites acessíveis.
Mesmo que as empresas façam isso sem mim, podemos avançar a acessibilidade na Web de uma forma muito significativa. É um gasto muito pequeno em comparação com outros esforços na Web, mas teria um impacto enorme na vida das pessoas.
A maneira atual de pensar é geralmente: "Quantas pessoas têm uma deficiência?" A pergunta correta é: "Qual é a relação de qualquer pessoa com a tecnologia dela?"
Algumas pessoas me disseram: "Não acho que o daltonismo seja uma deficiência". Você pode não se identificar como uma pessoa com deficiência se tiver daltonismo, mas isso afeta sua relação com a tecnologia.
Alexandra: me conte mais sobre como entender sua relação com a tecnologia. Como isso se relaciona com a acessibilidade?
Melanie: por exemplo, se você for neurodivergente, talvez precise de uma linguagem muito simples e instruções muito claras. Talvez seja melhor navegar por três ou quatro telas em um fluxo, fazendo algumas escolhas por vez até chegar ao final. Não há boas orientações para aplicativos técnicos modernos.
Temos empresas inteiras que fazem DevOps, e se você tentar usar alguns desses sites, vai pensar: "Meu Deus", sabe? Tentamos colocar tudo em todas as nossas interfaces hoje em dia.
Alexandra: pode compartilhar um exemplo?
Melanie: por exemplo, o GitHub tem menus suspensos com guias aninhadas. E [suspiro exasperado]. Não posso ficar chateado (mesmo que eu esteja frustrado). A Web moderna precisa crescer para atender às novas demandas. Mas também temos a responsabilidade de criar de uma forma que não deixe as pessoas para trás.
É isso que me motiva, essa é minha paixão. Não quero que alguém não consiga um emprego porque as ferramentas que precisaria usar não são acessíveis.
Alexandra: 100%. As pessoas costumam pensar em criar produtos acessíveis para usuários externos, mas não necessariamente para os funcionários.
Melanie: pensei: "Sabe de uma coisa? Essas dicas de financiamento provavelmente vão beneficiar todo mundo".
Ouço engenheiros dizerem o tempo todo que adorariam trabalhar com acessibilidade, mas que "minha empresa não se importa". Aposto que eles se importam! Basta preencher a lacuna na lógica de negócios. Mostre o resultado benéfico para a empresa. O site é de código aberto, é claro, e adoro contribuições e edições.
Alexandra: A acessibilidade geralmente é deixada para o final do processo, como "Ah, podemos tornar isso acessível depois". Mas vai levar muito mais tempo para adicionar depois do que para integrar práticas acessíveis em todo o projeto.
Melanie: costumo dizer: "Você quer pagar para criar uma vez ou duas?"
Ember.js e a equipe principal de acessibilidade
Alexandra: sei que você também faz parte da equipe principal do framework Ember.js. Como você se envolveu?
Melanie: fui contratada para trabalhar no JPMorgan Chase, nas plataformas de banco de investimento corporativo. O Ember é uma estrutura JavaScript robusta usada quando você precisa de uma base realmente estável (talvez até um pouco chata), que pode ajudar a evitar escrever código que perca muito dinheiro. O Ember tem uma garantia de compatibilidade com versões anteriores. Você pode fazer upgrade sempre, mesmo que encontre uma versão principal. Tentamos fazer as coisas de forma incremental para não prejudicar seu app.
De qualquer forma, fui a uma conferência do Ember e conheci várias pessoas da comunidade. As pessoas de Ember foram muito gentis. E há um código de conduta muito forte que eu ainda não tinha visto em outros lugares.
Quando saí do exército, queria trabalhar com segurança. Fui a um encontro de segurança da informação e não vi nenhuma outra mulher lá. Um dos caras mais velhos olhou para mim e disse: "Você tem certeza de que está na sala certa, querida?"
Alexandra: [Gemidos] Dói. E isso não é surpreendente. Já passei por algo parecido.
Melanie: Isso foi em 2011 ou 2012? O cenário mudou muito. Fiquei naquela noite, durante aquele encontro, para provar um ponto. Não ia deixar que esse comentário me fizesse desistir. Eu fazia piadas, tomava notas boas e participava da conversa para que as pessoas soubessem que eu estava ali. Sinto que grande parte da minha carreira foi para provar que os homens estavam errados.
Mas não quero que as mulheres se tornem engenheiras de software apenas para provar que os homens estão errados. Eu queria ser engenheira de software para criar coisas incríveis, porque é divertido fazer isso. As mulheres deveriam ter essa opção de carreira.
Alexandra: Com certeza.
Melanie: compartilhei o que sabia sobre acessibilidade com a comunidade Ember porque, obviamente, como uma plataforma bancária, você precisa obedecer aos requisitos federais dos EUA. Yehuda Katz e Tom Dale disseram: "Temos uma lacuna na equipe. Temos muitos especialistas em JavaScript, em performance, pessoas incrivelmente inteligentes, e precisamos de alguém com conhecimento em acessibilidade." E me convidaram para participar da equipe principal.
Estou trabalhando em iniciativas para tornar o Ember acessível por padrão. Isso significa que, ao dizer ember new <my-app-name>, você precisa atender imediatamente aos critérios de sucesso da WCAG.
Alexandra: vi uma longa lista de ferramentas de acessibilidade para Ember no GitHub. Você acha que as pessoas na comunidade Ember estão animadas para contribuir com essas ferramentas?
Melanie: Essa é uma parte muito interessante do trabalho. Escrevi regras de linting de acessibilidade para o Ember enquanto trabalhava no LinkedIn. Depois, saí do LinkedIn para trabalhar na Hashicorp, e outras pessoas ainda contribuem com o linter porque ele é útil para elas. Essa é a parte do trabalho que me dá arrepios e me deixa animado.
Aceitamos que, como base, a acessibilidade é um direito civil. Isso não está em discussão.
O que discutimos é: o que podemos implementar? Quando? Como fazemos isso? Como podemos ensinar isso e tornar compatível com versões anteriores? Como ajudamos os desenvolvedores a oferecer suporte à acessibilidade sem um recurso extra enorme que eles precisam criar ou planejar?
Alexandra: acessibilidade é um direito civil. Isso me dá calafrios! Ela deve ser algo que todos conhecemos como verdade.
Melanie: já ouvi pessoas dizerem coisas sem noção, como "Eu não usaria a Internet se fosse cega". Ou: "Por que preciso pensar em deficiências quando apenas 5% dos meus usuários têm alguma e 90% não têm?" Não vou ter essas discussões, porque elas geralmente são usadas para distrair do trabalho.
Ao escrever código acessível, você vai ter melhorias de desempenho porque está pensando em criar sites informados pelas especificações do W3C. Você vai usar o HTML semântico em vez de apenas divs e vai usar cabeçalhos. Você vai escolher um
<button> em vez de adicionar um evento de clique a um <div>, e vai receber
melhorias de desempenho.
Faça uma coisa: automatize a acessibilidade
Alexandra: o que os desenvolvedores da Web precisam fazer para criar sites acessíveis?
Melanie: adicione automação. Comece com um linter para qualquer framework ou tipo de código que você esteja usando. Não importa qual você usa! A build precisa ser interrompida se uma dessas regras for violada.
Algumas coisas não podem ser automatizadas porque a IA ainda não consegue decifrar a intenção. Por exemplo, o valor do texto alternativo de uma imagem precisa ser significativo, mas o que isso realmente significa? No momento, um humano precisa discernir isso, e não a automação.
Mas uma ferramenta automatizada pode dizer: "Você não está passando no contraste de cores". Só corrija. Não lute contra isso, não diga: "Mas eu não quero, prefiro assim". Não é sobre você. É sobre disponibilizar o que fazemos para todos no mundo todos os dias.
A acessibilidade é uma jornada, e você sempre vai aprender. Sou especialista em acessibilidade há mais de uma década e ainda aprendo coisas novas o tempo todo. Não fique na defensiva, apenas faça.
Acompanhe o trabalho de Melanie no site melanie.codes e no Twitter @a11yMel. Confira os recursos de acessibilidade dela em pleasefunda11y.com, a11y-info.com e a11y-automation.dev.