Dilemas da cibersegurança: Fugas de dados
A corrida pré-natalícia está ao rubro. Em busca de presentes para os seus entes queridos, as pessoas estão cada vez mais dispostas a "invadir" as lojas em linha
A Web é utilizada por milhões de pessoas todos os dias e um dos nossos principais objectivos enquanto programadores é tornar a Web acessível a todos. Este artigo apresenta alguns problemas comuns de acessibilidade da Web e formas de os resolver.
O problema de acessibilidade mais comum que tenho visto ao longo dos anos é a problema de contraste e acessibilidade de coresUma má relação de contraste dificultará a visualização do conteúdo da sua página, o que será muito prejudicial para os seus utilizadores, incluindo os que têm deficiências visuais.
O contraste é uma medida da diferença na perceção da "luminância" ou brilho entre duas cores, por exemplo, é a diferença entre a cor de fundo e a cor de primeiro plano do conteúdo da sua página. Vejamos esta barra de navegação.

Digamos que o seu cliente gosta mesmo daquela cor esverdeada e a acha espetacular, mas há aqui um problema de contraste. Temos um #FFFFFF fundo com um #83A94C cor do texto, resultando numa relação de contraste de 2,71:1, que é muito inferior ao mínimo 4.5:1 necessário. Para detetar este problema, temos várias soluções:

Para obter mais informações sobre o contraste, consulte Artigo sobre acessibilidade ao contraste e à cor.
Atualmente, as hiperligações são uma grande parte da Web, pelo que é muito importante torná-las acessíveis. Uma hiperligação tem de fazer sentido e informar o utilizador do seu contexto, pelo que uma hiperligação pouco informativa com texto como "leia mais", "clique aqui", "verifique os detalhes" não é muito útil. produto Por exemplo, é melhor e mais informativo utilizar o nome do produto, como "O capacete Mandaloriano". Palavras como clique aqui ou mais sobre pode ser omitido porque uma ligação é clicável por defeito e algo como "mais sobre as notícias de hoje" pode ser encurtado para "notícias de hoje". Não há nenhuma regra especial ou limite sobre o comprimento da ligação, o a ligação tem de ser legível e suficientemente longo para descrever bem o seu objetivo.
As imagens como hiperligações são um padrão muito utilizado, pelo que têm de seguir as mesmas regras de que falámos acima. O atributo alt da imagem desempenhará o papel de texto da ligação e será anunciado pelos leitores de ecrã. Existem vários cenários para o tratamento de imagens como hiperligações: se a imagem for o único conteúdo da hiperligação, tem de ter um atributo alt; se a hiperligação tiver algum texto e imagem, podemos omitir o atributo alt:
<a href="/notifications">
<img src="/img/notification.png" alt="Notificações">
</a>
Veja algumas ligações aqui para ler sobre a acessibilidade das ligações:Texto e aspeto da ligação, Imagens funcionais.

Todos nós já vimos estas entradas de formulário sem etiqueta e apenas com um marcador de posição para descrever o objetivo da entrada. Uma primeira nota é que, assim que o utilizador preencher todas as entradas e os marcadores de posição deixarem de estar à vista, não teremos qualquer contexto visual sobre o objetivo das entradas, mas vamos nós centrar-se na acessibilidade.
Associar um etiqueta a uma entrada dá-nos duas grandes vantagens: um leitor de ecrã lerá a etiqueta quando o utilizador estiver concentrado na entrada do formulário e, quando uma etiqueta é clicada ou tocada/tocada, o browser passa o foco para a entrada associada. Uma solução fácil para este tipo de situação é simplesmente adicionar etiquetas da seguinte forma:
Nome próprio
Apelido
Correio eletrónico
Enviar
```
É isso, todos os inputs têm as suas etiquetas associadas, tornando-os acessíveis a toda a gente. Podemos até remover os marcadores de posição para evitar duplicar o objetivo da entrada, mas todos sabemos que os cenários do mundo real não são assim tão fáceis de resolver, acabámos de receber um desenho que tem estas entradas de formulário sem etiquetas e o cliente não quer alterar essa parte. A primeira solução que vem à mente é aplicar um apresentação: nenhum; ou visibilidade: oculta; às nossas etiquetas, isto irá escondê-las, mas elas continuam lá, certo? Estas propriedades ocultam elementos não só no ecrã, mas também para os utilizadores de leitores de ecrã, pelo que não resolvem o nosso problema.
Podemos utilizar o padrão de clipe para resolver este problema. Desta forma, ocultamos o conteúdo visualmente, mas fornecemos o conteúdo aos leitores de ecrã. Vamos criar o seguinte CSS apenas sr e aplicá-la em todas as nossas etiquetas:
.sr-only:not(:focus):not(:active) {
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
posição: absoluta;
white-space: nowrap;
largura: 1px;
}
Isto irá ocultar as nossas etiquetas, torná-las disponíveis para os leitores de ecrã e corresponder ao nosso design. O :not(:focus):not(:active) pseudo-classe impede que elementos focalizáveis, tais como a, botão, entrada de ficarem ocultos quando estão a ser focados.
Em tempos, fiz isto na minha folha de estilos CSS global:
* {
outline: none; /* erro horrível */
}
Por volta de 2020, reparei que apareciam contornos pretos nos formulários do Google Chrome quando estavam focados ou nos botões quando se entrava no separador - foi muito estranho, porque não percebi na altura. Depois de alguma pesquisa, descobri que isso se devia à propriedade CSS de contorno, pelo que a remoção resolveu esse "problema".
Nessa altura, não fazia ideia de qual era a forma correta de o fazer. Depois de fazer alguma investigação sobre os porquês e os comos dessa nova predefinição, descobri que o contorno é um indicador de foco do elemento e que, se for removido, deve ser fornecido um estilo de foco óbvio. Pode personalizar os indicadores de foco como achar melhor, mas removê-los completamente do sítio Web é um grande problema de acessibilidade. Personalizar o estilo de foco de um elemento é bastante fácil, por exemplo:
a:focus {
outline: 4px solid #ee7834;
outline-offset: 4px;
}
Verificar todas as questões de que falámos pode dar muito trabalho, especialmente sabendo que há muito mais coisas a tratar sobre acessibilidade, por isso, para nos ajudar a lidar com a acessibilidade, temos duas excelentes extensões para o browser.
Ferramenta de avaliação WAVE é um conjunto de ferramentas de avaliação que nos ajuda a tornar o nosso conteúdo Web mais acessível. Está disponível no Google Chrome e no Firefox.
Vamos experimentá-la numa pequena página Web que contém uma barra de navegação e um input sem etiqueta e ver o que nos dá. Depois de instalar a extensão, basta clicar no ícone da extensão para a utilizar.

O separador Resumo mostra 1 erro (elemento de formulário sem etiqueta), 2 erros de contraste e 1 alerta (estrutura de cabeçalho em falta). O separador Detalhes apresenta uma lista de todos os erros, alertas e caraterísticas. Também podemos interagir diretamente na página, clicando nos rectângulos vermelhos para verificar a descrição e o tipo de erro.
Axe DevTools é um conjunto de ferramentas de acessibilidade poderoso e preciso. Está disponível no Google Chrome e no Firefox. Depois de instalar a extensão, temos de abrir as ferramentas de desenvolvimento do browser e ir para o separador axe DevTools e clicar em Verificar todas as minhas páginas.

Pode ver que a Axe DevTools comunicou os mesmos problemas com a ferramenta de avaliação WAVE, nomeadamente problemas de contraste, elementos de formulário sem etiqueta e elementos de cabeçalho em falta.
Uma forma adicional de testar a acessibilidade é utilizar um leitor de ecrã e testar o seu sítio Web com ele. Existem muitos leitores de ecrã disponíveis, para citar apenas alguns:
Vimos neste artigo alguns problemas comuns de acessibilidade da Web, formas de os resolver e algumas ferramentas excelentes para testar a acessibilidade da Web. Ainda há muito mais a abordar sobre a acessibilidade de elementos como Diálogos, Acordeões e Carrosséis, mas, como viu neste artigo, existe muita documentação e ferramentas para o ajudar a lidar com a acessibilidade.
Alguns pontos-chave a ter em conta:
