Como é ser um QA de acessibilidade?
Tags: qa, brazilliandevs, a11y
Published: 2022-12-31 22:12:56

---
title: Como é ser um QA de acessibilidade?
published: true
date: 2021-08-22 00:00:00 UTC
tags: qa, brazilliandevs, a11y
canonical_url: https://brunopulis.com/qa-acessibilidade-cotidiano-curiosidades/
---

Recentemente me tornei um **QA de acessibilidade**. Não foi uma decisão fácil, mas aceitei o desafio de participar do time de acessibilidade que mais cresce no Brasil.

Na [NTT Data](https://www.everis.com/brazil), temos um time com cerca de 70 profissionais dedicados em tempo integral pela acessibilidade. Nossa tendência é crescer mais.

Em breve, vou escrever sobre o time de acessibilidade da NTT Data.

Neste artigo vou contar para vocês, como é a rotina de um QA focado em acessibilidade, as curiosidades, desafios e oportunidades. Vamos lá?

* * *

## Cotidiano

Nosso cotidiano é um pouco diferente, além de seguirmos as boas práticas de testes e técnicas, utilizamos a [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/#intro), que é nosso norte para reportar as inconsistências relacionadas à acessibilidade.

Hoje atendo mais de uma squad por vez. Nossas demandas de testes são menores em relação aos nossos colegas funcionais. Isto contribui para acompanhar melhor os cenários.

### Relacionamento com os times

![Squad de futebol americano](https://brunopulis.com/images/squad-team.jpeg)

Photo by football wife on [Pexels.com](https://www.pexels.com/photo/football-player-huddled-together-in-field-1349339/)

Sempre procuramos manter um bom relacionamento com o time, os QAs funcionais sempre são bastante solícitos e curiosos sobre o tema, acessibilidade.

Inclusive, é gratificante quando conseguimos colocar a semente da acessibilidade no coração deles.

Os outros papéis como PO's, UX's e Team Leads nos auxiliam bastante e conseguimos ter uma boa sinergia para realizar nosso trabalho.

Nem tudo são flores, volta e meia precisamos exemplificar com bons argumentos nossa posição, em relação, a algum bug ou postura que adotamos.

### Formas de validação

Para validarmos usamos como norte a [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/#intro) , um documento da W3C, que contém as diretrizes de acessibilidade. Nossos testes são baseados em:

- testes exploratórios;
- testes manuais;
- testes semi automatizados;
- testes automatizados (apesar de hoje não atuar com eles).

O testes mais exaustivos, que fazemos são, os testes manuais com os leitores de tela. Atualmente testamos com o NVDA, TalkBack e VoiceOver.

A forma de interagir com a informação em cada um é similar, porém, existem algumas exceções. Validamos através de **títulos** e também por **palavras**.

Vale uma ressalva para os testes automatizados, eles contribuem em cerca de 57% para previnir possíveis inconsistências de acessibilidade. Esse número é resultado de [uma pesquisa](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/) da Deque Systems.

Existem diversas possibilidades de automação em testes de acessibilidade. Este é um outro tema que prometo surgir por aqui.

## Recursos e ferramentas

Usamos diversos recursos para garantir que as aplicações estejam acessíveis, irei listar alguns recursos:

- O [Guia WCAG](https://guia-wcag.com), uma referência rápida para consultar as diretrizes de acessibilidade;
- Colour Contrast Analyzer;
- leitores de telas;
- checklist para nos orientar.

## Soft Skills

Como um QA de acessibilidade, alguns pontos valem a pena ser destacados como:

- boa comunicação verbal e escrita;
- ser preciso;
- entender os conceitos de agilidade;
- ter flexibilidade.

## Curiosidades

Essas características nos auxiliam e deixam nosso trabalho mais tranquilo em relação ao time que trabalhamos.

Existem algumas curiosidades bem interessantes sobre nossa atuação e como lidamos com os problemas do cotidiano:

- trabalhamos em dupla;
- utilizamos a todo tempo, tecnologias assistivas (leitores de tela);
- realizamos testes de contraste;
- o reporte de bugs de acessibilidade é um pouco diferente;
- validamos a estrutura do HTML.

Outro fato legal, a acessibilidade é considerada desde a concepção do design. Isso contribui consideravelmente para nosso trabalho.

## Desafios

Os desafios que enfrentamos geralmente, são relacionados ao desconhecimento da WCAG e das direitrizes de acessibilidade. Também da escrita incorreta do HTML, esse já foi um tópico de outro [artigo no blog](https://brunopulis.com/blog/repensando-sobre-html/).

Outro ponto importante, é demonstrar quão crucial a acessibilidade é para o produto que está sendo desenvolvido.

## Oportunidades

O QA de acessibilidade está rodeado de oportunidades de crescimento, cada vez o assunto "acessibilidade" vem a tona.

Recentemente fiz um curso de "QA de acessibilidade" pela [INSEP](https://insep.org.br/), o [Maurício Pereiro](https://www.linkedin.com/in/mauricio-pereiro/) um dos instrutores, comentou que a projeção desses profissionais irá crescer exponencialmente.

Concordo com o comentário, pois as empresas, estão despertando para o tema e entendendo que além de cumprir uma legislação, devem promover um acesso justo e igualitário a todos.

## Está gostando desse conteúdo?

Escrevo semanalmente na [Pulis Letters](https://subscribepage.io/cartas) e compartilho insights valiosos sobre acessibilidade digital para desenvolvedores, QA’s e designers.

## Conclusão

Ser um QA de acessibilidade é olhar de uma forma mais humana e contribuir com o acesso igualitário para todas as pessoas, independente de sua deficiência.

E sair de uma zona de conforto e se importar pelo outro, talvez seja por isso que a acessibilidade me encanta tanto.

Esse conteúdo de ajudou em algo? [Considere apoiar meu trabalho](https://ko-fi.com/brunopulis).