Websites para órgãos governamentais, estabilidade, segurança e acessibilidade
Sou Mariusz Szatkowski e desenvolvo websites em WordPress desde 2006. Para câmaras municipais, juntas de freguesia, institutos públicos e empresas municipais faço a parte técnica: implemento o design que o organismo fornece, migro os conteúdos do site antigo, cumpro os requisitos de acessibilidade e mantenho o site depois do lançamento. Trabalho sozinho, a partir de Gdynia, na Polónia, por isso o código que o seu organismo recebe é escrito por mim e os acessos não passam para mais ninguém.
O design gráfico e os wireframes vêm do organismo, por exemplo num ficheiro Figma ou numa folha onde se marca que elemento fica em cada página. Eu transformo isso num tema WordPress responsivo.
O que o Decreto-Lei n.º 83/2018 exige ao site
O Decreto-Lei n.º 83/2018, de 19 de outubro, transpõe a Diretiva (UE) 2016/2102 e define as regras de acessibilidade dos sítios web e aplicações móveis do setor público. Os pontos que pesam no trabalho técnico:
| Artigo | O que diz | O que isso significa no site |
|---|---|---|
| 2.º | Aplica-se ao Estado, regiões autónomas, autarquias locais, institutos públicos, setor público empresarial e outras entidades | Câmaras, freguesias e empresas municipais estão abrangidas |
| 5.º | Conteúdo percetível, operável, compreensível e robusto | Os quatro princípios da WCAG aplicados a cada modelo de página |
| 7.º | Presunção de conformidade com as normas harmonizadas, na falta delas a EN 301 549 | Implemento segundo a EN 301 549, cuja parte web segue a WCAG 2.1 nível AA |
| 8.º | Declaração de acessibilidade no modelo da AMA, numa página terminada em /acessibilidade, ligada à página de entrada | Crio a página e a ligação no rodapé de todas as páginas |
| 9.º | Monitorização: avaliação automática, avaliação manual e testes com pessoas com deficiência | Entrego o site preparado para as duas primeiras; os testes com utilizadores ficam com o organismo |
| 12.º e 13.º | Mecanismo de notificação e mecanismo de queixa | Formulário acessível e contactos indicados na declaração |
As ferramentas de verificação e o modelo da declaração estão no portal acessibilidade.gov.pt, mantido pela AMA. Uso o AccessMonitor durante o desenvolvimento, não só no fim.
Como torno o site acessível na prática
A acessibilidade decide-se no código dos modelos de página, e um plugin acrescentado no fim não corrige esse código. Trabalho assim:
- Hierarquia de títulos correta em cada modelo, regiões ARIA e ligação “saltar para o conteúdo”.
- Contraste verificado nas cores que o organismo fornece; quando uma cor não chega a 4,5:1, digo-o antes de implementar.
- Navegação completa por teclado, com foco visível, incluindo menus, filtros e formulários.
- Mensagens de erro nos formulários ligadas ao campo e lidas pelo leitor de ecrã.
- Documentos: o WordPress não torna acessível um PDF digitalizado. Preparo os campos para descrições e versões HTML e explico aos editores como publicar documentos legíveis.
O site da WPPoland tem a sua própria declaração de acessibilidade, com o mesmo tipo de informação que um organismo público tem de publicar.
Porque WordPress num organismo público
O código é aberto e pertence ao organismo. Se amanhã outro fornecedor ganhar o procedimento de contratação, recebe o repositório, a documentação e os acessos e continua a partir daí, sem reconstruir o site. Com um CMS proprietário, o organismo fica preso a quem detém o código.
Se o organismo já tem um site em Drupal ou TYPO3, não tem de o reescrever: também mantenho sites em Drupal e TYPO3, com atualizações de versão e correções de acessibilidade.
Serviços ao munícipe que o site pode ter
Organizo os conteúdos pelas situações da vida do munícipe, como “nasceu um filho” ou “quero construir”, porque é assim que ele procura. Cada ficha de serviço tem os documentos necessários, prazos, contactos e a ligação para o serviço online correspondente no ePortugal ou na plataforma que o organismo já usa.
Outros módulos que faço com frequência em WordPress:
- Agenda de eventos e notícias com categorias e arquivo.
- Barra de aviso urgente no topo de todas as páginas, ativada por um editor em segundos, para cortes de água ou alertas meteorológicos.
- Formulários de contacto e de reporte de ocorrências, com os dados guardados apenas no que o organismo definir.
- Arquivo de atas, editais e regulamentos com datas de publicação preservadas na migração.
Integrações com sistemas internos de gestão documental dependem da API que esses sistemas expõem. Avalio cada caso pela documentação técnica antes de prometer seja o que for.
Um município, vários sites
Escolas, bibliotecas, museus e empresas municipais têm muitas vezes sites separados, com aspetos e níveis de manutenção diferentes. O WordPress Multisite junta-os numa instalação: as atualizações são feitas uma vez, o design é partilhado e cada entidade tem os seus próprios editores, que só veem o seu site. Compensa quando há um único responsável técnico para todos; quando cada entidade tem orçamento e fornecedor próprios, sites separados são mais simples.
Segurança e proteção de dados
Antes de receber qualquer acesso, assino com o organismo um acordo de subcontratação ao abrigo do artigo 28.º do RGPD. Na manutenção:
- Monitorizo a disponibilidade a cada 1 a 5 minutos.
- Guardo cópias de segurança durante 30 dias ou mais, em países da União Europeia.
- Testo cada atualização do núcleo, tema e plugins em staging antes da produção.
- Desativo a edição de ficheiros no painel e dou aos editores só as permissões de que precisam.
Não ofereço disponibilidade 24 horas por dia nem tempos de resposta garantidos, e nenhum site é imune a ataques. Se precisar de uma revisão do estado atual, faço uma auditoria de segurança WordPress. O serviço contínuo está descrito em manutenção de sites WordPress.
Leitura do caderno de encargos antes do concurso
Um requisito mal escrito no caderno de encargos não se consegue exigir na receção do site. Se o seu organismo está a preparar um procedimento para o site, posso ler o projeto de especificações e assinalar por escrito os pontos que fecham o mercado a um único fornecedor e os requisitos de acessibilidade formulados de forma tão vaga que não se podem verificar. Não tem de decidir nada sobre o fornecedor nessa fase. Envie-me o documento.
Como decorre o projeto
- O organismo envia o âmbito, os prazos e o design. Esclareço por escrito o que falta.
- Envio uma proposta escrita com âmbito, pressupostos e calendário.
- Após o contrato e o acordo do artigo 28.º, implemento o site no repositório Git e mostro cada fase em staging.
- Migro os conteúdos do site antigo, com datas de publicação e ficheiros anexos.
- O organismo aceita em staging, com base numa lista que liga cada requisito a um teste e a um resultado. Falhas por resolver ficam registadas como bloqueantes ou como trabalho posterior acordado.
- Entrego o código, a documentação técnica, a lista de licenças e serviços externos, o procedimento de cópia e recuperação e o manual para editores.
Com esta documentação, a equipa interna do organismo ou outro fornecedor pode assumir o site sem ter de redescobrir como foi construído.
Requisitos semelhantes de acessibilidade, proteção de dados e trabalho editorial aplicam-se a outras instituições: websites para hospitais, websites para instituições culturais e websites para fundações.
