Relatório Avaliação de Candidatura
BUPi - Balcão Único do Prédio

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #3 Área privada - Existem menus não estruturados como lista de opções

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.1

  O menu de navegação deve estar estruturado como uma lista de opções.

  • Ver requisito 1.1 da lista 10 aspetos

  Evidências:

  Na área pública do site BUPi, o menu em desktop e em mobile estão estruturados como lista de opções <ul><li>.

  

  Figura 1 - Menu desktop estruturado como lista de opções no HTML

  

  Figura 2 - Menu mobile estruturado como lista de opções no HTML

  

  Figura 3 - Opções no topo da página estruturadas como lista de opções no HTML

  Na Plataforma do BUPi, corresponde à área onde é necessário fazer login com autenticação.gov, as opções dos menus não estão estruturadas como lista de opções na versão desktop e na versão mobile:

  

  Figura 4 - Opções do menu desktop da área privada não estão estruturadas como lista de opções

  

  Figura 5 - Opções do menu mobile da área privada não estão estruturadas como lista de opções

  

  Figura 6 - Opções no topo da página não estão estruturadas como lista de opções

  Recomendações

  Para que a navegação seja acessível e corretamente interpretada pelas tecnologias de apoio, os elementos dos menus e submenus deverão estar todos estruturados como lista, recorrendo aos elementos <ul> e <li>. Essa estrutura informa o número de opções, assim como a posição das opções na lista (exemplo: 1 de 2).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #60 Área privada - Menu não acessível por teclado e sem feedback de estado (expandido/colapsado)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:

  Na área privada (Plataforma), onde é necessário fazer login com autenticação gov, não é possível aceder às opções do menu que surgem após pressionar o botão com as iniciais quando se navega com o teclado.

  

  Figura 1 - Área privada - Botão com avatar que contém iniciais do utilizador está estruturado apenas como <div> com um <span>

  Recomendações:

  Estruturar o botão das iniciais da área privada como <button>.

  Esse botão deve ser focável e incluir os atributos aria-haspopup, aria-expanded (para a informação sobre expandido e colapsado) e aria-controls. A navegação por teclado deve suportar setas, Tab e Escape. Ao fechar o menu, o foco deve voltar ao botão de avatar.

  Uma vez que o botão apenas contém as iniciais, para comunicar a função do botão, podem recorrer ao atributo aria-label="Menu do perfil AC".

• evidência: issue #4 Área pública - Menu não acessível por teclado e sem feedback de estado (expandido/colapsado)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:

  É possível navegar pelas opções do menu e submenu na área pública do site do BUPi, tanto na versão mobile como na versão desktop, mas existem dois problemas:

  1. No menu em versão desktop, a navegação por teclado e com leitor de ecrã apresenta um comportamento incorreto: ao aceder às subopções de um item, o foco fica retido nessas subopções, impedindo o regresso à opção principal através da navegação padrão por teclado. Na prática, o menu comporta-se como uma janela modal (pop-up), sendo necessário utilizar a tecla Escape para devolver o foco ao item principal.

  

  Figura 1 - Foco do teclado fica preso dentro das subopções do menu num loop

  2. O leitor de ecrã não comunica se as opções e subopções estão expandidas ou colapsadas, apenas diz que existe um Submenu.

  

  Figura 2 - Área pública - Leitor de ecrã não comunica que a opção do menu está colapsada

  Recomendações:

  • Construir o menu de navegação de forma a garantir um comportamento verdadeiramente interativo, característico de um menu, em vez de funcionar como um pop-up que isola o restante conteúdo. A implementação deve seguir as diretrizes do Ágora Design System, assegurando uma interação consistente e acessível. Nomeadamente, deve permitir regressar ao item principal ao navegar para trás com Shift + Tab, bem como avançar para o item principal seguinte após percorrer todas as respetivas subopções.

  • Adicionar o atributo aria-expanded às opções do menu da área pública, como está estruturado no Ágora Design Systems, com o valor aria-expanded="true" para quando o botão está expandido e o valor aria-expanded="false" para quando está recolhido. O mesmo deve ser aplicado ao botão do menu da área privada.

  

  Figura 3 - Ágora Design Systems tem o atributo aria-expanded nas opções do menu que comunica o estado de recolhido ou expandido

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #5 Área privada - O texto alternativo da imagem-link não é claro o suficiente

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.3

  As imagem-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto.

  • Ver requisito 1.3 da lista 10 aspetos

  Evidências:

  O leitor de ecrã lê o botão das iniciais como "AC", não dando contexto suficiente sobre ser um menu de perfil que contém subopções.

  

  Figura 1 - O botão do menu apenas contém o <span> com as iniciais AC

  Recomendações:

  No botão das iniciais/perfil, uma vez que contém apenas as iniciais, para comunicar a função do botão, podem recorrer ao atributo aria-label="Menu do perfil AC".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #63 Área privada - O <h1> não está corretamente atribuído na página inicial e páginas interiores

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

  Existe um título <h1> marcado na página.

  • Ver requisito 2.1 da lista 10 aspetos

  Evidências:

  Na área privada, existem páginas sem <h1> e que começam a hierarquia com <h5>, como acontece nas páginas Identificar terreno e Consultar processos.

  

  Figura 1 -Hierarquia de títulos da página "Identificar terreno" começa com título <h5>.

  Existem páginas, cujo título principal visível da página é demasiado genérico para compreender o objetivo da página, como acontece na página com o título "Pesquisa" no separador do browser e "Hoje é um excelente dia para pesquisar" no corpo da página.

  

  Figura 2 - Página com título genérico "Hoje é um excelente dia para pesquisar".

  Recomendações:

  • Na homepage, o <h1> deve estar atribuído ao logótipo para, em conjunto com um texto alternativo correto, melhorar o SEO da página.

    • Neste caso, o <h1> da página inicial deve estar atribuído à imagem do logótipo que tem o texto visível BUPi - Balcão Único do Prédio.
    • A imagem do logótipo tem como texto alternativo o title do link: title="A minha área". A informação do title pode não ser interpretada corretamente por todas tecnologias de apoio, pelo que recomendamos optarem pela construção igual à área pública, como elemento <img> que contém o svg e atribuir o alt="A minha área do BUPi - Balcão Único do Prédito". Desta forma, reflete o conteúdo da imagem, mas distingue também da área pública.

  • Nas páginas interiores, o <h1> deve estar atribuído ao título VISÍVEL do conteúdo principal dessa página.
    O <h1> deve ser claro, descritivo e refletir o propósito da página. Deve também ser coerente com o rótulo da ligação que conduz até ela. Por exemplo, o card “Identificar terreno” encaminha para uma página com o título “Hoje é um excelente dia para pesquisar”, o que não é consistente. Recomenda-se ajustar o título para “Identificar terreno”, garantindo alinhamento e melhorando a previsibilidade da navegação.

• evidência: issue #6 Área púbica - O <h1> não está corretamente atribuído na página inicial e páginas interiores

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

  Existe um título <h1> marcado na página.

  • Ver requisito 2.1 da lista 10 aspetos

  Evidencias:
  O elemento <h1> da página inicial está atualmente associado ao texto “Protege o seu terreno”, o que não é suficientemente descritivo nem permite identificar claramente o propósito da página inicial.

  

  Figura 1 - Na página inicial, o <h1> está atribuído a um texto genérico "Proteger o seu terreno é simples...".

  Nas páginas interiores do site, existem páginas sem <h1> marcado, como acontece nas páginas de Notícias sobre Adesão dos Açores ao BUPi.

  

  Figura 2- Hierarquia de títulos sem <h1> da página "Adesão dos Açores ao BUPi".

  Outras páginas com o mesmo problema são:

  • https://bupi.gov.pt/pt/indicators
  • https://bupi.gov.pt/pt/noticia/adesao-acores-bupi
  • https://bupi.gov.pt/pt/noticia/ebupi-disponibiliza-visualizador-pblico
  • https://bupi.gov.pt/pt/noticia/emigrante-chama
  • https://bupi.gov.pt/pt/noticia/mitigacao-incendios
  • https://bupi.gov.pt/pt/noticia/nova-plataforma-viseu
  • https://bupi.gov.pt/pt/noticia/novo-coordenador-adjunto-ebupi
  • https://bupi.gov.pt/pt/noticia/novo-visualizador-bupi

  Além disso, existem páginas interiores com o <h1> atribuído a um texto visualmente escondido e um <h2> atribuído ao título visível da página. Esse título escondido e o visível são iguais e ambos são anunciados pelo leitor de ecrã.

  Este comportamento acontece em páginas como Como funciona, Passo a Passo, Municípios aderentes,, Documentação, Plataforma e App, e nas restantes páginas ligadas ao menu que devem também rever.

  

  Figura 3 - <h1> está atribuído a um texto visualmente escondido

  Para utilizadores de leitores de ecrã, que frequentemente navegam diretamente até ao primeiro cabeçalho para compreenderem em que página se encontram, esta abordagem de páginas sem <h1> , ou com <h1> e <h2> com o mesmo texto, dificulta a orientação.

  Existem também páginas com vários <h1>, como acontece na página Documentação.

  

  Figura 4 - Hierarquia com vários h1 na página Documentação

  Recomendações:

  • Na homepage, o <h1> deve estar atribuído ao logótipo para, em conjunto com um texto alternativo correto, melhorar o SEO da página.
    • Neste caso, o <h1> da página inicial deve estar atribuído à imagem do logótipo, que tem o texto visível BUPi - Balcão Único do Prédio.
    • A imagem do logótipo tem o alt="Logotipo BUPi, não estando correto. Devem remover a palavra "logótipo" do alt porque não acrescenta informação ao título e garantir que o texto alternativo é alt="BUPi - Balcão Único do Prédio".
  • O texto "Proteger o seu terreno é simples. E não custa nada" deve ser estruturado como <h2>.
  • Nas páginas interiores, o <h1> deve estar atribuído ao título VISÍVEL do conteúdo principal dessa página. O título escondido deve ser removido.
  • Estas alterações devem ser aplicadas na versão portuguesa e inglesa do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #62 Área privada - Há saltos na hierarquia de títulos

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.2

  Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
  – ver requisito 2.2 na lista 10 aspetos

  Evidências:

  Na área privada, na página "Identificar terreno", não existe nenhum título visível a identificar a página do formulário, ao não ser o texto genérico "Hoje é um excelente dia para pesquisar", que começa com <h5>, sem haver hierarquia anterior.

  

  Figura 1 -Hierarquia de títulos da página "Identificar terreno" começa com título <h5>.

  Recomendações:

  Devem rever todas páginas do site (homepage e interiores) para garantir que respeitam a hierarquia de títulos e subtítulos, o que implica:

  • Ter 1 título <h1> (que marca o texto que representa o título da página ou, no caso da Homepage, o logo da entidade);
  • Ter as várias secções do documento marcadas com <h2>;
  • Ter as várias subseções de <h2> marcadas com <h3>, as subsecções destas com <h4> e assim hierarquicamente encadeados até <h6>;
  • Evitar ter elementos de hierarquia inferior sem um elemento de hierarquia imediatamente superior (subseções órfãs). Por exemplo, ter um <h3> sem a correspondente <h2>, ou <h4> sem a correspondente <h3>.

• evidência: issue #7 Área pública - Há saltos na hierarquia de títulos

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.2

  Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
  – ver requisito 2.2 na lista 10 aspetos

  Evidências:

  Na área pública, na página inicial, na secção "Quem pode ajudar", existe um salto hierarquia de <h2> para <h4>. Para utilizadores que navegam com o leitor de ecrã pelos cabeçalhos, esse salto de hierarquia deixa o conteúdo descontextualizado.

  

  Figura 1 - Secção "Quem pode ajudar" com conteúdo marcado com <h4>

  

  Figura 2 - Hierarquia de títulos da secção "Pesquisa" e secção "Quem pode ajudar" mostram saltos de hierarquia

  Recomendações:

  Devem rever todas páginas do site (homepage e interiores) para garantir que respeitam a hierarquia de títulos e subtítulos, o que implica:

  • Ter 1 título <h1> (que marca o texto que representa o título da página ou, no caso da Homepage, o logo da entidade);
  • Ter as várias secções do documento marcadas com <h2>;
  • Ter as várias subseções de <h2> marcadas com <h3>, as subsecções destas com <h4> e assim hierarquicamente encadeados até <h6>;
  • Evitar ter elementos de hierarquia inferior sem um elemento de hierarquia imediatamente superior (subseções órfãs). Por exemplo, ter um <h3> sem a correspondente <h2>, ou <h4> sem a correspondente <h3>.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #8 O site do BUPi não apresenta tabelas na área pública e privada

  etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 3.1

  As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th>.
  – ver requisito 3.1 na lista 10 aspetos

  Evidências:

  O site do BUPi não apresenta tabelas.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #9 O site do BUPi não apresenta tabelas na área pública e privada

  etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 3.2

  A legenda da tabela está marcada com o elemento <caption>
  – ver requisito 3.2 na lista 10 aspetos

  Evidências:

  O site do BUPi não apresenta tabelas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #67 Área privada - Existem caixas de verificação não envolvidos em elementos <fieldset>

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

  Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
  – ver requisito 4.1 na lista 10 aspetos

  Os grupos de checkboxes do formulário na página Pesquisa não estão envolvidos em elementos <fieldset>.

  

  Figura 1 - Etiqueta aplicada incorretamente ao grupo de checkboxes

  As checkboxes “Rústico” e “Urbano” são respostas possíveis à legenda “*Natureza da matriz". No entanto, essa associação não existe semanticamente e o leitor de ecrã lê cada checkbox como sendo 1 de 1, em vez de 1 de 2.

  Recomendações:

  Devem rever todos os formulários deste tipo, para que os radiobuttons sejam colocados dentro de um elemento <fieldset>, elemento esse que deve ter como primeiro filho um elemento <legend> contendo o texto “Natureza da matriz”, da seguinte forma:

  <fieldset>
    <legend>*Natureza da matriz</legend>
    <input id = " rchk1 " type = "checkbox">
    <label for = "chk11">Rústico</label>
    <input id = "chk2" type = "checkbox">
    <label for = "chk2">Urbano</label>
  </fieldset>
  

• evidência: issue #66 Área pública - Existem caixas de verificação não envolvidos em elementos <fieldset>

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

  Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
  – ver requisito 4.1 na lista 10 aspetos

  Evidências:

  Os grupos de checkboxes do formulário na página Formulário de Registo não estão envolvidos em elementos <fieldset>:

  

  Figura 1 - Etiqueta aplicada incorretamente ao grupo de checkboxes

  As checkboxes “Município”, “Vários Municípios - CIM” e “Entidades gestores” são respostas possíveis à legenda “Inscrição Município ou CIM”. No entanto, essa associação não existe semanticamente.

  Recomendações:

  Devem rever todos os formulários deste tipo, para que os radiobuttons sejam colocados dentro de um elemento <fieldset>, elemento esse que deve ter como primeiro filho um elemento <legend> contendo o texto “*Inscrição Município ou CM:”, da seguinte forma:

  <fieldset>
    <legend>*Inscrição Município ou CIM</legend>
    <input id = " rchk1 " type = "checkbox">
    <label for = "chk11">Município</label>
    <input id = "chk2" type = "checkbox">
    <label for = "chk2">Vários municípios - CIM</label>
    <input id = "chk3" type = "checkbox">
    <label for = "chk3">Entidades gestoras</label>
  ....
  </fieldset>
  

• evidência: issue #64 Área privada - Campos de edição sem label associada

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

  Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
  – ver requisito 4.1 na lista 10 aspetos

  Evidências:

  Na área privada, na página Identificar terreno, por exemplo, existem campos com labels visíveis que não estão associadas aos respetivos campos.

  

  Figura 1 - A label do campo Número da Matriz não está associada ao campo

  Recomendações:

  Devem garantir que todos os campos de edição da privada, dropdowns, pesquisa, date pickers, são estruturados como e com uma . O for da <label> deve ter o mesmo valor que o id do <input>, para que o leitor de ecrã consiga comunicar a informação da label do campo quando foca no componente, assim como o cursor surgir no respectivo campo de edição quando se clica na etiqueta.

• evidência: issue #10 Área pública - Campos de edição sem label visível e sem label associada

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

  Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
  – ver requisito 4.1 na lista 10 aspetos

  Evidências:

  Na área pública, existem campos de edição que não têm label, como é o caso do campo da pesquisa no topo da página do site.

  

  Figura 1 - Campo de pesquisa no topo da página não tem label

  O mesmo acontece com o campo da pesquisa da página Notícias e Artigos, do Glossário e com o campo do email na página inicial para subscrever a newsletter.

  

  Figura 2 - Campo de pesquisa da página Notícias e Artigos

  

  Figura 3 - Campo para subscrever newsletter na página inicial

  Além disso, existem campos de input com labels inseridos dentro de labels, fazendo com que o leitor de ecrã repita a label duas vezes.

  

  Figura 4 - HTML apresenta campo de input e a label asssociada inseridos dentro de uma label

  

  Figura 5 - Leitor de ecrã lê a label 2 vezes.

  Recomendações:

  Devem garantir que todos os campos de edição da área pública, dropdowns, pesquisa, date pickers, são estruturados como e com uma . O for da <label> deve ter o mesmo valor que o id do <input>, para que o leitor de ecrã consiga comunicar a informação da label do campo quando foca no componente, assim como o cursor surgir no respectivo campo de edição quando se clica na etiqueta.

  Evitar labels redundantes, uma vez que o leitor de ecrã lê a label associada ao campo, não sendo necessário criar uma label "sr-only".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #65 Área privada - Não há informação sobre o significado dos asteriscos nos campos de preenchimento obrigatório

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

  É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã.
  – ver requisito 4.2 na lista 10 aspetos

  Evidências:

  Os campos dos formulários que existem no site, como os campos na página apresentam um asterisco de cor vermelha na suas labels, no entanto, não é apresentada nenhuma definição do significado dos asteriscos no fundo ou no início do formulário.

  

  Figura 1 - Campos do formulário de Pesquisa com asterisco vermelho

  Embora os campos tenham o atributo required na construção HTML e transmitem a informação para pessoas que navegam com leitor de ecrã, a mesma informação não é imediatamente clara para quem depende da visão.

  Recomendações:

  Devem rever todos os formulários do site para que tenham o significado do asterisco.

  Os campos obrigatórios dos formulários devem estar devidamente identificados como tal.

  Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. No entanto,pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado, preferencialmente, no início do formulário (exemplo: * Preenchimento obrigatório).

• evidência: issue #11 Área pública - Não há informação sobre o significado dos asteriscos nos campos de preenchimento obrigatório

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

  É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã.
  – ver requisito 4.2 na lista 10 aspetos

  Evidências:

  Os campos dos formulários que existem no site, como os campos na página formulário de registo e Contactos apresentam um asterisco de cor vermelha na suas labels, no entanto, não é apresentada nenhuma definição do significado dos asteriscos no fundo ou no início do formulário.

  

  Figura 1 - Campos do formulário de Registo com asterisco vermelho

  Embora os campos tenham o atributo required na construção HTML e transmitem a informação para pessoas que navegam com leitor de ecrã, a mesma informação não é imediatamente clara para quem depende da visão.

  Recomendações:

  Devem rever todos os formulários do site para que tenham o significado do asterisco.

  Os campos obrigatórios dos formulários devem estar devidamente identificados como tal.

  Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. No entanto,pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado, preferencialmente, no início do formulário (exemplo: * Preenchimento obrigatório).

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #12 A mensagem de erro está perto do campo mas não está associada no código

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 4.3

  É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã.
  – ver requisito 4.3 na lista 10 aspetos

  Evidencias:
  As mensagens de erro que surgem durante o preenchimento de um formulário devem estar associadas aos respectivos campos. Idealmente, as mensagens devem estar posicionadas próximas dos campos a que dizem respeito, o que se verifica.

  No entanto, quando se navega apenas com a tecla Tab pelos campos do formulário, a informação do erro não é comunicada, sendo necessário navegar pelos elementos um a um até chegar especificamente à mensagem de erro.

  

  Figura 1 - Leitor de ecrã quando está focado no campo do formulário de Contactos não lê a mensagem de erro

  Recomendações:
  Deve-se aplicar o atributo aria-describedby="" para que as mensagens de erro fiquem associadas aos respectivos campos e que essa associação seja detectada pelos leitores de ecrã.

  Podem identificar a boa prática implementada no formulário de Pesquisa da área privada, no erro de NIF inválido.

  

  Figura 2 - Mensagem do NIF inválido está associada ao campo através do atributo aria-describedby

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #69 Área pública - Imagens decorativas com texto alternativo errado

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 5.1

  A imagem ou gráfico tem um equivalente em texto curto e correto.
  – ver requisito 5.1 na lista 10 aspetos

  Evidências:

  Existem imagens decorativas com texto alternativo a descrever o seu conteúdo. Por exemplo, na página Sobre Nós, existem várias imagens decorativas no meio do conteúdo, como da "Vista aérea dos terrenos" e do "Boneco BUPi com a bandeira".

  

  Figura 1 - Imagens decorativas do conteúdo com texto alternativo

  Na secção das notícias na página inicial, e em várias páginas secundárias, existem cards que contêm imagens. Essas imagens acabam por acrescentar informação repetida ou redundante do link, não acrescentando informação, sendo decorativas.

  

  Figura 2 - As imagens decorativas dos cards com texto alternativo

  

  Figura 3 - As imagens laterais decorativas com texto alternativo.

  Recomendações:

  Recomendamos a revisão das imagens decorativas para que incluam um texto alternativo nulo da seguinte forma: <img…alt=””>. Se a estrutura não for um <img>, optar pelo atributo aria-hidden="true". Em alternativa, estas podem ser colocadas em CSS como background-image.

• evidência: issue #68 Área privada - Imagens funcionais com texto alternativo errado

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.1

  A imagem ou gráfico tem um equivalente em texto curto e correto.
  – ver requisito 5.1 na lista 10 aspetos

  Evidências:

  Recomendações:

• evidência: issue #13 Área pública - Imagem funcional com texto alternativo errado e sem texto alternativo

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.1

  A imagem ou gráfico tem um equivalente em texto curto e correto.
  – ver requisito 5.1 na lista 10 aspetos

  Evidências:

  Na página inicial, o logótipo tem um alt="Logótipo BUPi".

  

  Figura 1 - Imagem funcional com texto alternativo a incluir termo "Logótipo".

  No Mapa Público, existem imagens das formas dos cadastros com texto alternativo errado e são lidas pelo leitor de ecrãs apenas como "Pré-visualizar.

  

  Figura 2 - Texto alternativo da forma dos cadastros

  Recomendações:

  • Deve evitar-se a utilização do termo “logótipo” no texto alternativo, uma vez que essa informação não acrescenta valor para utilizadores de tecnologias de apoio. O texto alternativo deve descrever de forma concisa e significativa o conteúdo da imagem funcional. Por exemplo, em vez de “logótipo do BUPi”, deve optar-se por "BUPi - Balcão Único do Prédio”.

  • Devem garantir que a forma dos cadastro é descrita no texto alternativo da imagem. Por exemplo, no caso do Cadastro Predial, teria de ser estruturado como aria-label="área com fundo amarelo".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #14 O mapa e os gráficos Power BI têm alguma informação que não é possível aceder com teclado e leitor de ecrã

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.2

  O gráfico é acompanhado de uma descrição longa.
  – ver requisito 5.2 na lista 10 aspetos

  Evidências:

  A página Indicadores e do Mapa Público apresentam gráficos complexos que necessitam de informação para pessoas que navegam com leitor de ecrã possam compreender.

  

  Figura 1 - Gráficos da página Indicadores

  

  Figura 2 - Mapa Público

  

  _Figura 3 - A forma dos cadastro é apenas comunicada pelo leitor de ecrã como Pré-visualizar _

  Recomendações:

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #70 Área privada - Imagens-link sem texto alternativo ou com termos redundantes

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

  As imagens-link têm um equivalente alternativo correto.
  – ver requisito 5.3 na lista 10 aspetos

  Evidências:

  Na página inicial e interiores, o logótipo tem o atributo title="A minha área" que advém do title do link. O leitor de ecrã NVDA lê essa informação, mas existem leitores de ecrã que podem não ler.

  

  Figura 1 - Logótipo com texto alternativo que deriva do title do link.

  No rodapé das páginas da área privada, existem vários logótipos das entidades com o termo "logótipo" no seu alt, mas também acrescentam a informação "que redireciona para o site oficial".

  

  Figura 2 - Logótipos do rodapé da área privada do BUPi

  Recomendações:

  • A informação do title pode não ser interpretada corretamente por todas tecnologias de apoio, pelo que recomendamos optarem pela construção igual à área pública, como elemento (que contém o svg) e atribuir o alt="A minha área do BUPi - Balcão Único do Prédito". Desta forma, reflete o conteúdo da imagem, mas distingue também da área pública.

  • Deve evitar-se a utilização do termo “logótipo” no texto alternativo, uma vez que essa informação não acrescenta valor para utilizadores de tecnologias de apoio. O texto alternativo deve descrever de forma concisa e significativa o conteúdo e a função da imagem. Por exemplo, em vez de “logótipo da empresa”, deve optar-se por “Nome da empresa” ou, caso relevante, incluir o propósito do elemento:

    • “alt="Página inicial da minha área do BUPi - Balcão Único do Prédio” no logótipo das páginas interiores, uma vez que é um link para a página inicial`.
    • alt="INR", alt="Autoridade Tributária", etc., são suficientes, pois a função de link da imagem já está implícita, ou seja, entende-se que a imagem encaminha para a página correspondente (por exemplo, a da Autoridade Tributária).

• evidência: issue #15 Área pública - Imagens-links sem texto alternativo ou com texto alternativo redundante, pouco claro ou em inglês

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

  As imagens-link têm um equivalente alternativo correto.
  – ver requisito 5.3 na lista 10 aspetos

  Evidências:

  Nas páginas interiores do site, como, por exemplo, Municípios Aderentes, o logótipo tem o texto alternativo "Logótipo BUPi", não descrevendo totalmente a função da imagem.

  

  Figura 1 - Logótipo das páginas interiores do site

  No rodapé das páginas, existem vários logótipos das entidades com o termo "logótipo" no seu alt.

  

  Figura 2 - Logótipos das entidades parceiras no rodapé

  Na secção "Porque devo identificar e registar o meu terreno?" da página inicial, os botões da galeria estão em inglês, não sendo compreensível quando se navega com o leitor de ecrã na versão portuguesa do site.

  

  Figura 3 - Leitor de ecrã lê os botões da seta como "Move Left" e "Move Right"

  Os botões das setas do calendário da página Notícias e Artigos são apenas lido como "Botão, Botão, Botão", não distinguindo a função de cada um deles porque o atributo aria-label encontra-se vazio.

  

  Figura 4 - Leitor de ecrã lê os botões das setas apenas como "Botão"

  Na página do mapa, existem botões que são apenas imagem, mas o seu alt está vazio, como se fosse uma imagem decorativo. No entanto, é uma imagem funcional, cujo alt deve descrever a função do botão, que neste caso é ir para a página inicial do site do BUPi.

  

  Figura 5 - Botão com imagem sem texto alternativo

  Recomendações:

  • Deve evitar-se a utilização do termo “logótipo” no texto alternativo, uma vez que essa informação não acrescenta valor para utilizadores de tecnologias de apoio. O texto alternativo deve descrever de forma concisa e significativa o conteúdo e a função da imagem. Por exemplo, em vez de “logótipo da empresa”, deve optar-se por “Nome da empresa” ou, caso relevante, incluir o propósito do elemento:

    • “alt="Página inicial do BUPi - Balcão Único do Prédio” no logótipo das páginas interiores, uma vez que é um link para a página inicial`). Na página inicial ficaria apenas "BUPI - Balcão Único do Prédio". A mesma lógica deve ser aplicada ao GeoPortal do BUPi, cujo logótipo deve ter o texto alternativo "GeoPortal do BUPi" na página inicial.
    • “alt="INR Institutos dos Registos e do Notoriado” , “alt="Autoridade Tributária” , etc.

  • O texto alternativo das imagens-links deve estar em português quando o utilizador está na versão portuguesa do site. Por isso, o texto alternativo de botões como "Move Left" devem ser alterados para português, por exemplo, alt="Ir para a esquerda" e alt="Ir para a direita".

  • Adicionar texto alternativo a botões, como os do calendário, para se perceber a função dos mesmos. Por exemplo, aria-label="Avançar mês", aria-label="Avançar ano", aria-label="Retroceder mês", aria-label="Retroceder ano".

  • Adicionar texto alternativo ao botão do mapa, como, por exemplo, alt="Página inicial do BUPI - Balcão Único do Prédio".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #16 O rácio de contraste entre a cor do texto normal e a cor de fundo é inferior a 4,5:1

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 6.1

  No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1.
  – ver requisito 6.1 na lista 10 aspetos

  Evidências:

  Na página do Mapa Público, o título da página tem um rácio de contraste inferior a 4,5:1.

  

  Figura 1 - Título da página branca sob fundo branco

  

  Figura 2 - Rácio de contraste de 4,37:1

  Recomendações:

  O contraste no texto normal (menor que 18 pontos ou menor que 14 pontos negrito) das páginas deve ser, no mínimo 4,5:1, para que pessoas com baixa visão consigam ler o texto.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #73 Área privada - Não é possível reconhecer a semântica do botão do perfil

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
  – ver requisito 8.3 na lista 10 aspetos

  Evidências:

  Quando os estilos da página inicial da área privada são removidos, o botão dp perfil e outros elementos interativos (botões de acesso aos formulários) deixam de responder, tornando impossível clicar, interagir ou aceder às informações disponíveis.

  

  Figura 1 - Página inicial da área privada sem estilos CSS

  

  Figura 2 - Página inicial da área privada com estilos CSS

  Recomendações:

  Devem estruturar os botões e cards como elementos <button> em HTML, garantindo que mantêm a semântica adequada e continuam funcionais mesmo na ausência de estilos. No caso do botão do menu que possuo subopções, podem consultar a referência Menu Button da W3C.

• evidência: issue #22 Área pública - Não é possível reconhecer a semântica das tabs

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
  – ver requisito 8.3 na lista 10 aspetos

  Evidências:

  Na página Documentação, existem quatro separadores (tabs) que podem ser selecionados com o rato. No entanto, estes elementos estão implementados com <div>, o que lhes retira o significado semântico de componentes interativos. Como consequência, não é possível navegar entre os separadores utilizando o teclado nem aceder ao seu conteúdo através de leitores de ecrã.

  

  Figura 1 - Tabs da página Documentação sem estilos CSS

  

  Figura 2 - Tabs da página Documentação com estilos CSS

  Recomendações:

  Devem rever todas as tabs com essa construção e estruturá-las como <div> que contém o atributo aria role="tablist", que por sua vez contém botões com atributo role="tab". Como referência, podem consultar a página Example of Tabs da W3C.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #72 A modal dos cookies não é considerada como exemplo de caixa de diálogo

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.1

  Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo
  – ver requisito 9.1 na lista 10 aspetos

  Evidências:

  Um exemplo de modal implementada para ser avaliada neste contexto é a caixa de cookies.

  No entanto, no HTML da página, esta encontra-se posicionada após o rodapé, sendo apenas alcançada pelo leitor de ecrã depois da navegação por todo o conteúdo da página. Deve estar posicionada no topo do código HTML.

  Recomendações:

  No site da Compete2030, é possível consultarem o exemplo da modal de cookies, que é o primeiro elemento a receber o foco, que fica restrito à modal até o utilizador selecionar uma das opções (ex: Sim, aceito).

  

  Figura 1 - Caixa de cookies

  Além disso, devem corrigir a evidência destes 4 critérios relacionado com caixas de diálogo para que tenham o exemplo da modal, não a área da Pesquisa.

• evidência: issue #25 A interação da área da Pesquisa está incorretamente estruturada como uma modal

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.1

  Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo
  – ver requisito 9.1 na lista 10 aspetos

  Evidências:

  Apresentaram como evidência de modal a área da caixa da pesquisa.

  No site do BUPi, a Pesquisa foi implementada como uma modal. Quando o utilizador navega com teclado e leitor de ecrã para dentro da modal, o foco fica corretamente restrito aos seus elementos, não sendo possível sair com a tecla Tab, apenas com Escape. Ao pressionar Escape, o foco regressa ao elemento que abriu a modal.

  

  Figura 1 - Modal da Pesquisa

  Recomendações:

  O botão de Pesquisa deve seguir as recomendações do Design System do Ágora - Header Navigation Fiver or Less Links.

  Ao navegar por teclado, ao passar do último link da pesquisa para o próximo item do menu principal, a área de pesquisa deve fechar automaticamente. O foco não deve ficar retido.

  A área da Pesquisa deve comportar-se como um item de navegação, e o botão deve ser acessível por teclado em todos os estados (colapsado e expandido). Atualmente, quando o botão muda para “× Pesquisar” (fechar), não é possível alcançá-lo via teclado, impedindo o utilizador de encerrar a pesquisa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #26 A interação da área da Pesquisa está incorretamente estruturada como uma modal

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.2

  Quando uma caixa de diálogo está aberta, a navegação com teclado (Browser ou Tecnologia de apoio) tem de ficar circunscrita aos elementos que compõem a caixa de diálogo
  – ver requisito 9.2 na lista 10 aspetos

  Evidências:

  Apresentaram como evidência de modal a área da caixa da pesquisa.

  No site do BUPi, a Pesquisa foi implementada como uma modal. Quando o utilizador navega com teclado e leitor de ecrã para dentro da modal, o foco fica corretamente restrito aos seus elementos, não sendo possível sair com a tecla Tab, apenas com Escape. Ao pressionar Escape, o foco regressa ao elemento que abriu a modal.

  

  Figura 1 - Modal da Pesquisa

  Recomendações:

  O botão de Pesquisa deve seguir as recomendações do Design System do Ágora - Header Navigation Fiver or Less Links.

  Ao navegar por teclado, ao passar do último link da pesquisa para o próximo item do menu principal, a área de pesquisa deve fechar automaticamente. O foco não deve ficar retido.

  A área da Pesquisa deve comportar-se como um item de navegação, e o botão deve ser acessível por teclado em todos os estados (colapsado e expandido). Atualmente, quando o botão muda para “× Pesquisar” (fechar), não é possível alcançá-lo via teclado, impedindo o utilizador de encerrar a pesquisa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #27 A interação da área da Pesquisa está incorretamente estruturada como uma modal

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.3

  A caixa de diálogo tem de ter um mecanismo que permita sair ou fechar a caixa, quer através de teclado quer através de um dispositivo apontador
  – ver requisito 9.3 na lista 10 aspetos

  Evidências:

  Apresentaram como evidência de modal a área da caixa da pesquisa.

  No site do BUPi, a Pesquisa foi implementada como uma modal. Quando o utilizador navega com teclado e leitor de ecrã para dentro da modal, o foco fica corretamente restrito aos seus elementos, não sendo possível sair com a tecla Tab, apenas com Escape. Ao pressionar Escape, o foco regressa ao elemento que abriu a modal.

  

  Figura 1 - Modal da Pesquisa

  Recomendações:

  O botão de Pesquisa deve seguir as recomendações do Design System do Ágora - Header Navigation Fiver or Less Links.

  Ao navegar por teclado, ao passar do último link da pesquisa para o próximo item do menu principal, a área de pesquisa deve fechar automaticamente. O foco não deve ficar retido.

  A área da Pesquisa deve comportar-se como um item de navegação, e o botão deve ser acessível por teclado em todos os estados (colapsado e expandido). Atualmente, quando o botão muda para “× Pesquisar” (fechar), não é possível alcançá-lo via teclado, impedindo o utilizador de encerrar a pesquisa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #28 A interação da área da Pesquisa está incorretamente estruturada como uma modal

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.4

  Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou
  – ver requisito 9.4 na lista 10 aspetos

  Evidências:

  Apresentaram como evidência de modal a área da caixa da pesquisa.

  No site do BUPi, a Pesquisa foi implementada como uma modal. Quando o utilizador navega com teclado e leitor de ecrã para dentro da modal, o foco fica corretamente restrito aos seus elementos, não sendo possível sair com a tecla Tab, apenas com Escape. Ao pressionar Escape, o foco regressa ao elemento que abriu a modal.

  

  Figura 1 - Modal da Pesquisa

  Recomendações:

  O botão de Pesquisa deve seguir as recomendações do Design System do Ágora - Header Navigation Fiver or Less Links.

  Ao navegar por teclado, ao passar do último link da pesquisa para o próximo item do menu principal, a área de pesquisa deve fechar automaticamente. O foco não deve ficar retido.

  A área da Pesquisa deve comportar-se como um item de navegação, e o botão deve ser acessível por teclado em todos os estados (colapsado e expandido). Atualmente, quando o botão muda para “× Pesquisar” (fechar), não é possível alcançá-lo via teclado, impedindo o utilizador de encerrar a pesquisa.

  Um exemplo de modal correto a considerar neste critério é a caixa de cookies.

  

  Figura 2 - Caixa de cookies

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #30 Existe uma descrição do propósito do site, mas não está imediatamente visível quando se entra na página inicial

  etiqueta: NOKetiqueta: R 1.1etiqueta: chk conteúdo

  O sítio Web apresenta um resumo breve do seu propósito, visível sem fazer scroll.
  – ver requisito 1.1 na lista Conteúdo

  Evidências:
  Verificou-se que existe uma descrição do propósito do site, mas não está imediatamente visível quando se entra na página inicial, sendo necessário fazer scroll down. A informação "Proteger o seu terreno é simples..." não é suficiente para descrever o propósito do site.

  

  Figura 1 - Página inicial, com conteúdo "above the fold" mas que não apresenta o propósito do site.

  Recomendações:
  Na Homepage deve existir uma breve descrição do propósito do website que demonstre que tarefas é possível realizar no mesmo. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no carrossel, entre outros, como se verifica no exemplo do site acessibilidade.gov.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 Há blocos de conteúdo sem data de atualização

  etiqueta: NOKetiqueta: R 1.3etiqueta: chk conteúdo

  Cada bloco de conteúdo contém a sua data de atualização.
  – ver requisito 1.3 na lista Conteúdo

  Evidências:

  Na página individual de cada Notícia, não é apresentada a data de atualização, apenas a data de publicação.

  

  Figura 1 - Notícia na página inicial

  Existem mais conteúdos sem data de atualização, estando apenas presente em alguns blocos informativos com percentagem.

  Recomendações:

  Aplicar o mesmo texto de data de atualização que existe na secção "O que já alcançámos" na página inicial.

  

  Figura 2 - Indicadores da página inicial com data de atualização

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #34 Evidência errada na checklist

  etiqueta: melhoriaetiqueta: chk conteúdoetiqueta: R 2.1

  O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos.
  – ver requisito 2.1 na lista Conteúdo

  Evidências:

  Nas evidências da checklist, referiram que o tamanho mais pequeno de letra de corpo utilizado no site é de 14px e apresentaram uma imagem de informação secundária com 14 px, correspondente ao critério 2.2 da lista de conteúdo.

  

  Figura 1 - Evidência errada

  Recomendações:

  Devem apresentar evidência do conteúdo principal, ou seja, do texto da notícia, ou das secções da página inicial, que no mínimo têm 16px, correspondente a 12 pontos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #36 Blocos e linhas de texto com largura superior a 100 caracteres

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.3

  Blocos e linhas de texto com largura não superior a 100 caracteres.
  – ver requisito 2.3 na lista Conteúdo

  Evidências:

  Os blocos e linhas de texto nem sempre têm sempre largura inferior a 100 caracteres, como se pode ver na página Emigrante Chama

  

  Figura 1 - Linhas de texto da página Emigrante Chama com 140 caracteres

  Recomendações:

  Para assegurar uma boa leitura, as linhas de texto devem ter até 80 caracteres (incluindo espaços). No limite, podem ir até aos 100 caracteres (incluindo espaços).

  Recomenda-se que seja definida uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades em ou rem) para garantir que não é ultrapassado o número máximo de caracteres por linha.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #44 Existem elementos interativos com dimensão mínima abaixo de 44px CSS vertical e horizontal.

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.2

  Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos), vertical e horizontal.
  – ver requisito 5.2 na lista Conteúdo

  Evidências:

  No rodapé da área pública existem botões das redes sociais com dimensões 24x25, e o mesmo acontece na área privada.

  

  Figura 1 - Botões das redes sociais do rodapé da área pública

  Na secção "Como posso identificar e registar o meu terreno", os botões tem altura inferior a 44px.

  

  Figura 2 - Cards com botões

  Recomendações:

  Devem garantir que os elementos interativos têm uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone/imagem tenha um tamanho inferior.

  Alguns exemplos de elementos interativos corretos na página inicial da área pública são os seguintes:

  

  Figura 3 - Botão da secção Algoritmo do futuro

  

  Figura 4 - Card principal da secção Notícias da página inicial com altura e largura a partir de 44px.

  

  Figura 5 - Card das notícias com altura e largura a partir de 44px

  Devem corrigir também a evidência que colocaram na checklist.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #47 A sequência de tabulação não segue a sequência de preenchimento.

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 1.1

  A sequência de tabulação entre campos segue a sequência de preenchimento.
  – ver requisito 1.1 na lista Transação

  Evidências:

  No formulário da página inicial, para subscrever a newsletter verificou-se que a ordem de tabulação não corresponde à ordem de preenchimento dos campos: Escrever o email > Dar consentimento > Carregar no botão "Subscrever"

  

  Figura 1 - Formulário de subscrição de newsletter

  Recomendações:

  Ao navegar pelo formulário com o teclado usando a tecla TAB, a sequência de tabulação deve seguir a ordem de preenchimento. Ou seja, quando o campo do email está preenchido, a ordem devem manter-se Escrever o email > Dar consentimento > Carregar no botão "Subscrever".

  Idealmente a o botão "Subscrever" devia estar fora do campo, abaixo da checkbox de consentimento.

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #48 Evidência de checklist errada

  etiqueta: melhoriaetiqueta: chk transaçãoetiqueta: R 1.2

  Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
  – ver requisito 1.2 na lista Transação

  Evidências:
  Na checklist, classificaram este critério como Não Aplicável e colocaram formulários da área pública como evidência.

  No entanto, na área privada, o formulário de Pesquisa está distribuído por várias páginas.

  

  Figura 1 - Formulário de pesquisar terreno da área privada

  Recomendações:
  Colocar a avaliação do critério como OK e colocar o formulário da área privada como evidência.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #75 Todos os separadores de passo têm o estado lido como "Selecionado" pelo leitor de ecrã

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 1.3

  Os formulários com mais de uma página têm a sequência de passos ilustrada.
  – ver requisito 1.3 na lista Transação

  Evidências:

  Ao navegar com um leitor de ecrã pelos diferentes passos do separador situado acima do formulário, é anunciado que todos os passos se encontram selecionados, não sendo feita qualquer distinção entre os passos ativos e os inativos. Desta forma, o utilizador terá dificuldade em compreender em que passo do formulário se encontra.

  

  Figura 1 - Separador de passos inativo lido como "Selecionado" pelo leitor de ecrã".

  Todos os passos têm role="tab" e tabindex="0", mas nenhum tem aria-selected definido. Os leitores de ecrã anunciam tabs sem aria-selected="false" como se estivessem todas ativas. O atributo aria-selected é o estado esperado para elementos com role="tab". Os leitores de ecrã anunciam automaticamente "selecionado" ou "não selecionado" com base neste atributo.

  Além disso, aria-current="step" está em todos os <div> filho (label), não no elemento com role="tab".

  Recomendações:

  • Adicionar aria-selected="true" no passo ativo, aria-selected="false" nos restantes
  • Adicionar aria-disabled="true" nos passos ainda não acessíveis
  • Remover aria-current="step" do elemento filho. É redundante face ao aria-selected e está no sítio errado.

• evidência: issue #49 Evidência da checklist errada

  etiqueta: melhoriaetiqueta: chk transaçãoetiqueta: R 1.3

  Os formulários com mais de uma página têm a sequência de passos ilustrada.
  – ver requisito 1.3 na lista Transação

  Evidências:
  Na checklist, classificaram este critério como Não Aplicável e colocaram formulários da área pública como evidência.

  No entanto, na área privada, o formulário de Pesquisa está distribuído por várias páginas.

  

  Figura 1 - Formulário de pesquisar terreno da área privada

  Recomendações:
  Colocar a avaliação do critério como OK e colocar o formulário da área privada como evidência.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #76 Área privada - Não há informação sobre o significado dos asteriscos nos campos de preenchimento obrigatório

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 2.4

  Campos obrigatórios devem ser claramente indicados como tal.
  – ver requisito 2.4 na lista Transação

  Evidências:

  Os campos dos formulários que existem no site, como os campos na página apresentam um asterisco de cor vermelha na suas labels, no entanto, não é apresentada nenhuma definição do significado dos asteriscos no fundo ou no início do formulário.

  

  Figura 1 - Campos do formulário de Pesquisa com asterisco vermelho

  Embora os campos tenham o atributo required na construção HTML e transmitem a informação para pessoas que navegam com leitor de ecrã, a mesma informação não é imediatamente clara para quem depende da visão.

  Recomendações:

  Devem rever todos os formulários do site para que tenham o significado do asterisco.

  Os campos obrigatórios dos formulários devem estar devidamente identificados como tal.

  Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. No entanto,pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado, preferencialmente, no início do formulário (exemplo: * Preenchimento obrigatório).

• evidência: issue #53 Área pública - Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 2.4

  Campos obrigatórios devem ser claramente indicados como tal.
  – ver requisito 2.4 na lista Transação

  Evidências:

  Os campos dos formulários que existem no site, como os campos na página formulário de registo e Contactos apresentam um asterisco de cor vermelha na suas labels, no entanto, não é apresentada nenhuma definição do significado dos asteriscos no fundo ou no início do formulário.

  

  Figura 1 - Campos do formulário de Registo com asterisco vermelho

  Embora os campos tenham o atributo required na construção HTML e transmitem a informação para pessoas que navegam com leitor de ecrã, a mesma informação não é imediatamente clara para quem depende da visão.

  Recomendações:

  Devem rever todos os formulários do site para que tenham o significado do asterisco.

  Os campos obrigatórios dos formulários devem estar devidamente identificados como tal.

  Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. No entanto,pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado, preferencialmente, no início do formulário (exemplo: * Preenchimento obrigatório).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #54 Não existem ações longas

  etiqueta: chk transaçãoetiqueta: N/Aetiqueta: R 3.1

  Em ações longas, o sistema deve indicar o que está a acontecer.
  – ver requisito 3.1 na lista Transação

  Evidências:

  O sítio não contém ações transicionais longas.

  Quando a página demora a carregar, optam por progressive loading.

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #55 O leitor de ecrã não anuncia o sucesso ou erro do envio de informações automaticamente

  etiqueta: melhoriaetiqueta: chk transaçãoetiqueta: R 3.2

  Deve ser confirmado o sucesso da transação/envio de informação.
  – ver requisito 3.2 na lista Transação

  Evidências:

  É sempre apresentada uma mensagem de confirmação ao utilizador após a submissão do formulário. No entanto, o leitor de ecrã não comunica essa informação automaticamente, sendo necessário o utilizador navegar até ao fundo do formulário manualmente para compreender que a informação foi enviada.

  

  Figura 1 - Mensagem de envio com sucesso do Formulário de registo

  Recomendações:

  Rever todos os formulários da área pública e privada, incluindo o formulário da newsletter na página inicial e da pesquisa no topo da página, para que as mensagens de sucesso, erro ou resultados não encontrados sejam lidos automaticamente pelo leitor de ecrã.

  Existem várias abordagens para resolver este problema de acessibilidade, sendo a utilização de regiões aria-live (a mais comum) uma das mais eficazes. Esta pode ser complementada com a gestão programática do foco, através da definição de tabindex="-1" na mensagem, permitindo que o foco seja deslocado automaticamente para o conteúdo relevante após a submissão.

  O objetivo é disponibilizar no DOM um contentor com aria-live previamente definido, antes da mensagem ser apresentada. Quando o seu conteúdo é atualizado, o leitor de ecrã anuncia automaticamente essa alteração.

  Podem optar por:

  • aria-live="polite": a mensagem é anunciada quando o utilizador fizer uma pausa na interação. É a opção recomendada para mensagens de confirmação ou informação não crítica.
  • aria-live="assertive": a mensagem é anunciada de imediato, interrompendo a leitura em curso. Deve ser utilizado apenas em situações críticas, como erros importantes ou falhas no sistema.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #57 Não existem ações destrutivas nos formulários

  etiqueta: chk transaçãoetiqueta: N/Aetiqueta: R 4.2

  As ações destrutivas nunca devem ser permanentes, deve ser sempre possível desfazer a operação.
  – ver requisito 4.2 na lista Transação

  Evidências:
  Nos formulários não existe situações "destrutivas" depois de submeter por exemplo não se pode cancelar, o que foi submetido.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #58 O leitor de ecrã não lê as mensagens de erro quando foca nos campos

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 4.3

  As mensagens de erro são claramente identificadas junto aos campos de origem.
  – ver requisito 4.3 na lista Transação

  Evidências:

  Quando se navega apenas com a tecla Tab pelos campos do formulário, a informação do erro não é comunicada, sendo necessário navegar pelos elementos um a um até chegar especificamente à mensagem de erro.

  

  Figura 1 - Leitor de ecrã quando está focado no campo do formulário de Contactos não lê a mensagem de erro

  Recomendações:

  Os campos dos formulários devem devolver mensagens de erros relativas ao problema encontrado em cada campo, que devem ser identificadas visualmente e pelo leitor de ecrã.

  Deve-se aplicar o atributo aria-describedby="" para que as mensagens de erro fiquem associadas aos respectivos campos e que essa associação seja detectada pelos leitores de ecrã.

  Podem identificar a boa prática implementada no formulário de Pesquisa da área privada, no erro de NIF inválido.

  

  Figura 2 - Mensagem do NIF inválido está associada ao campo através do atributo aria-describedby

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #74 Ausência de indicador de foco de teclado

  etiqueta: NOKetiqueta: outras violações

  Evidências

  Ao navegar na interface utilizando apenas o teclado, não é possível identificar visualmente qual elemento está em foco. A ausência de um indicador de foco (focus state) dificulta a navegação, especialmente para utilizadores que dependem do teclado ou de tecnologias assistivas, comprometendo a acessibilidade e a usabilidade da aplicação.

  Recomendações

  Deve ser implementado um estilo visível para o estado de foco dos elementos interativos (como :focus e :focus-visible em CSS). Este indicador deve ser claramente distinguível (por exemplo, outline, sombra ou alteração de cor) e consistente em toda a interface, garantindo que o utilizador consegue identificar facilmente o elemento atualmente selecionado durante a navegação por teclado.