Acessibilidade não é um "extra" que o time de design pede no fim do projeto — é parte de fazer o front funcionar para todo mundo, inclusive quem navega só pelo teclado, usa leitor de tela ou enxerga pouco contraste. Saber tornar uma interface acessível, e entender que isso é responsabilidade de quem escreve o HTML e o CSS, é esperado de um front pleno.
Por que a11y é responsabilidade do front
O sufixo "a11y" é só "accessibility" com as 11 letras do meio abreviadas. A questão central: o navegador expõe a estrutura da sua página para tecnologias assistivas através de uma árvore de acessibilidade, construída a partir do seu HTML. Se você usa <div onclick> no lugar de <button>, o leitor de tela não anuncia "botão", o teclado não foca e o Enter não dispara. O que você escreve é a acessibilidade. Além disso, em muitos países é obrigação legal.
HTML semântico é a base
Antes de qualquer ARIA, use a tag certa. <button>, <nav>, <label>, <h1>–<h6> já trazem papel, foco e comportamento de teclado de graça. Um <button> é focável, anunciado como botão e ativável por Enter e Espaço sem uma linha de JavaScript. Isso conecta direto com HTML semântico: 90% da acessibilidade é só usar a marcação correta.
Quando (e quando NÃO) usar ARIA
ARIA é um conjunto de atributos (role, aria-label, aria-expanded...) que complementa a semântica quando o HTML não dá conta — por exemplo, um componente customizado como um combobox. A primeira regra da ARIA, porém, é: não use ARIA se um elemento HTML nativo resolve. ARIA mal aplicada anuncia coisas erradas e quebra o que funcionava. role="button" num <div> obriga você a reimplementar foco e teclado na mão — use <button>.
Antes e depois de um botão
<!-- Antes: inacessível -->
<div class="btn" onclick="salvar()">Salvar</div>
<!-- Depois: acessível, sem JS extra -->
<button type="button" onclick="salvar()">Salvar</button>
<!-- Botão só com ícone precisa de nome -->
<button aria-label="Fechar"><svg aria-hidden="true">...</svg></button>O <div> não recebe foco por Tab, não responde a Enter e é anunciado como "Salvar" sem dizer que é clicável. O <button> resolve tudo isso de graça. O ícone decorativo ganha aria-hidden="true" para não poluir o leitor de tela, e o botão ganha um nome via aria-label.
Teclado e gerência de foco
Muita gente navega só pelo Tab. Três coisas importam: o foco precisa ser visível (nunca remova o outline sem por algo no lugar), a ordem do foco deve seguir a leitura visual (resolvida naturalmente pela ordem do DOM) e modais precisam aprisionar o foco. Ao abrir um modal, mova o foco para dentro dele, mantenha o Tab circulando lá dentro e devolva o foco ao elemento de origem ao fechar — senão o usuário "perde" onde estava.
Contraste, tamanho de alvo e texto alternativo
Texto cinza-claro sobre branco é bonito e ilegível para muita gente. A WCAG exige contraste mínimo de 4,5:1 para texto normal (nível AA). Alvos clicáveis devem ter área suficiente (em torno de 44×44px) para quem tem pouca precisão motora ou usa toque. E toda imagem que carrega informação precisa de alt descritivo; imagens puramente decorativas levam alt="" para serem ignoradas. Manter o tamanho do alvo e não recarregar layout também ajudam a renderização e a usabilidade geral.
Leitor de tela e níveis WCAG
Um leitor de tela lê a página em voz alta, navegando pela árvore de acessibilidade — por isso a ordem e os rótulos importam tanto. As diretrizes WCAG definem três níveis de conformidade:
| Nível | O que cobre |
|---|---|
| A | Mínimo essencial (ex.: teclado funciona) |
| AA | Alvo prático da maioria dos projetos (contraste 4,5:1) |
| AAA | Mais rigoroso, nem sempre viável em tudo |
Na prática, mire em AA — é o padrão exigido pela maioria das legislações e contratos.
A melhor forma de testar acessibilidade é guardar o mouse: navegue sua tela só pelo Tab e pelo Enter. Se você não consegue chegar ou ativar algo, ninguém que depende do teclado também consegue.
Conclusão
Acessibilidade começa com HTML semântico, usa ARIA só quando o nativo não basta, garante navegação por teclado com foco visível e gerenciado, e respeita contraste, tamanho de alvo e texto alternativo. Mire no nível AA da WCAG. Não é trabalho a mais no fim do projeto: é fazer o front cumprir o que sempre foi seu papel — funcionar para todas as pessoas.
Accessibility is not an "extra" the design team asks for at the end of the project — it is part of making the front end work for everyone, including people who navigate only by keyboard, use a screen reader or have low contrast vision. Knowing how to make an interface accessible, and understanding that this is the responsibility of whoever writes the HTML and CSS, is expected of a mid-level front-end developer.
Why a11y is the front end's responsibility
The "a11y" suffix is just "accessibility" with the 11 middle letters abbreviated. The core idea: the browser exposes your page's structure to assistive technologies through an accessibility tree, built from your HTML. If you use <div onclick> instead of <button>, the screen reader doesn't announce "button", the keyboard can't focus it and Enter doesn't fire it. What you write is the accessibility. On top of that, in many countries it is a legal requirement.
Semantic HTML is the foundation
Before any ARIA, use the right tag. <button>, <nav>, <label>, <h1>–<h6> already come with role, focus and keyboard behavior for free. A <button> is focusable, announced as a button and activated by Enter and Space without a single line of JavaScript. This connects directly to semantic HTML: 90% of accessibility is just using the correct markup.
When (and when NOT) to use ARIA
ARIA is a set of attributes (role, aria-label, aria-expanded...) that complements semantics when HTML isn't enough — for example, a custom component such as a combobox. The first rule of ARIA, though, is: don't use ARIA if a native HTML element solves it. Misapplied ARIA announces the wrong things and breaks what used to work. role="button" on a <div> forces you to reimplement focus and keyboard handling by hand — use <button>.
A button, before and after
<!-- Before: inaccessible -->
<div class="btn" onclick="salvar()">Salvar</div>
<!-- After: accessible, no extra JS -->
<button type="button" onclick="salvar()">Salvar</button>
<!-- Icon-only button needs a name -->
<button aria-label="Fechar"><svg aria-hidden="true">...</svg></button>The <div> doesn't get focus via Tab, doesn't respond to Enter and is announced as "Salvar" without saying it's clickable. The <button> solves all of that for free. The decorative icon gets aria-hidden="true" so it doesn't clutter the screen reader, and the button gets a name via aria-label.
Keyboard and focus management
Many people navigate only with Tab. Three things matter: focus must be visible (never remove the outline without putting something in its place), the focus order should follow the visual reading order (naturally solved by DOM order) and modals must trap focus. When opening a modal, move focus inside it, keep Tab cycling within it and return focus to the originating element on close — otherwise the user "loses" where they were.
Contrast, target size and alternative text
Light gray text on white looks nice and is unreadable for many people. WCAG requires a minimum contrast of 4.5:1 for normal text (level AA). Clickable targets must have enough area (around 44×44px) for people with limited motor precision or using touch. And every image that carries information needs a descriptive alt; purely decorative images get alt="" so they are ignored. Keeping target size and not triggering layout reloads also helps rendering and general usability.
Screen readers and WCAG levels
A screen reader reads the page aloud, moving through the accessibility tree — which is why order and labels matter so much. The WCAG guidelines define three conformance levels:
| Level | What it covers |
|---|---|
| A | Essential minimum (e.g., keyboard works) |
| AA | Practical target for most projects (4.5:1 contrast) |
| AAA | Strictest, not always feasible for everything |
In practice, aim for AA — it's the standard required by most laws and contracts.
The best way to test accessibility is to put the mouse away: navigate your screen using only Tab and Enter. If you can't reach or activate something, nobody who depends on the keyboard can either.
Conclusion
Accessibility starts with semantic HTML, uses ARIA only when native elements aren't enough, ensures keyboard navigation with visible, managed focus, and respects contrast, target size and alternative text. Aim for WCAG level AA. It's not extra work at the end of the project: it's making the front end do what it has always been meant to do — work for all people.