O perigo da propriedade CSS list-style-type: none para listas acessíveis na web
Tags: liststyletype, acessibilidade, css, html
Published: 2023-03-31 01:02:15

## A propriedade CSS list-style-type: none remove os bullet points das listas, mas também remove o significado semântico delas. Veja como corrigir isso.
 
---
 
Se usar `list-style-type: none` para remover um marcador de lista, faça também uma dessas opções:
 
- Adicione o atributo `role="list"` no elemento de lista
- Adicione `li::before { content: "/200B" }` no item de lista
 
Isso serve para a lista não perder o significado semântico no leitor de tela VoiceOver no Safari.
 
A exceção a isso são listas dentro da tag `<nav>`.

---
 
Você já usou `list-style-type: none` para remover um marcador de lista?
 
Legal, mas e a acessibilidade, como ficou?
 
Hoje vou te contar:
 
- O impacto disso na árvore de acessibilidade
- Duas formas simples de corrigir
- A importância do CSS para a acessibilidade
- A discussão em torno da decisão da Apple
 
Vem!
 
## Por que usar list style type none?
 
Para remover o marcador de listas não textuais.
 
Não são apenas os textos que usam as tags de lista (como você vê muito ao longo dos meus posts), mas também para outras coisas. Menus de navegação e até grids de produtos em um ecommerce são feitos assim.
 
![o menu principal no site da nike feito com tags de lista](https://www.datocms-assets.com/64896/1680100374-menu-li.png)
 
![o grid de produtos no site da farmrio feito com tags de lista](https://www.datocms-assets.com/64896/1680100383-grid-li.png)
 
E para remover o marcador de lista, se usa o `list-style-type: none`.
 
Caso contrário, esses menus e grids ficariam assim:
 
![o menu principal no site da nike com marcadores de lista](https://www.datocms-assets.com/64896/1680100397-menu-li-marcador.png)
 
![o grid de produtos no site da farmrio com marcadores de lista](https://www.datocms-assets.com/64896/1680100402-grid-li-marcador.png)
 
Mas por que é preciso ter cuidado com essa propriedade?
 
## Qual o problema de usar list style type none?
 
Acessibilidade com o leitor de tela VoiceOver no Safari.
 
Quando um leitor de tela encontra uma tag `<ul>` ou `<ol>`, ele envia mensagens com as seguintes informações:
 
- Encontrou uma lista
- A quantidade de `<li>`s dessa lista
- Cada um dos itens de forma individual
- E o fim dela
 
Uma pessoa usuária que usa leitor de tela pode pular uma lista inteira caso deseje.
 
**O problema é que a propriedade `list-style-type: none` remove a semântica de lista dessas tags. Assim, o VoiceOver não sabe mais que aquilo é uma lista (é como se virasse uma `<div>`),  e obriga a pessoa a ouvir todos os itens.**
 
Ao remover o marcador, essa tag perde a *aparência de lista*. E a Apple entende que ela não deve ser considerada uma lista, caso não se pareça com uma. Não importa se as pessoas usuárias enxergam ou usam leitores de tela.
 
Já falei que isso acontece apenas no VoiceOver com o Safari. Mesmo assim, a Apple não vê isso como um bug, e sim uma feature (costumo dizer essa frase no trabalho).
 
Segundo ela, como se usa lista com frequência, os leitores de tela avisavam *início da lista* e *fim da lista* muitas vezes. Um incômodo. Ao remover a semântica de listas daquelas com list-style-type: none, esses anúncios frequentes pararam.
 
Você pode acompanhar a [explicação completa nessa thread de James Craig](https://twitter.com/cookiecrook/status/1337227792069533697).
 
Em função desse problema, você deve parar de usar essa propriedade? Claro que não!
 
## Como resolver a acessibilidade do list style type none?
 
Existem duas formas de fazer isso: via HTML ou via CSS.
 
### Via HTML: use o atributo role="list"
 
Se você fizer uma pesquisa, escontrará essa solução na maioria dos lugares:
 
```html
<ul role="list">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Não é bug</li>
</ul>
```

.

```css
ul {
  list-style-type: none;
}
```
 
Caso você não conheça, o atributo `role="list"` define a [semântica de lista para qualquer elemento HTML](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/list_role).
 
Não é preciso usar `role="listitem"` para devolver o significado semântico das `<li>`s.
 
James Craig comenta sobre o [role="list" nesse tweet](https://twitter.com/cookiecrook/status/1337228205942456321).
 
---
 
Apesar dessa solução ser o suficiente, acredito que a próxima faz mais sentido. Eu explico o porquê.
 
### Via CSS: adicione um pseudo-elemento antes de cada `<li>`
 
O pseudo-elemento não pode ser vazio ou um espaço em branco:
 
```css
li::before {
  /* errado */
  content: "";
  content: " ";
  
  /* certo */
  content: "g";
  content: "+";
}
```
 
![uma lista em html que utiliza o sinal de "+" como um marcador para devolver a semântica de lista](https://www.datocms-assets.com/64896/1680100421-before-content.png)
 
E por que eu considero isso melhor, se preciso inserir algo indesejado nas listas? Porque existe um truque muito simples.
 
Na propriedade `content`, use o símbolo HTML **zero width space**. Esse símbolo é algo válido, porém invisível. Seu código é `\200B`:
 
```css
ul {
  /* remove o marcador e a semântica */
  list-style-type: none;
}

li::before {
  /* devolve a semântica apenas */
  content: "\200B";
}
```
 
![uma lista em html que utiliza o símbolo html zero width space como um marcador para devolver a semântica de lista](https://www.datocms-assets.com/64896/1680100434-before-content-zero.png)
 
Assim, a lista recebe a semântica de volta.
 
Não se esqueça de que o pseudo-elemento deve vir antes (`::before`) e não depois (`::after`) da `<li>`.
 
### Motivos para eu preferir a solução via CSS
 
Acredito que essa seja a melhor opção por alguns motivos.
 
O primeiro é que **ela evita a repetição da semântica**. [Segundo a W3C, é desnecessário e não recomendado que um elemento HTML use um atributo para declarar a mesma semântica que ele já possui de forma nativa](https://www.w3.org/TR/using-aria/#rule1https:/www.w3.org/TR/using-aria/#rule1). Ou seja, a tag `<ul>` não precisa de `role="list"`, assim como a tag `<button>` não deve precisar de `role="button"`.
 
Logo, os verificadores automáticos irão acusar semântica duplicada nesses elementos.
 
O segundo motivo é que **a solução via HTML gera mais código**, quanto mais listas, mais código. Com CSS, infinitas listas exigem apenas 1 linha para corrigir a semântica.
 
O terceiro motivo é que **basta eu fazer isso uma vez**. No HTML eu preciso lembrar de escrever `role="list"` para cada lista.
 
O quarto motivo é a **manutenção de código**. Ao ver um bloco de CSS com `list-style-type: none`, não é preciso ir atrás de todos as listas do HTML para saber se possuem `role=list`. Basta ver se o mesmo bloco de CSS insere o pseudo-elemento.
 
O quinto motivo é que em certas situações, você front-end, não terá acesso ao HTML de uma página (estranho, eu sei). Isso é muito comum com a página de checkout de alguns ecommerces. Então **você só terá acesso ao CSS para resolver o problema**.
 
O sexto e último motivo (meio bobinho, mas vamos lá) é **resolver o problema com CSS, já que ele mesmo o causou**.
 
Independente de você adotar a solução via HTML ou CSS, existe uma exceção. Nesse caso, você não precisa fazer nada.
 
## Exceção ao list style type none
 
A tag `<nav>`.
 
Tudo que você leu até aqui já é uma questão bem específica. Ou seja, acontece apenas com o leitor de tela VoiceOver no navegador Safari.
 
Agora você verá a exceção da exceção. **A semântica não é removida, caso a lista seja um elemento filho de uma tag `<nav>`**.
 
```html
<nav>
  <!--
    Esta <ul> mantém seu significado semântivo
    caso tenha a propriedade list-style-type: none;
  -->
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
  </ul>
</nav>
```
 
No exemplo acima, caso não houvesse uma tag `<nav>` ao redor da `<ul>`, sim, a semântica seria removida.
 
Acredito que apresentei soluções bem completas, porém...
 
## Nem todo mundo gosta dessas soluções
 
Como disse antes, a Apple não considera esse caso do VoiceOver no Safari um bug. Ela fez isso para que as pessoas usuárias de leitores de tela não ouvissem infinitos anúncios de listas.
 
Eu concordo com a Apple (você ouvirá eu falar pouco isso), um **elemento deve se parecer com o que ele é**. Se algo não se parece com uma lista, não deve ser uma lista, independente da pessoa usuária usar ou não leitor de tela.
 
O problema é que para a Apple os marcadores são *a única maneira* de fazer algo se parecer como uma lista. Nisso eu discordo.
 
Como ela usa uma propriedade CSS para remover a semântica de lista, é coerente que ela devolva a semântica usando CSS. Nesse caso, o `content: "\200B"`. Mais um motivo para eu preferir essa opção.
 
Independente da minha opinião, ou de toda discussão que isso gerou, de uma coisa eu tenho certeza. E é dessa coisa que você precisa se lembrar ao terminar de ler esse texto: **o HTML não é o único responsável pela árvore de acessibilidade, pois o CSS também é**.
 
O exemplo desse artigo não é o único, ou seja, remover o significado semântico das listas com o `list-style-type: none`.
 
Isso porque aplicar `display: none` ou `visibility: hidden`, além de remover o elemento da tela, remove também da árvore de acessibilidade. Segundo [James Craig, são dezenas, se não centenas de propriedades CSS que afetam a acessibilidade](https://twitter.com/cookiecrook/status/1337228458439503872).
 
## Callback
 
A propriedade `list-style-type: none` remove o marcador de lista de tags `<ul>` e `<ol>`. Mas remove também a semântica de lista no leitor de tela VoiceOver no Safari.
 
Para resolver isso, coloque `role="list"` na tag de lista, ou insira um pseudo-elemento em cada `<li>`. Recomendo usar o `li::before { content: "/200B" }`, pois é um espaço com zero de largura.
 
Isso só acontece com o VoiceOver, no Safari e apenas se a tag de lista (`<ul>` ou `<ol>`) não for filha de uma tag `<nav>`.
 
Diferente do que algumas pessoas pensam, O CSS também é responsável pela acessibilidade, e não só o HTML.
 
Espero que goste de todo esse material que reuni. Tanto técnico e prático, quanto da discussão atrás da solução para a acessibilidade das listas.
 
Deixe seu comentário com o que você achou de tudo isso. Realizar a pesquisa para escrever esse artigo foi muito satisfatório 😄
 
Se você gostou desse assunto, signigica que considera acessibilidade um assunto muito importante. Então vou deixar mais 3 posts com esse mesmo tema, mas de outras perspecticas.
 
Nesse post falei sobre o uso do [focus em HTML, CSS e Javascript](https://demenezes.dev/posts/focus-em-elementos-html-css-javascript/). Aqui, usei alguns capítulos para falar da [acessibilidade em links e botões](https://demenezes.dev/posts/link-botao-button-html/). Por fim, outro post sobre acessibilidade, porém foquei nas [imagens sem texto alternativo](https://demenezes.dev/posts/imagem-sem-alt-text-texto-alternativo/).
 
Continue estudando:
 
- [https://developer.mozilla.org/en-US/docs/Web/CSS/list-style#accessibility_concerns](https://developer.mozilla.org/en-US/docs/Web/CSS/list-style#accessibility_concerns)
- [https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-image](https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-image)
- [https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-position](https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-position)
- [https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type](https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-type)
- [https://bugs.webkit.org/show_bug.cgi?id=170179#c1](https://bugs.webkit.org/show_bug.cgi?id=170179#c1)
- [https://twitter.com/cookiecrook/status/1337226933822603270](https://twitter.com/cookiecrook/status/1337226933822603270)
- [https://css-tricks.com/a-perfect-table-of-contents-with-html-css/#aa-applying-styles-to-the-table-of-contents](https://css-tricks.com/a-perfect-table-of-contents-with-html-css/#aa-applying-styles-to-the-table-of-contents)
- [https://css-tricks.com/newer-things-to-know-about-good-ol-html-lists/](https://css-tricks.com/newer-things-to-know-about-good-ol-html-lists/)
- [https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html](https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html)
- [https://gerardkcohen.me/writing/2017/voiceover-list-style-type.html](https://gerardkcohen.me/writing/2017/voiceover-list-style-type.html)
- [https://www.tempertemper.net/blog/accessibility-issues-when-removing-list-markers](https://www.tempertemper.net/blog/accessibility-issues-when-removing-list-markers)