Relatório Avaliação da Candidatura da SNS 24

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#7 As subopções do menu estão estruturadas fora da lista principal

  etiqueta: chk 10 webetiqueta: R 1.1etiqueta: NOK

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

  • Ver requisito 1.1 da lista 10 aspetos

  Observa-se que as subopções associadas a “Serviços” são estruturadas no HTML depois das opções de primeiro nível. Embora o foco do leitor seja conduzido para as subopções, ao regressar um nível acima o utilizador fica sem contexto da navegação do menu, sendo redirecionado para “Canais SNS24” em vez de “Serviços”.

  

  Subopções de "Serviços" estão sendo estruturadas fora da lista do menu

  Recomendamos que as subopções sejam apresentadas no HTML dentro da lista, integradas na respetiva opção de primeiro nível (Serviços), conforme o exemplo abaixo:

  <ul>
    <li class="has-submenu"><a href="…" aria-expanded="false">Space Bears</a>
      <ul>
        <li><a href="…">Space Bear 6</a></li>
        <li><a href="…">Space Bear 6 Plus</a></li>
      </ul>
    </li> 
  </ul>
  

• evidência: issue#6 As opções do menu não estão estruturadas como lista

  etiqueta: chk 10 webetiqueta: R 1.1etiqueta: NOK

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

  • Ver requisito 1.1 da lista 10 aspetos

  Verifica-se que nas opções do menu principal está sendo utilizado o atributo role=”menu” na lista ul. O uso de atributos ARIA, como o role="menu", faz com que as tecnologias de apoio identifiquem o elemento como um widget de menu, em vez de uma lista não ordenada, perdendo a sua semântica de lista. Para além disso, o atributo deve ser utilizado em conjunto com outras propriedades, como o role="menuitem" que não estão inseridos.

  

  Lista não ordenada sendo atribuída como “role=menu” e a tag li

  Recomendamos remover os atributos relacionados com a construção de um menu de aplicação, como por exemplo, o role="menu" e role="menuitem" para garantir que o menu funcione corretamente, sendo estruturado como uma lista de opções ul li.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#8 Não é possível identificar quais opções contém subopções no menu

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

  É 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

  A opção “Serviços” contém subopções, no entanto essa informação não está a ser transmitida aos leitores de ecrã. Atualmente, o leitor de ecrã anuncia a opção como “Serviços keyboard_arrow_down, botão, 1 de 4”.

  Para além de o texto alternativo do botão não ser adequado, não é comunicada a informação relativa ao estado do botão, ou seja, se a opção se encontra fechada (colapsado) ou aberta (expandido).

  

  Leitor de ecrã não informa que a opção "Serviços" está fechada

  Recomendamos utilizarem o atributo ARIA “aria-expanded” para as tecnologias de apoio identificarem que existem subopções e quando o menu está colapsado (aria-expanded=”false”) ou expandido (aria-expanded=”true”).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#9 Não existem imagens-link no menu

  etiqueta: R 1.3etiqueta: chk 10 webetiqueta: N/A

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

  • Ver requisito 1.3 da lista 10 aspetos

  Verifica-se que não são apresentadas imagens-link no menu. Por esse motivo, o critério é considerado como "Não aplicável":

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#11 O texto alternativo do logótipo está incorreto

  etiqueta: chk 10 webetiqueta: R 2.1etiqueta: NOK

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

  • Ver requisito 2.1 da lista 10 aspetos

  Verifica-se, na página inicial do SNS 24, que o texto alternativo do logótipo se encontra definido como “Logo SNS 24”. O termo “Logo” não acrescenta informação relevante para o utilizador, gerando ruídos e conteúdos desnecessários.

  

  Logótipo do website com o termo "Logo"

  Recomendamos remover o termo "Logo" do texto alternativo.

• evidência: issue#10 Cabeçalho h1 não está visível na homepage pelo iPhone

  etiqueta: chk 10 webetiqueta: R 2.1etiqueta: NOK

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

  • Ver requisito 2.1 da lista 10 aspetos

  Verifica-se, na página inicial do SNS 24, que o cabeçalho h1 não está visível para o leitor de ecrã Voice Over, quando se navega com o iPhone no Safari. O leitor de ecrã Voice Over "salta" do menu para o campo de pesquisa, o logotipo não é visível na versão iOS 26.2.1:

  

  Recomendamos a revisão do cabeçalho h1 da homepage, de forma a garantir que este se encontra devidamente visível e acessível para leitores de ecrã no iPhone. Uma das possíveis razões para o VoiceOver no iPhone estar a ignorar o h1 poderá estar relacionada também com a utilização do atributo CSS overflow: clip, isso poderá ser analisado em mais detalhes pela equipa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#12 Existem títulos que não estão sendo atribuídos como cabeçalhos

  etiqueta: chk 10 webetiqueta: R 2.2etiqueta: NOK

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

  Na página inicial do SNS 24 existem secções que não estão lhe sendo atribuídos cabeçalhos. Como por exemplo, a secção dos canais do SNS 24 não possui um cabeçalho h2:

  

  A secção seguinte, apesar de apresentar o título “Serviços digitais SNS 24”, ela não se encontra estruturada como um cabeçalho h2:

  

  Na secção seguinte, são apresentadas informações sobre a app do SNS 24. No entanto, a página não dispõe de um cabeçalho h2 que identifique o conteúdo:

  

  Na página inicial do SNS 24, recomendamos que:

  • O título “Serviços digitais SNS 24” deve ser estruturado como cabeçalho h2.
  • A secção de “Canais SNS 24” deverá ser atribuído um título h2, como por exemplo, “Canais SNS 24”. Esse título poderá estar visível apenas para as tecnologias de apoio e deverá estar posicionado antes do link linha no HTML. Para mais informações podem consultar o artigo CSS em Ação: Conteúdo Invisível apenas para Utilizadores de Leitor de Ecrã da acessibilidade.gov
  • Na secção da app, deverá ser atribuído um título h2, como por exemplo “Aplicação SNS 24”. Esse título poderá estar visível apenas para as tecnologias de apoio e estruturado antes do título “A sua saúde mais digital” no HTML. Para mais informações podem consultar o artigo CSS em Ação: Conteúdo Invisível apenas para Utilizadores de Leitor de Ecrã da acessibilidade.gov.

  ---

  Verifica-se que em outras páginas do website existe apenas o cabeçalho h1 sendo que existe conteúdo para que seja atribuído uma sequência de cabeçalhos h2.

  Por exemplo, na página de Autodeclaração de doença, existem componentes em acordeão e uma secção lateral designada “Aceder a serviços”. No entanto, nenhuma destas estruturas se encontra devidamente estruturada com cabeçalhos h2:

  

  Na página de Autodeclaração de doença recomendamos que:

  • Os títulos dos acordeões deverão ser estruturados como cabeçalhos h2. Para isso, o botão do acordeão deverá ser estruturado dentro da tag h2 no HTML.
  • A secção “Esta informação foi útil?” deverá ser atribuído um título h2, como por exemplo, “Feedback” ou “Deixe a sua opinião”, o título poderá ou não estar visível. O próprio texto “Esta informação foi útil?” poderá ser um cabeçalho h2.
  • O texto “Aceder a serviços” deverá ser estruturado como um cabeçalho h2.

  ---

  Na página Info Saúde: Saúde de A-Z, os diferentes conteúdos encontram-se organizados por letras iniciais do alfabeto. No entanto, a página não apresenta cabeçalhos correspondentes a essas letras, o que impede o utilizador de realizar saltos por cabeçalhos:

  

  Na página Info Saúde: Saúde de A-Z recomendamos que:

  • As letras iniciais deverão ser estruturadas como cabeçalho h2.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#13 Critério declarado como "Sim", mas verifica-se que é "Não aplicável"

  etiqueta: chk 10 webetiqueta: R 3.1etiqueta: NOK

  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

  Não foi identificado tabelas no website. Quando o website não possui elementos mencionados pelo requisito, então o requisito será considerado como “Não Aplicável”. É necessário remover as evidências e alterar a checklist.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#14 Critério declarado como "Sim", mas verifica-se que é "Não aplicável"

  etiqueta: R 3.2etiqueta: chk 10 webetiqueta: NOK

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

  Não foi identificado tabelas no website. Quando o website não possui elementos mencionados pelo requisito, então o requisito será considerado como “Não Aplicável”. É necessário remover as evidências e alterar a checklist.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#16 O texto placeholder está a substituir a label

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

  O campo de pesquisa apresentado no topo do website e na página de Info saúde não possui etiqueta associada. Atualmente, existe apenas texto placeholder no campo:

  

  Recomendamos a revisão de todos os campos apresentados no website, de forma a garantir que estão corretamente associados a uma etiqueta. Para esse efeito, deverá ser utilizada a tag label, associando cada campo à respetiva etiqueta através dos atributos for e id.

• evidência: issue#15 Existem etiquetas que não estão associadas ao seu respetivo campo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

  Verifica-se que os campos dos formulários do website possuem duas estruturas sendo apresentadas no HTML: a primeira, uma estrutura apresentada visualmente, recorrendo a divs genéricas com estilos personalizados através de CSS, que não são acessíveis; e a segunda, elementos nativos, como input ou select, que permitem garantir a acessibilidade por teclado e a compatibilidade com tecnologias de apoio.

  Esta abordagem não é recomendada, uma vez que a estrutura visual construída com divs genéricas é a que está visível e a ser interagida pelas tecnologias de apoio, enquanto os elementos nativos se encontram ocultos através de CSS (display: none). Esta prática origina problemas críticos de acessibilidade, nomeadamente a navegação pelo teclado (TAB e SHIFT + TAB) e leitores de ecrã.

  No formulário de Autodeclaração de doença é possível verificar que o campo Data apresenta uma etiqueta visível. No entanto, para além de o campo estar construído de forma inadequada, essa etiqueta não se encontra corretamente associada ao respetivo campo que está visível.

  Esta situação ocorre porque embora o input oculto via CSS esteja visível para as tecnologias de apoio, o outro elemento input, que é o elemento visível e que recebe a interação do leitor de ecrã, não se encontra associado à etiqueta:

  

  Etiqueta associada ao campo pelo atributo id="birthDate" ao invés do atributo id= “birthDate_display”

  ---

  No formulário Fale Connosco, os campos de seleção “Canal”, “Assunto” e “Sub-assunto” apresentam uma etiqueta visível; no entanto, ela está associada ao campo que se encontra oculto visualmente. Esse exemplo é ainda mais crítico, uma vez que os campos nativos de seleção estão escondidos tanto visualmente como programaticamente para as tecnologias de apoio, devido à utilização da propriedade CSS display: none:

  

  Etiqueta associada ao campo pelo atributo id=" channel" do elemento nativo select que está escondido via CSS pelo display:none

  Recomendamos reverem todos os campos de formulário do website, para garantir que os campos sejam construídos com elementos nativos do HTML e eles deverão estar visíveis e interativos com o rato, teclado e leitores de ecrã. A sua apresentação no ecrã poderá ser estilizada via CSS diretamente no elemento.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#17 Não é possível identificar campos obrigatórios com o leitor de ecrã

  etiqueta: chk 10 webetiqueta: R 4.2etiqueta: NOK

  É 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

  Verifica-se que os campos dos formulários do website possuem duas estruturas sendo apresentadas no HTML: a primeira, uma estrutura apresentada visualmente, recorrendo a divs genéricas com estilos personalizados através de CSS, que não são acessíveis; e a segunda, elementos nativos, como input ou select, que permitem garantir a acessibilidade por teclado e a compatibilidade com tecnologias de apoio.

  Esta abordagem não é recomendada, uma vez que a estrutura visual construída com divs genéricas é a que está visível e a ser interagida pelas tecnologias de apoio, enquanto os elementos nativos se encontram ocultos através de CSS (display: none). Esta prática origina problemas críticos de acessibilidade, nomeadamente a navegação pelo teclado (TAB e SHIFT + TAB) e leitores de ecrã.

  No formulário Autodeclaração de doença não é possível identificar que o campo “Data de nascimento” é obrigatório. Para além da construção do campo estar inapropriado, pois está sendo utilizado um input type=”date” e um input com o role=”combobox”, o atributo required está sendo atribuído ao elemento que está sendo oculto visualmente:

  

  Atributo required está inserido no campo input type="date" que está oculto via CSS

  No formulário de Fale connosco, o leitor de ecrã não identifica os campos “Canal”, “Assunto” e “Sub-assunto” como obrigatórios. O atributo required está atribuído ao elemento nativo que está oculto via CSS:

  

  O campo de seleção que está atribuído o required é o campo nativo oculto via CSS

  Recomendamos que seja revisto os campos dos formulários para garantir a sua correta construção. Para isso, recomendamos utilizar os elementos nativos do HTML e apresentá-los diretamente no ecrã. Os campos de preenchimento devem ter o atributo required ou aria-required.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#18 Existem campos que não transmitem mensagens de erro

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

  Nos formulários de Fale connosco e Autodeclaração de doença, verifica-se a existência de campos que não apresentam qualquer mensagem de erro quando são preenchidos incorretamente ou deixados em branco.

  Por exemplo, no formulário de Fale connosco, os campos "Canal", "Assunto" e "Sub-assunto" não exibem mensagens de erro quando não são selecionados. É possível verificar também que o radio button não exibe mensagem de erro pois ele já está preenchido inicialmente:

  

  Recomenda-se a revisão de todos os campos do formulário, de modo a garantir que apresentam mensagens de erro adequadas. Para além disso, o radio button não deve iniciar já preenchido.

  ---

  No formulário de Autodeclaração de doença, o campo “Data de nascimento” não exibe qualquer mensagem de erro. A indicação de que o campo contém um problema é feita exclusivamente através da cor, o que não é recomendado:

  

  A utilização da cor pode utilizada, desde que não constitua o único meio de indicar que um campo não foi preenchido ou que se encontra incorretamente preenchido. Por esse motivo recomendamos que seja inserido uma mensagem junto ao campo e que seja acessível para as tecnologias de apoio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#20 Existem imagens decorativas com texto alternativo preenchido

  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

  Na página Outros Serviços, Existem imagens cujo texto alternativo é idêntico ao texto visível apresentado na página. Esta situação faz com que o leitor de ecrã anuncie a mesma informação em duplicado, gerando ruído desnecessário e sobrecarregando a leitura do conteúdo:

  

  Leitor de ecrã anuncia o texto “Sistema de atendimento e resposta ágil (SARA)” duas vezes no link

  Isso acontece em outras páginas do website, como por exemplo, na página Digitais e nos links de canais apresentados no rodapé do website:

  

  Leitor de ecrã anuncia o texto “Assistente de apoio à triagem telefónica” duas vezes no link

  

  Canais do SNS 24 apresentado com imagens cujo texto alternativo é igual ao texto que está visível

  Recomendamos uma revisão geral do website, de forma a garantir que as imagens cujo texto alternativo seja idêntico ao texto visível que as acompanha sejam tratadas como decorativas. Para tal, o respetivo texto alternativo deve ser definido como nulo (alt="").

• evidência: issue#19 A mesma imagem possui texto alternativo diferente em outras páginas

  etiqueta: chk 10 webetiqueta: R 5.1etiqueta: NOK

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

  A imagem da aplicação SNS 24 apresentada na página inicial e na página de Iniciar sessão é a mesma; contudo, o texto alternativo associado é diferente em cada uma das páginas:

  

  Na página inicial do website a imagem da app SNS 24 possui texto alternativo "SNS 24 app”

  

  Na página de login a mesma imagem da app SNS 24 possui texto alternativo "Publicidade da app SNS 24”

  Para garantir a consistência do website e assegurar que a mesma informação é transmitida de forma uniforme, recomenda-se que todas as imagens idênticas tenham o mesmo significado.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#21 Não existem imagens complexas no website

  etiqueta: R 5.2etiqueta: chk 10 webetiqueta: N/A

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

  Verifica-se que a area pública na qual não requer login, que não existem diagramas, fluxogramas, gráficos, mapas, etc que são considerados como imagens complexas. O critério é avaliado como "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#23 Existem imagens-link iguais com texto alternativo diferente em outras páginas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  As imagens que funcionam como links para o download da aplicação apresentam texto alternativo diferente consoante a página. Na página de Iniciar sessão, o texto alternativo indica também a ação que será realizada — neste caso, descarregar a app. Já na página inicial, essas mesmas imagens-link apresentam apenas o texto alternativo “Apple App Store”, não informando a ação que será executada:

  

  Recomendamos rever as imagens-link da página inicial para garantir que seu texto alternativo seja igual as imagens-link apresentadas na página de Iniciar sessão: “Descarregar APP na Apple Store”, “Descarregar APP na Google Play Store” e “Descarregar APP na Huawei Store”.

• evidência: issue#22 Existem imagens-link com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  No rodapé do website existem imagens-link com o termo “Logo”. Para além de gerar ruídos desnecessário, estas descrições sobrecarregam a informação sem acrescentar algo útil para o utilizador:

  

  Recomendamos que nos logotipos do rodapé o termo "logo" deve ser removido. Como as imagens-link remetem para outro website, essa informação precisa estar junto ao seu texto alternativo para complementar a informação. Por exemplo: alt="República portuguesa - Ir para website".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#24 O texto normal não tem contraste suficiente

  etiqueta: R 6.1etiqueta: chk 10 webetiqueta: NOK

  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

  Verifica-se que o texto placeholder e o texto digitado nos campos de formulários apresentados no website possuem contraste abaixo do recomendado (campo de pesquisa, Fale connosco, Autodeclaração de doença, contacto acessível para cidadão surdo e teleconsulta)

  

  Texto placeholder dos campos possuem contraste abaixo do recomendado (2,8:1) no formulário do Fale connosco

  Recomendamos rever o contraste do placeholder para garantir que tenham contraste, de no mínimo, 4,5:1.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#25 O texto grande não tem contraste suficiente

  etiqueta: chk 10 webetiqueta: R 6.2etiqueta: NOK

  O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1.
  – ver requisito 6.2 na lista 10 aspetos

  Na página inicial do SNS 24, verifica-se que, nas resoluções desktop, mobile e tablet, os textos do banner estão sobrepostos às imagens, o que faz com que o contraste fique abaixo do recomendado:

  

  Texto do banner possui contraste de 1,8:1 e está abaixo do recomendado com a imagem de fundo verde quando visto no mobile, tablet e desktop

  

  Contraste do texto “sociais” é de 1,1:1 e está ilegível com o plano de fundo branco

  Recomendamos rever os textos que são apresentados no banner para garantir que a sobreposição das imagens não prejudique o seu contraste. Para isso, devem garantir que o texto tenha, no mínimo, um contraste de 4,5:1 com a imagem de fundo nas diferentes resoluções (mobile, tablet e desktop).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#28 Não há legendas nos reprodutores de multimédia

  etiqueta: R 7.2etiqueta: chk 10 webetiqueta: NOK

  O vídeo ou áudio deve conter preferencialmente legendas fechadas sincronizadas.
  – ver requisito 7.2 na lista 10 aspetos

  No vídeo da página Nova App SNS 24 não existe legenda nem transcrição textual dos conteúdo:

  

  Vídeo sendo apresentado na plataforma vimeo e que não possui legenda ou transcrição

  Devem ser adicionadas legendas e transcrição nos reprodutores de vídeo do website, para que todas as pessoas consigam interagir com a informação desses reprodutores.

• evidência: issue#27 As legendas fornecidas pelos vídeos são automáticas

  etiqueta: R 7.2etiqueta: chk 10 webetiqueta: NOK

  O vídeo ou áudio deve conter preferencialmente legendas fechadas sincronizadas.
  – ver requisito 7.2 na lista 10 aspetos

  Na página Sobre nós é possível ligar e desligar a legenda dos vídeos, no entanto, a legenda fornecida é automática que não descreve exatamente o conteúdo do vídeo:

  

  Legenda automática do vídeo com problemas na descrição do conteúdo

  Recomendamos que seja incluído uma legenda fechada para cada vídeo e sua respetiva transcrição.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#30 A ordem de leitura programática é diferente da apresentação visual

  etiqueta: R 8.2etiqueta: chk 10 webetiqueta: NOK

  Quando se retira a CSS, a informação aparece numa ordem lógica.
  – ver requisito 8.2 na lista 10 aspetos

  Nos formulários de Contacto acessível para cidadão surdo, Teleconsulta Linha SNS 24 e Validar autodeclaração de doença, as mensagens de erro são apresentadas visualmente a seguir da respetiva etiqueta do campo. No entanto, ao nível estrutural, as mensagens de erro encontram-se posicionadas após o campo de formulário. Isso faz com que a ordem de leitura da informação por tecnologias de apoio não corresponda à ordem apresentada visualmente:

  

  No campo Email, a mensagem de erro surge a seguir à etiqueta, apesar de no HTML a sua estrutura se encontrar depois do campo no formulário de Validar autodeclaração de doença

  Recomendamos que a ordem visual deverá ser a mesma estruturada programaticamente. Por esse motivo, a mensagem de erro deve ser apresentada abaixo do campo.

  ---

  No formulário de Teleconsulta Linha SNS 24, para além de a mensagem se encontrar posicionada programaticamente de forma diferente da ordem visual, verifica-se ainda uma quebra no texto, fazendo com que parte da mensagem seja apresentada ao lado da etiqueta e a sua continuação surja abaixo do campo:

  

  Campos número de utente e código de acesso com mensagens “quebradas” que aparecem junto à etiqueta e depois do campo

  Recomendamos que a ordem visual deverá ser a mesma estruturada programaticamente. Por esse motivo, a mensagem de erro deve ser apresentada abaixo do campo. No formulário de Teleconsulta Linha SNS 24 é necessário ajustar o CSS para não existir a quebra do texto.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#81 Existem campos construídos de forma inapropriada

  etiqueta: R 8.3etiqueta: chk 10 webetiqueta: NOK

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

  Verifica-se que os campos dos formulários do website possuem duas estruturas sendo apresentadas no HTML: a primeira, uma estrutura apresentada visualmente, recorrendo a divs genéricas com estilos personalizados através de CSS, que não são acessíveis; e a segunda, elementos nativos, como input ou select, que permitem garantir a acessibilidade por teclado e a compatibilidade com tecnologias de apoio.

  Esta abordagem não é recomendada, uma vez que a estrutura visual construída com divs genéricas é a que está visível e a ser interagida pelas tecnologias de apoio, enquanto os elementos nativos se encontram ocultos através de CSS (display: none). Esta prática origina problemas críticos de acessibilidade, nomeadamente a navegação pelo teclado (TAB e SHIFT + TAB) e leitores de ecrã

  Por exemplo, no formulário Autodeclaração de doença ao desligar o CSS, é possível verificar que o campo "Data de nascimento" possui dois campos, no entanto, o que é visível é justamente o campo estruturado sem semântica, fazendo com que aconteça problemas de acessibilidade:

  

  Ao desligar CSS é possível ver o campo "Data de nascimento" com dois campos

  

  O que está visível e que permite a interação por parte do utilizador é o campo que não possui semântica apropriada

  Recomendamos que seja revisto os campos dos formulários para garantir a sua correta construção. Para isso, é necessário utilizar os elementos nativos do HTML e apresentá-los diretamente no ecrã. As issues #17 e #18 descrevem problemas causados pela construção inapropriada dos campos e que também precisam ser corrigidos.

• evidência: issue#34 Os radio buttons não possuem fieldset

  etiqueta: R 8.3etiqueta: chk 10 webetiqueta: NOK

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

  Nos formulários de Fale connosco e Autodeclaração de doença não é possível identificar que as opções de botão de rádio pertencem ao mesmo grupo quando o CSS se encontra desativado, uma vez que estas não estão agrupadas através do elemento fieldset:

  

  Recomendamos que sejam revistos todos os locais onde existam radio buttons, garantindo que os mesmos se encontrem corretamente agrupados num fieldset. Isso é especialmente útil para utilizadores de leitores de ecrã pois permite informar que as opções são relacionadas ao mesmo tema. Para mais informações partilhamos exemplos de construção de elementos de formulários do WebAIM.

• evidência: issue#33 Os acordeões de expandir/colapsar tudo estão construídos de forma inapropriada

  etiqueta: R 8.3etiqueta: chk 10 webetiqueta: NOK

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

  A opção de expandir ou fechar o conteúdo tem a funcionalidade similar ao de um acordeão. No entanto, ao utilizar um leitor de ecrã, não é possível identificar a alteração do texto do botão, nem perceber se o conteúdo se encontra expandido ou fechado:

  

  Leitor de ecrã não informa que a opção ”Expandir tudo” está comprimido/fechado

  

  Leitor de ecrã não identifica a mudança do texto “Expandir tudo” para “Colapsar tudo” e não informa que está aberta

  

  Exemplo de acordeão em que o leitor de ecrã informa o nome “Show all sections” e informa que está comprimido/fechado

  

  Exemplo de acordeão em que o leitor de ecrã informa automaticamente a alteração do nome para “Hide all sections” e informa que está expandido/aberto

  Recomendamos reverem o componente de abertura e colapso, de forma a garantir que o seu estado seja comunicado aos leitores de ecrã sempre que ocorrer uma alteração. Importa destacar que este componente está presente em praticamente todas as páginas de conteúdo do website. Para isso, é necessário utilizar o atributo aria-expanded em conjunto com o JavaScript para gerenciar a abertura e fecho do conteúdo.

• evidência: issue#32 O tabulador não está estruturado corretamente

  etiqueta: R 8.3etiqueta: chk 10 webetiqueta: NOK

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

  As opções “Digitais” e “Outros serviços” do menu encontram-se organizadas visualmente sob a forma de separadores (tabuladores). No entanto, essa organização não está a ser devidamente comunicada aos leitores de ecrã, o que pode gerar problemas durante a navegação pelo menu:

  

  Leitor de ecrã não informa que é um tabulador e o número de opções disponíveis

  

  Leitor de ecrã não informa que as respetivas opções fazem parte de "Digitais" ou "Outros serviços"

  

  Exemplo de como o leitor de ecrã informa que é um tabulador (tab), o número de suas opções (2 de 4) e qual delas é a selecionada

  

  Exemplo de como o leitor de ecrã identifica a secção aonde está sendo apresentado o conteúdo da opção selecionada: conteúdo (link), da opção “Carl Andersen”, é um painel de separadores

  O mesmo problema acontece nas páginas de Contacto acessível para cidadão surdo e Info saúde.

  Recomendamos reverem o menu para garantir que seja construído de forma apropriada. Para isso, devem utilizar os atributos role=”tab” e role=”tabpanel” para indicar o que é um tabulador e seu respetivo secção de conteúdo (painel de separador), o aria-selected=”true” para indicar qual das opções está selecionada, aria-controls e id para identificar qual é a secção a apresentar.

  Para mais informações partilhamos as seguintes referências que podem auxiliar na construção:

  • Role=”tab” HTML do Developer Mozilla
  • Accordion example Authoring Practice Guide da W3C

• evidência: issue#31 O mapa do site está construído de forma inapropriada

  etiqueta: R 8.3etiqueta: chk 10 webetiqueta: NOK

  Verifica-se na página do mapa do site, que ao desativar o CSS, os links que remetem para as várias páginas do website se encontram estruturados dentro de um único botão. Esta situação é crítica, pois, para além de provocar um funcionamento incorreto, impossibilita a navegação para as páginas:

  

  Páginas do website apresentadas viisualmente como links

  

  Ao desligar o CSS é perceptível que todos as páginas estão inseridas em um único botão

  Recomendamos a revisão da página do mapa do site, de forma a garantir que cada item esteja configurado como um link () que direcione corretamente para a respetiva página.

• evidência: issue#35 O conteúdo do website se mantém ao desligar o CSS

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

  Quando se retira o CSS, a informação relevante permanece visível.
  – ver requisito 8.4 na lista 10 aspetos

  Ao desligar o CSS é possível verificar que o conteúdo do website continua sendo apresentado. O critério está a cumprir:

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#36 A estrutura da página é feita com elementos de tabela

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.5

  A maquetização da página é feita sem recorrer ao elemento <table>.
  – ver requisito 8.5 na lista 10 aspetos

  A página Nova app SNS 24 está estruturada utilizando elementos de tabela, o qual não deve ser utilizado para esse propósito:

  

  Uso de tabelas para fins de layout e que são visíveis para leitores de ecrã na página Nova app SNS 24

  Recomendamos que o layout da página seja apresentada visualmente através do CSS. Para isso, é necessário remover da estrutura toda a semântica de tabelas (tags table, td, th, caption, etc...).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#37 O foco é direcionado para dentro da modal mas o leitor de ecrã não anuncia o elemento na qual está em foco

  etiqueta: R 9.1etiqueta: chk 10 webetiqueta: NOK

  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

  Na página Contacto acessível para cidadão surdo é apresentada uma modal. Embora o foco do leitor de ecrã seja corretamente posicionado no seu interior, o primeiro elemento não é lido automaticamente. Isso faz com que o utilizador não receba qualquer indicação de que a modal foi aberta, ficando sem contexto sobre a alteração ocorrida na interface:

  

  Foco do leitor de ecrã visualmente posicionado dentro da modal. No entanto, ele não anuncia o primeiro elemento da modal

  Recomendamos rever as modais apresentadas no website, de forma a garantir que, ao serem abertas com um leitor de ecrã, não apenas o foco seja corretamente definido, mas também que o elemento em foco seja anunciado, que poderá ser por exemplo, o título “Alerta”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#40 O botão fechar não está acessível pelo teclado ou leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: 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

  Na página de Contacto acessível para cidadão surdo e de Iniciar sessão, a opção de fechar a modal encontra-se estruturado como uma tag span em vez de um elemento button no HTML. Isso faz com que o elemento interativo não seja corretamente identificado pelos leitores de ecrã e não feche a modal quando acionado pelo teclado ou leitor de ecrã:

  

  Leitor de ecrã anuncia botão fechar como "Close, grupo"

  

  Opção de fechar modal estruturada com a tag span no HTML

  Recomendamos sempre que possível utilizar elementos nativos do HTML. Por esse motivo, é necessário rever as páginas mencionadas para verificar os elementos interativos que são construídos por tags genéricas, como por exemplo, div e span e garantir que sejam corretamente construídos, como um link, tag ou um botão .

• evidência: issue#39 O botão 'Fechar’ está em outro idioma (inserir issue de outras violações)

  etiqueta: melhoriaetiqueta: 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

  Na página Contacto acessível para cidadão surdo e de Iniciar sessão, a modal apresentada possui o botão “Fechar” nomeado em inglês e que precisa ser corrigido para o mesmo idioma da página:

  

  Botão de fechar nomeado como "Close"

  Recomendamos rever os elementos interativos do website para garantir que estejam com o mesmo idioma do website. Para mais detalhes é possível ver outros exemplos na secção de Outras Violações.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#41 O foco retorna ao elemento interativo que ativou a modal. No entanto, a verificação está incompleta

  etiqueta: chk 10 webetiqueta: R 9.4etiqueta: NOK

  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

  Na página Iniciar sessão verifica-se que o foco retorna para o botão que abriu a modal. O critério está a cumprir:

  

  No entanto, a análise foi realizada ao pressionar a tecla “ESC”. É necessário rever as observações levantadas na issue #40, de forma a garantir que, ao utilizar o botão “Fechar”, o encerramento da modal devolve o foco ao respetivo botão. Por esse motivo, a análise está incompleta sendo necessário efetuar essas alterações.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#42 Critério declarado como "Sim", mas verifica-se que é "Não aplicável"

  etiqueta: chk 10 webetiqueta: R 10.1etiqueta: N/A

  Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT.
  – ver requisito 10.1 na lista 10 aspetos

  Não foi identificado tabelas no website. Quando o website não possui elementos mencionados pelo requisito, então o requisito será considerado como “Não Aplicável”. É necessário remover as evidências.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#43 Não existe um resumo do propósito do site na homepage

  etiqueta: chk conteúdoetiqueta: R 1.1etiqueta: NOK

  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

  Não existe qualquer resumo do propósito na Homepage do SNS 24 pelo que deve ser adicionado:

  

  Como referência de uma boa prática, é possível verificar no website acessibilidade.gov que o seu propósito está escrito no topo da página:

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#45 A data de atualização não está sendo apresentada em todas as páginas do website

  etiqueta: R 1.3etiqueta: chk conteúdoetiqueta: NOK

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

  A página Info saúde apresenta informações relativas a de um glossário, no entanto, não é apresentado a data de atualização pelo que deve ser inserido:

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#46 O website apresenta o responsável pelo conteúdo e apresenta mais de um canal de contacto

  etiqueta: R 1.4etiqueta: chk conteúdoetiqueta: NOK

  A informação sobre a entidade responsável pelo conteúdo está em todas as páginas.
  – ver requisito 1.4 na lista Conteúdo

  No rodapé do website SNS 24 é possível localizar o responsável pelo conteúdo e os canais de comunicação:

  

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

Lista de evidências recolhidas:

• evidência: issue#47 O conteúdo principal possui tamanho mínimo de 16px (melhoria)

  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

  Verifica-se de forma geral no website que o corpo do texto possui tamanho mínimo de 16 pixéis:

  

  No entanto, nas páginas internas de conteúdo existe um título nomeado como “Aceder a serviços” cujo tamanho está abaixo do recomendado:

  

  Embora não reprove o requisito, por ser um título que define uma secção da página recomendamos que seu tamanho de fonte seja de no mínimo, 16 pixéis. Essa alteração deverá acontecer em todas as páginas internas de conteúdo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#48 Existem textos com tamanho inferior ao recomendado 10pt (13.3px)

  etiqueta: chk conteúdoetiqueta: R 2.2etiqueta: NOK

  A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos.
  – ver requisito 2.2 na lista Conteúdo

  No rodapé do website, a informação do responsável pelo conteúdo possui tamanho de fonte de 10px, o que está abaixo do recomendado que deverá ser de, no mínimo, 13.3px:

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#49 Existem blocos de texto com mais de 100 caracteres por linha

  etiqueta: chk conteúdoetiqueta: R 2.3etiqueta: NOK

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

  O texto apresentado na modal da página Contacto acessível para cidadão surdo possui tamanho maior que 100 caracteres:

  

  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#50 O espaçamento de linha dos conteúdos é de 1,5x o tamanho da fonte

  etiqueta: R 2.4etiqueta: chk conteúdoetiqueta: NOK

  O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra.
  – ver requisito 2.4 na lista Conteúdo

  Verifica-se de modo geral no website SNS 24 que o espaçamento entre as linhas de texto é de, no mínimo, 1.5x o tamanho da fonte. O critério está a cumprir:

  

  Tamanho da fonte do texto é de 16px e seu espaçamento entre linha é de 24px

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#54 Existem diferentes estilos para os links apresentados no website

  etiqueta: melhoriaetiqueta: R 3.3etiqueta: chk conteúdo

  As hiperligações de texto não devem ser diferenciadas apenas com base na cor.
  – ver requisito 3.3 na lista Conteúdo

  Na página Contacto acessível para cidadão surdo, o link encontra-se destacado apenas através da cor e do peso da fonte (negrito). No entanto, esta abordagem difere do padrão adotado no restante website, onde os links são apresentados com peso normal e destacados através de sublinhado e cor:

  

  Na página nova app SNS 24 o link está sendo estilizado em negrito e a cor verde, e links em negrito com sublinhado na cor preta:

  

  Na página de recrutamento o link está estilizado em negrito, na cor branca e com fundo em verde-escuro:

  

  Recomendamos rever de modo geral os links do website para garantir que todos tenham o mesmo estilo apresentado no website.

• evidência: issue#53 As hiperligações não se diferenciam do texto envolvente

  etiqueta: R 3.3etiqueta: chk conteúdoetiqueta: NOK

  As hiperligações de texto não devem ser diferenciadas apenas com base na cor.
  – ver requisito 3.3 na lista Conteúdo

  Na página da Nova App SNS 24, existem links que estão a ser diferenciados apenas pela cor e pelo peso da fonte. No entanto, o peso da fonte também está a ser utilizado em textos que não são links, sendo os links distinguidos apenas pela cor:

  

  Recomendamos rever do modo geral o website para garantir que as hiperligações do texto envolvente sejam diferenciadas com base na cor e na forma, tal como é feito em outros locais do website.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#55 O índice está a ser substituído por acordeões que não estão estruturados como títulos

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.1

  Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
  – ver requisito 4.1 na lista Conteúdo

  Para além de existir melhorias a serem feitas na estrutura dos acordeões, verifica-se que os mesmos não estão sendo estruturados como cabeçalhos:

  

  Recomendamos que os acordeões tenham o seu nome estruturado como título, devem também garantir a sua correta construção . Para mais informações podem consultar as issues #12, #33 e um exemplo de construção de um acordeão da Authoring Practices Guide (APG) da W3C

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#58 Existem elementos interativos com área clicável que não cumprem a dimensão mínima exigida (44px de altura e largura)

  etiqueta: R 5.2etiqueta: chk conteúdoetiqueta: NOK

  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

  Nas modais das páginas de Contacto acessível para cidadão surdo e Iniciar sessão a opção de fechar possui tamanho abaixo do recomendado:

  

  Tamanho da opção de fechar é de 40px de altura e largura na página contacto acessível para cidadão surdo

  

  Tamanho da opção de fechar é de 40px de altura e largura na página iniciar sessão

  ---

  Na página Info saúde existem elementos interativos com 23 pixéis de altura e largura:

  

  Tamanho dos elementos interativos é de 23px de altura e largura na página info saúde

  

  Botão voltar possui tamanho de 36 pixéis de altura e largura

  Na página inicial é possível identifica elementos interativos com tamanho abaixo do recomendado. As setas indicadoras de voltar ou avançar estão com tamanho de 32 pixéis de largura e altura:

  

  As redes sociais que são apresentadas nas páginas internas de conteúdo, como por exemplo, em Baixa médica, possuem 33 pixéis de largura e 44 de altura:

  

  Recomendamos a revisão geral do website, de forma a garantir que todos os elementos interativos apresentem uma dimensão mínima de 44 pixéis, tanto em altura como em largura. No que diz respeito às redes sociais presentes nas páginas internas, esta alteração deverá ser aplicada em todas as páginas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#61 Existem elementos interativos que não possuem contraste

  etiqueta: chk conteúdoetiqueta: R 5.4etiqueta: NOK

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  – ver requisito 5.4 na lista Conteúdo

  Verifica-se de modo geral no website que existem elementos interativos cuja área clicável não possui contraste mínimo recomendado (3:1).

  Por exemplo, na página Info Saúde, para além de o elemento interativo apresentar tmaanho abaixo do recomendado, a sua área clicável está delimitada por uma borda com contraste de apenas 1,2:1 com a cor de fundo:

  

  Os campos de formulários apresentados no website possuem contorno com contraste abaixo do recomendado. Por exemplo, o campo “Data de nascimento” do formulário de Autodeclaração de doença possui contraste de 1,5:1 com a cor de fundo:

  

  O mesmo acontece nos formulário de Iniciar sessão, Contacto acessível para cidadão surdo, Fale connosco, e nos campos de buscas apresentados no website que devem ser corrigidos.

  Outro exemplo acontece nas páginas internas, como por exemplo, em Resumo de saúde, os serviços disponíveis são apresentados como cards cujo contraste é de 1,1:1 com a cor de fundo branca:

  

  Na página inicial é possível identificar outros exemplos cujo contraste estão abaixo do recomendado. Por exemplo, o botão “Saber mais” possui contraste de 2,1:1 com a cor de fundo verde da imagem:

  

  O botão de “Iniciar sessão” apresentado no topo da página possui contraste de 1,2:1 com a cor de fundo branca:

  

  Recomendamos rever os campos e os elementos interativos que são apresentados no website para garantir que seu contorno tenha, no mínimo, um contraste de 3:1 com a cor de fundo.

• evidência: issue#60 Existem elementos interativos que não aparentam ser clicáveis

  etiqueta: chk conteúdoetiqueta: R 5.4etiqueta: NOK

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  – ver requisito 5.4 na lista Conteúdo

  Na página Info saúde as palavras do glossário são links e estão sendo apresentadas como um texto simples, isso poderá gerar dúvidas se realmente são clicáveis:

  

  Recomendamos que os textos que funcionam como elementos interativos sejam estilizados de forma distinta, de modo a poderem ser facilmente identificados.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#63 Não existem formulário com mais de 2 ecrãs na área pública do website

  etiqueta: R 1.2etiqueta: chk transaçãoetiqueta: N/A

  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

  Não foi identificado formulários maiores de 2 ecrãs. Por esse motivo, o critério é considerado "Não aplicável".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue#64 Não existem formulário longos na área pública do website

  etiqueta: R 1.3etiqueta: chk transaçãoetiqueta: N/A

  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

  Não foi identificado formulários longos para ser necessário essa estrutura de organização. Por esse motivo, o critério é considerado "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#66 Existem campos que mudam conforme escolha do utilizador na opção anterior

  etiqueta: chk transaçãoetiqueta: R 2.2etiqueta: NOK

  É usada revelação progressiva em vez de campos inativos.
  – ver requisito 2.2 na lista Transação

  Nos formulário de fale connosco, os campos "N.º de utente" e "Data de nascimento" são apresentados mediante escolha da opção anterior "Possui n.º de utente do SNS?". No entanto, pelo facto desse campo já aparecer preenchido, o que não é recomendado, o campo "N.º de utente" aparece inicialmente sempre visível:

  

  O mesmo acontece com o formulário de Validar autodeclaração de doença. O campo "Nome completo" e "N.º de identificação de segurança social" se alternam dependendo da escolha anterior do utilizador.

  Recomendamos que o radio button não seja preenchido automaticamente, para evitar erros na escolha do utilizador. Ao fazer isso, será necessário que o campo "N.º de utente", "Data de nascimento", "Nome completo" e "N.º de identificação de segurança social" apareçam apenas quando o utilizador selecionar uma opção. O campo deverá aparecer a seguir do respectivo radio button.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#67 Existem opções que não possuem legenda nos formulários

  etiqueta: R 2.3etiqueta: chk transaçãoetiqueta: NOK

  As legendas dos campos são breves e claras.
  – ver requisito 2.3 na lista Transação

  No formulário de Validar autodeclaração de doença as opções "Nome completo" e "N.º de identificação de segurança social" embora sejam do mesmo grupo de informação eles não possuem legenda atribuída:

  

  Recomendamos rever os radio buttons apresentados nos formulários para garantir que todos tenham uma legenda clara e que informe o tipo de conteúdo a ser selecionado.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Não foi identificado formulários que realizam ações longas no website. Por esse motivo, o critério é considerado "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#70 É necessário percorrer toda a página para identificar o sucesso/erro do envio do formulário

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

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

  Verifica-se que, em todos os formulários do website, a mensagem de sucesso ou erro sobre o envio da informação não está a ser anunciada automaticamente para o leitor de ecrã. Isso faz com que o utilizador fique sem contexto sobre o resultado da ação efetuada.

  Esta situação é mais crítica pelo facto de a mensagem está sendo apresentada no topo da página, e não junto ao botão de submissão, fazendo com que utilizador seja obrigado a percorrer novamente a página para localizar a informação sobre o estado do envio do formulário:

  

  Mensagem de sucesso de envio do formulário posicionado no topo da página e não é informado automaticamente para o leitor de ecrã no formulário de fale connosco

  

  Mensagem de sucesso de envio do formulário posicionado no topo da página e não é informado automaticamente para o leitor de ecrã no formulário de contacto acessível para cidadão surdo

  Recomendamos posicionar a mensagem após ao botão de submeter formulário. Idealmente o foco do leitor de ecrã poderá ser posicionado automaticamente na mensagem assim que surgir.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#71 O website permite editar o que já foi preenchido

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

  A informação já introduzida deve poder ser corrigida a qualquer momento.
  – ver requisito 4.1 na lista Transação

  O website possui formulários em que os campos de preenchimento podem ser alterados até a submissão do formulário. O critério está a cumprir:

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#72 Critério declarado como "Sim", mas verifica-se que é "Não aplicável"

  etiqueta: R 4.2etiqueta: chk transaçãoetiqueta: NOK

  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

  Não foi identificado cenários em que a submissão de um formulário faz com que tenha uma perda de dados do utilizador. Quando o website não possui elementos mencionados pelo requisito, então o requisito será considerado como “Não Aplicável”. É necessário remover as evidências.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#73 Não são devolvidas mensagens de erro junto a cada campo do formulário

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

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

  Nos formulários de Fale connosco e Autodeclaração de doença, verifica-se a existência de campos que não apresentam qualquer mensagem de erro quando são preenchidos incorretamente ou deixados em branco.

  Por exemplo, no formulário de Fale connosco, os campos "Canal", "Assunto" e "Sub-assunto" não exibem mensagens de erro quando não são selecionados:

  

  Campos "Canal", "Assunto" e "Sub-assunto" não exibem uma mensagem de erro que avise que os campos de seleção são obrigatórios

  No formulário de Autodeclaração de doença, o campo “Data de nascimento” não exibe qualquer mensagem de erro. A indicação de que o campo contém um problema é feita exclusivamente através da cor, o que não é recomendado:

  

  Recomenda-se a revisão de todos os campos do formulário, de modo a garantir que apresentam mensagens de erro adequadas. A utilização da cor pode utilizada, desde que não constitua o único meio de indicar que um campo não foi preenchido ou que se encontra incorretamente preenchido.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue#74 A mensagem de erro do campo email não ajuda na resolução do problema

  etiqueta: R 4.4etiqueta: chk transaçãoetiqueta: NOK

  As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos.
  – ver requisito 4.4 na lista Transação

  Nos formulários do website, as mensagens de erro não são explícitas no campo email, não oferecendo qualquer tipo de sugestão ou ajuda no preenchimento:

  

  Erro de preenchimento do campo email no formulário de fale connosco

  

  Exemplo de uma mensagem de erro que ajuda o utilizador a preencher o campo de email

  Recomendamos rever todos os campos de email do website para garantir que tenham uma mensagem de erro mais explicativa e que informe como efetuar o preenchimento do campo.

etiqueta: OK (no entanto contém 4 melhorias que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue#79 Outras violações - Links com o nome acessível diferente remetem para a mesma página

  etiqueta: melhoriaetiqueta: outras violações

  Na página inicial do SNS 24 é possível identificar links nomeados como “Saber mais” que quando vistos individualmente não é possível distingui-los:

  

  Recomendamos que o nome acessível dos links seja alterado de forma a indicar claramente o respetivo tema ao qual dizem respeito.
  Por exemplo, em vez de utilizar apenas “Saber mais”, o link poderá ser nomeado como “Saber mais Autodeclaração de Doença”. Para isso, poderá ser utilizado o atributo aria-describedby, permitindo aproveitar o nome do respetivo cartão associado ao link “Saber mais”. Em alternativa, poderá ser definido um nome acessível específico através do atributo aria-label aplicado ao link.

• evidência: issue#78 Outras violações - O website não utiliza landmarks de forma apropriada

  etiqueta: melhoriaetiqueta: outras violações

  Verifica-se de modo geral no website a inexistência da landmark main nas páginas. Essa landmark é importante porque identifica a área de conteúdo principal da página. Isso permite aos utilizadores de tecnologias de apoio a saltarem rapidamente até a parte principal da página sem precisar percorrer outros conteúdos, como menus de navegação ou cabeçalhos.

  

  Leitor de ecrã identifica apenas a navegação principal e o rodapé

  Recomendamos a revisão geral do website, de forma a garantir que todas as páginas incluam corretamente as landmarks estruturais — nomeadamente as etiquetas header, nav, footer e, em particular, a main. Não deverá existir conteúdos estruturados fora das landmarks.

• evidência: issue#77 Outras violações - Leitor de ecrã notifica demasiadas vezes a alteração do conteúdo do carrossel no iPhone

  etiqueta: melhoriaetiqueta: outras violações

  Verifica-se que, ao navegar na página inicial num iPhone com a versão 26.2.1, o utilizador é notificado de forma recorrente sobre a alteração de conteúdo do carrossel, independentemente da posição em que se encontre na página. Este comportamento compromete a experiência de navegação, uma vez que a leitura é constantemente interrompida pela notificação de “elemento atual” na página.

  

  Recomendamos verificar o uso do atributo aria-current a aria-live="off" que está sendo apresentado nos controles do carrosel e no conteúdo dos slides para identificar o motivo de estar a disparar notificações repetitivas para os leitores de ecrã.

• evidência: issue#76 Outras violações - Nome acessível dos botões estão com idioma diferente do website

  etiqueta: melhoriaetiqueta: outras violações

  Verifica-se que de modo geral no website a existência de elementos interativos nomeados em inglês. Por exemplo, os controles do carrossel da página inicial estão nomeadas como “Previous slide”, “Next slide” sendo necessário alterarem para o mesmo idioma do website:

  

  Nas modais apresentadas no website, a opção de fechar está escrita em português pelo atributo aria-label em uma div e o texto em inglês “Close” numa tag span:

  

  Não é uma boa prática fazer o uso do atributo aria-label em tags genéricas como divs e spans. Por esse motivo, para além de ser necessário estruturar a opção como um botão, devem nomeá-lo no mesmo idioma da página.