Você está na página 1de 128

AMBIENTE DE GOVERNO

Governo Eletrônico: E-Ping

A arquitetura e-PING – Padrões de Interoperabilidade de Governo Eletrônico – define um conjunto


mínimo de premissas, políticas e especificações técnicas que regulamentam a utilização da
Tecnologia de Informação e Comunicação (TIC) na interoperabilidade de Serviços de Governo
Eletrônico, estabelecendo as condições de interação com os demais Poderes e esferas de governo
e com a sociedade em geral.

As áreas cobertas pela e-PING estão segmentadas em:


• Interconexão;
• Segurança;
• Meios de Acesso;
• Organização e Intercâmbio de Informações;
• Áreas de Integração para Governo Eletrônico.

Para cada um desses segmentos foram especificados componentes, para os quais são
estabelecidos padrões.

Todo o conteúdo deste documento de referência está em consonância com as diretrizes do Comitê
Executivo de Governo Eletrônico, criado pelo Decreto de 18 de outubro de 2000, e está publicado
em sítio específico na Internet (http://www.eping.e.gov.br), garantindo acesso público às
informações de interesse geral e transparência intrínseca à iniciativa. O governo brasileiro está
comprometido em assegurar que estas políticas e especificações permaneçam alinhadas com as
necessidades da sociedade e com a evolução do mercado e da tecnologia.

O documento de referência da e-PING contém:

• os fundamentos de concepção, implantação e administração da e-PING, relacionando os


benefícios esperados com o trabalho, definindo os limites da abrangência da arquitetura
e-PING e destacando as premissas consideradas e as políticas estabelecidas;
• o modelo de gestão da e-PING, discriminando responsabilidades, critérios de verificação
de conformidade, gestão de mudanças, divulgação e orientação para capacitação;
• as políticas e as especificações técnicas estabelecidas para todos os componentes de
cada um dos segmentos da e-PING;
• glossário de termos técnicos referenciados;
• relação dos integrantes e colaboradores da presente versão deste documento.

O conteúdo deste documento é de domínio público, não havendo restrições quanto à sua
reprodução nem quanto à utilização das informações nele contidas. A reprodução pode ser
realizada em qualquer mídia, sem necessidade de autorização específica. O uso inadequado do
material com fins depreciativos será considerado objeto de tratamento jurídico apropriado por parte
do governo brasileiro, detentor dos direitos autorais.

É proibida a utilização do todo ou de parte do conteúdo deste documento com fins comerciais.
Parte I – Visão Geral da e-PING
Documento de Referência da e-PING – Versão 2011

1. Introdução

A base para o fornecimento de melhores serviços, adequados às necessidades dos cidadãos e dos
negócios, a custos mais baixos, é a existência de uma infraestrutura de Tecnologia da Informação
e Comunicação (TIC) que se preste como alicerce para a criação desses serviços. Um governo
moderno, integrado e eficiente, exige sistemas igualmente modernos, integrados e interoperáveis,
trabalhando de forma íntegra, segura e coerente em todo o setor público.
Nesse contexto, a interoperabilidade de tecnologia, processos, informação e dados é condição vital
para o provimento de serviços de qualidade, tornando-se premissa para governos em todo o
mundo, como fundamento para os conceitos de governo eletrônico, o e-gov. A interoperabilidade
permite racionalizar investimentos em TIC, por meio do compartilhamento, reúso e intercâmbio de
recursos tecnológicos.
Governos como o norte-americano, o canadense, o britânico, o australiano e o neozelandês
investem fortemente no desenvolvimento de políticas e processos e no estabelecimento de
padrões em TIC, montando estruturas dedicadas para obter a interoperabilidade, com o objetivo de
prover serviços de melhor qualidade a custos reduzidos.
O governo brasileiro vem consolidando a arquitetura e-PING – “Padrões de Interoperabilidade de
Governo Eletrônico”, que tem como propósito ser o paradigma para o estabelecimento de políticas
e especificações técnicas que permitam a prestação de serviços eletrônicos de qualidade à
sociedade.
O que é Interoperabilidade?
Para o estabelecimento dos objetivos da e-PING, é fundamental que se defina claramente o que se
entende por Interoperabilidade. A seguir são apresentados quatro conceitos que fundamentaram o
entendimento do governo brasileiro a respeito do assunto:
“Intercâmbio coerente de informações e serviços entre sistemas. Deve possibilitar a substituição de
qualquer componente ou produto usado nos pontos de interligação por outro de especificação
similar, sem comprometimento das funcionalidades do sistema.” (governo do Reino Unido);
“Habilidade de transferir e utilizar informações de maneira uniforme e eficiente entre várias
organizações e sistemas de informação.” (governo da Austrália);
“Habilidade de dois ou mais sistemas (computadores, meios de comunicação, redes, software e
outros componentes de tecnologia da informação) de interagir e de intercambiar dados de acordo
com um método definido, de forma a obter os resultados esperados.” (ISO);
“Interoperabilidade define se dois componentes de um sistema, desenvolvidos com ferramentas
diferentes, de fornecedores diferentes, podem ou não atuar em conjunto.” (Lichun Wang, Instituto
Europeu de Informática – CORBA Workshops);
Interoperabilidade não é somente Integração de Sistemas, não é somente Integração de Redes.
Não referencia unicamente troca de dados entre sistemas. Não contempla simplesmente definição
de tecnologia.
É, na verdade, a soma de todos esses fatores, considerando, também, a existência de um legado
de sistemas, de plataformas de Hardware e Software instaladas. Parte de princípios que tratam da
diversidade de componentes, com a utilização de produtos diversos de fornecedores distintos. Tem
por meta a consideração de todos os fatores para que os sistemas possam atuar
cooperativamente, fixando as normas, as políticas e os padrões necessários para consecução
desses objetivos.
Para que se conquiste a interoperabilidade, as pessoas devem estar engajadas num esforço
contínuo para assegurar que sistemas, processos e culturas de uma organização sejam
gerenciados e direcionados para maximizar oportunidades de troca e reúso de informações.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 7


Documento de Referência da e-PING – Versão 2011

2. Escopo

Políticas e especificações claramente definidas para interoperabilidade e gerenciamento de


informações são fundamentais para propiciar a conexão do governo, tanto no âmbito interno como
no contato com a sociedade e, em maior nível de abrangência, com o resto do mundo – outros
governos e empresas atuantes no mercado mundial. A e-PING é concebida como uma estrutura
básica para a estratégia de governo eletrônico, aplicada inicialmente ao governo federal – Poder
Executivo, não restringindo a participação, por adesão voluntária, de outros poderes e esferas de
governo.
Os recursos de informação do governo constituem valiosos ativos econômicos. Ao garantir que a
informação governamental possa ser rapidamente localizada e intercambiada entre o setor público
e a sociedade, mantidas as obrigações de privacidade e segurança, o governo auxilia no
aproveitamento máximo deste ativo, impulsionando e estimulando a economia do país.
A arquitetura e-PING cobre o intercâmbio de informações entre os sistemas do governo federal –
Poder Executivo e as interações com:
• Cidadãos;
• Outros níveis de governo (estadual e municipal);
• Outros Poderes (Legislativo, Judiciário) e Ministério Público Federal;
• Organismos Internacionais;
• Governos de outros países;
• Empresas (no Brasil e no mundo);
• Terceiro Setor.
A figura a seguir representa esse relacionamento.

Figura 1 – Relacionamentos do governo federal.

2.1. Adesão à e-PING

A adoção dos padrões e políticas contidos na e-PING não pode ser imposta aos cidadãos e às
diversas instâncias de governo, dentro e fora do país. O governo brasileiro, no entanto, estabelece
essas especificações como o padrão por ele selecionado e aceito, ou seja, estes são os padrões
em que deseja interoperar com as entidades fora do governo federal – Poder Executivo brasileiro.
A adesão dessas entidades dar-se-á de forma voluntária e sem qualquer ingerência por parte da
Coordenação da e-PING.
Para os órgãos do governo federal – Poder Executivo brasileiro a adoção dos padrões e políticas
contidos na e-PING é obrigatória (Portaria SLTI/MP nº 5, de 14 de julho de 2005).
O governo federal – Poder Executivo brasileiro inclui:
• os órgãos da Administração Direta: Ministérios, Secretarias e outras entidades
governamentais de mesma natureza jurídica, ligados direta ou indiretamente à
Presidência da República do Brasil;

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 8


Documento de Referência da e-PING – Versão 2011

• as Autarquias e fundações.
No âmbito das entidades supramencionadas, são obrigatórias as especificações contidas na e-
PING para:
• todos os novos sistemas de informação que vierem a ser desenvolvidos e implantados no
governo federal e que se enquadram no escopo de interação, dentro do governo federal e
com a sociedade em geral;
• sistemas de informação legados que sejam objeto de implementações que envolvam
provimento de serviços de governo eletrônico ou interação entre sistemas;
• outros sistemas que façam parte dos objetivos de disponibilizar os serviços de governo
eletrônico.
A adesão ocorrerá de maneira gradativa, a partir da definição do Plano Diretor de Tecnologia da
Informação – PDTI do Órgão. O PDTI deverá possuir como um de seus apêndices o plano de
implementação que considerará a situação da instituição em relação às condições para se adequar
às especificações e recomendações da e-PING. Este plano será analisado pelo órgão central do
SISP com o objetivo de promover uma aderência deste aos demais planos do Poder Executivo,
alinhando as necessidades com as evoluções de TI previstas para Governo.
A aferição da situação do órgão quanto ao uso efetivo dos padrões se dará com base no Modelo
de Maturidade de Adoção da e-PING – M-PING, atualmente em construção, aferindo a aderência
em 3 (três) níveis: Organizacional, Semântico e Técnico.
Para os sistemas de informação de governo que estiverem fora do escopo de obrigatoriedade
delimitado, é recomendável que os responsáveis considerem a adequação aos padrões da e-PING
sempre que forem planejados esforços significativos de atualização.
Todas as compras e contratações do governo federal – Poder Executivo direcionadas para
desenvolvimento de serviços de governo eletrônico e para atualizações de sistemas legados
devem estar em consonância com as especificações e políticas contidas neste documento.
A e-PING incentiva a participação de todas as partes interessadas no desenvolvimento e
atualização contínua das especificações e recomendações integrantes da arquitetura. A gestão da
e-PING prevê essa participação, com utilização da Internet (http://www.eping.e.gov.br) como meio
preferencial para o contato entre os gestores da e-PING e a sociedade.

2.2. Foco na interoperabilidade

A e-PING não terá como foco de trabalho todos os assuntos da área de Tecnologia da Informação
e Comunicação (TIC). Serão tratadas apenas especificações que forem relevantes para garantir a
interconectividade de sistemas, integração de dados, acesso a serviço de governo eletrônico e
gerenciamento de conteúdo. A e-PING envolve os assuntos compreendidos na segmentação,
descrita no item 4 deste documento.

2.3. Assuntos não abordados

A e-PING não tem por objetivo padronizar a forma de apresentação das informações dos serviços
de governo eletrônico, restringindo-se à definição dos requisitos de intercâmbio de dados e das
condições de disponibilidade desses dados para os dispositivos de acesso.
Informações sobre diretrizes e políticas relativas à apresentação e acessibilidade dos portais e
sítios de governo eletrônico estão disponíveis no portal do governo eletrônico brasileiro
(http://www.governoeletronico.gov.br).

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 9


Documento de Referência da e-PING – Versão 2011

3. Políticas Gerais

Relacionam-se a seguir as políticas gerais utilizadas na construção da e-PING e que fundamentam


as políticas e especificações técnicas de cada segmento:

3.1. Adoção Preferencial de Padrões Abertos

A e-PING define que, sempre que possível, serão adotados padrões abertos nas especificações
técnicas. Padrões proprietários são aceitos, de forma transitória, mantendo-se as perspectivas de
substituição assim que houver condições de migração. Sem prejuízo dessas metas, serão
respeitadas as situações em que haja necessidade de consideração de requisitos de segurança e
integridade de informações.

3.2. Software Público e/ou Software Livre

A implementação dos padrões de interoperabilidade deve priorizar o uso de software público e/ou
software livre, em conformidade com diretrizes do Comitê Executivo de Governo Eletrônico e
normas definidas no âmbito do SISP.

3.3. Transparência

Os documentos da e-PING estarão à disposição da sociedade, via Internet, sendo previstos


mecanismos de divulgação, recebimento e avaliação de sugestões. Nesse sentido, serão definidos
– e divulgados para amplo conhecimento – prazos e compromissos para implantação e gestão de
sítio dedicado na Internet (http://www.eping.e.gov.br).

3.4. Segurança

A interoperabilidade na prestação dos serviços de governo eletrônico deve considerar o nível de


segurança requerido pelo serviço, com a máxima transparência.

3.5. Suporte de mercado

Todas as especificações contidas na e-PING contemplam soluções amplamente apoiadas pelo


mercado. O objetivo a ser alcançado é a redução dos custos e dos riscos na concepção e
produção de serviços nos sistemas de informações governamentais.

A e-PING considera que a interoperabilidade envolve elementos técnicos, semânticos e


organizacionais, sendo políticas gerais direcionadoras dessas dimensões:

3.6. Dimensão técnica

3.6.1. Alinhamento com a INTERNET

Todos os sistemas de informação da administração pública deverão estar alinhados com as


principais especificações usadas na Internet e com a World Wide Web.

3.6.2. Adoção do XML

Como padrão primário de intercâmbio de dados para todos os sistemas do setor público.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 10


Documento de Referência da e-PING – Versão 2011

3.6.3. Adoção de navegadores (browsers)

Como principal meio de acesso todos os sistemas de informação de governo deverão ser
acessíveis, preferencialmente, por meio de tecnologia baseada em browser; outras interfaces são
permitidas em situações específicas, como em rotinas de atualização e captação de dados onde
não haja alternativa tecnológica disponível baseada em navegadores.

3.6.4. Escalabilidade

As especificações selecionadas deverão ter a capacidade de atender alterações de demanda no


sistema, tais como, mudanças em volumes de dados, quantidade de transações ou quantidade de
usuários. Os padrões estabelecidos não poderão ser fator restritivo, devendo ser capazes de
fundamentar o desenvolvimento de serviços que atendam desde necessidades mais localizadas,
envolvendo pequenos volumes de transações e de usuários, até demandas de abrangência
nacional, com tratamento de grande quantidade de informações e envolvimento de um elevado
contingente de usuários.

3.7. Dimensão semântica

3.7.1. Desenvolvimento e manutenção de recursos de organização da informação

Visando contribuir para a simplificação do acesso a documentos e serviços pelo cidadão brasileiro,
devem ser utilizados recursos tais como vocabulários controlados, taxonomias, ontologias e outros
métodos de organização e recuperação de informações.

3.7.2. Desenvolvimento e adoção de um Padrão de Metadados do Governo Eletrônico – e-


PMG

Baseado em padrões internacionalmente aceitos (http://www.eping.e.gov.br).

3.7.3. Desenvolvimento e Adoção de um Padrão de Modelagem de Dados para Governo, o


Modelo Global de Dados – MGD

Baseada em notação simples e objetiva, facilmente utilizável, que permita evidenciar as


integrações atuais e as integrações necessárias entre os dados que suportem as interações do
governo em suas diversas secretarias e órgãos, seu alinhamento com os processos de negócios
governamentais, promovendo melhoria na gestão pública, servindo como arquitetura de
interoperabilidade para o Governo.

3.7.4. Desenvolvimento e Adoção de uma Política de Disseminação de Dados e Informações

Baseada em experiências internacionais de abertura de dados governamentais (OpenData), a


política consiste em uma série de ações coordenadas para orientar a incorporação de processos
de disponibilização dos dados públicos para permitir seu melhor uso pela sociedade, alinhada com
a diretriz da e-PING de adoção de padrões abertos na interação do governo federal com a
sociedade.

3.8. Dimensão organizacional

3.8.1. Simplificação administrativa

A aplicação da e-PING visa contribuir para que as interações do governo com a sociedade sejam
realizadas de forma simples e direta, sem prejuízo da legislação vigente.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 11


Documento de Referência da e-PING – Versão 2011

3.8.2. Promoção da colaboração entre organizações

Por meio da integração entre objetivos institucionais e processos de negócio de organizações com
estruturas internas e processos internos diferentes.

3.8.3. Garantia à privacidade de informação

Todos os órgãos responsáveis pelo oferecimento de serviços de governo eletrônico devem garantir
as condições de preservação da privacidade das informações do cidadão, empresas e órgãos de
governo, respeitando e cumprindo a legislação que define as restrições de acesso e divulgação.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 12


Documento de Referência da e-PING – Versão 2011

4. Segmentação

A arquitetura e-PING foi segmentada em cinco partes, com a finalidade de organizar as definições
dos padrões. Para cada um dos segmentos, foi criado um grupo de trabalho, composto por
profissionais atuantes em órgãos dos governos federal, estadual e municipal, especialistas em
cada assunto. Esses grupos foram responsáveis pela elaboração desta versão da arquitetura, base
para o estabelecimento dos padrões de interoperabilidade do governo brasileiro.
Os cinco segmentos – “Interconexão”, “Segurança”, “Meios de Acesso”, ”Organização e
Intercâmbio de Informações” e “Áreas de Integração para Governo Eletrônico” – foram subdivididos
em componentes, para os quais foram estabelecidas as políticas e as especificações técnicas a
serem adotadas pelo governo federal. A seguir são relacionados alguns componentes que
constituem cada um dos cinco segmentos.

4.1. Interconexão

O segmento “Interconexão” estabelece as condições para que os órgãos de governo se


interconectem, além de fixar as condições de interoperação entre o governo e a sociedade.
Neste segmento, são estabelecidas as especificações para:
• Mensageria;
• Infraestrutura de Rede;
• Serviços de Rede.

4.2. Segurança

Este segmento trata dos aspectos de segurança de TIC que o governo federal deve considerar.
São tratados os padrões para:
• Comunicação de Dados;
• Correio Eletrônico;
• Criptografia;
• Desenvolvimento de Sistemas;
• Serviços de Rede;
• Redes sem Fio;
• Resposta a Incidentes de Segurança da Informação.

4.3. Meios de Acesso

No segmento “Meios de Acesso”, são explicitadas as questões relativas aos padrões dos
dispositivos de acesso aos serviços de governo eletrônico. Nesta versão são abordadas as
políticas e as especificações para estações de trabalho, televisão digital e mobilidade. Em versões
futuras, serão tratados outros dispositivos. É formado por três subgrupos contemplando os
seguintes componentes:
Padrões para acesso via estações de trabalho:
• Navegadores (browsers);
• Conjunto de Caracteres e Alfabetos;
• Formato de Intercâmbio de Hipertexto;
• Arquivos do Tipo Documento;
• Arquivos do Tipo Planilha;
• Arquivos do Tipo Apresentação;
• Arquivos do Tipo Banco de Dados para Estações de Trabalho;
• Especificação de Intercâmbio de Informações Gráficas e Imagens Estáticas;
• Gráficos Vetoriais;
• Especificação de Padrões de Animação;
• Arquivos do Tipo Áudio e do Tipo Vídeo;
• Compactação de Arquivos de Uso Geral;
• Arquivos para georreferenciamento;

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 13


Documento de Referência da e-PING – Versão 2011

• Programação Estendida (Plugins).


Mobilidade:
• Definição;
• Protocolo de transmissão;
• Navegador;
• Padrão de Hipertexto;
• Programação estendida;
• Mensageria;
• Arquivos de Vídeo e Som;
• Arquivos de Imagem;
• Arquivos de Escritório;
• Leitor PDF.
TV Digital:
• Definição;
• Normas da ABNT;
• Especificações de Padrões.

4.4. Organização e Intercâmbio de informações

Aborda os aspectos relativos ao tratamento e à transferência de informações nos serviços de


governo eletrônico. Inclui padrão de estrutura de assuntos de governo e de metadados,
compreendendo os seguintes componentes, sendo que alguns deles ainda estão em construção:
• Linguagem para intercâmbio de dados: XML;
• Linguagem para transformação de dados: XLS;
• Definição dos dados para intercâmbio: XML Schema e UML;
• Vocabulário Controlado do Governo Eletrônico (VCGE);
• Padrão de Metadados do Governo (e-PMG).

4.5. Áreas de Integração para Governo Eletrônico

O segmento estabelece a utilização ou construção de especificações técnicas baseadas no padrão


XML para sustentar o intercâmbio de informações em áreas transversais da atuação
governamental, cuja padronização seja relevante para a interoperabilidade de serviços de Governo
Eletrônico, tais como Dados e Processos, Informações Contábeis e Informações Geográficas,
compreendendo:
• Modelo Global de Dados (MGD);
• Guia de Gestão de Processos de Governo (GGPG);
• Catálogo Padrão de Dados (CPD);
• Catálogo XML Schemas;
• Catálogo de Serviços Interoperáveis (Web Services).

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 14


Documento de Referência da e-PING – Versão 2011

5. Gestão da e-PING

Neste item são tratados os aspectos de gestão da arquitetura e-PING, especificando a forma pela
qual o governo brasileiro pretende consolidar a implantação das políticas e especificações técnicas
como padrões efetivos adotados tanto internamente, pelos órgãos que compõem a Administração
Pública Federal, como na interoperação com as entidades externas, representadas por outras
instâncias de governo, pela iniciativa privada, por instituições atuantes no terceiro setor e pelo
cidadão.

5.1. Histórico

A arquitetura e-PING tem por finalidade ser o paradigma de interoperabilidade para o governo
federal, inicialmente no âmbito do Poder Executivo, onde seu uso é obrigatório. A iniciativa de
montagem da arquitetura coube a três órgãos da esfera federal:
• Ministério do Planejamento, Orçamento e Gestão, por meio da sua Secretaria de
Logística e Tecnologia da Informação (SLTI/MP);
• Instituto Nacional de Tecnologia da Informação, da Presidência da República (ITI);
• Serviço Federal de Processamento de Dados (SERPRO), empresa pública ligada ao
Ministério da Fazenda.
Esses três órgãos organizaram um Seminário, com participação de entidades do governo federal,
no âmbito do Poder Executivo, tendo como objetivo a formação de um comitê interórgãos –
denominado Comitê Constituinte – para conduzir os trabalhos iniciais de montagem da arquitetura.
Após a sua institucionalização, por intermédio da Portaria Normativa nº 5, de 14 de julho de 2005,
este se passou a denominar Coordenação da e-PING. Além dos três organizadores, participam
desse grupo os seguintes órgãos: Presidência da República, Ministério das Relações Exteriores, ,
Ministério da Saúde, Banco do Brasil, Caixa Econômica Federal, DATAPREV e Associação
Brasileira de Entidades Estaduais de Tecnologia da Informação e Comunicação (ABEP).
O Comitê estabeleceu o seguinte programa de trabalho:
• Definição da forma inicial de elaboração e gestão da arquitetura e-PING;
• Definição da segmentação dos assuntos a serem cobertos pela e-PING;
• Criação de cinco grupos de trabalho responsáveis pelas definições iniciais de políticas e
especificações técnicas para cada um dos segmentos;
• Estabelecimento de um cronograma de trabalho com o objetivo de construção e
divulgação da versão inicial da arquitetura, denominada versão 0;
• Realização de consulta pública e audiências públicas em RS, SP, DF, RJ, MG e PE, de
modo a colher contribuições, da sociedade em geral, sobre o conteúdo proposto na
versão 0;
• Publicação da versão 1, juntamente com a resolução de institucionalização da e-PING no
âmbito da APF – Poder Executivo;
• Publicação da versão 1.5, contendo as atualizações e revisão das especificações
técnicas e da visão geral da e-PING. As versões 1.1 até 1.4 ficaram em discussão interna
aos grupos de trabalho e à coordenação da e-PING;
• Realização de consulta pública e audiências públicas de modo a colher contribuições, da
sociedade em geral, a cada nova versão do documento de referência;
• Publicação de versão anual, contendo as atualizações e revisões das especificações
técnicas e da visão geral da e-PING.
Experiências semelhantes desenvolvidas por governos de outros países são constantemente
pesquisadas. A e-GIF – Government Interoperability Framework – do governo britânico foi adotada
como base para construção da arquitetura de interoperabilidade do governo brasileiro. A gestão da
e-PING está apoiada na forma implementada pelo governo do Reino Unido, em operação desde o
ano 2000, e, atualmente, situada num grau de maturidade internacionalmente reconhecido como
referência.

5.2. Estratégia de Implantação

A divulgação dos padrões e especificações estabelecidos pelo governo brasileiro segue o esquema

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 15


Documento de Referência da e-PING – Versão 2011

de versionamento. É prevista a elaboração de uma versão anual, com publicação intermediária de


atualizações, sempre que existirem modificações significativas.
A presente versão consolidou o trabalho dos grupos montados para os cinco segmentos definidos.
Todo seu conteúdo foi disponibilizado para Consulta Pública, com o objetivo de obter contribuições
às propostas de padrões publicados na minuta da versão 2011.

5.3. Modelo de Gestão

Neste item são especificadas as formas de gestão da arquitetura e-PING, sendo relacionadas as
principais atribuições e a forma de implementação dessas atividades na organização estrutural do
governo.

5.3.1. Atribuições

A Gestão da e-PING compreende o desempenho de atribuições de ordem administrativa e de


ordem técnica.
Dentre as atribuições de caráter administrativo, destacam-se:
• Definir os objetivos estratégicos e de gestão de governo para o estabelecimento dos padrões;
• Administrar a arquitetura de interoperabilidade do governo brasileiro, provendo a
infraestrutura gerencial necessária para sua correta utilização e garantindo sua atualização,
considerando: as prioridades e metas de governo, as necessidades da sociedade e a
disponibilidade de novas tecnologias maduras e suportadas pelo mercado de TIC;
• Atuar como centro de coordenação da arquitetura e-PING, buscando alinhamento dos
esforços de interoperabilidade, assegurando a coerência das iniciativas empreendidas pelos
órgãos de governo;
• Especificamente para os segmentos de Interoperabilidade, administrar o relacionamento do
governo federal – Poder Executivo – com as demais instâncias definidas no item 2 - Escopo;
• Gerenciar e operacionalizar a divulgação dos padrões da e-PING, considerando:
• Criação e administração de um sítio na Internet para a e-PING
(http://www.eping.e.gov.br);
• Coordenação do processo de consultas públicas;
• Coordenação do processo de recebimento e avaliação de proposições de alteração e
complementação;
• Coordenação do processo de solicitação de sugestões para a e-PING;
• Publicação das versões atualizadas da e-PING e das atualizações intermediárias;
• Gerenciar a interação com iniciativas de mesmo propósito, conduzidas por outros governos,
no país e no exterior;
• Incentivar a capacitação das equipes do governo federal, atuando em conjunto com os
órgãos, tanto na consideração da e-PING nos planos específicos de treinamento de cada um
deles como na realização de eventos corporativos direcionados para disseminação dos
padrões e-PING;
• Estabelecer, implantar e divulgar indicadores de acompanhamento dos resultados obtidos
com a implantação da e-PING;
• Gerenciar a interação com organismos de especificação (W3C, IEEE, BSI, OMG, OGC,
OASIS, IETF, Institutos Normativos de segmentos específicos, como ABNT, INMETRO, ISO,
NIST, etc). Estes organismos serão escolhidos a critério da coordenação da e-PING levando
em consideração o seu notório reconhecimento internacional, competência em sua área de
atuação e o estabelecimento de padrões abertos;
• Gerenciar a interação com órgãos de fomento nacionais e internacionais, para canalizar
recursos, visando atender as necessidades de criação de infraestrutura da e-PING e
promover a pesquisa e desenvolvimento;
• Viabilizar a implantação e gerenciar o processo de homologação dos padrões a serem
estabelecidos para o governo;
• Viabilizar a implantação e gerenciar processos de auditoria realizados com a finalidade de
verificar o nível de adesão às recomendações e especificações da e-PING;
• Atuar cooperativamente, como apoio aos órgãos de governo, na realização dos processos
necessários para adequação aos padrões e-PING; avaliar a possibilidade de patrocinar
programas abrangentes que promovam a utilização intensiva dos padrões propostos.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 16


Documento de Referência da e-PING – Versão 2011

Dentre as atribuições de caráter técnico, destacam-se:


• Estabelecer as formas de elaboração e de manutenção das políticas e especificações
técnicas que compõem a e-PING, considerando:
• Identificação, criação e gestão de grupos de trabalho específicos;
• Estabelecimento de convênios e definição de instituições de governo como responsáveis
pelas políticas e especificações técnicas de componentes específicos dos segmentos de
interoperabilidade;
• Identificação e implementação de formas alternativas de gerenciamento técnico dos
assuntos contemplados na abrangência de atuação da e-PING;

• Coordenar o desenvolvimento e manutenção, no âmbito do governo federal – Poder


Executivo, de:
• Padrão de Metadados de Governo (e-PMG);
• Vocabulário Controlado do Governo Eletrônico (VCGE);
• Catálogo de Padrões de Dados (CPD);
• Catálogo de Referência dos XML Schemas;
• Demais padrões de Organização e Intercâmbio de Informações;
• Padrões de Interconexão;
• Padrões de Segurança;
• Padrões de Meios de Acesso a serviços eletrônicos de governo;
• Padrões de uso de Cartões Inteligentes, Tokens e outros tipos de cartão;
• Modelo Global de Dados (MGD);
• Guia de Gestão de Processos de Governo (GGPG);
• Política de Disseminação de Dados e Informações.
• Garantir a unicidade de concepção, conceitos, definições e estabelecimento de padrões por
parte dos responsáveis pelos segmentos técnicos definidos para a e-PING.

5.3.2. Responsabilidades

A estrutura de governo criada para administração da e-PING é apresentada no esquema


simplificado a seguir.

Figura 2 – Administração da e-PING.

A SLTI/MP, por meio do instrumento do Sistema de Administração dos Recursos de Informação e


Informática (SISP), instituído pelo Decreto 1.048, de 21 de janeiro de 1994, é a responsável pela
institucionalização e pela definição do formato jurídico da Coordenação da e-PING.
A atuação da Coordenação da e-PING será pautada pelos seguintes pontos:
• Implantação da arquitetura e-PING, providenciando as atividades necessárias para
consolidação da versão atual e dinâmica da sua evolução;
• Gestão da arquitetura e-PING;
• Estabelecimento e gestão das normas e dos instrumentos institucionais e legais que
garantam a efetividade das recomendações e especificações da e-PING;
• Administração dos padrões considerados na e-PING;
• Garantia de manutenção da atualização dos diversos catálogos da e-PING;
• Gestão dos processos de Comunicação e Divulgação dos padrões, das decisões e das
atividades da e-PING, incluindo a publicação de novas versões e das atualizações

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 17


Documento de Referência da e-PING – Versão 2011

intermediárias;
• Criação de um selo e-PING e administração de processo que certifique a aderência de
determinado serviço ou produto à e-PING;
• Fornecimento de critérios e subsídios para a elaboração da Lei Orçamentária Anual do
governo federal;
• Gestão dos processos de contratação dos serviços e de estabelecimento de convênios para
realização das atribuições necessárias para consolidação dos padrões, como, por exemplo,
avaliação de propostas de projetos de e-gov voltados para a Administração Pública Federal,
homologação de padrões e verificação de conformidade;
• Estabelecimento dos pontos de contato com os diversos órgãos da Administração Pública
Federal;
• Administração dos Grupos de Trabalho – GT, definindo sua composição e determinando as
diretrizes de trabalho, baseadas nas políticas técnicas, gerais e especificas, nas
necessidades de governo e na monitoração do cenário tecnológico.

Os Grupos de Trabalho da e-PING, constituídos por representantes indicados pelos vários órgãos
da APF e por representantes de instituições de outras esferas de governos, são responsáveis por:
• Tratar os assuntos que compõem os segmentos da e-PING;
• Monitorar sistematicamente o mercado, especificamente para os segmentos sob sua
responsabilidade, com o objetivo de detectar as necessidades de atualização tecnológica das
políticas e especificações técnicas;
• Subsidiar a atuação da Coordenação da e-PING, no desempenho de suas atribuições
administrativas e técnicas.
Os coordenadores dos Grupos de Trabalho terão assento na Coordenação da e-PING.

5.4. Atividades adicionais

Além das atribuições de caráter administrativo e técnico para implantação e manutenção evolutiva
da arquitetura e-PING, outras atividades estarão sob responsabilidade da Coordenação da e-PING.

5.4.1. Seleção e Homologação de Padrões Tecnológicos

As políticas técnicas contidas neste documento fundamentam os padrões da e-PING, prestando-se


como referência na seleção dos componentes para os quais são estabelecidas as especificações
técnicas.
A e-PING prevê um processo de análise dos padrões candidatos a integrar a arquitetura. Esse
processo abrange a seleção, a homologação e a classificação das especificações selecionadas em
cinco níveis de situações, que caracterizam o grau de aderência às políticas técnicas gerais e
específicas de cada segmento.
Esses cinco níveis são os seguintes:
• Adotado (A): item adotado pelo governo como padrão na arquitetura e-PING, tendo sido
submetido a um processo formal de homologação realizado por parte de uma instituição do
governo ou por uma outra instituição com delegação formal para realizar o processo.
Também é considerado homologado quando baseado em uma proposição devidamente
fundamentada pela coordenação do segmento, publicada no sítio e aprovado pela
Coordenação da e-PING;
• Recomendado (R): item que atende às políticas técnicas da e-PING, é reconhecido como
um item que deve ser utilizado no âmbito das instituições de governo, mas ainda não foi
submetido a um processo formal de homologação;
• Em Transição (T): item que o governo não recomenda, por não atender a um ou mais
requisitos estabelecidos nas políticas gerais e técnicas da arquitetura; é incluído na e-PING
em razão de seu uso significativo em instituições de governo, tendendo a ser desativado
assim que algum outro componente, em uma das duas situações anteriores venha a
apresentar condições totais de substituí-lo. Pode vir a ser considerado um componente
“recomendado” caso venha a se adequar a todas as políticas técnicas estabelecidas.
Convém salientar que o desenvolvimento de novos serviços ou a reconstrução de partes
significativas dos já existentes deve evitar o uso de componentes classificados como
transitórios;

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 18


Documento de Referência da e-PING – Versão 2011

• Em Estudo (E): componente que está em avaliação e poderá ser enquadrado numa das
situações acima, assim que o processo de avaliação estiver concluído;
• Estudo Futuro (F): componente ainda não avaliado e que será objeto de estudo posterior.

O processo de seleção dos componentes adotados pela e-PING e sua consequente classificação
nas situações acima indicadas, é de responsabilidade dos Grupos de Trabalho compostos por
profissionais especialistas com atuação no governo e em instituições com as quais seja
estabelecido algum tipo de convênio ou contrato especificamente para essa finalidade.
A seleção é feita a partir de sugestões formalizadas, demandas internas dos órgãos do governo
federal, Poder Executivo, e pesquisas realizadas pelos Grupos de Trabalho.
Já a homologação deverá ser objeto de estudo mais aprofundado por parte dos gestores da e-
PING. Em virtude da grande variedade de componentes tratados pela arquitetura, haverá
necessidade de elaboração de uma sistemática de homologação que contemple desde processos
em que será indispensável a avaliação de características físicas de determinados componentes
(Cartões Inteligentes, por exemplo) até outros em que sejam requeridos estudos de aspectos que
envolvam o uso do componente no desenvolvimento e construção de serviços (organização e
intercâmbio de informações e segurança, por exemplo).
Nesse caso, o governo deverá estabelecer convênios ou credenciar instituições para elaboração
de testes de conformidade, sempre definindo quais componentes devem ser submetidos a
processos de homologação, quais os critérios de avaliação dos resultados e quais as condições de
realização dos procedimentos.
A definição completa do processo de seleção e homologação, levando em consideração as
especificidades dos segmentos, ficará a cargo da Coordenação da e-PING.

5.4.2. Auditoria de Conformidade

O cumprimento das especificações e recomendações por parte dos órgãos do governo federal –
Poder Executivo, é fator crítico de sucesso na implantação e consolidação da e-PING. Os gestores
da e-PING recomendarão a realização de processos de auditoria para verificação do atendimento
às especificações e políticas da arquitetura.
Poderá haver delegação de responsabilidade para equipes especialmente montadas para essa
finalidade, compostas por técnicos de governo com experiência em procedimentos dessa natureza.
A forma preferencial de realização desse tipo de procedimento, entretanto, será a utilização das
estruturas próprias nos órgãos responsáveis por auditoria de sistemas. A Coordenação da e-PING
atuará no sentido de sugerir os critérios básicos a serem seguidos pelos órgãos. Para tal, foi
constituído, por intermédio da Portaria nº 8, de 31 de outubro de 2008, da SLTI/MP, Grupo de
Trabalho para estudar, analisar e propor modelo de auditoria quanto à aderência aos padrões da e-
PING. Essa proposta também contemplará o modelo de maturidade da e-PING (M-PING).
Outra questão a ser considerada será a colaboração de órgãos de governo atuantes na área,
prevendo-se contatos com instituições de outros Poderes e esferas de governo.

5.4.3. Criação e Manutenção do Sítio

Todo o processo de troca de informações sobre a e-PING com usuários, colaboradores e


interessados é realizado, preferencialmente, pela Internet, no endereço http://www.eping.e.gov.br
Em seu estágio mais avançado de funcionamento, o sítio da e-PING terá, como principais
funcionalidades:
• Divulgação completa da documentação relativa à arquitetura: versões oficiais e respectivas
atualizações da arquitetura, versões para consultas públicas, documentação técnica de
apoio, documentação legal e institucional correlata;
• Disponibilidade das recomendações, determinações, especificações técnicas e políticas para
validação, homologação e recebimento de comentários e sugestões por parte da sociedade;
• Publicação de solicitação de comentários relativos à especificação de componentes para a
arquitetura;
• Disponibilidade de meio eletrônico para recebimento de sugestões;

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 19


Documento de Referência da e-PING – Versão 2011

• Disponibilidade de links para documentos, padrões, normas ou qualquer outro tipo de


referência constante na e-PING.

5.4.4. Acompanhamento Legal e Institucional

A e-PING terá apoio constante da equipe da Assessoria Jurídica do Ministério do Planejamento,


Orçamento e Gestão para garantir a aderência do conteúdo dos documentos que compõem a
arquitetura às normas e instrumentos legais vigentes no país.
Adicionalmente, essa Assessoria terá ainda a responsabilidade de preparar toda a parte
institucional necessária para garantir que as adequações e recomendações da e-PING venham a
compor o conjunto de instrumentos legais de TIC no país.
A Coordenação da e-PING poderá atuar no sentido de estabelecer uma forma de colaboração com
algum outro órgão de governo que tenha condições de fornecer sua estrutura de apoio jurídico
para realização dessa atividade.

5.4.5. Divulgação

Será dada total publicidade a todo o conteúdo da e-PING. As principais formas de divulgação
previstas, além do sítio na Internet, são:
• Realização de eventos específicos de divulgação, como Seminários, Workshops e
apresentações em geral;
• Participação em eventos governamentais na área de TIC e correlatas;
• Participação em eventos direcionados a públicos específicos;
• Publicação de todas as versões da e-PING e das atualizações intermediárias;
• Intercâmbio com outras esferas e outros Poderes de governo, com instituições públicas,
privadas e do terceiro setor e com governos de outros países.

5.4.6. Capacitação

Farão parte da agenda de implantação e gestão da e-PING eventos direcionados para


capacitação. Também é previsto o uso intensivo de Ensino a Distância (EAD).
A Coordenação da e-PING irá elaborar e publicar uma grade mínima de treinamento, de modo que
cada órgão da APF tenha subsídios para planejar e estimar investimentos necessários para
capacitação dos profissionais envolvidos no processo de adequação às recomendações da e-
PING.
Cada órgão de governo deverá observar as definições de padrão da e-PING na montagem de seus
planos particulares de capacitação, garantindo o fornecimento de treinamento adequado para os
componentes de suas equipes técnicas.

5.5. Relacionamento com Governo e Sociedade

Neste item são tratadas as formas de relacionamento da e-PING com as entidades que compõem
o governo e a sociedade.

5.5.1. Organizações do Governo Federal – Poder Executivo

No âmbito do Poder Executivo, a participação de todos os níveis hierárquicos da Administração


Pública Federal, suas agências e organismos reguladores e as empresas e instituições públicas é
essencial para a promoção e consolidação da interoperabilidade no setor público.
Embora as diretrizes gerais sejam geridas pela Coordenação da e-PING, cada instituição em
particular terá sua responsabilidade na gestão e garantia de uso dos padrões e-PING. Dentre as
atribuições dessa natureza, destacam-se:
• Contribuir para o desenvolvimento e melhoria contínua da e-PING;
• Garantir que suas estratégias organizacionais de TIC considerem que os sistemas

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 20


Documento de Referência da e-PING – Versão 2011

integrantes de serviços de governo eletrônico sob sua responsabilidade estejam adequados


às recomendações da e-PING;
• Dispor de um plano de implementação e adequação da infraestrutura de TIC da organização
à arquitetura e-PING;
• Assegurar que sejam de domínio das equipes da instituição, as habilidades para definir e
utilizar as especificações requeridas para interoperabilidade, fornecendo suporte de
treinamento quando necessário;
• Estabelecer ponto de contato nas instituições, para intercâmbio de informações e de
necessidades com a Coordenação da e-PING;
• Alocar e suprir recursos para dar suporte aos seus processos de adequação à e-PING;
• Aproveitar a oportunidade para racionalizar processos (como resultado do aumento da
interoperabilidade) de maneira a melhorar a qualidade e reduzir custos de provimento dos
serviços de e-gov.

5.5.2. Outras Instâncias de Governo (outros Poderes Federais, Governos Estaduais e


Municipais)

A adoção da e-PING é obrigatória para os órgãos e entidades do governo federal – Poder


Executivo. Aos outros Poderes (Judiciário, Legislativo) e outras esferas de governo (estadual e
municipal) a adoção é facultativa.
A coordenação da e-PING atua proativamente visando a adoção da e-PING pelos entes
integrantes de outras esferas e poderes, dada a relevância do intercâmbio de informações entre
esferas e poderes para a eficiência, eficácia e efetividade da atuação governamental e para a
construção de serviços de governo eletrônico orientados à sociedade, em especial, ao cidadão.
Para facilitar a adoção da e-PING pelos governos estaduais, a ABEP participa da coordenação da
e-PING, atuando em colaboração com a coordenação da e-PING na construção de uma matriz de
interesses federativos para troca de informações.

5.5.3. Organizações do Setor Privado e do Terceiro Setor

A e-PING prevê a interação com o Setor Privado e com o Terceiro Setor por meio dos mecanismos
de Consulta Pública, Solicitação de Comentários e Recebimento de Sugestões.
Todas as entidades dessa natureza que participarem de processos de licitação para fornecimento
de produtos e serviços para o Poder Executivo Federal deverão atender às especificações e
recomendações da e-PING.
Outras formas de participação dessas instituições na e-PING podem ser consideradas,
estabelecendo-se critérios que garantam a transparência e equidade de oportunidades.

5.5.4. Cidadão

Governo eletrônico significa, essencialmente, o governo servir melhor às necessidades do cidadão


utilizando os recursos de Tecnologia, Informação e Comunicação. A arquitetura e-PING possibilita
a integração e torna disponíveis serviços de forma íntegra, segura e coerente, permitindo obter
melhores níveis de eficiência no governo.
O governo deve incentivar a sociedade a opinar, comentar, e contribuir com sugestões de
inovações que possam ajudá-lo a melhorar o acesso à informação e a prestação de seus serviços.
Todos os processos de divulgação e de inter-relacionamento da e-PING preveem a participação
ativa do cidadão e da sociedade em geral, no processo de construção e gestão da arquitetura.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 21


Documento de Referência da e-PING – Versão 2011

Parte II – Especificação Técnica dos Componentes da e-PING

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 22


Documento de Referência da e-PING – Versão 2011

6. Interconexão

6.1. Interconexão: Políticas Técnicas

As políticas técnicas para interconexão são:


6.1.1. Os órgãos da APF deverão se interconectar utilizando IPv4 e planejar sua futura migração
para IPv6. Novas contratações e atualizações de redes devem prever suporte à coexistência dos
protocolos IPv4 e IPv6 e a produtos que suportem ambos os protocolos.
6.1.2. Os sistemas de e-mail devem utilizar SMTP/MIME para o transporte de mensagens. Para
acesso às mensagens, devem ser utilizados os protocolos POP3 e/ou IMAP, sendo encorajado o
uso de interfaces web para correio eletrônico, observados quando necessário os aspectos de
segurança.
6.1.3. Os órgãos da APF devem obedecer à política de nomeação de domínios do governo federal,
estabelecida na Resolução nº 7, que pode ser visualizada no endereço eletrônico
https://www.planalto.gov.br/ccivil_03/Resolução/2002/RES07-02web.htm.
6.1.4. O DNS deve ser utilizado para resolução de nomes de domínios Internet, convertendo-os em
endereços IP e, inversamente, convertendo IPs em nomes de domínios, através da manutenção
dos mapas direto e reverso, respectivamente.
6.1.5. Os protocolos FTP e/ou HTTP devem ser utilizados para transferência de arquivos,
observando suas funcionalidades para recuperação de interrupções e segurança, quando
necessário. O HTTP deve ser priorizado para transferências de arquivos originários de páginas de
sítios da Internet.
6.1.6. Sempre que possível(1), deve ser utilizada tecnologia baseada na web em aplicações que
utilizaram Emulação de Terminal anteriormente.
6.1.7. A tecnologia de Web Services é recomendada como solução de interoperabilidade da e-
PING. Recomenda-se a utilização do protocolo Simple Object Access Protocol (SOAP) para
interconexão em arquiteturas descentralizadas e/ou distribuídas para implementação de serviços
em sistemas de qualquer porte. Alternativamente, para serviços web de pequeno porte, considera-
se possível o desenvolvimento de projetos baseados em REST, que utiliza o protocolo HTTP.

6.2. Interconexão: Especificações Técnicas

Tabela 1 – Especificações para Interconexão – Mensageria2

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Endereços de caixa As regras para definição dos nomes das caixas A
postal eletrônica postais de correio eletrônico deverão seguir ao
estabelecido no documento “Caixas Postais
Individuais-Funcionais no governo federal”,
disponível no endereço eletrônico
http://www.e.gov.br/correios/cp_individ.htm

1
Existem produtos que podem fornecer acesso pelo browser aos sistemas legados, sem necessidade de
mudar esses sistemas; tipicamente estes produtos podem fornecer acesso direto às telas de legado ou serem
substituídas por interfaces gráficas (GUIs). Deve-se prestar atenção a qualquer implicação de segurança em
relação a seu uso.
2
As RFCs podem ser acessadas em http://www.ietf.org/rfc.html

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 23


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Transporte de Utilizar produtos de mensageria eletrônica que A
mensagem suportam interfaces em conformidade com
eletrônica SMTP/MIME para transferência de mensagens. RFC
correlacionadas: RFC 5321, RFC 5322, RFC 2045,
RFC 2046, RFC 3676, RFC 2047, RFC 2231
(atualização das RFC 2045, 2047 e 2183), RFC
2183, RFC 4288, RFC 4289, RFC 3023 e RFC 2049.
Acesso à caixa Post Office Protocol – POP3 para acesso remoto a T
postal caixa postal. RFC correlacionada: RFC 1939
(atualizada pela RFC 1957 e RFC 2449).
Internet Message Access Protocol – IMAP para A
acesso remoto à caixa postal. RFCs correlacionadas:
RFC 2342 (atualizada pela RFC 4466), RFC 2910
(atualizada pela RFC 3380, RFC 3381, RFC 3382,
RFC 3510 e RFC 3995), RFC 2971, RFC 3501, RFC
3502 e RFC 3503.
Mensageria em O modelo e requisitos para Instant Messaging and T
Tempo Real Presence Protocol (IMPP) são definidos pela RFC
2778 e RFC 2779.
O modelo e requisitos para Extensible Messaging R
and Presence Protocol (XMPP) são definidos pela
RFC 3920 e RFC 3921.
AntiSpam – Implementar submissão de e-mail via porta 587/TCP E
Gerenciamento da com autenticação, reservando a porta 25/TCP
Porta 25 apenas para transporte entre servidores SMTP,
conforme recomendação CGI / Cert.br
http://www.cert.br/

Tabela 2 – Especificações para Interconexão – Infraestrutura de Rede

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Transporte TCP (RFC 793) A
UDP (RFC 768) quando necessário, sujeito às A
limitações de segurança.
Intercomunicação IPv4 conforme RFC 791 (atualizada pela RFC 1349). A
LAN/WAN
IPv6 conforme RFC 2460 (atualizada pela RFC 5095, E
RFC 5722 e RFC 5871).
Tráfego avançado Quando necessário, o tráfego de rede pode ser A
otimizado pelo uso do MPLS (RFC 3031), devendo
este possuir, no mínimo, quatro classes de serviço.
Qualidade de Adoção de uma arquitetura para serviços E
serviço diferenciados pelo uso do Diffserv (RFC 2475,
atualizada pela RFC 3260).
Rede metropolitana IEEE 802.16, em conformidade com as E

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 24


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


sem fio determinações do WiMax Forum
(http://www.wimaxforum.org) e com as normas da
Anatel (http://www.anatel.gov.br).
Rede local sem fio IEEE 802.11 b, em conformidade com as T
determinações do Wi-Fi Alliance (http://www.wi-fi.org)
e com as normas da Anatel
(http://www.anatel.gov.br).

IEEE 802.11 g, em conformidade com as A


determinações do Wi-Fi Alliance (http://www.wi-fi.org)
e com as normas da Anatel
(http://www.anatel.gov.br).

IEEE 802.11 n, em conformidade com as F


determinações do Wi-Fi Alliance (http://www.wi-fi.org)
e com as normas da Anatel
(http://www.anatel.gov.br).
Rede de acesso por Power Line Communication (PLC), segundo as F
cabeamento elétrico normas da Anatel (http://www.anatel.gov.br) e da
Aneel (http://www.aneel.gov.br).

Tabela 3 – Especificações para Interconexão – Serviços de Rede

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Protocolo de Utilizar HTTP/1.1 (RFC 2616). A
transferência de
hipertexto
Protocolos de FTP (com re-inicialização e recuperação) conforme R
transferência de RFC 959 (atualizada pela RFC 2228, RFC 2640, RFC
arquivos 2773, RFC 3659 e RFC 5797) e HTTP conforme RFC
2616 (atualizada pela RFC 2817 e RFC 5785) para
transferência de arquivos.
Diretório LDAP v3 deverá ser utilizado para acesso geral ao A
diretório, conforme RFC 4510.
Sincronismo de RFC 5905 IETF - Network Time Protocol - NTP A O Simple Network
tempo version 4.0. Time Protocol – SNTP
version 4.0 está
definido na seção 14
da RFC 5905.
Serviços de O DNS deve ser utilizado para resolução de nomes A
Nomeação de de domínios Internet, conforme a RFC 1035
Domínio (atualizada pela RFC 1183, RFC 1348, RFC 1876,
RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC
2136, RFC 2181, RFC 2137, RFC 2308, RFC 2535,
RFC 1101, RFC 3425, RFC 3658, RFC 4033, RFC
4034, RFC 4035, RFC 4343, RFC 5936 e RFC 5966).
Por sua vez, as diretivas de nomeação de domínio do
governo brasileiro são encontradas na Resolução nº
7 do Comitê Executivo do Governo Eletrônico, no
endereço eletrônico

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 25


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


https://www.planalto.gov.br/ccivil_03/Resolução/2002/
RES07-02web.htm
Além dessas diretivas, por decisão do Comitê Gestor
da Internet no Brasil, a nomeação de domínios
obedece às orientações do Ministério do
Planejamento, Orçamento e Gestão, a quem
compete gerenciar os domínios .GOV.BR.
As particularidades de outros níveis de governo,
como por exemplo, os domínios dos governos das
Unidades da Federação, que incluem a sigla da UF
na composição dos endereços, são abordadas no
endereço eletrônico http://registro.br/faq/faq1.html#12
Protocolos de Uso do Protocolo de Inicialização de Sessão (SIP), A
sinalização definido pela RFC 3261 (atualizada pela RFC ,
RFC3265, RFC4320, RFC4916, RFC5393, RFC5621,
RFC5626, RFC5630, RFC5922, RFC5954 e
RFC6026), como protocolo de controle na camada de
aplicação (sinalização) para criar, modificar e
terminar sessões com um ou mais participantes.
Uso do protocolo H.323 em sistemas de T
comunicação multimídia baseado em pacotes,
definido pela ITU-T (International Telecommunication
Union Telecommunication Standardization sector).
Protocolos de Uso do protocolo SNMP, definido pelas RFC 3411 T Versão 2
gerenciamento de (atualizada pela RFC 5343 e RFC 5590) e 3418,
R Versão 3
rede como protocolo de gerência de rede.
Protocolo de troca SOAP v1.2, como definido pelo W3C A
de informações http://www.w3.org/TR/soap12-part1/
estruturadas em http://www.w3.org/TR/soap12-part2/
plataforma
descentralizada e/ou Especificações do protocolo SOAP podem ser
distribuída encontradas em http://www.w3.org/TR/soap12-part0/
Protocolo de análise IPFix F
de tráfego de rede

6.3. Mensagem Eletrônica (E-mail)

Para efeito de clareza, a e-PING utilizará os seguintes conceitos:

Transporte de Mensagem Eletrônica


O transporte de mensagem eletrônica é definido como a interface entre dois sistemas de correio.

Acesso à caixa postal


Acesso à caixa postal é definido como a interface entre um cliente de correio e um sistema de
correio.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 26


Documento de Referência da e-PING – Versão 2011

Figura 3 – Interfaces entre sistemas e clientes de Correio.

6.4. VPN

Virtual Private Network (VPN), ou Rede Privada Virtual, é um túnel virtual privativo construído sobre
a infraestrutura de uma rede pública ou privada. Em vez de se utilizar circuitos dedicados ou redes
de pacotes para conectar redes remotas, utiliza-se usualmente a infraestrutura da Internet.
Tal utilização, como infraestrutura de conexão entre hosts da rede privada, é uma boa solução em
termos de custos, mas não em termos de privacidade, pois os dados em trânsito podem ser lidos
por qualquer equipamento, sendo necessário o uso de VPN.
Os túneis virtuais trafegam dados criptografados sobre redes pública ou privadas, formando um
canal virtual seguro através dessas redes. Para tanto, são utilizados protocolos de tunelamento.
Os dispositivos responsáveis pelo gerenciamento da VPN devem ser capazes de garantir
privacidade, integridade e autenticidade dos dados.
As especificações sobre VPN estão apresentadas no segmento de segurança.

6.5. Redes peer-to-peer

Sistemas Peer-to-Peer (P2P) são sistemas distribuídos que consistem de nodos interconectados,
com capacidade de se auto-organizarem em topologias de rede, com o objetivo de compartilhar
recursos como processamento, armazenamento e largura de banda, capazes de se adaptar a
falhas e acomodar populações transientes de nodos, enquanto mantêm conectividade e
performance aceitáveis, sem depender da intermediação ou suporte de uma autoridade (servidor)
central.
Embora sistemas P2P possam contribuir para compartilhamento de recursos e colaboração em
larga escala, com controle descentralizado e baixo acoplamento, ainda estão suscetíveis a
diversos problemas de segurança. Este assunto será abordado em momento futuro.

6.6. Serviço SMS (Short Message Service)

Serviço de mensagem de texto que habilita mensagens curtas que contenham não mais que 160
caracteres de tamanho. O enfoque da e-PING em relação a essa especificação deve ser adstrito a
fomentar serviços governamentais prestados ao cidadão utilizando a tecnologia descrita, que é
amplamente suportada pelo mercado e é acessível à grande maioria da população. Não é enfoque
da e-PING regulamentar essa tecnologia, sendo esta uma competência da ANATEL.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 27


Documento de Referência da e-PING – Versão 2011

7. Segurança

7.1. Segurança: Políticas Técnicas

7.1.1. Os dados, informações e sistemas de informação do governo devem ser protegidos contra
ameaças de forma a reduzir riscos e garantir a integridade, confidencialidade, disponibilidade e
autenticidade, observando-se Política de Segurança da Informação e Comunicações, favorecendo
assim, a interoperabilidade.
7.1.2. Os dados e informações devem ser mantidos com o mesmo nível de proteção,
independentemente do meio em que estejam sendo processados, armazenados ou trafegando.
7.1.3. As informações classificadas e sensíveis que trafegam em redes inseguras, incluindo as sem
fio, devem ser criptografadas, de modo adequado, conforme os componentes de segurança
especificados neste documento.
7.1.4. Os requisitos de segurança da informação, dos serviços e de infraestrutura devem ser
identificados e tratados de acordo com a classificação da informação, níveis de serviço definidos e
resultado da análise de riscos.
7.1.5. A segurança deve ser tratada de forma preventiva. Para os sistemas que apoiam processos
críticos devem ser elaborados planos de continuidade, nos quais serão tratados os riscos residuais
visando atender os níveis mínimos de produção.
7.1.6. A segurança é um processo que deve estar inserido em todas as etapas do ciclo de
desenvolvimento de um sistema.
7.1.7. Os sistemas devem possuir registros históricos (logs) para permitir auditorias e provas
materiais, sendo imprescindível a adoção de um sistema de sincronismo de tempo centralizado,
bem como deve-se utilizar mecanismos que garantam a autenticidade dos registros armazenados,
se possível com assinatura digital.
7.1.8. Os serviços de segurança de XML devem estar em conformidade com as especificações do
W3C.
7.1.9. Nas redes sem fio metropolitanas recomenda-se a adoção de valores randômicos nas
associações de segurança, diferentes identificadores para cada serviço e a limitação do tempo de
vida das chaves de autorização.
7.1.10. O uso de criptografia e certificação digital, para a proteção do tráfego, armazenamento de
dados, controle de acesso, assinatura digital e assinatura de código, deve estar em conformidade
com as regras da ICP-Brasil.
7.1.11. A documentação dos sistemas, dos controles de segurança e das topologias dos ambientes
deve ser mantida atualizada e protegida, mantendo-se grau de sigilo compatível.
7.1.12. Os usuários devem conhecer suas responsabilidades com relação à segurança e devem
estar capacitados para a realização de suas tarefas e utilização correta dos meios de acesso.
7.1.13. Os Órgãos da APF, visando a melhoria da segurança, devem ter como referência: Decreto
nº 3.505/2000, Decreto nº 4.553/2002, a Instrução Normativa nº 01/2008 – GSI/PR e suas Normas
Complementares; as normas NBR ISO/IEC 27002:2005 – código de prática para a gestão da
segurança da informação; NBR ISO/IEC 27001:2006 – sistemas de gestão de segurança da
informação; NBR 15999-1:2007 e 15999-2:2008 – gestão de continuidade de negócios; e NBR
ISO/IEC 27005:2008 – gestão de riscos de segurança da informação.
7.1.14. Para especificações sobre cartões inteligentes e tokens, deverão ser adotados os requisitos
contidos nos normativos que tratam da homologação de equipamentos e sistemas no âmbito da
Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil (http://www.icpbrasil.gov.br/). Estes
requisitos, observados por produtos homologados na ICP-Brasil, tais como mídias que armazenam
os certificados digitais e respectivas leitoras, além dos sistemas e equipamentos necessários à
realização da certificação digital, estabelecem padrões e especificações técnicas mínimas, a fim de
garantir a sua interoperabilidade e a confiabilidade dos recursos de segurança da informação por
eles utilizados. Importante observar que os dados armazenados em um determinado cartão
inteligente ou token não poderão estar protegidos por qualquer tipo de licenciamento que proíba a
sua leitura por qualquer outro software que não o do fornecedor daquele cartão inteligente ou

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 28


Documento de Referência da e-PING – Versão 2011

token.

7.2. Segurança: Especificações Técnicas

Tabela 4 – Especificações para Segurança – Comunicação de dados

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Transferência de TLS – Transport Layer Security, RFC 52463 R Consultar errata para
dados em redes (atualizada pela RFC 5746 e RFC 5878). Caso seja RFC 5246 e RFC
inseguras pelos necessário o protocolo TLS v1 pode emular o SSL 2818.
protocolos HTTP, v3.
LDAP, IMAP, POP3,
Telnet. HTTP sobre TLS, RFC 2818 (atualizada pela RFC
5785).
Podendo implementar os seguintes algoritmos
criptográficos:

- Algoritmos para troca de chaves de sessão, durante


o handshake:
RSA, Diffie-Hellman RSA, Diffie-Hellman DSS,
DHE_DSS, DHE_RSA;

- Algoritmos para definição de chave de cifração:


RC4, IDEA, 3DES e AES;

- Algoritmos que implementam a função de hash para


definição do MAC:
SHA-256 ou SHA-512.

- Tipo de Certificado Digital - X.509 v3 - ICP-Brasil,


http://www.iti.gov.br
SASL - Simple Authentication and Security Layer,
RFC 4422.
Segurança de redes IPSec Authentication Header RFC 4303 e RFC 4835 A Consultar errata para
IPv4 para autenticação de cabeçalho do IP. RFC 4303 e RFC
4306.
IKE – Internet Key Exchange, RFC 4306 (atualizada
pela RFC5282), deve ser utilizado sempre que
necessário para negociação da associação de
segurança entre duas entidades para troca de
material de chaveamento.

ESP – Encapsulating Security Payload, RFC 4303


Requisito para VPN – Virtual Private Network.
Segurança de redes O S/MIME v3, RFC 5751 deverá ser utilizado quando A Consultar errata para
IPv4 para protocolos for apropriado para segurança de mensagens gerais RFC 5751.
de aplicação de governo.

3
As RFCs podem ser acessadas em http://www.ietf.org/rfc.html

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 29


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Segurança de redes O IPv6 definido na RFC 2460 (atualizada pela RFC R Consultar errata para
IPv6 na camada de 5095), RFC 5722 e RFC 5871 apresenta RFC 4302 e RFC
rede implementações de segurança nativas no protocolo. 4303.
As especificações do IPv6 definiram dois
mecanismos de segurança: a autenticação de
cabeçalho AH (Authentication Header) RFC 4302 ou
autenticação IP, e a segurança do encapsulamento
IP, ESP (Encrypted Security Payload) RFC 4303.

Tabela 5 – Especificações para Segurança – Correio Eletrônico

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Acesso a caixas O acesso à caixa postal deverá ocorrer através do A Consultar errata para
postais cliente do software de correio eletrônico utilizado, a RFC 2595.
considerando as facilidades de segurança nativas do
cliente. Quando não for possível utilizar o cliente
específico ou for necessário acessar a caixa postal
através de redes não seguras (por exemplo: Internet)
deve-se utilizar HTTPS de acordo com os padrões de
segurança de transporte descritos na RFC 2595
(atualizada pela RFC 4616), que trata da utilização
do TLS com IMAP, POP3 e ACAP.
Conteúdo de e-mail O S/MIME V3 deverá ser utilizado quando for A Consultar errata para
apropriado para segurança de mensagens gerais de RFC 5652, RFC 3370,
governo. Isso inclui RFC 5652, RFC 3370 (atualizada RFC 5754, RFC 2631,
pela RFC 5754), RFC 2631, RFC 5750, RFC 5751 e RFC 5751 e RFC
RFC 5652. 5652.
Transporte de e-mail Utilizar SPF (Sender Policy Framework) nos termos A Consultar errata para
da RFC 4408. RFC 4408.
Identificação de e- Utilizar DKIM (DomainKey Identified Mail) nos termos E Consultar errata para
mail da RFC 4871 (atualizada pela RFC 5672). RFC 4871.
Assinatura Utilizar certificado padrão ICP-Brasil para assinatura A O serviço de
de e-mail, quando exigido. Em conformidade com o assinatura deverá
disposto na Medida Provisória nº 2.200-2, de estar de acordo com
24/08/2001 e Decreto nº 3.996 de 31/10/2001. as normas da Infra-
estrutura de Chaves
Públicas Brasileira –
ICP-Brasil

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 30


Documento de Referência da e-PING – Versão 2011

Tabela 6 – Especificações para Segurança – Criptografia

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Algoritmo de 3DES ou AES R
cifração
Algoritmo para SHA-256 ou SHA-512 Resolução 65 R Os sistemas devem ter
assinatura/hashing suporte para o
algoritmo de hash
MD5 com RSA, para
garantir
compatibilidade com
implementações
anteriores.
Algoritmos para SHA-224 ou SHA-238 E Considerando que
assinatura/hashing foram incluídas no
Relatório Final do
Grupo de Trabalho de
Criptografia I,
instituído pelo
Gabinete de
Segurança
Institucional da
Presidência da
República, porém,
ainda não se
transformaram em
norma na
Administração Pública
Federal.
Algoritmo para RSA A
transporte de chave
criptográfica de
conteúdo/sessão
Algoritmos ECDSA 256 e ECDSA 512 (RFC 5480). A ECDSA, para
criptográficos assinaturas digitais, e
baseados em curvas ECIES para cifração e
elípticas transporte seguro de
chaves criptográficas.
ECIES 256 e ECIES 512 (Resolução nº 65, de
09/06/2009, do Comitê Gestor da Infra-estrutura de Consultar errata para
Chaves Públicas Brasileira – ICP-Brasil). RFC 5480.

ECMQV e ECDH, ambos para acordo de chaves, E


conforme RFC 5753.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 31


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Requisitos de Homologação da ICP-Brasil NSH-2 e NSH-3; R Ver Resolução nº 65,
segurança para FIPS 140-1 e FIPS 140-2. de 09/06/2009, do
módulos Comitê Gestor da
criptográficos Infra-estrutura de
Chaves Públicas
Brasileira – ICP-
Brasil).
Certificado Digital da Devem ser aderentes aos padrões da ICP – Brasil. R Os certificados da AC-
AC-raiz para raiz devem ser
Navegadores e instalados nos
Visualizadores de navegadores e
Arquivos visualizadores de
arquivos conforme
recomendado na IN nº
5/2009/ITI.

Tabela 7 – Especificações para Segurança – Desenvolvimento de Sistemas

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Assinaturas XML Sintaxe e Processamento de assinatura XML A
(XMLsig) conforme definido pelo W3C
http://www.w3.org/TR/xmldsig-core/
Cifração XML Sintaxe e Processamento de Cifração XML (XMLenc) R
conforme definido pelo W3C
http://www.w3.org/TR/xmlenc-core/
Assinatura e Transformação de decifração para assinatura XML R
cifração XML conforme definido pelo W3C
http://www.w3.org/TR/xmlenc-decrypt
Principais XML – Key Management Specification (XKMS 2.0) R
gerenciamentos (Especificações de Gerenciamento de Chave XML)
XML quando um conforme definido pelo W3C
ambiente PKI é http://www.w3.org/TR/xkms2/
utilizado
Autenticação e SAML – conforme definido pelo OASIS quando um R
autorização de ambiente ICP é utilizado http://www.oasis-
acesso XML open.org/committees/security/index.shtml
Intermediação ou WS-Security 1.1 - arcabouço de padrões para R O componente anterior
Federação de garantir integridade e confidencialidade em (SAML) poderá se
Identidades mensagens SOAP. (http://docs.oasis- juntar a este
open.org/wss/2004/01/oasis-200401-wss-soap- componente após
message-security-1.0.pdf). estudos.

WS-Trust 1.3 - extensões para o padrão WS-


Security, definindo o uso de credenciais de
segurança e gerência de confiança distribuída.
(http://docs.oasis-open.org/ws-sx/ws-trust/200512).

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 32


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Navegadores Somente utilizar testemunhas de conexão de caráter A
permanente (cookies) com a concordância do
usuário. Resolução nº 7 do Comitê Executivo do
Governo Eletrônico (Capítulo II, Art.7º).

Tabela 8 – Especificações para Segurança – Serviços de Rede

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Diretório Portaria Normativa nº 2, de 3 de outubro de 2002 - R Consultar errata para
Publicada no D.O. do dia 4 de outubro de 2002. RFC 4511 e RFC
Seção 1, página 85. 4512.
LDAPv3 RFC 4510, RFC 4511, RFC 4512 e RFC
4513 .
LDAP v3 extensão para TLS RFC 4510, RFC 4511 e
RFC 4513.
DNSSEC Resolução nº 7 de 29/07/2002 – Comitê Executivo do R
Governo Eletrônico
Práticas de Segurança para Administradores de
Redes Internet
Centro de Estudos, Respostas e Tratamento de
Incidentes de Segurança no Brasil – CERT.BR
http://www.cert.br/docs/seg-adm-redes/seg-adm-
chklist.pdf Versão 1.2, 16 de maio de 2003.

Transferência de HTTPS RFC 2818 (atualizada pela RFC 5785). R Consultar errata para
arquivos de forma RFC 2818.
segura
SSH FTP E Os documentos ainda
estão no formato de
rascunhos.
Securing FTP with TLS, RFC 4217 e RFC 5246 E Consultar errata para
(atualizada pela RFC 5746 e RFC 5878). RFC 4217 e RFC
5246.

Mensagem RFC 2778, RFC 3261 (atualizada pela RFC 3265, E Consultar errata para
instantânea RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC RFC 3261, RFC 3262,
5621, RFC 5626, RFC 5630, RFC 5922), RFC 3262, RFC 3264, RFC 3265
RFC 3263, RFC 3264 e RFC 3265 (Atualizada pela e RFC 5727.
RFC 5367 e RFC 5727)

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 33


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Carimbo do tempo RFC 3628 TSAs – Policy Requirements for Time- R O serviço de carimbo
Stamping Authorities, Time-Stamp Protocol, do tempo deverá estar
RFC 3161 ETSI TS101861 (Time-Stamping Profile) de acordo com as
(atualizada pela RFC 5816). normas da ICP-Brasil.

Consultar errata para


RFC 3161.

Tabela 9 – Especificações para Segurança – Redes Sem Fio

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
MAN4 sem fio Utilizar PKM-EAP (Privacy Key Management - E
802.16-20045 Extensible Autentication Protocol) com:
802.16.2-20046
802.16e7 e • EAP – TLS ou TTLS;
802.16f8 • AES9 (Advanced Encryption Standard).
LAN sem fio Utilizar a especificação WPA2 (Wi-Fi Protect Access). R
802.11

Tabela 10 – Especificações para Segurança – Resposta a Incidentes de Segurança da


Informação

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Preservação de Guidelines for Evidence Collection and Archiving, R
registros RFC 3227.

4
O 802.16 é definido pelo IEEE como uma interface tecnológica para redes de acesso sem fio metropolitanas
ou WMAN (Wireless Metropolitan Access Network).
5
http://standards.ieee.org/getieee802/download/802.16-2004.pdf.
6
http://standards.ieee.org/getieee802/download/802.16.2-2004.pdf.
7
http://standards.ieee.org/getieee802/download/802.16e-2005.pdf.
8
http://standards.ieee.org/getieee802/download/802.16f-2005.pdf.
9
http://csrc.nist.gov/CryptoToolkit/aes/rijndael/Rijndael.pdf.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 34


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Tratamento e Expectations for Computer Security Incident R
resposta a Response, RFC 2350.
incidentes em redes
computacionais Diretrizes para o processo de Gestão de Riscos de
Segurança da Informação e Comunicações – GRSIC
nos órgãos e entidades da Administração Pública
Federal conforme Norma Complementar nº 04/09
(http://dsic.planalto.gov.br/documentos/nc_04_grsic.p
df).

Criação de equipes de tratamento e resposta a


incidentes em redes computacionais conforme
Norma Complementar nº 05/09
(http://dsic.planalto.gov.br/documentos/nc_05_etir.pdf
).

Diretrizes para Gestão de Continuidade de Negócios,


nos aspectos relacionados à Segurança da
Informação e Comunicações, nos órgãos e entidades
da Administração Pública Federal, direta e indireta –
APF conforme Norma Complementar nº 06/09.
(http://dsic.planalto.gov.br/documentos/nc_6_gcn.pdf)

Diretrizes para Implementação de Controles de


Acesso Relativos à Segurança da Informação e
Comunicações, nos órgãos e entidades da
Administração Pública Federal, direta e indireta –
APF conforme Norma Complementar nº 07/09
(http://dsic.planalto.gov.br/documentos/nc_7_controle
_acesso.pdf).
Informática Forense Guide to Integrating Forensic Techniques into A
Incident Response – NIST - Special Publication 800-
86 – (http://csrc.nist.gov/publications/nistpubs/800-
86/SP800-86.pdf).

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 35


Documento de Referência da e-PING – Versão 2011

8. Meios de Acesso

8.1. Meios de Acesso: Políticas Técnicas

As políticas técnicas para permitir o acesso aos serviços eletrônicos do governo federal para a
sociedade em geral – cidadãos, outras esferas de governo, outros Poderes, servidores públicos,
empresas privadas e outras instituições – são:
8.1.1. Os sistemas de informação do governo devem ser projetados de maneira a respeitar a
legislação brasileira, fornecendo recursos de acessibilidade aos cidadãos portadores de
necessidades especiais, a grupos étnicos minoritários e àqueles sob risco de exclusão social ou
digital. O atendimento via balcão de prestação de serviços deve ser considerado em toda a sua
abrangência, de forma a possibilitar que os benefícios decorrentes do uso dos serviços de governo
eletrônico venham a ser estendidos à camada da população que não pode ter acesso direto a
esses serviços por meio dos dispositivos previstos.
8.1.2. Sistemas de informação do governo que fornecem serviços de governo eletrônico:
• quando utilizarem a Internet como meio de comunicação e estações de trabalho como
dispositivo de acesso, serão preferencialmente projetados para fornecer acesso a suas
informações com uso de tecnologias e protocolos de comunicação da web baseados em
navegadores (browsers);
• quando utilizarem outros dispositivos de acesso, como, por exemplo, telefones celulares e
televisão digital, poderão fazer uso de outras interfaces além dos navegadores web;
• deverão ser projetados para disponibilizar aos usuários serviços de governo eletrônico por
intermédio de vários meios de acesso;
• nesta versão, a e-PING trata dos seguintes meios de acesso:
• Estações de Trabalho;
• Mobilidade;
• TV Digital.
8.1.3. Os sistemas de informação do governo, construídos para suportar um determinado
dispositivo de acesso, devem seguir, obrigatoriamente, as especificações publicadas na e-PING
para aquele dispositivo.
8.1.4. Todos os sistemas de informação do governo que forneçam serviços eletrônicos devem ser
capazes de utilizar a Internet como meio de comunicação, seja diretamente ou por meio de
serviços de terceiros.
8.1.5. O desenvolvimento dos serviços de governo eletrônico deve ser direcionado de modo a
prover atendimento aos usuários que não tenham acesso às tecnologias mais recentes disponíveis
no mercado. Por outro lado, também deve ser considerada a necessidade de atendimento àqueles
usuários portadores de necessidades especiais, requisito que envolve a utilização de recursos
mais sofisticados e de uso específico. De modo a conciliar essas necessidades, deverão ser
observadas as recomendações do Modelo de Acessibilidade de Governo Eletrônico (e-MAG) (10).
8.1.6. Quando a Internet for usada como meio de comunicação, os sistemas de informação do
governo devem ser projetados de maneira que sejam aderentes às especificações da seção 8.2.
Complementarmente, a e-PING recomenda que todo serviço de governo eletrônico especifique,
com clareza e, de preferência, na sua página inicial, as versões mínimas de navegadores que
suportam as funcionalidades requeridas pelo serviço associado.
No atendimento ao padrão mínimo supramencionado, devem ser consideradas as exceções que
envolvam questões de segurança no tratamento de informações.
8.1.7. Quando a Internet for utilizada como meio de comunicação, middleware ou plug-ins
adicionais poderão ser utilizados, se não houver alternativa tecnicamente viável, para otimizar a
funcionalidade do navegador nas estações de trabalho. Neste caso, esse software adicional deverá
ser oferecido sem o pagamento de taxa de licença e deverá estar em conformidade com todas as
especificações técnicas correspondentes discriminadas na e-PING. Além disso, deverá ser
disponibilizado em repositório seguro mantido pelo órgão governamental responsável pela
10
BRASIL. Ministério do Planejamento, Orçamento e Gestão. Recomendações de Acessibilidade para a
construção e adaptação de conteúdos do Governo Brasileiro na Internet: modelo de acessibilidade. Versão
2.0. Brasília, 2005. Disponível em: (http://www.governoeletronico.gov.br/emag/). Acessado em:
13/07/2006.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 36


Documento de Referência da e-PING – Versão 2011

aplicação.
8.1.8. Os serviços de governo eletrônico devem ser projetados de maneira a garantir aos usuários
a autenticidade do conteúdo por meio de emissão de certificado digital, conforme padrões
preconizados pela ICP – Brasil. Referência: http://www.icpbrasil.gov.br/. Nesse sentido, todos os
sítios web deverão obrigatoriamente utilizar “https” ao invés de “http”.
8.1.9. A necessidade da sociedade aliada à possibilidade do governo de desenvolver e implantar
serviços eletrônicos fundamentará a definição das especificações técnicas exigidas pelos meios de
acesso disponíveis. Técnicas de gerenciamento de conteúdo e tecnologias que possibilitem
adaptação dos dispositivos para suportar os serviços de governo eletrônico poderão ser usadas
para facilitar o acesso por meio do padrão mínimo de navegador web (conforme item 3. Políticas
Gerais) e para tornar viável o uso de quiosques públicos, de balcões de atendimento e de Centrais
de Atendimento ao cidadão (como, por exemplo, Telecentros).
8.1.10. Os sistemas de informação do governo federal devem prever, quando necessário e quando
técnica e economicamente viável, a construção de adaptadores que permitam o acesso às
informações dos serviços eletrônicos em web para uma diversidade de ambientes, apresentando
tempos de resposta aceitáveis e custos reduzidos.
Esses adaptadores podem ser utilizados para filtrar, converter e reformatar, dinamicamente, o
conteúdo web, de modo a se adaptar às exigências e às capacidades de exibição do dispositivo de
acesso. Podem, ainda, possibilitar a modificação do conteúdo de uma página web, com base em
protocolos de dados, XML, XSL, preferências de usuário e parametrização de rede e de
dispositivos de acesso.
Esses adaptadores também poderão ser utilizados como forma alternativa de possibilitar o acesso
a minorias étnicas, a portadores de deficiência visual (por exemplo: pela utilização de tradutores de
textos, fontes e gráficos maiores, áudio, etc.). Tais aspectos são abordados pela Resolução n.º 7
do Comitê Executivo de Governo Eletrônico. Referência:
https://www.planalto.gov.br/ccivil_03/Resolução/2002/RES07-02web.htm
8.1.11. Serão considerados preferenciais aqueles tipos de arquivo que têm como padrão de
representação o “xml”, de forma a facilitar a interoperabilidade entre os serviços de governo
eletrônico.
8.1.12. Os serviços de governo eletrônico que disponibilizem documentos aos seus usuários
deverão fazê-lo empregando no próprio link de acesso ao documento informação clara quanto a
sua proveniência, versão, data de publicação e formato. Por data de publicação entende-se aquela
em que o documento foi publicado em diário oficial, para os casos em que esta medida seja
exigida, ou a data da disponibilização no sítio, para os demais casos. Outras informações sobre o
documento, tais como, autor, redator, emissor, data tópica ou outras relevantes para a sua precisa
caracterização, deverão constar no campo propriedades do próprio documento.

8.2. Meios de Acesso: Especificações Técnicas para Estações de Trabalho

Para elaboração de minutas de documentos ou trabalhos que necessitem ser criados


colaborativamente por mais de uma pessoa e/ou órgão, podem ser utilizados os formatos previstos
na Tabela 11.
Já para a elaboração da versão final de documentos, deve ser enviada a outros órgãos ou mesmo
arquivada digitalmente, recomenda-se a utilização do formato pdf/a. Documentos que necessitem
de garantia de integridade e/ou autoria, além de estarem em formato pdf/a, devem ser assinados
digitalmente pelo seu autor, utilizando certificado ICP-Brasil.
A menção aos produtos que geram os formatos de arquivos citados na Tabela 11 tem como
objetivo único a identificação de uma referência mínima a partir da qual os serviços de e-gov
devem intercambiar informações, estando aptos a receber ou enviar arquivos em versões iguais ou
posteriores às mencionadas.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 37


Documento de Referência da e-PING – Versão 2011

Tabela 11 – Especificações para Meios de Acesso – Estações de Trabalho

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Navegadores Devem ser aderentes aos padrões W3C e aos A
(browsers) itens Adoção de navegadores e Adoção
Preferencial de Padrões Abertos em Políticas
Gerais.
Conjunto de UNICODE standard versão 4.0, latin-1, UTF8, R
caracteres e ISBN 0-321-18578-1.
alfabetos
Formato de HTML versão 4.01 (.html ou .htm), gerado A
intercâmbio de conforme especificações do W3C(11).
hipertexto
XHTML versões 1.0 ou 1.1 (.xhtml), gerado R
conforme especificações do W3C(12).
XML versões 1.0 ou 1.1 (.xml), gerado A
conforme especificações do W3C(13).
SHTML (.shtml). R

MHTML (.mhtl ou .mht)(14). T


HTML 5 conforme especificações do W3C(15). E
Arquivos do tipo XML versões 1.0 ou 1.1 (.xml), ou com R
documento formatação (opcional) XSL (.xsl), gerado
conforme especificações do W3C(16).
Open Document (.odt), gerado conforme A
especificações do padrão NBR ISO/IEC
26.300:2008.
Rich Text Format (.rtf). T
PDF (.pdf). T
PDF versão aberta PDF/A (17)
. R
Texto puro (.txt). A
HTML versão 4.01 (.html ou .htm), gerado R
conforme especificações do W3C.
HTML 5 conforme especificações do W3C(18). E
11
HTML 4.01 Specification – W3C Recommendation 24 December 1999. Disponível em:
http://www.w3.org/TR/html4/.
12
XHTML 1.0 The Extensible HyperText Markup Language (Second Edition): A Reformulation of HTML 4 in
XML 1.0 – W3C Recommendation 26 January 2000, revised 1 August 2002. Disponível em:
http://www.w3.org/TR/xhtml1/.
13
Extensible Markup Language (XML) 1.0 (Third Edition) – W3C Recommendation 04 February 2004 .
Disponível em: http://www.w3.org/TR/2004/REC-xml-20040204/.
Extensible Markup Language (XML) 1.1 – W3C Recommendation 04 February 2004, edited in place 15 April
2004. Disponível em: http://www.w3.org/TR/2004/REC-xml11-20040204/.
14
Formato de empacotamento de arquivos web da Microsoft (Mime Enscapsulation of Aggregate HTML
Documents).
15
HTML 5 (http://www.w3.org/TR/html5/).
16
Extensible Stylesheet Language (XSL) Version 1.0 – W3C Recommendation 15 October 2001. Disponível em:
http://www.w3.org/TR/xsl/.
17
Document management -- Electronic document file format for long-term preservation -- Part 1: Use of
PDF 1.4 (PDF/A -1) – padrão ISO 19005-1:2005. Disponível em: http://www.iso.org/.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 38


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Arquivos do tipo Open Document (.ods), gerado conforme A
planilha especificações do padrão NBR ISO/IEC
26.300:2008.
Arquivos do tipo Open Document (.odp), gerado conforme A
apresentação especificações do padrão NBR ISO/IEC
26.300:2008.
HTML (.html ou .htm), gerado conforme R
especificações do W3C.
Arquivos do tipo XML versões 1.0 ou 1.1 (.xml). R Nas opções texto plano (txt)
“banco de dados” e csv, deve ser incluído
MySQL Database (.myd, .myi), gerados nos R
para estações de obrigatoriamente o leiaute
formatos do MySQL, versão 4.0 ou superior.
trabalho dos campos, de forma a
Texto Puro (.txt). A possibilitar seu tratamento.
Texto Puro (.csv) – comma-separated values A
Arquivo do Base (.odb), gerado conforme R
especificações do padrão NBR ISO/IEC
26.300:2008.
Intercâmbio de PNG (.png), gerado conforme especificações do A
informações W3C(19) – ISO/IEC 15948:2003 (E).
gráficas e imagens
TIFF (.tif)(20). R
estáticas
SVG (.svg), gerado conforme especificações do R
W3C(21).
JPEG File Interchange Format (.jpeg, .jpg ou R
.jfif)(22).
BMP (.bmp). T
GIF (.gif), gerado conforme as especificações T
GIF87a e GIF89a(23).
Gráficos vetoriais SVG (.svg), gerado conforme especificações do R
W3C.
Especificação de SVG (.svg), gerado conforme especificações do R
padrões de W3C.
animação
GIF (.gif), gerado conforme a especificação T
GIF89a.
Arquivos do tipo Áudio e vídeo MPEG-4, Part 14 (.mp4)(24). T
áudio e do tipo
MIDI (.mid) .
(25)
R
vídeo

18
HTML 5 (http://www.w3.org/TR/html5/).
19
Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November
2003.
ISO/IEC 15948:2003 (E) – Information technology – Computer graphics and image processing – Portable
Network Graphics (PNG): Functional specification. Disponível em: http://www.w3.org/TR/2003/REC-PNG-
20031110/. Acesso em: 7 dez 2005.
20
Tagged Image File Format (Adobe Systems).
21
Scalable Vector Graphics (SVG) 1.1 Specification. W3C Recommendation 14 January 2003. Disponível em:
http://www.w3.org/TR/2003/REC-SVG11-20030114/. Acesso em: 7 dez. 2005.
22
JPEG File Interchange Format (version 1.02) 1 September 1992. Disponível em:
http://www.jpeg.org/public/jfif.pdf. Acesso em: 7 dez. 2005.
23
Graphics Interchange Format (CompuServe/America Online, Inc.).
24
ISO/IEC 14496-14:2003 – Information Technology – Coding of audio-visual objects – Part 14: MP4 file
format.
25
Musical Instrument Digital Interface, conforme a especificação The Complete MIDI 1.0 Detailed
Specification. Version 96.1, 2.ed., nov. 2001. Disponível em: http://www.midi.org/about-
midi/specinfo.shtml. Acesso em: 30 mai. 2007.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 39


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Áudio Ogg Vorbis I (.ogg) (26)
. R
Audio-Video Interleaved (.avi), com codificação T
Xvid.
Audio-Video Interleaved (.avi), com codificação T
divX.
WAVE (.wav). T
Theora (.ogv)(27). R
WebM (28)
. E
Compactação de ZIP (.zip). R
arquivos de uso
GNU ZIP (.gz). R
geral
Pacote TAR (.tar). R
Pacote TAR compactado (.tgz ou .tar.gz). R
BZIP2 (.bz2). R
Pacote TAR compactado com BZIP2 (.tar.bz2). R
MS Cabinet (.cab). T
Informações GML versão 2.0 ou superior29. A Indicado para estruturas
georreferenciadas vetoriais complexas,
– padrões de envolvendo primitivas
arquivos para geográficas como polígonos,
intercâmbio entre pontos,
estações de linhas, superfícies, coleções,
trabalho e atributos numéricos ou
textuais sem limites de
número de caracteres.
ShapeFile30. A Indicado para estruturas
vetoriais limitadas a linhas,
pontos e polígonos, cujos
atributos textuais não
ultrapassem 256 caracteres.
Pode armazenar também as
dimensões M e Z.
GeoTIFF31. A Indicado para estruturas
matriciais limitadas a
matrizes de pixel.
Programação Assunto para consideração futura. F
Estendida (Plug-
ins)

8.3. Meios de Acesso: Especificações Técnicas para Mobilidade

O número de aparelhos de telefonia móvel já ultrapassou a quantidade de telefonia fixa, em


outubro de 2010 já eram 194 milhões de aparelhos celulares habilitados no país (TELECO, 2010).
Além disso, a oferta de computadores pessoais com recursos de mobilidade, a preços mais

26
Xiph.Org Foundation. Especificação disponível em: http://xiph.org/vorbis/doc/Vorbis_I_spec.html.
27
Theora. Especificação disponivel em: http://www.theora.org/.
28
WebM. Especificação disponivel em http://www.webmproject.org/.
29
Geography Markup Language. Especificações disponíveis em:
http://www.opengeospatial.org/standards/gml.
30
ESRI Shapefile Technical Description. Disponível em:
http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf.
31
GeoTIFF Format Especification. Disponível em: http://remotesensing.org/geotiff/geotiff.html .

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 40


Documento de Referência da e-PING – Versão 2011

acessíveis ao cidadão, está crescente a cada dia, motivada por incentivos governamentais e
redução do custo de produção. Assim, torna-se um grande desafio para o governo possibilitar à
sociedade acesso aos produtos e serviços do governo eletrônico, por intermédio de dispositivos
móveis, em geral portáteis, como notebooks, celulares, smartphones e similares, almejando assim
o aumento da inclusão digital via mobilidade.
Um conceito que vem se consolidando para a interface de aplicações aos usuários, é o de “web
universal”, que seja para todos, em qualquer lugar, em qualquer momento, independente do
dispositivo de acesso. Conceito este que deve ser aplicado aos serviços a serem disponibilizados
por meio dos dispositivos móveis, o chamado Governo Móvel (m-Gov).

Tabela 12 – Especificações para Meios de Acesso – Mobilidade

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Todos os Deve ser aderente aos padrões W3C – Mobile Web R
Componentes application Best Practices, disponíveis no endereço
eletrônico: http://www.w3.org/TR/2010/PR-mwabp-
20101021/

8.4. Meios de Acesso: Especificações Técnicas para TV Digital

Tendo em vista o alto nível da presença de aparelhos receptores de sinais de televisão nos lares
brasileiros e a eminente implantação do Sistema Brasileiro de TV Digital, que permite interação
com os telespectadores, este se transforma em canal de grande potencial de relacionamento entre
governo e sociedade. Assim surgem novas possibilidades de acesso aos produtos e serviços do
governo eletrônico, a partir dos novos aparelhos de TV Digital.
Sua utilização oferece muito mais que um sinal de qualidade, proporciona interatividade e
acessibilidade com Serviços Comerciais como: compras, jogos e acesso à bancos, e também
Serviços Sociais, tais como: consultas ao FGTS, PIS, Programas Sociais do governo, tele-
educação dentre outros, fazendo com que os cidadãos passem de uma atividade essencialmente
passiva para uma atividade participativa.
A TV Digital torna-se um padrão de comunicação em diferentes perspectivas como: a tecnológica,
com a migração do sistema analógico para o digital; a econômica, com a migração de novas
possibilidades de serviços e negócios; a social, com oferta de diversidade de conteúdos e inclusão
digital ao utilizar internet através do aparelho de TV; a política, com a possibilidade de estimular a
discussão de um novo marco regulatório e a comportamental, com a possibilidade de participação
ativa das audiências através do uso de diferentes níveis de interatividade na TV Digital.
Para atender às questões técnicas, o Fórum do Sistema Brasileiro de TV Digital Terrestre –
SBTVD, publicado junto à Associação Brasileira de Normas Técnicas – ABNT, agrupa diversas
normas no sítio: http://www.forumsbtvd.org.br/materias.asp?id=112, onde está referenciado um
conjunto de especificações, padronizado e livre de royalties, denominado GINGA.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 41


Documento de Referência da e-PING – Versão 2011

Tabela 13 – Especificações para Meios de Acesso – TV Digital

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Transmissão ABNT NBR 15601 R
Parte 1 – Sistema de transmissão.
Codificação ABNT NBR 15602 R
Parte 1 – Codificação de Video.
Parte 2 – Codificação de Áudio.
Parte 3 – Sistema de multiplexação de sinais.
Multiplexação ABNT NBR 15603 R
Parte 1 – Serviços de informação do sistema de
radiodifusão.
Parte 2 – Sintaxes e definições da informação básica
de SI.
Parte 3 – Sintaxe e definição da informação
estendida do SI.
Receptores ABNT NBR 15604 R
Parte 1 – Receptores.
Segurança ABNT NBR 15605 R
Parte 1 – Tópicos de segurança.
Middleware ABNT NBR 15606 R
Parte 1 – Codificação de dados.
Parte 2 – Ginga-NCL para receptores fixos e móveis
– Linguagem de aplicação XML para codificação de
aplicações.
Parte 3 – Especificação de transmissão de dados.
Parte 4 – Ginga-J – Ambiente para a execução de
aplicações procedurais.
Parte 5 – Ginga-NCL para receptores portáteis –
Linguagem de aplicação XML para codificação de
aplicações.
Parte 6 – Java DTV 1.3.
Canal de ABNT NBR 15607 R
Interatividade Parte 1 – Protocolos, interfaces físicas e interfaces
de software.
Guia de Operações ABNT NBR 15608 R
Parte 1 – Sistema de Transmissão – Guia para
implementação da ABNT NBR 15601.
Parte 2 – Codificação de vídeo, áudio e
multiplexação – Guia para implementação da ABNT
NBR 15602.
Parte 3 – Multiplexação e serviço de informação (SI)
– Guia de implementação da ABNT NBR 15603.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 42


Documento de Referência da e-PING – Versão 2011

9. Organização e Intercâmbio de Informações

9.1. Organização e Intercâmbio de informações: Políticas Técnicas

As políticas técnicas para sistemas de organização e intercâmbio de informações e dados são:


9.1.1. Uso de XML para intercâmbio de dados.
9.1.2. Uso de XML Schema e da UML (quando for o caso) para definição dos dados para
intercâmbio.
9.1.3. Uso de XSL para transformação de dados.
9.1.4. Uso do Padrão de Metadados de Governo Eletrônico (e-PMG) para a gestão de conteúdos
eletrônicos.

9.2. Organização e Intercâmbio de Informações: Especificações Técnicas

Tabela 14 – Especificações para Organização e Intercâmbio de Informações

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Linguagem para XML (Extensible Markup Language) como definido A
intercâmbio de pelo W3C
dados http://www.w3.org/XML
JSON (Javascript Object Notation) R
Como definido pela IETF
http://www.ietf.org/rfc/rfc4627.txt
Transformação de XSL (Extensible Stylesheet Language) como definido A
dados pelo W3C http://www.w3.org/TR/xsl

XSL Transformation (XSLT) como definido pelo W3C


http://www.w3.org/TR/xslt
Definição dos dados XML Schema como definido pelo W3C: A
para intercâmbio - XML Schema Part 0: Primer
http://www.w3.org/TR/2004/REC-xmlschema-0-
20041028/
- XML Schema Part 1: Structures
http://www.w3.org/TR/xmlschema-1/structures
- XML Schema Part 2: Datatypes
http://www.w3.org/TR/xmlschema-2/datatypes
UML (Unified Modeling Language) como definido
pelo OMG
http://www.omg.org/gettingstarted/specsandprods.ht
m/
Descrição de RDF (Resource Description Framework) R
recursos Como definido pela W3C.

Elementos de e-PMG – Padrão de Metadados para o Governo E


Metadados para Eletrônico.
gestão de
conteúdos

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 43


Documento de Referência da e-PING – Versão 2011

Componente Especificação SIT Observações


Sistemas de SKOS (Simple Knowledge Organization System) E
Organização do como definido pelo W3C
Conhecimento http://www.w3.org/2004/02/skos/

Linguagem de OWL (Web Ontology Language) E


definição de Como definido pelo W3C
ontologias na web

Linguagem de SPARQL (Sparql Protocol and RDF Query Language) F


consulta semântica Como definido pelo W3C

Taxonomia para VCGE – Vocabulário Controlado do Governo A


navegação Eletrônico. Conforme definição em
http://www.eping.e.gov.br

Sistema de Handle system (http://www.handle.net). E


resolução de
Identificadores

9.3. Nota sobre o uso de UML

Para a descrição de dados complexos visando melhor explicitação é recomendado, quando


cabível, o uso do diagrama de classes da UML.

9.4. Nota sobre a LAG

Em 2010 a LAG passou a ser denominado VCGE – Vocabulário Controlado do Governo Eletrônico.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 44


Documento de Referência da e-PING – Versão 2011

10. Áreas de Integração para Governo Eletrônico

10.1. Áreas de Integração para Governo Eletrônico: Políticas Técnicas

10.1.1. Neste segmento, são tratados componentes relacionados a temas transversais às Áreas de
Atuação de Governo, cuja padronização seja relevante para a interoperabilidade de serviços de
Governo Eletrônico, tais como Processos e Informações Geográficas.
10.1.2. O Modelo Global de Dados (MGD) foi adotado como a Arquitetura de Interoperabilidade
para o Governo, sendo a utilização de sua metodologia e notação requeridas para a construção de
modelos de dados de alto nível, possibilitando o compartilhamento de informações relativas a
integrações atuais e futuras de dados atreladas a uma visão de negócio, macroprocessos e
dimensões de governo. Sua utilização possibilitará a evolução ordenada dos atuais sistemas
estruturantes de governo, o desenvolvimento de novos com maior nível de reusabilidade e
interoperabilidade, além da integração a soluções estratégicas nos diversos níveis e esferas de
governo.
10.1.3. O Guia de Gestão de Processos de Governo (GGPG) tem como objetivo conduzir os
diferentes órgãos da Administração Pública Federal a trabalhar padronizadamente com a Gestão
de Processos. Este guia define o vocabulário comum da área de gestão de processos para
Governo Federal, esclarece aos órgãos a importância da gestão de processos, sugere padrões de
notação e artefatos necessários a modelagem de processos e com isso proporciona uma melhor
troca de informações referentes aos processos de negócio entre os órgãos da Administração
Pública.
10.1.4. Como diretriz técnica para integração de sistemas de informação recomenda-se a gradual
adoção da Arquitetura Orientada a Serviços (SOA), tendo como referência para implementação, a
iniciativa “Arquitetura Referencial de Interoperabilidade dos Sistemas Informatizados de
Governo (AR)”, que é um modelo de Arquitetura Orientada a Serviços, adaptado à realidade dos
Sistemas Informatizados do Governo Federal, disponível no sítio http://www.eping.e.gov.br.
10.1.5. A arquitetura e-PING - Padrões de Interoperabilidade de Governo Eletrônico preconiza a
adoção do XML e o desenvolvimento de XML Schemas como fundamentos para a integração e
interoperabilidade eletrônica do governo.
10.1.6. Orienta-se o uso de Web Services para demandas de integração entre sistemas de
informação de governo. De maneira que, independente das tecnologias em que foram
implementados, possa-se adotar um padrão de interoperabilidade que garanta escalabilidade,
facilidade de uso, além de possibilitar atualização de forma simultânea e em tempo real.
10.1.7. No Portal do Governo Eletrônico está disponível o Guia de Interoperabilidade de Serviços
de Governo, para facilitar a aderência à e-PING, orientando o uso das ferramentas e tecnologias
recomendadas e adotadas. O Guia está dividido em dois volumes dirigidos a perfis específicos de
profissionais: Manual do Gestor e Cartilha Técnica.
10.1.8. O segmento atuará buscando a identificação, acompanhamento da produção e análise de
padrões de dados de interesse geral da Administração Pública, em articulação com grupos
representativos do governo e da sociedade, reportando-se a instâncias competentes no que tange
à priorização.
10.1.9. O formato dos Dados de interesse geral do governo devem ser disponibilizados no
Catálogo de Interoperabilidade, segundo as regras de utilização desta ferramenta.
10.1.10. Os Serviços Interoperáveis (Web Services) de interesse geral devem ser disponibilizados
no Catálogo de Interoperabilidade, porém, há necessidade de se observar regras de utilização
dos serviços de acesso restrito definidas pelos respectivos órgãos.
10.1.11. O Catálogo de Interoperabilidade é um elemento central do ambiente de
interoperabilidade do Governo Federal. Sua utilização é considerada equivalente à situação
Adotado (A).

10.2. Catálogo de Interoperabilidade

10.2.1. O Catálogo de Interoperabilidade está disponível no sítio http://www.eping.e.gov.br, sendo

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 45


Documento de Referência da e-PING – Versão 2011

composto pelo Catálogo Padrão de Dados (CPD) e pelo Catálogo de Serviços Interoperáveis.
10.2.2. O Catálogo Padrão de Dados (CPD) tem por objetivo estabelecer padrões de tipos e itens
de dados que se aplicam às interfaces dos sistemas que fazem parte do setor público, estando
dividido em dois documentos:
• Volume 1, que estabelece os princípios gerais, isto é, as razões, abordagem e regras
para a aplicação dos padrões de Tipo e Itens de Dados; e
• Volume 2, que apresenta os Tipos e Item de Dados padronizados.
10.2.3. A Coordenação da e-PING é responsável pelo Catálogo de Interoperabilidade, em especial
pela definição das regras para o gerenciamento dos processos de mudanças e por fomentar que
os padrões sejam usados em desenvolvimentos futuros.
10.2.4. O desenvolvimento e manutenção do Catálogo de Interoperabilidade é de responsabilidade
do Grupo Áreas de Integração para Governo Eletrônico que tem a participação de diferentes
segmentos do governo nas esferas federal e estadual.

10.3. Modelos para documentação de Web Services e outras modalidades de trocas de


dados

10.3.1. Como forma de documentar os serviços interoperáveis, é recomendado o uso, em cada


caso, do modelo de documentação para Web Services e do modelo de documentação para
serviços de modo geral (não Web Services), como troca de arquivos, FTP, etc. Esses modelos
estão disponíveis no sítio da e-PING e no site do Catálogo de Interoperabilidade.
10.3.2. A adoção dos modelos de documentação tem status equivalente à situação Recomendada
(R).
10.3.4. Solicita-se aos órgãos que utilizarem os Modelos de Documentação que enviem a
documentação das interfaces para o email: eping@planejamento.gov.br.

10.4. Áreas de Integração para Governo Eletrônico: Nota explicativa sobre os Catálogos
Padrão de Dados e XML Schemas

10.4.1. Considerações Iniciais

Os Catálogos Padrão de Dados e XML Schemas estão disponíveis no portal do Governo Eletrônico
no sítio http://www.governoeletronico.gov.br/.
O Catálogo Padrão de Dados tem por objetivo estabelecer padrões de tipos e itens de dados que
se aplicam às interfaces dos sistemas que fazem parte do setor público, estando dividido em dois
documentos:
• Volume 1, que estabelece os princípios gerais, isto é, as razões, abordagem e regras
para a aplicação dos padrões de Tipo e Itens de Dados; e
• Volume 2, que apresenta os Tipos e Item de Dados padronizados.
O Catálogo XML Schemas tem por objetivo estabelecer padrões de XML Schemas que se aplicam
às interfaces de sistemas que apóiem a oferta de serviços de Governo Eletrônico.
O Catálogo XML Schemas contém os padrões aceitos, na forma de XML Schemas para
intercâmbio de dados envolvendo o setor público. Tais padrões tanto podem constituir-se em um
único esquema, quanto em um conjunto de XML Schemas, desde que o conjunto se refira a uma
mesma temática dentro da Área de Integração associada.
A publicação de XML Schemas não implica automaticamente em garantia de acesso aos
conteúdos correspondentes ou serviços associados, para o quê podem ser definidas regras
específicas pelo respectivo gestor.

10.4.2. Propriedade e Responsabilidade

A Coordenação da e-PING é responsável por estes Catálogos, em especial pela definição das

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 46


Documento de Referência da e-PING – Versão 2011

regras para o gerenciamento dos processos de mudanças e por fomentar que os padrões sejam
usados em desenvolvimentos futuros.
Neste sentido, recomenda-se que o desenvolvimento ou manutenção de sistemas que apóiem a
oferta de serviços de Governo Eletrônico correlatos a áreas/sub-áreas de atuação de governo
contempladas no Catálogo considerem os XML Schemas publicados.
O desenvolvimento e manutenção destes Catálogos são de responsabilidade do Grupo Áreas de
Integração para Governo Eletrônico que tem a participação de diferentes segmentos do governo
nas esferas federal e estadual.

10.4.3. Mecanismos de Gestão do Catálogo de XML Schemas

As entradas no Catálogo de XML podem se dar através das seguintes situações:


a) Proposição seguida de aceite de proposta de conteúdo para o Catálogo de Padrões de
Dados (CPD);
b) Submissão seguida de aceite de proposta de conteúdo à Arquitetura Referencial de
Interoperação dos Sistemas Informatizados de Governo (AR);
c) Submissão, por profissional vinculado ao setor público, de conteúdo diretamente ao
Catálogo de XML Schemas, através de formulário eletrônico disponível a partir do sítio da
e-PING.
A proposição de cadastro de XML Schemas será submetida à análise dos integrantes do Grupo
Áreas de Integração para Governo Eletrônico por meio de formulário eletrônico específico,
disponível no sítio da e-PING (www.e-ping.e.gov.br). Serão mantidas no Catálogo apenas as
proposições aceitas, sendo que as que ainda estiverem em estudo, as rejeitadas, bem como as
versões anteriores de XML Schemas aceitos serão mantidas em ambiente “de testes” a ser
oportunamente concebido e implementado.
Os critérios de avaliação empregados incluirão:
• reconhecimento pela comunidade usuária;
• acordo do gestor da área/sub-área (no caso de não ser ele o proponente); e
• aderência aos padrões da e-PING.
Ou seja, a ocorrência de submissões em que o proponente de determinado XML Schemas não
seja o gestor da área está prevista, mas terá como condição adicional de aceite a concordância do
gestor, a partir de interlocução realizada pelo próprio proponente e/ou pelo Grupo Áreas de
Integração para Governo Eletrônico.
Solicitações de alteração para XML Schemas já publicados serão analisadas preliminarmente
pelos integrantes do Grupo Áreas de Integração para Governo Eletrônico. A decisão de aceite
caberá à Coordenação Central da e-PING, que poderá adotar as mudanças propostas conforme
sua abrangência e impacto ou submetê-las à consulta pública, através do sítio
http://www.governoeletronico.gov.br.
Para esta versão do documento e-PING, optou-se por disponibilizar o conteúdo do Catálogo XML
Schemas apenas na ferramenta desenvolvida para a gestão deste, sendo suprimida a publicação
no documento das referências aos mesmos. Esta escolha fundamenta-se no objetivo de incentivar
o uso e manutenção dos XML Schemas na ferramenta apropriada e permitir mais flexibilidade da
gestão dos XML Schemas.

10.5. Áreas de Integração para Governo Eletrônico: Especificações Técnicas

As especificações para as Áreas de Integração para Governo Eletrônico são:

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 47


Documento de Referência da e-PING – Versão 2011

Tabela 15 – Especificações para Áreas de Integração para Governo Eletrônico – Temas


Transversais a Áreas de Atuação de Governo

Temas Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
PROCESSOS – BPEL4WS V1.1, conforme definido pelo OASIS R O grupo irá
Linguagem para http://www.oasis- acompanhar a
Execução de open.org/committees/download.php/2046/BPEL evolução do
Processos %20V1-1%20May%205%202003%20Final.pdf BPEL4WS versão 2.0.
Estudos referentes à
orquestração de
processos e
coreografia serão
futuramente
conduzidos pelo grupo.
PROCESSOS – BPMN 1.0, conforme definido pelo OMG R Necessitará ser
Notação de http://www.bpmn.org/Documents/OMG%20Final revisado a partir do
Modelagem de %20Adopted%20BPMN%201-0%20Spec%2006-02- resultado do Guia de
Processos 01.pdf Processos.
Troca de XBRL – eXtensible Business Reporting Language R www.xbrl.org
Informações http://www.xbrl.org/SpecRecommendations/
Financeiras
Legislação, LexML v. 1.0 R Projeto LexML define
Jurisprudência e http://projeto.lexml.gov.br recomendações para a
Proposições identificação e
Legislativas estruturação de
documentos
legislativos e jurídicos.
Planejamento StratML - Strategy Markup Language F
Estratégico http://xml.gov/stratml/index.htm
Integração de MGD R
Dados e Processos http://modeloglobaldados.serpro.gov.br
INFORMAÇÕES WMS versão 1.0 ou posterior A
GEORREFEREN- http://www.opengeospatial.org/standards
CIADAS –
WFS versão 1.0 ou posterior A
Interoperabilidade
http://www.opengeospatial.org/standards
entre sistemas de
informação WCS versão 1.0 ou posterior A
geográfica http://www.opengeospatial.org/standards
CSW versão 2.0 ou posterior A
http://www.opengeospatial.org/standards/cat
WFS-T versão 1.0 ou posterior R Observar padrões e
http://www.opengeospatial.org/standards/wfs políticas de segurança
indicados pelo GT2,
principalmente WS-
Security.
WKT R Para codificar
http://www.opengeospatial.org/standards/sfa coordenadas em
serviços Web
convencionais. As
coordenadas devem
estar em Lat/Long

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 48


Documento de Referência da e-PING – Versão 2011

Temas Especificação SIT Observações


utilizando o datum
SIRGAS2000 ou
WGS-84. Usar GML
sempre que possível.

Tabela 16 – Especificações para Áreas de Integração para Governo Eletrônico – Web


Services32

Componente Especificação SIT Observações


A = Adotado
R = Recomendado
T = Em Transição
E = Em Estudo
F = Estudo Futuro
Infraestrutura de Especificação UDDI v3.0.2 (Universal Description, R
registro Discovery and Integration) definida pela OASIS
http://uddi.org/pubs/uddi_v3.htm
ebXML (Electronic Business using eXtensible Markup E
Language). A especificação pode ser encontrada em
http://www.ebxml.org/specs/index.htm
Linguagem de WSDL 1.1 (Web Service Description Language) A
definição do serviço como definido pelo W3C.

A especificação pode ser encontrada em


http://www.w3.org/TR/wsdl
WSDL 2.0 (Web Service Description Language) E
como definido pelo W3C.

A especificação pode ser encontrada em


http://www.w3.org/TR/wsdl20/
Perfil básico de Basic Profile 1.1 Second Edition, como definido pela E A versão 1.2 do Basic
interoperabilidade WS-I Profile encontra-se
http://www.ws-i.org/Profiles/BasicProfile-1.1.html como rascunho
(Working Draft) em
http://www.ws-
i.org/Profiles/BasicProf
ile-1.2.html
Portlets remotos WSRP 1.0 (Web Services for Remote Portlets) como E
definido pela OASIS
http://www.oasis-open.org/committees/wsrp

32
As questões de segurança relativas a Web Services são abordadas no capítulo 7.

Padrões de Interoperabilidade de Governo Eletrônico - versão de 03/12/2010 49


Governo Eletrônico: E-Mag

O governo brasileiro, comprometido com a inclusão, buscou, através da elaboração do


modelo de acessibilidade do governo eletrônico, facilitar o acesso para todas as
pessoas às informações e serviços disponibilizados nos sítios e portais do governo.
Assim, a primeira versão do e-MAG, elaborada pelo Departamento de Governo
Eletrônico em parceria com a ONG Acessibilidade Brasil, foi disponibilizada para
consulta pública em 18 de janeiro de 2005, e a versão 2.0 já com as alterações
propostas, em 14 de dezembro do mesmo ano. Em 2007, a Portaria nº 3, de 7 de
maio, institucionalizou o e-MAG no âmbito do sistema de Administração dos Recursos
de Informação e Informática – SISP, tornando sua observância obrigatória nos sítios e
portais do governo brasileiro.

1.1 Sobre a versão 3.0

Para a elaboração da versão 2.0 do e-MAG foi realizado um estudo das regras de
acessibilidade através de um método comparativo entre as normas adotadas por
diversos países, como a Section 508 do governo dos Estados Unidos, os padrões CLF
do Canadá, as diretrizes irlandesas de acessibilidade e documentos de outros países,
entre eles Portugal e Espanha. Também foi realizada uma análise detalhada das
regras e pontos de verificação do órgão internacional WAI/W3C, presentes na WCAG
1.0.

A versão 2.0 do e-MAG dividia-se em duas partes:

1. a cartilha técnica, voltada a desenvolvedores de sítios, apresentando


detalhadamente a proposta de implementação das recomendações de
acessibilidade em sítios do governo;

2. a visão do cidadão, voltada a todos os cidadão brasileiros, apresentando o


modelo de acessibilidade de forma simples e de fácil compreensão.

A divisão do e-MAG apresentou alguns inconvenientes durante o processo de


disseminação do Modelo, como a dificuldade das pessoas entenderem as áreas da
Visão do Cidadão e seu relacionamento com a aplicação efetiva da acessibilidade. O
aprendizado durante os seis anos da versão 2.0 do e-MAG e o lançamento da versão
2.0 do WCAG marcaram o caminho para a revisão do Modelo.
A revisão do modelo e a nova versão foi desenvolvida através da parceria entre o
Departamento de Governo Eletrônico e o Projeto de Acessibilidade Virtual da RENAPI
(Rede de Pesquisa e Inovação em Tecnologias Digitais). Também, para a elaboração
dessa nova versão, foram consideradas as contribuições de especialistas na área da
acessibilidade.

A elaboração da versão 3.0 foi embasada na versão anterior do e-MAG, apoiando-se


na WCAG 2.0, lançada em dezembro de 2008, e considerando as novas pesquisas na
área de acessibilidade à Web. Apesar de utilizar a WCAG como referência, o e-MAG
3.0 foi desenvolvido e pensado para as necessidades locais, visando atender as
prioridades brasileiras e mantendo-se alinhado ao que existe de mais atual neste
segmento.

Seguindo a diretriz do programa de Governo Eletrônico de promover a Cidadania, o


documento-proposta passou por Consulta Pública no período de novembro de 2010 a
janeiro de 2011, recebendo contribuições tanto pelo sistema de Consulta Pública do
Portal do Programa , quanto por e-mail. O número de contribuições superou as
expectativas e a avaliação criteriosa destas impactou na data de entrega do modelo,
que teve seu cronograma estendido.

Assim, após um longo período de maturação e estudo, é entregue à sociedade


brasileira a terceira versão do Modelo de Acessibilidade em Governo Eletrônico, o e-
MAG versão 3.0, atualizado e mais abrangente no que diz respeito a tornar acessível
o conteúdo do governo brasileiro na Web.

A versão 3.0 do e-MAG é apresentada em apenas um documento, não havendo


separação entre visão técnica e visão do cidadão. Outra decisão foi o abandono dos
níveis de prioridade A, AA e AAA, visto que o padrão é voltado as páginas do
Governo, não sendo permitido exceções com relação ao cumprimento das
recomendações. Além disso, no e-MAG 3.0 foi incluída a seção chamada “Padronização
de acessibilidade nas páginas do governo federal”, com o intuito de padronizar
elementos de acessibilidade que devem existir em todos os sítios e portais do
governo.

1.2 Legislação

Estão listados abaixo alguns dos principais documentos, que fazem parte da legislação
que norteia o processo de promoção da acessibilidade e a implementação do e-MAG:
1. Decreto número 5296, de 2 de dezembro de 2004, que regulamenta as leis n°
10.048, de 8 de novembro de 2000, que dá prioridade de atendimento às
pessoas que especifica, e 10.098, de 19 de dezembro de 2000, que estabelece
normas gerais e critérios básicos para a promoção da acessibilidade das
pessoas com deficiência, e dá outras providências;

2. Comitê CB-40 da ABNT, que se dedica à normatização no campo de


acessibilidade, atendendo aos preceitos de desenho universal. O Comitê possui
diversas comissões, definindo normas de acessibilidade em todos os níveis,
desde o espaço físico até o virtual;

3. Decreto n° 6949, de 25 de agosto de 2009, que promulga a Convenção


Internacional sobre os Direitos das Pessoas com Deficiência elaborada pelas
Nações Unidas em 30 de março de 2007, definindo, em seu artigo 9°, a
obrigatoriedade de promoção do acesso de pessoas com deficiência a novos
sistemas e tecnologias da informação e comunicação, inclusive à Internet.

4. Portaria nº 3, de 7 de maio de 2007, que institucionalizou o e-MAG no âmbito


do sistema de Administração dos Recursos de Informação e Informática –
SISP, tornando sua observância obrigatória nos sítios e portais do governo
brasileiro.

1.3 O acesso de pessoas com deficiência

O computador e a Internet representam um enorme passo para a inclusão de pessoas


com deficiência, promovendo autonomia e independência. Mas como pessoas com
deficiência utilizam o computador? Muitas vezes, a deficiência não é severa o
suficiente a ponto de tornar-se uma barreira à utilização do computador. Entretanto,
na maioria das páginas da Web, as pessoas cegas ou com baixa visão, pessoas com
deficiência auditiva, com dificuldade em utilizar o mouse, por exemplo, encontram
inúmeras barreiras de acessibilidade que dificultam ou impossibilitam o acesso aos
seus conteúdos.

No que se refere a acesso ao computador, as quatro principais situações vivenciadas


por usuários com deficiência são:

 Acesso ao computador sem mouse: no caso de pessoas com deficiência visual,


dificuldade de controle dos movimentos, paralisia ou amputação de um
membro superior;

Modelo de Acessibilidade em Governo Eletrônico e-MAG 7


 Acesso ao computador sem teclado: no caso de pessoas com amputações,
grandes limitações de movimentos ou falta de força nos membros superiores;

 Acesso ao computador sem monitor: no caso de pessoas com cegueira;

 Acesso ao computador sem áudio: no caso de pessoas com deficiência auditiva.

No entanto, esses não são os únicos casos que devem ser considerados quando se
pensa em acessibilidade na Web. Muitas pessoas apresentam outras limitações
relacionadas à memória, resolução de problemas, atenção, compreensão verbal,
leitura e linguística, compreensão matemática e compreensão visual. Uma pessoa com
dislexia, por exemplo, pode apresentar dificuldade de leitura de uma página devido a
um desenho inadequado. Por isso, um sítio desenvolvido considerando a acessibilidade
deve englobar diferentes níveis de escolaridade, faixa etária e pouca experiência na
utilização do computador, bem como ser compatível com as diversas tecnologias
utilizadas para acessar uma página da Web.

Um dos aliados das pessoas com deficiência para o uso do computador são os
recursos de tecnologia assistiva, que auxiliam na realização de tarefas antes muito
difíceis ou impossíveis de realizar, promovendo, desta maneira, a autonomia,
independência, qualidade de vida e inclusão social de pessoas com deficiência.

Existe atualmente uma enorme gama de recursos de tecnologia assistiva, desde


artefatos simples até objetos ou softwares mais sofisticados e específicos, de acordo
com a necessidade de cada pessoa. Uma pessoa com limitado movimento das mãos,
por exemplo, pode utilizar um teclado adaptado que contém teclas maiores ou um
mouse especial para operar o computador. Já as pessoas com baixa visão podem
recorrer a recursos como ampliadores de tela, enquanto usuários cegos podem utilizar
softwares leitores de tela para fazer uso do computador.

Apesar de sua enorme importância na promoção da acessibilidade às pessoas com


deficiência, os recursos de tecnologia assistiva, por si só, não garantem o acesso ao
conteúdo de uma página da Web. Para tal, é necessário que a página tenha sido
desenvolvida de acordo com os padrões Web (Web Standards) e as recomendações de
acessibilidade, os quais serão abordados ao longo deste documento.

Dentro desse contexto, este documento objetiva garantir que o processo de


acessibilidade dos sítios do governo brasileiro seja conduzido de forma padronizada,
de fácil implementação, coerente com as necessidades brasileiras e em conformidade
com os padrões internacionais.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 8


1.4 O processo para desenvolver um sítio acessível

A acessibilidade à Web refere-se a garantir acesso facilitado a qualquer pessoa,


independente das condições físicas, dos meios técnicos ou dispositivos utilizados. No
entanto, ela depende de vários fatores, tanto de desenvolvimento quanto de interação
com o conteúdo. O processo para desenvolver um sítio acessível é realizado em três
passos:

1. Seguir os padrões Web;

2. Seguir as diretrizes ou recomendações de acessibilidade;

3. Realizar a avaliação de acessibilidade.

PRIMEIRO PASSO: PADRÕES WEB

Para se criar um ambiente online efetivamente acessível é necessário, primeiramente,


que o código esteja dentro dos padrões Web internacionais definidos pelo W3C.

Os padrões de desenvolvimento Web do W3C, ou Web Standards, são um conjunto de


recomendações que visa padronizar o conteúdo Web, possibilitando melhores práticas
no desenvolvimento de páginas da Web. Uma página desenvolvida de acordo com os
padrões Web deve estar em conformidade com as normas HTML, XML, XHTML e CSS,
seguindo as regras de formatação sintática. Além disso, é muito importante que o
código seja semanticamente correto, ou seja, que cada elemento seja utilizado de
acordo com um significado apropriado, valor e propósito.

A conformidade com os padrões Web permite que qualquer sistema de acesso à


informação interprete a mesma adequadamente e da mesma forma, seja por meio de
navegadores, leitores de tela, dispositivos móveis (celulares, tablets, etc.) ou agentes
de software (mecanismos de busca ou ferramentas de captura de conteúdo). Páginas
que não possuem um código de acordo com os padrões do W3C apresentam
comportamento imprevisível, e na maioria das vezes impedem ou pelo menos
dificultam o acesso.

Para conhecer as boas práticas em desenvolvimento de sítios de acordo com os


padrões, ver Cartilha de Codificação dos Padrões Brasil e-GOV, disponível em:
http://www.governoeletronico.gov.br/acoes-e-projetos/padroes-brasil-e-gov

Modelo de Acessibilidade em Governo Eletrônico e-MAG 9


SEGUNDO PASSO: DIRETRIZES OU RECOMENDAÇÕES DE ACESSIBILIDADE

As diretrizes ou recomendações de acessibilidade explicam como tornar o conteúdo


Web acessível a todas as pessoas, destinando-se aos criadores de conteúdo Web
(autores de páginas e criadores de sítios) e aos programadores de ferramentas para
criação de conteúdo. Um dos principais documentos nessa área é a WCAG, atualmente
em sua versão 2.0, desenvolvida pelo consórcio W3C a partir da criação do WAI (Web
Accessibility Initiative), contendo as recomendações de acessibilidade para conteúdo
Web. Em nível nacional, o e-MAG é o documento que contém as diretrizes ou
recomendações que norteiam o desenvolvimento de sítios e portais acessíveis.

TERCEIRO PASSO: AVALIAÇÃO DE ACESSIBILIDADE

Após a construção do ambiente online de acordo com os padrões Web e as diretrizes


de acessibilidade, é necessário testá-lo para garantir sua acessibilidade. No caso dos
padrões Web, há um validador automático disponibilizado pelo próprio W3C (ver seção
de Recursos). No que diz respeito às diretrizes de acessibilidade, é necessário realizar,
inicialmente, uma validação automática através de validadores, que são softwares ou
serviços online que ajudam a determinar se um sítio respeitou ou não as
recomendações de acessibilidade, gerando um relatório de erros. Uma das
ferramentas que podem ser utilizadas é o ASES, avaliador e simulador de
acessibilidade em sítios, cujos instrumentos permitem avaliar, simular e corrigir a
acessibilidade de páginas, sítios e portais, viabilizando a adoção da acessibilidade por
órgãos do governo. Além do ASES, existem outros validadores automáticos (para mais
informações, ver seção de Recursos deste documento).

É preciso salientar que, apesar de tornarem a avaliação de acessibilidade mais rápida


e menos trabalhosa, os validadores automáticos por si só não determinam se um sítio
está ou não acessível. Para uma avaliação efetiva, será necessária uma posterior
validação manual.

A validação manual é necessária porque nem todos os problemas de acessibilidade em


um sítio são detectados mecanicamente pelos validadores. Para a validação manual,
são utilizados checklists de validação humana.

Assim, os passos sugeridos para a avaliação de acessibilidade em um sítio são os


seguintes:

1. Validar os códigos do conteúdo HTML e das folhas de estilo;

Modelo de Acessibilidade em Governo Eletrônico e-MAG 10


2. Verificar o fluxo de leitura da página – para tal, utilizar um navegador textual,
como o Lynx, ou um leitor de tela (recomendamos o NVDA ou ORCA). Para
maiores detalhes, ver documento Descrição dos Leitores de Tela, disponível
em: http://www.governoeletronico.gov.br/acoes-e-projetos/e-MAG/material-
de-apoio.

3. Verificar o fluxo de leitura da página sem estilos, sem script e sem as imagens;

4. Verificar as funcionalidades da barra de acessibilidade, aumentando e


diminuindo a letra, modificando o contraste, etc.;

5. Realizar a validação automática de acessibilidade utilizando o ASES e outros


avaliadores automáticos sugeridos no Capítulo 4;

6. Realizar a validação manual, utilizando os checklists de validação humana


disponíveis em http://www.governoeletronico.gov.br/acoes-e-projetos/e-
MAG/material-de-apoio.

A validação manual é uma etapa essencial na avaliação de acessibilidade de um sítio,


já que os validadores automáticos não são capazes de detectar todos os problemas de
acessibilidade em um sítio, pois muitos aspectos requerem um julgamento humano.
Por exemplo, validadores automáticos conseguem detectar se o atributo para
descrever imagens foi utilizado em todas as imagens do sítio, mas somente uma
pessoa poderá verificar se a descrição da imagem está adequada ao seu conteúdo.
Para realizar uma validação manual efetiva, o desenvolvedor deverá ter conhecimento
sobre as diferentes tecnologias, as barreiras de acessibilidade enfrentadas por pessoas
com deficiência e as técnicas ou recomendações de acessibilidade.

Outra etapa essencial da validação de uma página é a realização de testes com


usuários reais (pessoas com deficiência ou limitações técnicas). Um usuário real
poderá dizer se um sítio está realmente acessível, compreensível e com boa
usabilidade e não simplesmente tecnicamente acessível. Quanto maior e mais
diversificado o número de usuários reais participando da avaliação de acessibilidade,
mais eficaz e robusto será o resultado.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 11


2. Recomendações de acessibilidade

Os padrões de acessibilidade compreendem recomendações ou diretrizes que visam


tornar o conteúdo Web acessível a todas as pessoas, inclusive às pessoas com
deficiência, destinando-se aos autores de páginas, projetistas de sítios e aos
desenvolvedores de ferramentas para criação de conteúdo. A observação destes
padrões também facilita o acesso ao conteúdo da Web, independente da ferramenta
utilizada (navegadores Web para computadores de mesa, laptops, telefones celulares,
ou navegador por voz) e de certas limitações técnicas, como, por exemplo, uma
conexão lenta, a falta de recursos de mídia, etc.

As recomendações de acessibilidade deste documento não estão dividas por níveis de


prioridade, já que todas elas são de grande importância e devem ser seguidas. Dessa
forma, optou-se por classificar as recomendações nas seguintes seções:

 Marcação

 Comportamento (DOM)

 Conteúdo/Informação

 Apresentação/Design

 Multimídia

 Formulário

OBS: As recomendações deste documento são baseadas em HTML 4.0 e XHTML 1.1.
A maioria dos exemplos apresentados nas recomendações a seguir mostram o código
(X)HTML que deve ser renderizado no navegador, já que é esse código que apresenta
importância para garantir a acessibilidade. Assim, não foram apresentados exemplos
do lado do servidor, pois o desenvolvedor pode utilizar a linguagem do lado do
servidor que preferir, apenas tomando o cuidado com o código que será gerado.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 12


2.1 Marcação

RECOMENDAÇÃO 1 – RESPEITAR OS PADRÕES DE DESENVOLVIMENTO WEB

Ver WCAG 2.0 Critérios de Sucesso 4.1.1 e 4.1.2

É essencial seguir os padrões de desenvolvimento Web, do W3C (World Wide Web


Consortium), com o intuito de maximizar a compatibilidade com atuais e futuros
agentes de usuário.

É preciso declarar o DOCTYPE correto da página de qualquer documento HTML ou


XHTML. O DOCTYPE define qual versão do (X)HTML o documento está usando e esta é
uma informação fundamental para que os agentes de usuário processem corretamente
o documento. Além disso, é por meio do DOCTYPE que as ferramentas de validação
analisam o código da página e indicam correções. Poderá ser utilizado qualquer
DOCTYPE para HTML ou XHTML, com exceção do Frameset. Além disso, qualquer
código HTML ou CSS inserido em uma página por script ou outro método similar deve
produzir uma página válida quando renderizada.

As camadas lógicas deverão ser separadas, de acordo com o objetivo para o qual elas
foram desenvolvidas. Assim, para a camada de conteúdo devem ser utilizadas as
linguagens de marcação, como html e xhtml. Para a camada de apresentação visual
do conteúdo, utilizam-se as folhas de estilo css em qualquer uma de suas versões. Já
para a camada que modifica o comportamento dos elementos, são utilizadas
linguagens javascript e modelos de objeto (dom).

Exemplos de DOCTYPE
Em HTML 4.01 Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"


"http://www.w3.org/TR/html4/strict.dtd">
<html lang="pt-BR">
<head>
<title>Exemplo de DOCTYPE em HTML 4.01</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>

Em XHTML 1.1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"


"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt-BR">
<head>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 13


<title> Exemplo de DOCTYPE em XHTML 1.1</title>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
</head>

Para mais detalhes a respeito dos padrões de desenvolvimento web, ver a Cartilha de
Codificação Padrões Web e-GOV do padrão e-PWG, disponível em:
http://www.governoeletronico.gov.br/acoes-e-projetos/padroes-brasil-e-gov

RECOMENDAÇÃO 2 – ORGANIZAR O CÓDIGO HTML DE FORMA LÓGICA E SEMÂNTICA

Ver WCAG 2.0 Critério de Sucesso 1.3.1

O código HTML deve ser organizado de forma lógica e semântica, ou seja,


apresentando os elementos em uma ordem compreensível e correspondendo ao
conteúdo desejado. Assim, marcação semântica adequada deve ser utilizada para
designar os cabeçalhos (h1, h2, h3), as listas (ul, ol, dl), texto enfatizado (strong),
marcação de código (code), marcação de abreviaturas (abbr), marcação de citações
longas (blockquote), etc. Dessa forma, as páginas poderão ser apresentadas e
compreendidas sem recursos de estilização, tal como as folhas de estilo. Além disso, o
código semanticamente correto é muito importante para usuários com deficiência
visual, pois os leitores de telas descrevem primeiro o tipo de elemento e depois
realizam a leitura do conteúdo que está dentro desse elemento.

Exemplo correto

<h1>Padrões Web</h1>
<ul>
<li><a href="menu1.html">Menu 1</a></li>
<li><a href="menu2.html">Menu 2</a></li>
</ul>
<h2>Web Semântica</h2>
<blockquote>
O poder da web está em sua universalidade. Ser
acessada por todos, independente de deficiência, é um
aspecto essencial.
</blockquote>
<cite xml:lang="en">Tim Berners Lee</cite>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 14


Exemplo Incorreto

<h1>Padrões Web</h1>
<p><a href="menu1.html">Menu 1</a></p>
<p><a href="menu2.html">Menu 2</a></p>

<h2>Web Semântica</h2>
<p>
O poder da web está em sua universalidade. Ser
acessada por todos, independente de deficiência, é um
aspecto essencial.
</p>
<p>Tim Berners Lee</p>

RECOMENDAÇÃO 3 – UTILIZAR CORRETAMENTE OS NÍVEIS DE CABEÇALHO

Ver WCAG 2.0 Critérios de Sucesso 1.3.1 e 2.4.10

Os níveis de cabeçalho devem ser utilizados de forma lógica e semântica para facilitar
a leitura e compreensão. Além disso, pessoas acessando uma página com leitor de
tela podem navegar através dos cabeçalhos, pulando de um para outro, agilizando,
assim, a navegação. Conceitualmente, existem seis níveis de títulos, sendo o h1 o
mais alto, ou seja, deverá corresponder ao título principal da página. Dessa forma,
cada página deverá ter apenas um h1, o qual poderá ser substituído por uma imagem,
mas deverá permanecer com seu conteúdo, mesmo que não visualmente, permitindo
a leitura pelo leitor de tela. Já os níveis do h2 ao h6 poderão ser utilizados mais de
uma vez na página, mas sem excesso e com lógica textual. Para compreender melhor
os níveis de título pode-se tomar como exemplo um sítio de um livro, onde o nome do
livro é o h1, os capítulos são h2, os subcapítulos são h3 e assim por diante.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 15


Exemplo

Figura 1 – Exemplo de utilização dos níveis de título

HTML

<h1>Técnicas culinárias</h1>
<p>A seguir os segredos que facilitam a vida na cozinha.</p>

<h2>Legumes, folhas e vegetais</h2>


<h3>Baba do quiabo</h3>

<p>Para eliminar a baba do quiabo, lave-o ainda inteiro, seque-o e coloque-o numa tigela
com um pouco de suco de limão, deixando repousar durante 15 minutos. Depois lave
ligeiramente, corte e cozinhe.</p>

<h3>Feijão</h3>
<p>1 xícara de feijão cru serve trás pessoas depois de pronto.</p>

<h3>Cenouras e aipos</h3>
<p>Para resolver o problema de cenouras e aipos meio murchos, mergulhe-os em água
gelada misturada com uma colher de chá de mel por uma hora. Escorra e seque levemente
depois.</p>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 16


<h2>Congelamento e descongelamento</h2>
<h3>Carne em pedaços</h3>
<p>Para descongelar carne em pedaços inteiros coloque–a embrulhada, numa vasilha com
água. Coloque sal na água e no pacote e tampe por uma hora.</p>

<h3>Carne moída</h3>
<p>Para apressar o descongelamento da carne moída, salgue a quantidade que irá usar. O
sal apressa o descongelamento.</p>

RECOMENDAÇÃO 4 – ORDENAR DE FORMA LÓGICA E INTUITIVA A LEITURA E TABULAÇÃO

Ver WCAG 2.0 Critérios de Sucesso 1.3.2 e 2.4.3

Deve-se criar o código HTML com uma sequência lógica de leitura para percorrer links,
controles de formulários e objetos. Essa sequência é determinada pela ordem que se
encontra no código HTML.

É recomendável disponibilizar o bloco de conteúdo no HTML antes do bloco de menu,


para que usuários, navegando pelo teclado, não precisem navegar por todos os itens
de menu antes de chegar ao conteúdo. Apesar de os atalhos auxiliarem nesse sentido,
alguns usuários não sabem utilizá-los. Os atalhos não funcionam em interfaces
especializadas, como o do Leitor de Tela DOSVOX e podem ser de difícil utilização para
pessoas com deficiência motora.

OBS: O atributo tabindex somente deverá ser utilizado quando existir real
necessidade. Com o uso de CSS para fins de leiaute, o código HTML pode facilmente
ser desenvolvido de maneira que a ordem de tabulação seja a correta. No entanto, se
houver necessidade de utilizar o tabindex , o mesmo deverá ser utilizado com a
semântica correta e deverá ser verificado manualmente se o fluxo fornecido pelo
tabindex é realmente o desejado, evitando, assim, que o uso do tabindex resulte
em uma ordem de tabulação inconsistente.

Exemplo correto (sem o uso do tabindex)

<ul>
<li><a href="#">Página Inicial</a></li> <!—primeiro foco -->
<li><a href="#">Capítulo 1</a></li> <!—segundo foco -->
<li><a href="#">Capítulo 2</a></li> <!—terceiro foco -->
<li><a href="#">Capítulo 3</a></li> <!—quarto foco -->
</ul>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 17


Exemplo incorreto do uso do tabindex

<ul>
<li><a href="main.html" tabindex="1">Página Inicial</a></li>
<li><a href="capitulo1.html" tabindex="4">Capítulo 1</a></li>
<li><a href="capitulo2.html" tabindex="3"> Capítulo 2</a></li>
<li><a href="capitulo3.html" tabindex="2"> Capítulo 3</a></li>
</ul>

Ordem de tabulação errada, conferida pelo tabindex:

RECOMENDAÇÃO 5 - DISPONIBILIZAR TODAS AS FUNÇÕES DA PÁGINA VIA TECLADO

Ver WCAG 2.0 Critérios de Sucesso 2.1.1 e 2.1.2

Todas as funções da página desenvolvidas utilizando-se linguagens de script


(javascript) deverão estar disponíveis quando for utilizado apenas o teclado. É
importante salientar que o foco não deverá estar bloqueado ou fixado em um
elemento da página, para que o usuário possa mover-se pelo teclado por todos os
elementos.

Algumas funções específicas do mouse possuem uma função lógica correspondente via
teclado, conforme mostrado na tabela a seguir:

Evento do mouse Evento do teclado

onmousedown onkeydown

onmouseup onkeyup

onclick* onkeypress

onmouseover onfocus*

onmouseout onblur*

OBS: * Alguns manipuladores de eventos são dispositivo-independentes, ou seja, se aplicam a qualquer


dispositivo (mouse, teclado ou outro), como é o caso de: onFocus, onBlur, onSelect, onChange, e onClick
(quando o onClick for utilizado em um link ou elemento de formulário).

Modelo de Acessibilidade em Governo Eletrônico e-MAG 18


Quando forem utilizados múltiplos manipuladores de eventos para uma ação, de
maneira que ela funcione tanto pelo mouse como pelo teclado, é importante testar o
resultado final em diferentes navegadores e utilizando diferentes recursos de
tecnologia assistiva, para garantir que o evento seja, de fato, acessível.

Dê preferência por utilizar o onclick/onkeypress em vez de onmousedown/onkeydown


e onmouseup/onkeyup, pois estes últimos fazem com que o evento seja disparado
automaticamente através do teclado. Se houver real necessidade de utilização destes
eventos, deverá ser feito um controle sobre qual tecla deverá ser acionada para que o
evento ocorra, conforme o exemplo a seguir:

JavaScript

<script type="text/javascript">
var x=document.getElementById("link")
x.onkeydown=function(e){
var pressedkey
if(typeof event!='undefined'){ //navegador Internet Explorer
pressedkey=window.event.keyCode
}else{//outros navegadores
pressedkey=e.keyCode //identifica tecla pressionada
}
if(pressedkey=='13'){ //teste se a tecla é o “enter”
window.open('http://www.brasil.gov.br/') //abre a URL
}
}
</script>

HTML

<p><a href="#" id="link">Portal Brasil</a></p>

Existem funções do mouse que não possuem uma função correspondente via teclado,
como é o caso de duplo clique (dblclick). Nesses casos, é necessário implementar a
função de maneira alternativa, como, por exemplo, incluindo botões que executem,
pelo teclado, a função de forma equivalente. O evento onclick já funciona pelo teclado
(tecla ENTER) na maioria dos navegadores.

RECOMENDAÇÃO 6 – FORNECER ÂNCORAS PARA IR DIRETO A UM BLOCO DE CONTEÚDO

Ver WCAG 2.0 Critério de Sucesso 2.4.1

Devem ser fornecidas âncoras, disponíveis na barra de acessibilidade, que apontem


para links relevantes presentes na mesma página. Assim, é possível ir ao bloco de

Modelo de Acessibilidade em Governo Eletrônico e-MAG 19


conteúdo desejado. Os links devem ser colocados em lugares estratégicos da página,
como por exemplo, no início e final do menu, do conteúdo, etc.

Para facilitar a utilização das âncoras, podem ser disponibilizados atalhos por teclado,
utilizando o atributo accesskey nos links relevantes. É importante ressaltar que as
dicas de atalhos presentes na barra de acessibilidade não devem possuir o atributo
accesskey, já que não pode haver repetição do mesmo accesskey em uma página.
Recomenda-se fornecer atalhos para o menu principal, para o conteúdo e para a caixa
de pesquisa.

Exemplo

Topo da Página (na barra de acessibilidade)

<ul id="atalhos">
<li><a href="#conteudo">Ir para conteúdo [1]</a></li>
<li><a href="#menu">Ir para menu principal[2]</a></li>
<li><a href="#busca">Ir para busca [3]</a></li>
</ul>

Conteúdo da Página

<div>
<a name="conteudo" id="conteudo" class="oculto" accesskey="1">Início do
conteúdo</a>
<!-- Conteúdo →
</div>

Menu Principal da Página

<div>
<a name="menu" id="menu" class="oculto" accesskey="2">Início do menu</a>
<!--itens de menu -->
</div>

Formulário de pesquisa do sítio (pode estar em qualquer lugar no sítio)

<form action="#"method="post">
<fieldset>
<legend>Buscar</legend>
<label for="busca">Pesquise aqui</label>
<input type="text" id="busca" name="busca" accesskey="3" value="Pesquise
aqui" />
<input type="submit" value="Buscar" class="buscar" name="buscar" />
</fieldset>
</form>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 20


Foram utilizados ambos os atributos name e id para que as âncoras funcionem em
todos os navegadores, tanto textuais quanto gráficos, já que há os que suportam
ambos os atributos e os que suportam apenas um deles.

As dicas dos principais atalhos do sítio devem ser disponibilizadas na barra de


acessibilidade e na página sobre a acessibilidade do sítio. Maiores detalhes a esse
respeito podem ser encontrados no capítulo 3 – Elementos de acessibilidade nas
páginas do Governo Federal.

RECOMENDAÇÃO 7 – NÃO UTILIZAR TABELAS PARA DIAGRAMAÇÃO

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnica H51)

As tabelas devem ser utilizadas apenas para dados tabulares e não para efeitos de
disposição dos elementos na página. Para este fim, utilize as folhas de estilo.

RECOMENDAÇÃO 8 – SEPARAR LINKS ADJACENTES

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnica H48)

Links adjacentes devem ser separados por mais do que simples espaços, para que não
fiquem confusos, em especial para usuários que utilizam leitor de tela. Para isso, é
recomendado o uso de listas, onde cada elemento dentro da lista é um link. As listas
podem ser estilizadas visualmente com CSS para que os itens sejam mostrados da
maneira desejada, como um ao lado do outro, por exemplo.

Caso os links estejam no meio de um parágrafo, pode-se utilizar vírgulas, parênteses,


colchetes, etc., para fazer a separação.

Exemplo correto

<ul id="menu">
<li> <a href="home.html">Home</a></li>
<li> <a href="pesquisa.html">Pesquisa</a></li>
<li> <a href="mapasite.html">Mapa do Site</a></li>
</ul>
<!-- Conteudo do Site -->

Modelo de Acessibilidade em Governo Eletrônico e-MAG 21


Exemplo incorreto

<p id="menu">
<a href="#menu">Pular o menu</a><br />
<a href="home.html">Home</a><br />
<a href="pesquisa.html">Pesquisa</a><br />
<a href="mapasite.html">Mapa do Site</a>
</p>
<!-- Conteudo do Site -->

RECOMENDAÇÃO 9 – NÃO ABRIR NOVAS INSTÂNCIAS SEM A SOLICITAÇÃO DO USUÁRIO

Ver WCAG 2.0 Critério de Sucesso 3.2.5

A decisão de se utilizar-se de novas instâncias – por exemplo abas ou janelas - para


acesso a páginas e serviços ou qualquer informação é do cidadão. Assim, não devem
ser utilizados:

• Pop-ups;

• A abertura de novas abas ou janelas;

• O uso do atributo target=“_blank”;

• Mudanças no controle do foco do teclado;

• Entre outras, que não tenham sido solicitadas pelo usuário.

2.2 Comportamento (DOM)

RECOMENDAÇÃO 10 – GARANTIR QUE OS OBJETOS PROGRAMÁVEIS SEJAM ACESSÍVEIS

Ver WCAG 2.0 Critérios de Sucesso 2.1.1 e 2.1.2

Deve-se garantir que scripts, Flash, conteúdos dinâmicos e outros elementos


programáveis sejam acessíveis. Se não for possível que o elemento programável seja
diretamente acessível, deve ser fornecida uma alternativa em HTML para o conteúdo.
Assim, é preciso garantir que o conteúdo e as funcionalidades de objetos
programáveis sejam acessíveis aos recursos de tecnologia assistiva e que seja possível
a navegação por teclado.

Quando o script for utilizado em uma página da Web, uma forma de fornecer uma
alternativa para ele é através do elemento <noscript>. Este elemento pode ser

Modelo de Acessibilidade em Governo Eletrônico e-MAG 22


utilizado para mostrar conteúdos em navegadores que não suportam scripts ou que
tenham o script desabilitado. No entanto, se o navegador tiver suporte a scripts e
estes estiverem habilitados, o elemento <noscript> será ignorado. Dessa forma, a
utilização do elemento <noscript> para um script inacessível não garante que o objeto
seja acessível. Assim, a recomendação é que o próprio script seja desenvolvido
tomando-se o cuidado para que ele seja acessível, e o elemento <noscript> deve ser
utilizado para abranger os casos em que scripts não são suportados.

Exemplo correto

Página HTML

<a href="cadastro.html" id="cadastro">Cadastre-se agora!</a>

Página JavaScript (.js)

function pop() {
alert("Você vai fazer um novo cadastro!");
}
var element = document.getElementById("cadastro");
element.onclick = pop;

Exemplo incorreto
Página HTML

<a href="javascript:pop()">Cadastre-se agora!</a>


<script language="javascript" type="text/javascript">
function pop() {
alert("Você vai fazer um novo cadastro!");
}
</script>

Nesse caso, se o navegador não tiver suporte a scripts, o usuário ficará impossibilitado
de acessar o link.

OBS: A função “alert” do javascript não gera um pop-up e sim uma mensagem que é
lida por todos os leitores de tela.

RECOMENDAÇÃO 11- NÃO CRIAR PÁGINAS COM ATUALIZAÇÃO AUTOMÁTICA PERIÓDICA

Ver WCAG 2.0 Critério de Sucesso 3.2.5 (Técnicas SVR1 e H76)

Modelo de Acessibilidade em Governo Eletrônico e-MAG 23


Não devem ser criadas páginas com atualização automática periódica. Assim, não
deve ser utilizada a meta tag refresh, nem outra forma de atualização automática.
Páginas que se atualizam automaticamente podem confundir e desorientar os
usuários, especialmente usuários que utilizam leitores de tela.

Exemplo1
Em uma interface Web para e-mail (Webmail), um desenvolvedor pode fornecer um
botão ou link para buscar novos e-mails recebidos em vez de atualizar
automaticamente.

Em páginas onde o limite de tempo é absolutamente necessário, o usuário deverá ser


informado que a página é atualizada automaticamente.

Exemplo2

Em uma página de leilões online, é fornecido um banner contendo a informação de


que a página é atualizada a cada 15 segundos.

RECOMENDAÇÃO 12 – NÃO UTILIZAR REDIRECIONAMENTO AUTOMÁTICO DE PÁGINAS

Ver WCAG 2.0 Critério de Sucesso 3.2.5 (Técnicas SVR1 e H76)

Não devem ser utilizadas marcações para redirecionar para uma nova página, como a
meta tag refresh. Ao invés disso, deve-se configurar o servidor para que o
redirecionamento seja transparente para o usuário.

Exemplo Incorreto

<head>
<title>Exemplo<title>
<meta http-equiv="refresh" content="20; url='http://www.exemplo.com/'" />
</head>
<body>
<p>Esta página mudou seu endereço para www.novoendereco.com.br</p>
</body>

RECOMENDAÇÃO 13 – FORNECER ALTERNATIVA PARA MODIFICAR LIMITE DE TEMPO

Ver WCAG 2.0 Critério de Sucesso 2.2.1

Em uma página onde há limite de tempo para realizar uma tarefa deve haver a opção
de desligar, ajustar ou prolongar esse limite.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 24


Essa recomendação não se aplica a eventos em que o limite de tempo é
absolutamente necessário.

Exemplo : Na inserção de dados em um formulário para obtenção de um benefício ou


consulta a processo, o cidadão deve ter tanto tempo quanto for necessário para o
preenchimento de seus dados.

RECOMENDAÇÃO 14 – NÃO INCLUIR SITUAÇÕES COM INTERMITÊNCIA DE TELA

Ver WCAG 2.0 Critério de Sucesso 2.3.1

Não devem ser utilizados efeitos visuais piscantes, intermitentes ou cintilantes. Em


pessoas com epilepsia fotosensitiva, o cintilar ou piscar pode desencadear um ataque
epilético. A exigência dessa diretriz aplica-se também para propaganda de terceiros
inserida na página.

RECOMENDAÇÃO 15 – ASSEGURAR O CONTROLE DO USUÁRIO SOBRE AS ALTERAÇÕES

TEMPORAIS DO CONTEÚDO

Ver WCAG 2.0 Critério de Sucesso 2.2.2

Conteúdos que “se movem”, rolagens, movimentações em geral ou animações não


devem ser disparadas automaticamente sem o controle do usuário, mesmo em
propagandas na página. Ao usuário deve ser repassado o controle sobre essas
movimentações (quer seja por escolha de preferência de visualização da página, quer
por outro método qualquer acessível a usuário com deficiência). Além disso, o usuário
deve ser capaz de parar e reiniciar conteúdos que se movem, sem exceção.

A velocidade desses conteúdos também deve ser passível de controle pelo usuário, a
menos que a implementação de mecanismo para alterar a velocidade seja uma tarefa
de difícil execução (se for necessário realizar uma escolha baseando-se nas limitações,
prefira implementar mecanismos para reduzir a velocidade dos conteúdos no lugar de
aumentar).

Modelo de Acessibilidade em Governo Eletrônico e-MAG 25


2.3 Conteúdo / Informação

RECOMENDAÇÃO 16 – IDENTIFICAR O IDIOMA PRINCIPAL DA PÁGINA

Ver WCAG 2.0 Critério de Sucesso 3.1.1

Deve-se identificar o principal idioma utilizado nos documentos. A identificação é feita


por meio do atributo lang do HTML e, para documentos XHTML, é utilizado o xml:lang.

Exemplo
Em HTML 4.01

...
<html lang="pt-BR">
<head>
<title>documento escrito em português do Brasil</title>
...

Em XHTML 1.1

...
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt-BR">
<head>
<title>documento escrito em português do Brasil</title>
...

RECOMENDAÇÃO 17 – OFERECER UM TÍTULO DESCRITIVO E INFORMATIVO À PÁGINA

Ver WCAG 2.0 Critério de Sucesso 2.4.2

O título da página deve ser descritivo e informativo, já que essa informação será a
primeira lida pelo leitor de tela, quando o usuário acessar a página. O título é
informado pela tag <title>.

Exemplo
O sítio sobre o Projeto Acessibilidade Virtual da RENAPI (Rede Nacional de Pesquisa e
Inovação em Tecnologias Digitais) apresenta o seguinte título:

<title>
Projeto Acessibilidade Virtual - Portal RENAPI – Página Inicial
</title>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 26


RECOMENDAÇÃO 18– DISPONIBILIZAR INFORMAÇÃO SOBRE A LOCALIZAÇÃO DO USUÁRIO

NA PÁGINA

Ver WCAG 2.0 Critério de Sucesso 2.4.8

Deverá ser fornecido um mecanismo que permita ao usuário orientar-se dentro de um


conjunto de páginas, permitindo que ele saiba onde está no momento. Assim, poderá
ser utilizado o recurso de “migalha de pão” (breadcrumbs), que são links navegáveis
em forma de lista hierárquica e permitem que o usuário saiba qual o caminho
percorrido até chegar à página em que se encontra no momento.

Exemplo
Um usuário navegando por um sítio de uma universidade encontra-se na seção de
editais, que está dentro do menu “Ensino”. Acima do conteúdo, é disponibilizado a
seguinte Migalha de pão:

Você está em: Página inicial > Ensino > Editais

OBS: Na migalha de pão, todos as páginas do caminho, com exceção da qual está o
usuário (posição atual), deverão estar implementadas como links.

RECOMENDAÇÃO 19 – DESCREVER LINKS CLARA E SUCINTAMENTE

Ver WCAG 2.0 Critérios de Sucesso 2.4.4 e 2.4.9

Deve-se identificar claramente o destino de cada link, informando, inclusive, se o link


remete a outro sítio. Além disso, é preciso que o texto do link faça sentido mesmo
quando isolado do contexto da página.

É preciso tomar cuidado para não utilizar o mesmo título para dois ou mais links que
apontem para destinos diferentes.

Exemplo 1

<h2>Educação Superior</h2>
<p>Tomam posse os reitores das federais da Bahia e Triângulo</p>

<p> <a href="notici5125.html">Leia mais notícias sobre Educação Superior</a>


</p>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 27


Repare que não há necessidade de utilizar o atributo title em links, já que esse
atributo não é bem suportado por recursos de tecnologia assistiva, como leitores de
tela, não tem utilidade para quem navega apenas pelo teclado e não tem bom suporte
em dispositivos móveis, como celulares, entre outros problemas. Assim, se você
quiser fornecer informações adicionais para um link, faça-o no próprio texto do link ou
no contexto.

Exemplo 2

Correto:
Ganhe um prêmio fornecido pelo nosso patrocinador

Ganhe um prêmio fornecido pelo nosso patrocinador

Incorreto:
Clique aqui para ganhar um prêmio fornecido pelo nosso patrocinador

OBS: Não é recomendada a utilização de links do tipo “clique aqui” pois esta
expressão não faz sentido fora do contexto. Muitos usuários de leitores de tela
navegam por links, tornando descrições como “Clique aqui”, “Veja mais” insuficientes
para o usuário saber o destino do link, ou localizá-lo na página. Evitar essas
expressões para evitar verborragia, ou seja, evitar que o leitor de tela “leia” para o
usuário palavras ou frases desnecessárias.

RECOMENDAÇÃO 20 – FORNECER ALTERNATIVA EM TEXTO PARA AS IMAGENS DO SÍTIO

Ver WCAG 2.0 Critério de Sucesso 1.1.1 (Técnica G95)

Deve ser fornecida uma descrição para as imagens da página, utilizando-se o atributo
alt. Imagens que não transmitem conteúdo, ou seja, imagens decorativas, devem ser
inseridas por CSS.

No entanto, descrever qualquer imagem, em geral, é algo bastante subjetivo e a


descrição deve ser adaptada ao contexto em que a imagem se encontra. Para maiores
detalhes de como escrever um texto alternativo veja o tutorial O uso correto do texto
alternativo na seção do e-MAG no portal de Governo Eletrônico.

Exemplo 1

Modelo de Acessibilidade em Governo Eletrônico e-MAG 28


Figura 2 – Exemplo de descrição de imagem. Foto de Jônatas
Cunha em licença Creative Commons Fonte:
http://www.flickr.com/photos/jonycunha/4019704214/in/photostream
/

No código:
<img src="crianca.jpg" alt="Foto de uma criança cheirando uma flor" />

Exemplo 2

Figura 3 – Exemplo de descrição de banner

No código:
<a href="http://www.dominiopublico.gov.br/">
<img src="dominioPublico.jpg" alt="Portal Domínio Público" />
</a>

Apesar de não haver um limite de caracteres no atributo alt, ele é utilizado para
descrições sintéticas, em poucas palavras ou em uma frase curta. Para imagens mais
complexas que exigem uma descrição mais detalhada, como gráficos, por exemplo,
deve-se fornecer, além do alt, a descrição no próprio contexto ou um link para a
descrição longa logo após a imagem. Deve ficar claro para o usuário que esse link
remete para a descrição longa da imagem, conforme o exemplo a seguir.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 29


Exemplo 3

Figura 4 – Exemplo de descrição de gráfico


A descrição textual do gráfico está disponível em outra página

No código:
<img src="grafico.jpg" alt="Gráfico de pizza demonstrando os resultado da pesquisa sobre a
distribuição de espaço em páginas" />

<p><a href="graficoPesquisa.html">A descrição textual do gráfico</a> está disponível em


outra página</p>

Para gráficos, poderá ser disponibilizada tanto a descrição textual quanto a tabela de
dados que lhe deu origem, desde que a tabela seja fornecida em HTML, tomando-se
os devidos cuidados relativos à acessibilidade.

Além de fornecer a descrição longa no contexto ou em um link próximo, pode-se


utilizar o atributo longdesc na imagem, o qual é recomendado pela WCAG para
descrições longas, mas não é suportado por alguns recursos de tecnologia assistiva. A
utilização do longdesc pode ser vista no exemplo a seguir.

Exemplo 4

<img src="grafico.jpg" alt="Gráfico de pizza demonstrando os resultado da pesquisa sobre a


distribuição de espaço em páginas" longdesc="graficoPesquisa.html" />

<p><a href="graficoPesquisa.html">A descrição textual do gráfico</a> está disponível em


outra página</p>

graficoPesquisa.html

<h2> Distribuição de espaço em páginas</h2>


<ul>
<li>Propaganda - 60%</li>
<li>Sem Uso - 10%</li>
<li>Navegação - 10%</li>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 30


<li>Conteúdo de Interesse - 20%</li>
</ul>

Exemplo de imagem decorativa:

Figura 5 – Imagem decorativa em link “Volta ao topo da página”

HTML

<a href="#id_de_destino">Topo da página</a>

CSS

a{
background:transparent url(img/topo_pagina.jpg)no-repeat right top; /*inserção da imagem decorativa
do link */
padding:4px 27px 0 0; /* espaço colocado para a imagem ficar ao lado do link */
height:23px; /*ajuste na altura do link para que apareça toda a imagem */
}

RECOMENDAÇÃO 21 – FORNECER ALTERNATIVA EM TEXTO PARA AS ZONAS ATIVAS DE

MAPA DE IMAGEM

Ver WCAG 2.0 Critério de Sucesso 1.1.1 (Técnica H24)

Para mapas de imagem do lado do cliente, devem ser fornecidas descrições através do
atributo alt para cada uma das zonas ativas, ou seja, para cada um dos links que
receberá o foco.

Exemplo (mapa de imagem do lado do cliente)

Figura 6 – Mapa de imagem exemplo 1

<img src="mapaImg.jpg" alt="Imagem com alternativas [A] e [B]" usemap="#Map" />

<map name="Map" id="Map">


<area shape="rect" coords="8,10,63,59" href="a.html" alt="Link para a seção [A]"
/>
<area shape="rect" coords="77,9,126,61" href="b.html" alt="Link para a seção [B]"
/>
</map>

Além dos mapas de imagem do lado do cliente, existem os do lado do servidor. No

Modelo de Acessibilidade em Governo Eletrônico e-MAG 31


entanto, é recomendada a utilização de mapas de imagem do lado do cliente, já que
para mapas de imagem do lado do servidor não é possível fornecer um alt para cada
uma das zonas ativas, somente para o mapa como um todo, não sendo possível,
portanto, torná-lo acessível. No entanto, se for realmente necessária sua utilização,
devem ser fornecidos links redundantes relativos a cada região ativa do mapa de
imagem, conforme o exemplo a seguir, para que, desta forma, usuários com leitores
de tela possam ter acesso ao seu conteúdo.

Exemplo (mapa de imagem do lado do servidor)

<a href="novaPagina.jpg"><img
src="bandeiraBrasil.jpg" ismap="ismap"
alt="Bandeira do Brasil (Links a seguir)"/></a>
<p><a href="areaVerde.html">Área Verde</a> -
</p>
<p><a href="areaAmarela.html">Área
Amarela</a> - </p>
<p><a href="areaAzul.html">Área Azul</a></p>

Figura 7 – Mapa de imagem exemplo 2

OBS: Não devem ser utilizados mapas de imagem para menus ou seleção de regiões
para serviços.

RECOMENDAÇÃO 22 – DISPONIBILIZAR DOCUMENTOS EM FORMATOS ACESSÍVEIS

Sem correspondência a critérios da WCAG 2.0

Os documentos devem ser disponibilizados preferencialmente em HTML. Também


podem ser utilizados arquivos para download no formato ODF, tomando-se os
cuidados para que sejam acessíveis. Se um arquivo for disponibilizado em PDF,
deverá ser fornecida uma alternativa em HTML ou ODF. É necessário, também,
informar a extensão e o tamanho do arquivo no próprio texto do link.

Exemplo

<a href=”manual.odt”> Manual do W3C (formato .odt, tamanho 150Kb) </a>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 32


OBS: O ODF (Open Document Format) é um formato aberto de documento adotado
pela e-PING (Arquitetura de Interoperabilidade em Governo Eletrônico) que pode ser
implementado em qualquer sistema. O ODF engloba formatos como: ODT para
documentos de texto, ODS para planilhas eletrônicas, ODP para apresentações de
slides, entre outros.

Muitos softwares já utilizam esses formatos, como é o caso do OpenOffice, BrOffice,


Google Docs, Abiword e StarOffice. O Microsoft Office 2010 também inclui suporte
para ODF. Para versões anteriores do Microsoft Office, pode ser instalado um Add-in
gratuito para suporte aos formatos ODF.

RECOMENDAÇÃO 23 – EM TABELAS, UTILIZAR TÍTULOS E RESUMOS DE FORMA

APROPRIADA

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnicas H39 e H73)

O título da tabela deve ser definido pelo elemento caption e deve ser o primeiro
elemento utilizado após a declaração do elemento table. Em casos de tabelas
extensas, deve ser fornecido um resumo de seus dados através do atributo summary
que deve ser declarado no elemento table.

Exemplo

<table summary="Esta tabela exibe os copos de café consumidos por cada senador, o tipo de
café (descafeinado ou normal), com açúcar ou sem açúcar.">
<caption>Copos de café por Senador</caption>
...

Para mais detalhes veja o tutorial tabelas acessíveis (documento pdf - 154 KB), na
seção do
e-MAG no Portal do Programa de Governo Eletrônico.

RECOMENDAÇÃO 24 – ASSOCIAR CÉLULAS DE DADOS ÀS CÉLULAS DE CABEÇALHO EM UMA

TABELA

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnicas H43 e H63)

Em tabelas de dados simples, a uso apropriado do elemento th para os cabeçalhos e


do elemento td para as células de dados é essencial para torná-las acessíveis. Para
incrementar a acessibilidade, deve-se utilizar os elementos thead, tbody e tfoot, para

Modelo de Acessibilidade em Governo Eletrônico e-MAG 33


agrupar as linhas de cabeçalho, do corpo da tabela e do final, respectivamente, com
exceção de quando a tabela possuir apenas o corpo, sem ter seções de cabeçalho e
rodapé. O W3C sugere utilizar o tfoot antes do tbody dentro da definição table para
que o agente de usuário possa renderizar o rodapé antes de receber todas
(potencialmente numerosas) linha de dados.

Exemplo 1

<table>
<caption>Demonstrativo do Patrimônio</caption>
<thead>
<tr>
<th>Tipos</th>
<th>Valores (R$)</th>
<th>Percentual</th>
</tr>
</thead>
<tfoot>
<tr>
<td>Total</td>
<td>110.740,22</td>
<td>100%</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Recursos Financeiro</td>
<td>56.879,63</td>
<td>51,36%</td>
</tr>
<tr>
<td>Bens Móveis</td>
<td>25.691,23</td>
<td>23,20%</td>
</tr>
<tr>
<td>Bens Imóveis</td>
<td>28.169,36</td>
<td>25,44%</td>
</tr>
</tbody>
</table>

Figura 8 – Imagem da tabela descrita no código do exemplo 1

Modelo de Acessibilidade em Governo Eletrônico e-MAG 34


Para tabelas mais complexas, é necessário utilizar marcações para associar as células
de dados com as células de cabeçalho. A maneira mais adequada de realizar esse
procedimento é utilizar os elementos id/headers ou scope/col. No primeiro, pode-se
associar qualquer célula de conteúdo a qualquer célula de cabeçalho, utilizando o
mesmo valor para o atributo id e para o headers. No segundo caso, a associação é
automática, sendo mais utilizado em tabelas de associação direta, onde é dado o valor
“col” para o atributo scope nos cabeçalhos. Nos exemplo a seguir, é possível verificar
a utilização do id/headers e do scope/col.

Exemplo 2

<table summary="...">

<table>
<caption>Resultado do Concurso</caption>
<tr>
<th id="vaga">Vaga</th>
<th id="candidato">Nome do candidato</th>
<th id="basico">Prova de Conhecimento Básico</th>
<th id="especifico">Prova de Conhecimento Específico</th>
</tr>
<tr>
<td id="adm" rowspan="2">Técnico Administrativo</td>
<td id="PaulodaSilva">Paulo da Silva</td>
<td headers="adm basico PaulodaSilva">8</td>
<td headers="adm especifico PaulodaSilva">16</td>
</tr>
<tr>
<td id="PedroPontes">Pedro Pontes</td>
<td headers="adm basico PedroPontes">7</td>
<td headers="adm especifico PedroPontes">15</td>
</tr>
<tr>
<td id="inf">Técnico em Informática</td>
<td id="JoaoPereira">João Pereira</td>
<td headers="inf basico JoaoPereira">9</td>
<td headers="inf especifico JoaoPereira">17</td>
</tr>
</table>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 35


Figura 9 – Imagem da tabela descrita no código do exemplo 2

Exemplo 3

<table summary="Tabela de vendas de maçã e banana efetuadas no ano de 2010">


<caption>Vendas 2010</caption>
<tr>
<th scope="col">Mês</th>
<th scope="colgroup" colspan="2">Rio Grande do Sul</th>
<th scope="colgroup" colspan="2">Santa Catarina</th>
</tr>
<tr>
<td>Janeiro</td>
<td scope="col">Maçã</td>
<td scope="col">Banana</td>
<td scope="col">Maçã</td>
<td scope="col">Banana</td>
</tr>
<tr>
<td>Feveiro</td>
<td>1000</td>
<td>1500</td>
<td>3000</td>
<td>1000</td>
</tr>
<tr>
<td>Março</td>
<td>2000</td>
<td>1500</td>
<td>3500</td>
<td>500</td>
</tr>
</table>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 36


Figura 10 – Imagem da tabela descrita no código do exemplo 3

Exemplo 4

<table summary="Tabela com resumo das despesas de transporte durante o mês de


Agosto nas cidades de Porto Alegre e Florianópolis">
<caption>Relatório de despesa de viagem</caption>
<tr>
<th></th>
<th id="alimentacao" axis="despesas">Alimentação</th>
<th id="hotel" axis="despesas">Hotel</th>
<th id="transporte" axis="despesas">Transporte</th>
</tr>
<tr>
<th id="poa" axis="localização" colspan="4">Porto Alegre</th>
</tr>
<tr>
<td id="data1" axis="data">25 de agosto de 2010</td>
<td headers="poa data1 alimentacao">R$ 37,74</td>
<td headers="poa data1 hotel">R$ 112,00</td>
<td headers="poa data1 transporte">R$ 45,00</td>
</tr>
<tr>
<td id="data2" axis="data">26 de agosto de 2010</td>
<td headers="poa data2 alimentacao">R$ 27,28</td>
<td headers="poa data2 hotel">R$ 112,00</td>
<td headers="poa data2 transporte">R$ 45,00</td>
</tr>
<tr>
<th id="subPoa">Subtotal</th>
<td headers="poa subPoa alimentacao">R$ 65,02</td>
<td headers="poa subPoa hotel">R$ 224,00</td>
<td headers="poa subPoa transporte">R$ 90,00</td>
</tr>
<tr>
<th id="floripa" axis="localização" colspan="4">Florianópolis</th>
</tr>
<tr>
<td id="data3" axis="data">27 de agosto de 2010</td>
<td headers="floripa data3 alimentacao">R$ 96,25</td>
<td headers="floripa data3 hotel">R$ 109,00</td>
<td headers="floripa data3 transporte">R$ 36,00</td>
</tr>
<tr>
<td id="data4" axis="data">28 de agosto de 2010</td>
<td headers="floripa data4 alimentacao">R$ 35,00</td>
<td headers="floripa data4 hotel">R$ 109,00</td>
<td headers="floripa data4 transporte">R$ 36,00</td>
</tr>
<tr>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 37


<th id="subFloripa">Subtotal</th>
<td headers="floripa subFloripa alimentacao">R$ 131,25</td>
<td headers="floripa subFloripa hotel">R$ 218,00</td>
<td headers="floripa subFloripa transporte">R$ 72,00</td>
</tr>
<tr>
<th id="total">Total</th>
<td headers="total alimentacao">R$ 196,27</td>
<td headers="total hotel">R$ 442,00</td>
<td headers="total transporte">R$ 162,00</td>
</tr>
</table>

Figura 11 – Exemplo da tabela do exemplo 4 com o uso do atributo axis

Para mais detalhes veja o tutorial Tabelas Acessíveis (documento pdf - 154 KB) na
seção do e-MAG no Portal do Programa de Governo Eletrônico.

RECOMENDAÇÃO 25 – GARANTIR A LEITURA E COMPREENSÃO DAS INFORMAÇÕES

Ver WCAG 2.0 Critério de Sucesso 3.1.5

O texto de um sítio deve ser de fácil leitura e compreensão, não exigindo do usuário
um nível de instrução mais avançado do que o ensino fundamental completo. Quando
o texto exigir uma capacidade de leitura mais avançada, deve ser disponibilizado
informações suplementares que expliquem ou ilustrem conteúdo principal. Outra
alternativa é versão simplificada do conteúdo em texto.

Existem algumas técnicas que auxiliam na melhora da inteligibilidade de textos, como,


por exemplo:

 Desenvolver apenas um tópico por parágrafo;

Modelo de Acessibilidade em Governo Eletrônico e-MAG 38


 Utilizar sentenças organizadas de modo simplificado para o propósito do
conteúdo (sujeito, verbo e objeto, preferencialmente);
 Dividir sentenças longas em sentenças mais curtas;
 Evitar o uso de jargão, expressões regionais ou termos especializados que
possam não ser claros para todos;
 Utilizar palavras comuns no lugar de outras pouco familiares;
 Utilizar listas de itens ao invés de uma longa série de palavras ou frases
separadas por vírgulas;
 Fazer referências claras a pronomes e outras partes do documento;
 Utilizar, preferencialmente, a voz ativa.

Para mais informações sobre como escrever textos para web, acesse a Cartilha de
Redação Web na Seção do e-PWG (Padrões Web em Governo Eletrônico) no Portal de
Governo Eletrônico.

RECOMENDAÇÃO 26 – DISPONIBILIZAR UMA EXPLICAÇÃO PARA SIGLAS, ABREVIATURAS E

PALAVRAS INCOMUNS

Ver WCAG 2.0 Critérios de Sucesso 3.1.3 e 3.1.4

Deve estar disponível uma explicação que identifique a forma completa ou o


significado das abreviaturas e siglas. Para isso, pode ser utilizada a tag abbr.

Exemplo

<p>Bem-vindo à <abbr title="World Wide Web" lang="en">WWW</abbr>!</p>

Já as palavras que podem ser ambíguas, desconhecidas ou utilizadas de forma muito


específica, deverão ser definidas através de um texto adjacente, uma lista de
definições ou estarem contidas num glossário.

RECOMENDAÇÃO 27 – INFORMAR MUDANÇA DE IDIOMA NO CONTEÚDO

Ver WCAG 2.0 Critério de Sucesso 3.1.2

Modelo de Acessibilidade em Governo Eletrônico e-MAG 39


Se algum elemento de uma página possuir conteúdo em um idioma diferente do
principal, este deverá estar identificado pelo atributo lang. Essa recomendação não se
aplica para nomes próprios ou termos técnicos que sejam compreendidos no contexto.

Exemplo

XHTML

<p xml:lang="de">
Da dachte der Herr daran, ihn aus dem Futter zu schaffen,
aber der Esel merkte, daß kein guter Wind wehte, lief fort
und machte sich auf den Weg nach Bremen: dort, meinte er,
könnte er ja Stadtmusikant werden.
</p>

HTML

<p lang="de">
Da dachte der Herr daran, ihn aus dem Futter zu schaffen,
aber der Esel merkte, daß kein guter Wind wehte, lief fort
und machte sich auf den Weg nach Bremen: dort, meinte er,
könnte er ja Stadtmusikant werden.
</p>

2.4 Apresentação / Design

RECOMENDAÇÃO 28 - OFERECER CONTRASTE MÍNIMO ENTRE PLANO DE FUNDO E

PRIMEIRO PLANO

Ver WCAG 2.0 Critério de Sucesso 1.4.3

As cores do plano de fundo e do primeiro plano deverão ser suficientemente


contrastantes para que possam ser visualizadas, também, por pessoas com baixa
visão, com cromodeficiências ou que utilizam monitores de vídeo monocromático.

Não deverão ser utilizadas imagens atrás do texto (background), pois acabam por
dificultar a leitura e desviar a atenção do usuário.

A relação de contraste pode ser encontrada dividindo-se o valor da luminosidade


relativa da cor mais clara de um dos planos pelo valor da luminosidade relativa da cor
mais escura do outro plano. A relação de contraste entre plano de fundo e primeiro
plano de 3:1 é o nível mínimo de contraste recomendado pela ISO-9241-3. No
entanto, levando-se em consideração a perda de percepção do contraste resultante da
baixa acuidade visual, cromodeficiência ou perda de sensibilidade ao contraste devido

Modelo de Acessibilidade em Governo Eletrônico e-MAG 40


ao envelhecimento, é recomendada aqui uma maior relação de contraste, de, no
mínimo, 4,5:1. Existem ferramentas gratuitas disponíveis na Web que verificam a
relação de contraste entre as cores do plano de fundo e do primeiro plano,
referenciadas no capítulo 4 deste documento e para uma tabela de cores no anexo 1.

RECOMENDAÇÃO 29 – NÃO UTILIZAR APENAS COR OU OUTRAS CARACTERÍSTICAS

SENSORIAIS PARA DIFERENCIAR ELEMENTOS

Ver WCAG 2.0 Critérios de Sucesso 1.3.3 e 1.4.1

A cor ou outras características sensoriais, como forma, tamanho, localização visual,


orientação ou som não devem ser utilizadas como o único meio para transmitir
informações, indicar uma ação, pedir uma resposta ao usuário ou distinguir um
elemento visual.

Exemplo

HTML

<p>Existem três procedimentos para executar a tarefa:</p>

<ul>
<li><a href="#">Procedimento A</a></li>
<li><a href="#" class="recomendado">Procedimento B (Recomendado)</a></li>
<li><a href="#">Procedimento C</a></li>
</ul>

CSS

a.recomendado{
color: #FF0000;
}

Figura 12 – Exemplo correto de utilização de cores nos elementos

Modelo de Acessibilidade em Governo Eletrônico e-MAG 41


RECOMENDAÇÃO 30 – PERMITIR REDIMENSIONAMENTO DE TEXTO SEM PERDA DE

FUNCIONALIDADE

Ver WCAG 2.0 Critério de Sucesso 1.4.4

A página deve continuar legível e funcional quando redimensionada para até 200%.
Assim, é preciso garantir que, quando a página for redimensionada, não ocorram
sobreposições de texto nem o aparecimento de uma barra horizontal.

Exemplo

Um sítio possui uma ferramenta que permite o redimensionamento do tamanho da


fonte. Para isso existe um botão que aumenta a fonte de dois em dois pixels. Da
mesma forma, existe um botão que diminui a fonte de dois em dois pixels e outro que
retorna ao tamanho padrão da fonte. O sítio utiliza um leiaute flexível, isto é, à
medida que a fonte aumenta ou diminui, o leiaute se ajusta automaticamente para
que não ocorram “quebras”.

<title>Exemplo Básico de Leiaute Líquido</title>


<style type="text/css">
.coluna {
border-left: 1px solid green;
padding-left:1%;
float: left;
width: 32%;
}
#rodape {
border-top: 1px solid green;
clear: both;
}
</style>
</head>
<body>

<h1>Exemplo de Redimensionamento</h1>
<form action="#">
<fieldset>
<legend>Redimensionamento do texto</legend>
<input type="button" id="mais" value="Aumentar" />
<input type="button" id="mais" value="Diminuir" />
<input type="button" id="mais" value="Tamanho padrão" />
</fieldset>
</form>

<h2>Este texto está dividido em três blocos...</h2>


<div class="coluna">
<h3>Bloco 1</h3>
<p>O objetivo desta técnica é apresentar o conteúdo sem que ocorra a introdução de uma barra
horizontal.</p> </div>
<div class="coluna">
<h3>Bloco 2</h3>
<p>Este é um exemplo simples de leiaute de página que se adapta ao redimensionamento de
texto.</p>
</div>
<div class="coluna">

Modelo de Acessibilidade em Governo Eletrônico e-MAG 42


<h3>Bloco 3</h3>
<p>Esta é uma técnica simples mas que pode ser implementada para leiautes mais complexos.</p>

</div>
<p id="rodape">Texto do Rodapé</p>
</body>
</html>

Figura 13 – Exemplo de página em seu tamanho padrão

Figura 14 – Exemplo de página redimensionada em 200% sem perda de funcionalidade

RECOMENDAÇÃO 31 – DIVIDIR AS ÁREAS DE INFORMAÇÃO

Ver WCAG 2.0 Critério de Sucesso 3.2.3 (Técnica G61)

Áreas de informação devem ser divididas em grupos fáceis de gerenciar. As divisões


mais comuns são “topo”, “conteúdo”, “menu” e “rodapé”. Nas páginas internas deve-

Modelo de Acessibilidade em Governo Eletrônico e-MAG 43


se manter uma mesma divisão para que o usuário se familiarize mais rapidamente
com a estrutura do sítio. É importante destacar, entretanto, que a página inicial pode
ter uma divisão diferente das páginas internas, pois normalmente ela contém mais
elementos. O exemplo a seguir mostra a divisão da página inicial de um sítio contendo
os blocos “topo”, “menu”, “conteúdo” e “rodapé”, além da barra de acessibilidade
contendo os atalhos.

Exemplo

Figura 15 – Exemplo de divisão de blocos de conteúdo

<div id="topo">
<a href="#inicioTopo" id="inicioTopo">Topo</a>
<h1>NOME DA INSTITUIÇÃO</h1>

<div id="barraAcessibilidade">
<p>Barra de Acessibilidade</p>
<ul>
<li><a href="#inicioConteudo">Ir para conteúdo [1]</a></li>
<li><a href="#inicioMenu">Ir para menu principal [2]</a></li>
<li><a href="#busca">Ir para Busca [3]</a></li>
</ul>
</div>
</div>
<div id="menu">
<a href="#inicioMenu" id="inicioMenu" accesskey="2">Menu</a>
<ul>
<li>Itens de menu</li>
<li>...</li>
</ul>
</div>
<div id="conteudo">
<a href="#inicioConteudo" id="inicioConteudo" accesskey="1">Conteúdo</a>
<form action="#" method="post">
<fieldset>
<legend>Buscar</legend>
<label for="busca">Pesquise aqui</label>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 44


<input type="text" id="busca" name="busca" accesskey="3" value="Pesquise aqui" />
<input type="submit" value="Buscar" class="buscar" name="buscar" />
</fieldset>
</form>
<h2>BEM VINDO</h2>
<p>Seja bem vindo ao nosso site.</p>
</div>
<div id="rodape">
<a href="#inicioRodape" id="inicioRodape">Rodapé</a>
<address> Rua XXX</address>
</div>

A divisão em blocos de conteúdo representa a base para a utilização dos atalhos,


permitindo que o usuário tenha rápido acesso à área desejada. Para mais detalhes
sobre a barra de acessibilidade e os atalhos, ver o capítulo 3 – Padronização de
acessibilidade nas páginas do Governo Federal.

É importante que as diversas páginas de um sítio possuam um estilo de apresentação


coerente e sistemático, mantendo-se um padrão de estrutura. Assim, elementos
principais de navegação deverão ser mantidos na mesma posição em todas as
páginas, com exceção da página inicial que, muitas vezes, apresenta uma estrutura
diferenciada.

Exemplo
Um sítio possui um logotipo, um título, um formulário de pesquisa e uma barra de
navegação. Esses elementos aparecem na mesma ordem relativa em cada página do
sítio em que se repetem. Em uma das páginas, não há o formulário de pesquisa, mas
o restante dos itens continua na mesma ordem.

RECOMENDAÇÃO 32 – POSSIBILITAR QUE O ELEMENTO COM FOCO SEJA VISUALMENTE

EVIDENTE

Ver WCAG 2.0 Critério de Sucesso 2.4.7

A área que recebe o foco pelo teclado deve ser claramente marcada, devendo a área
de seleção ser passível de ser clicada.

Por padrão, links e elementos de formulário já apresentam a borda destacada ao


receberem o foco do teclado. Essa borda pode ser modificada via CSS, mas não
deverá ser removida.

Exemplo

CSS

Modelo de Acessibilidade em Governo Eletrônico e-MAG 45


a:active, a:focus, a:hover {
border: 1px solid #F00;
}

HTML
<ul>
<li><a href="/acessibilidade/index.php">Página Inicial</a></li>
<li><a href="/acessibilidade/eventos.php">Eventos</a></li>
<li><a href="/acessibilidade/quemsomos.php">Quem Somos</a></li>
<li><a href="/acessibilidade/ead.php">Ensino a Distância (EaD)</a></li>
<li><a href="/acessibilidade/videoaulas.php">Vídeoaulas</a></li>
<li><a href="/acessibilidade/video.php">Vídeo em Libras</a></li>
<li><a href="/acessibilidade/oa.php">Objetos de Aprendizagem</a></li>
<li><a href="/acessibilidade/trabalhos.php">Trabalhos Realizados</a></li>
<li><a href="/acessibilidade/mapa.php">Mapa do Site</a></li>
</ul>

Figura 16 – Exemplo de foco visível em menu

A pseudo-classe :focus é utilizada para definir o estilo de qualquer elemento HTML


que receber o foco do teclado, como links e elementos de formulário. A pseudo-classe
:hover é utilizada para definir o estilo de um elemento quando passa-se o mouse
sobre ele. Já a pseudo-classe :active define o estilo de link ativo. No caso do
exemplo acima, a pseudo-classe :active foi utilizada para definir o estilo do link com
foco para navegadores Internet Explorer 7 e anteriores, que ainda não tinham suporte
à pseudo-classe :focus.

2.5 Multimídia

RECOMENDAÇÃO 33 – FORNECER ALTERNATIVA PARA VÍDEO

Ver WCAG 2.0 Critérios de Sucesso 1.2.1, 1.2.2, 1.2.6 e 1.2.8

Modelo de Acessibilidade em Governo Eletrônico e-MAG 46


Deve haver uma alternativa sonora ou textual para vídeos que não incluem faixas de
áudio. Para vídeos que contêm áudio falado e no idioma natural da página, devem ser
fornecidas legendas. Além de essencial para pessoas com deficiência visual, a
alternativa em texto também é importante para usuários que não possuem
equipamento de som, que desejam apenas realizar a leitura do material ou não
dispõem de tempo para ouvir um arquivo multimídia. Para tanto, podem ser
fornecidos:

Situação 1

Um vídeo mostra como produzir uma tecnologia assistiva de baixo custo. Não há
áudio, mas o vídeo inclui uma série de números para representar cada etapa do
processo. Nesse caso, junto ao vídeo, deve ser disponibilizado um arquivo com a
alternativa de texto que indica o conteúdo do vídeo e a descrição de cada uma das
etapas.

Figura 17 – Vídeo contendo arquivo com alternativa em texto

Situação 2

Uma universidade oferece a opção de visualizar suas videoaulas com ou sem


legendas.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 47


Figura 18 – Vídeo com legenda

Além de alternativa em texto e legenda, é desejável que os vídeos com áudio


apresentem alternativa na Língua Brasileira de Sinais (Libras).

RECOMENDAÇÃO 34 – FORNECER ALTERNATIVA PARA ÁUDIO

Ver WCAG 2.0 Critérios de Sucesso 1.2.1, 1.2.2 e 1.2.6

Áudio gravado deve possuir uma transcrição descritiva. Além de essencial para
pessoas com deficiência auditiva, a alternativa em texto também é importante para
usuários que não possuem equipamento de som, que desejam apenas realizar a
leitura do material ou não dispõem de tempo para ouvir um arquivo multimídia. Neste
caso, também é desejável a alternativa em Libras.

Situação 1

Em um podcast o entrevistador faz perguntas a um especialista de saúde. Como essas


informações são disponibilizadas ao usuário do sítio em um arquivo de áudio, deve ser
fornecido um link para um arquivo com alternativa em texto, logo após o conteúdo em
áudio.

Uma apresentação prévia do conteúdo dos dois tipos de arquivo e de sua duração
também é desejável.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 48


RECOMENDAÇÃO 35 – OFERECER AUDIODESCRIÇÃO PARA VÍDEO PRÉ-GRAVADO

Ver WCAG 2.0 Critério de Sucesso 1.2.3, 1.2.5 e 1.2.7

Vídeos que transmitem conteúdo visual que não está disponível na faixa de áudio
devem possuir uma audiodescrição.

A audiodescrição consiste na descrição clara e objetiva de todas as informações


apresentadas de forma visual e que não fazem parte dos diálogos. Essas descrições
são apresentadas nos espaços entre os diálogos e nas pausas entre as informações
sonoras.

Exemplo

Um vídeo de um malabarista se apresentando para um grupo de crianças inclui uma


versão com audiodescrição. O narrador da audiodescrição descreve o número e o tipo
de instrumentos que o malabarista utiliza, bem como as reações que as crianças têm
durante a performance.

RECOMENDAÇÃO 36 – FORNECER CONTROLE DE ÁUDIO PARA SOM

Ver WCAG 2.0 Critério de Sucesso 1.4.2

Deve ser fornecido um mecanismo para parar, pausar, silenciar ou ajustar o volume
de qualquer som que se reproduza na página.

RECOMENDAÇÃO 37 – FORNECER CONTROLE DE ANIMAÇÃO

Ver WCAG 2.0 Critério de Sucesso 2.2.2

Para qualquer animação que inicie automaticamente na página devem ser fornecidos
mecanismos para que o usuário possa pausar, parar ou ocultar tal animação.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 49


2.6 Formulários

RECOMENDAÇÃO 38 – FORNECER ALTERNATIVA EM TEXTO PARA OS BOTÕES DE IMAGEM

DE FORMULÁRIOS

Ver WCAG 2.0 Critério de Sucesso 1.1.1

Ao serem utilizados botões do tipo imagem (input type=”image”), que servem para o
mesmo propósito do botão do tipo submit, deve ser fornecida uma descrição textual
para o botão através do atributo alt, conforme o exemplo a seguir.

Exemplo 1

Figura 19 – Imagem deBotão enviar

Código:
<input type="image" name="enviar" src="enviar.jpg" alt="enviar" />

Já para outros tipos de botões (reset e button), é preciso substituir o botão pela
imagem que se deseja utilizar através do CSS. Nesse caso, para que o botão seja
acessível, ele deve possuir um value descritivo, conforme o exemplo a seguir.

Exemplo 2

Figura 20 – Imagem de Botão Limpar

HTML

<input type="reset" name="limpar" value="Limpar" class="btLimpar" />

CSS

input.btLimpar{

background:transparent url(btLimpar.jpg) no-repeat left top;


width:100px;
height:47px;
text-indent:-20000px;
border:0;
}

Modelo de Acessibilidade em Governo Eletrônico e-MAG 50


RECOMENDAÇÃO 39 – ASSOCIAR ETIQUETAS AOS SEUS CAMPOS

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnica H44)

As etiquetas de texto (label) devem estar associadas aos seus campos (input)
correspondentes no formulário, através dos atributos for do label e id do input, os
quais deverão ter o mesmo valor.

Exemplo

<label for="nome">Nome: </label>


<input type="text" name="nome" id="nome" />

<label>Sexo:</label>
<input type="radio" id="fem" name="sexo" />
<label for="fem">Feminino</label>
<input type="radio" id="mas" name="sexo" />
<label for="mas">Masculino</label>

<label for="msg">Mensagem: </label>


<textarea name="msg" id="msg">Digite sua mensagem</textarea>

<input type="checkbox" id="receber" name="receber" />


<label for="receber">Deseja receber nossa newsletter?</label>

RECOMENDAÇÃO 40 – ESTABELECER UMA ORDEM LÓGICA DE NAVEGAÇÃO

Ver WCAG 2.0 Critério de Sucesso 2.4.3

Os elementos do formulário devem ser distribuídos corretamente através do código


HTML, criando, assim, uma sequência lógica de navegação. Assim, os formulários
devem primeiro ser codificados considerando a ordem lógica de navegação para
depois serem organizados visualmente via CSS.

OBS: O atributo tabindex somente deverá ser utilizado quando existir real
necessidade. É importante ressaltar que este atributo deverá ser utilizado com a
semântica correta e deverá ser verificado manualmente se o fluxo fornecido pelo
tabindex é realmente o desejado.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 51


RECOMENDAÇÃO 41 – NÃO PROVOCAR AUTOMATICAMENTE ALTERAÇÃO NO CONTEXTO

Ver WCAG 2.0 Critério de Sucesso 3.2.2

Quando um elemento de formulário receber o foco, não deve ser iniciada uma
mudança automática na página que confunda ou desoriente o usuário. Assim, as
mudanças devem ocorrer através do acionamento de um botão.

Exemplo Correto

<select id="cidade" name="cidade">


<option value="POA">Porto Alegre</option>
<option value="BH">Belo Horizonte</option>
<option value="RJ">Rio de Janeiro</option>
<option value="SP">São Paulo</option>
</select>
<input type="submit" id="submit" value="Enviar" />

Figura 21 – Acionamento - forma correta

Exemplo Incorreto

<select name="cidade" id="cidade" onchange="location =


this.options[this.selectedIndex].value;">
<option value="POA">Porto Alegre</option>
<option value="BH">Belo Horizonte</option>
<option value="RJ">Rio de Janeiro</option>
<option value="SP">São Paulo</option>
</select>

Figura 22 – Acionamento - forma incorreta

Modelo de Acessibilidade em Governo Eletrônico e-MAG 52


RECOMENDAÇÃO 42 – FORNECER INSTRUÇÕES PARA ENTRADA DE DADOS

Ver WCAG 2.0 Critério de Sucesso 3.3.2

Para conteúdo que exigir entrada de dados por parte do usuário, devem ser fornecidas
, quando necessário, instruções de preenchimento juntamente com as etiquetas
(label). A utilização de caracteres pré-definidos em áreas de entrada de texto só deve
ocorrer se:

• O texto for incluído após a entrada de dados pelo usuário (por exemplo, sugerir
um novo nome de usuário caso o escolhido já exista);

• A semântica do documento justifique a inclusão de texto pré-definido (por


exemplo, uma loja virtual que só vende para determinado país já vem com o
campo país preenchido);

• Os caracteres tenham sido fornecidos previamente pelo usuário (por exemplo,


refinamento de busca).

Exemplo

O seguinte exemplo indica que a data precisa ser inserida no formato dia (dd) –mês
(mm) –ano (aaaa).

<label for="data">Data (dd-mm-aaaa)</label>

<input type="text" id="data" name="data" />

RECOMENDAÇÃO 43 – IDENTIFICAR E DESCREVER ERROS DE ENTRADA DE DADOS

Ver WCAG 2.0 Critério de Sucesso 3.3.1

Quando um erro de entrada de dados for automaticamente detectado, o item que


apresenta erro deve ser identificado e descrito ao usuário por texto.

Exemplo 1
Um usuário tenta submeter um formulário, mas esquece de preencher campos
obrigatórios. Utilizando validação client-side (do lado do cliente), a omissão é
detectada e um alerta aparece informando ao usuário que campos obrigatórios não
foram preenchidos. Para a identificação destes campos, as etiquetas são modificas
tornando-se avisos e também o foco do teclado é remetido para o primeiro campo
sem preenchimento.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 53


Figura 23 – Alerta sobre o não preenchimento de campos obrigatórios

Figura 24 – Indicação do erro no formulário após a mensagem de alerta

Modelo de Acessibilidade em Governo Eletrônico e-MAG 54


Exemplo 2

Quando o usuário enviar o formulário e esquecer-se de preencher um campo


obrigatório ou preencher um campo de maneira incorreta, o foco é remetido
novamente ao formulário, mas que estará contendo apenas os campos com erro, para
que o usuário não precise navegar por todos os outros campos novamente. Abaixo dos
campos com erro que deverão ser novamente preenchidos, haverá o botão de envio e
um botão para o usuário retornar ao formulário completo, caso ele deseje verificar
todos os campos.

Exemplo 3

O usuário envia o formulário e deixa de preencher campos obrigatórios ou preenche


algum campo de maneira incorreta. O foco retorna ao início do formulário contendo o
aviso de erro e links (âncoras) para os campos do formulário que apresentaram erro.

RECOMENDAÇÃO 44 – AGRUPAR CAMPOS DE FORMULÁRIO

Ver WCAG 2.0 Critério de Sucesso 1.3.1 (Técnicas H71 e H85)

Deverão ser agrupados os controles de formulário relacionados de maneira lógica,


utilizando-se o elemento fieldset, associando o elemento legend de forma significativa
(o elemento fieldset é útil para agrupar, de forma lógica, elementos do formulário).
Para cada fieldset, é possível fornecer uma legenda que explica claramente o
propósito ou natureza dos agrupamentos.

Exemplo

<form method="post" action="...">


<fieldset>
<legend>Dados Pessoais</legend>
<label for="nome">O seu Nome: </label>
<input type="text" name="nome" id="nome" />
...
</fieldset>
<fieldset>
<legend>Dados Profissionais</legend>
<label for="profissao">Sua profição:</label>
<input type="text" id="profissao" name="profissao" />
...
</fieldset>
<fieldset>
<legend>Informações de Contato</legend>
<label for="email">E-mail: </label>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 55


<input type="text" id="email" name="email" />
...
</fieldset>
</form>

Figura 25 – Imagem do Formulário

Para agrupar elementos option dentro de um elemento de lista select, deve ser
utilizado o elemento optgroup.

Exemplo 2

<label for="instituto">Qual a sua instituição?</label>

<select id="instituto" name="instituto">

<optgroup label="Rio Grande do Sul">


<option value="ifrs">IFRS</option>
<option value="ifsul">IFSUL</option>
<option value="iffarroupilha">IFFarroupilha</option>
</optgroup>

<optgroup label="Santa Catarina">


<option value="ifsc">IFSC</option>
<option value="ifc">IFC</option>
</optgroup>

<optgroup label="Paraná">
<option value="ifpr">IFPR</option>
</optgroup>

</select>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 56


Figura 26 – Imagem da caixa de seleção

RECOMENDAÇÃO 45 – FORNECER CAPTCHA HUMANO

Ver WCAG 2.0 Critério de Sucesso 1.1.1 (Técnicas G143 e G144)

O CAPTCHA (teste interativo humano, completamente automatizado, para distinguir


computadores de seres humanos), quando utilizado, deverá ser fornecido em forma
de pergunta de interpretação. Tais perguntas poderão ser respondidas apenas por um
ser humano. No entanto, é preciso garantir que a pergunta não seja de difícil
resolução, permitindo que a mesma possa ser respondida por pessoas de variadas
culturas e níveis de instrução. Para tal, podem ser utilizadas perguntas de senso
comum, como por exemplo, “qual é a cor do céu?” ou “o fogo é quente ou frio?”.
Também podem ser utilizados testes matemáticos. No entanto, é preciso tomar
cuidado para que esses testes não sejam facilmente “quebrados” por determinados
programas. Uma alternativa é solicitar que o usuário escreva o resultado do teste
matemático por extenso, como “escreva por extenso quanto é 2 + 3”, ou ainda
“responda por extenso quanto é dois mais três”.

OBS: O CAPTCHA deverá ser utilizado apenas quando estritamente necessário.

Exemplo

<form action="action.php" method="post">

<fieldset>
<legend>CAPTCHA</legend>

<label for="pergunta">Escreva por extenso quanto é dois mais três.</label>


<input type="text" id="pergunta" name="pergunta" />

<input type="submit" name="enviar" value="Enviar!" />


</fieldset>

</form>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 57


Figura 27 – Exemplo de CAPTCHA

Para mais detalhes sobre o desenvolvimento de formulários acessíveis, veja o tutorial


Formulários Acessíveis (arquivo pdf – 160 KB) na seção e-MAG no Portal do Programa
de Governo Eletrônico.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 58


3. Padrões de acessibilidade digital no Governo
Federal

Esta seção pretende padronizar elementos de acessibilidade que devem ter


características em comum em todas as páginas do governo federal, para fins de
facilitar o acesso por pessoas com deficiência. Este conjunto de elementos busca
garantir o desenvolvimento de sítios acessíveis a todas as pessoas.

Os elementos a serem padronizados, que devem estar presentes em todas as páginas


do Governo Federal são:

1. Página com a descrição dos recursos de acessibilidade

2. Teclas de atalho

3. Barra de acessibilidade

4. Apresentação do mapa do sitio

5. Apresentação de formulário

6. Conteúdo alternativo para imagens

7. Apresentação de documentos

Ao final deste capítulo também serão apresentados elementos que não serão
permitidos nas páginas do governo federal.

3.1 Página de descrição com os recursos de acessibilidade

Esta página apresenta os recursos de acessibilidade presentes no sítio, como as teclas


de atalho disponíveis, as opções de redimensionamento de texto e alto contraste,
detalhes sobre testes de acessibilidade realizados no sítio e outras informações
pertinentes a respeito de sua acessibilidade. O link para a página contendo os recursos
de acessibilidade deve ser disponibilizado na barra de acessibilidade, a qual será
abordada no terceiro item desta seção.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 59


Figura 28 – Exemplo de página sobre acessibilidade do sítio

3.2 Atalhos de teclado

Deverão ser disponibilizados atalhos por teclado para pontos estratégicos da página,
permitindo que o usuário possa ir diretamente a esses pontos. Os atalhos deverão
funcionar através de números precedidos da tecla padrão de cada navegador (Alt no
Internet Explorer, Shift + Alt no Firefox, Shift + Esc no Opera, etc.). Os atalhos que
deverão existir nas páginas do Governo Federal são os seguintes:

• 1: para ir ao conteúdo;

• 2: para ir ao menu principal;

• 3: para ir à caixa de pesquisa;

Modelo de Acessibilidade em Governo Eletrônico e-MAG 60


As dicas dos atalhos deverão ser disponibilizadas na barra de acessibilidade, abordada
a seguir e, também, na página sobre a acessibilidade do sítio, já comentada
anteriormente. Para mais detalhes ver Recomendação 6.

3.3 Barra de acessibilidade

O sítio deverá conter uma barra de acessibilidade no topo de cada página contendo os
seguintes itens:

• Aumentar fonte
• Diminuir fonte
• Fonte normal
• Alto contraste
• Atalhos (para Menu, Conteúdo e Busca)
• Acessibilidade (link para a página contendo os recursos de acessibilidade do
sítio)

Exemplo de Barra de Acessibilidade

<div id="acessibilidade">
<ul id="atalhos">
<li><a href="#iniciodoconteudo">Ir para Conteúdo [1]</a></li>
<li><a href="#iniciodomenu">Ir para Menu [2]</a></li>
<li><a href="#busca">Ir para busca [3]</a></li>
</ul>
<ul id="botoes">
<li><a href="#" id="btnAumentarFonte">aumentar letra</a></li>
<li><a href="#" id="btnDiminuirFonte">diminuir letra</a></li>
<li><a href="#" id="btnTamanhoFonte">tamanho normal</a></li>
<li><a href="#" id="bt_contraste">alto contraste</a></li>
<li><a href="acessibilidade.html"> Página de acessibilidade </a></li>
</ul>
</div>

Figura 29 – Exemplo de página sobre acessibilidade do sítio

Quando uma das ferramentas aumentar fonte, diminuir fonte e fonte normal for
utilizada, o bloco como um todo deve ser modificado, não apenas a fonte do texto.

A opção alto contraste deve gerar uma página em que a relação de contraste entre o
plano de fundo e os elementos do primeiro plano seja de, no mínimo 7:1 (contraste

Modelo de Acessibilidade em Governo Eletrônico e-MAG 61


otimizado). As ferramentas utilizadas para verificar a relação de contraste entre as
cores estão listadas no capítulo 4 – Recursos e Ferramentas para Acessibilidade.

Figura 30 – Exemplo de página com alto contraste

Para mais detalhes ver Recomendações 28 e 30.

3.4 Apresentação do mapa do sítio

Deverá ser fornecido um mapa do sítio para sítios que contenham páginas internas
que não estão presentes no menu. O mapa do sítio deve ser disponibilizado em forma
de lista, podendo conter quantos níveis forem necessários.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 62


Figura 31 –Exemplo de mapa do sítio

3.5 Apresentação de formulário

Os formulários deverão estar de acordo com os seguintes itens:

• Sempre utilizar a tag form, mesmo que o formulário possua apenas um


elemento, como é o caso de uma caixa para pesquisa.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 63


• Disponibilizar os elementos do formulário no HTML na ordem correta de
navegação, sem utilizar o tabindex.

• Associar as etiquetas (label) aos seus campos (input) correspondentes.

• Não deve ocorrer mudança no contexto quando um elemento receber o foco.

• Deve ser fornecido um botão de envio (submit) para enviar os dados. No


entanto, é necessário fornecer uma maneira de o usuário poder verificar as
informações antes que elas sejam enviadas.

• Os erros de entrada de dados devem ser identificados e descritos ao usuário.

• Para cada conjunto de informações, com dois ou mais elementos de entrada de


dados, os mesmo deverão ser agrupados através do elemento fieldset/legend.
Em um formulário de busca simples, por exemplo, não há a necessidade de
utilizar o elemento fieldset/legend, pois apresenta apenas um campo de
entrada de dados.

Exemplo de formulário de Fale Conosco


<form method="post" action="act/contato.php">
<fieldset>
<legend>Formulário de Contato</legend>
<label for="nome">Nome:</label>
<input type="text" name="nome" id="nome" />
<label for="nome">E-mail:</label >
<input type="text" name="email" id="email" />
<label for="assunto">Assunto:</label>
<select name="assunto" id="assunto">

<option value="0" selected="selected">Selecione o assunto desejado</option>


<option value="informacoes">Informações</option>
<option value="sugestoes">Sugestões</option>
<option value="duvidas">Dúvidas</option>
</select>

<label for="msg">Mensagem:</label>
<textarea name="msg" id="msg"></textarea>

<input type="submit" name="enviar" id="enviar" value="Enviar" class="bnt" />

</fieldset>
</form>

Modelo de Acessibilidade em Governo Eletrônico e-MAG 64


Figura 32 –Formulário de contato

Após clicar no botão enviar, uma tela de confirmação deverá aparecer, conforme no
exemplo a seguir, permitindo que o usuário verifique e, se necessário, edite as
informações antes de enviá-las.

Figura 33 –Página de Confirmação

Modelo de Acessibilidade em Governo Eletrônico e-MAG 65


Para mais detalhes ver recomendações 38 a 45.

3.6 Conteúdo alternativo para imagens

Deverá ser fornecida uma alternativa textual, pelo atributo alt, para imagens, fotos,
gráficos, banners, botões de imagem, áreas ativas de mapa de imagem, CAPTCHA,
etc. Além do alt, para imagens mais complexas, que necessitem de uma descrição
mais detalhada, deverá ser fornecida uma descrição longa no próprio contexto ou em
um link (claramente identificado como descrição da imagem) logo após a imagem.
Para mais detalhes ver recomendações 20 e 21.

3.7 Apresentação de documentos

Os documentos em texto deverão ser disponibilizados preferencialmente em HTML.


Também podem ser disponibilizados arquivos para download no formato ODF,
tomando-se os cuidados para que sejam acessíveis. Se houver necessidade de
disponibilizar arquivos em PDF, deverá ser fornecida uma alternativa em HTML ou
ODF. É necessário, também, informar a extensão e o tamanho do arquivo no próprio
texto do link.

Para mais detalhes ver Recomendação 22.

3.8 Elementos que não devem ser utilizados

• Tabelas para fins de diagramação, conforme Recomendação 7;

• Atualizações automáticas periódicas, conforme Recomendação 11;

• Situações com intermitência de tela, conforme Recomendação 14;

• Elementos considerados depreciados pelo W3C, como frame, applet, blink,


marquee, basefont, center, dir, align, font, isindex, menu, strike, u, etc.

Modelo de Acessibilidade em Governo Eletrônico e-MAG 66


DECRETO Nº 7.579, DE 11 DE OUTUBRO DE 2011
Dispõe sobre o Sistema de Administração dos
Recursos de Tecnologia da Informação - SISP,
do Poder Executivo federal.

A PRESIDENTA DA REPÚBLICA, no uso das atribuições que lhe confere o art. 84, incisos
o
IV e VI, alínea “a”, da Constituição, e tendo em vista o disposto nos arts. 30 e 31 do Decreto-Lei n
o
200, de 25 de fevereiro de 1967, e no art. 27, inciso XVII, da Lei n 10.683, de 28 de maio de 2003,

DECRETA:

o
Art. 1 Ficam organizados sob a forma de sistema, com a denominação de Sistema de
Administração dos Recursos de Tecnologia da Informação - SISP, o planejamento, a
coordenação, a organização, a operação, o controle e a supervisão dos recursos de tecnologia
da informação dos órgãos e entidades da administração pública federal direta, autárquica e
fundacional, em articulação com os demais sistemas utilizados direta ou indiretamente na
gestão da informação pública federal.

Parágrafo único. É facultada às empresas públicas e às sociedades de economia mista


a participação no SISP, cujas condições devem constar de termo próprio a ser firmado entre os
dirigentes das entidades e o titular do Órgão Central do SISP.

o
Art. 2 O SISP tem por finalidade:

I - assegurar ao Governo federal suporte de informação adequado, dinâmico, confiável e


eficaz;

II - facilitar aos interessados a obtenção das informações disponíveis, resguardados os


aspectos de disponibilidade, integridade, confidencialidade e autenticidade, bem como
restrições administrativas e limitações legais;

III - promover a integração e a articulação entre programas de governo, projetos e


atividades, visando à definição de políticas, diretrizes e normas relativas à gestão dos recursos
de tecnologia da informação;

IV - estimular o uso racional dos recursos de tecnologia da informação, no âmbito do


Poder Executivo federal, visando à melhoria da qualidade e da produtividade do ciclo da
informação;

V - estimular o desenvolvimento, a padronização, a integração, a interoperabilidade, a


normalização dos serviços de produção e disseminação de informações, de forma
desconcentrada e descentralizada;

VI - propor adaptações institucionais necessárias ao aperfeiçoamento dos mecanismos


de gestão dos recursos de tecnologia da informação;

VII - estimular e promover a formação, o desenvolvimento e o treinamento dos


servidores que atuam na área de tecnologia da informação; e

VIII - definir a política estratégica de gestão de tecnologia da informação do Poder


Executivo federal.

o
§ 1 Consideram-se recursos de tecnologia da informação o conjunto formado pelos
bens e serviços de tecnologia da informação que constituem a infraestrutura tecnológica de
suporte automatizado ao ciclo da informação, que envolve as atividades de produção, coleta,
tratamento, armazenamento, transmissão, recepção, comunicação e disseminação.
o
§ 2 As questões relativas à gestão de segurança da informação são disciplinadas
o
conforme as disposições do Decreto n 3.505, de 13 de junho de 2000.

o
Art. 3 Integram o SISP:

I - como Órgão Central, a Secretaria de Logística e Tecnologia da Informação do


Ministério do Planejamento, Orçamento e Gestão;

II - como Órgãos Setoriais, representadas por seus titulares, as unidades de


administração dos recursos de tecnologia da informação dos Ministérios e dos órgãos da
Presidência da República;

III - a Comissão de Coordenação, formada pelos representantes dos Órgãos Setoriais,


presidida por representante do Órgão Central;

IV - como Órgãos Seccionais, representadas por seus titulares, as unidades de


administração dos recursos de tecnologia da informação das autarquias e fundações; e

V - como Órgãos Correlatos, representados pelos seus titulares, as unidades


desconcentradas e formalmente constituídas de administração dos recursos de tecnologia da
informação nos Órgãos Setoriais e Seccionais.

Parágrafo único. Poderão colaborar com o SISP, mediante acordos específicos com o
Órgão Central, outras entidades do Poder Público e entidades da iniciativa privada
interessadas no desenvolvimento de projetos de interesse comum.

o
Art. 4 Compete ao Órgão Central do SISP:

I - orientar e administrar os processos de planejamento estratégico, de coordenação


geral e de normalização relativos aos recursos de tecnologia da informação abrangidos pelo
SISP;

II - definir, elaborar, divulgar e implementar, com apoio da Comissão de Coordenação, as


políticas, diretrizes e normas gerais relativas à gestão dos recursos do SISP e ao processo de
compras do Governo na área de tecnologia da informação;

III - promover a elaboração de planos de formação, desenvolvimento e treinamento do


pessoal envolvido na área de abrangência do SISP;

IV - incentivar ações prospectivas, visando acompanhar as inovações técnicas da área


de tecnologia da informação, de forma a atender às necessidades de modernização dos
serviços dos órgãos e entidades abrangidos pelo SISP; e

V - promover a disseminação das políticas, diretrizes, normas e informações disponíveis, de


interesse comum, entre os órgãos e entidades abrangidos pelo SISP.

o
Art. 5 Compete à Comissão de Coordenação do SISP:

I - participar da elaboração e implementação das políticas, diretrizes e normas gerais relativas à


gestão dos recursos do SISP e ao processo de compras do Governo na área de tecnologia da
informação;

II - assessorar o Órgão Central do SISP no cumprimento de suas atribuições;

III - promover o intercâmbio de conhecimento entre seus participantes e homogeneizar o


entendimento das políticas, diretrizes e normas gerais relativas ao SISP; e
IV - acompanhar e avaliar os resultados da regulamentação emanada do Órgão Central
do SISP, e propor ajustamentos.

o
Art. 6 Compete aos Órgãos Setoriais do SISP:

I - coordenar, planejar, articular e controlar as ações relativas aos recursos de tecnologia


da informação, no âmbito dos respectivos Ministérios ou órgãos da Presidência da República;

II - fornecer subsídios ao Órgão Central do SISP, por intermédio da Comissão de


Coordenação, para a definição e elaboração de políticas, diretrizes e normas gerais relativas
ao SISP;

III - cumprir e fazer cumprir, por meio de políticas, diretrizes, normas e projetos setoriais,
as políticas, diretrizes e normas gerais emanadas do Órgão Central do SISP; e

IV - participar, como membro da Comissão de Coordenação, dos encontros de trabalho


programados para tratar de assuntos relacionados ao SISP.

o
Art. 7 Compete aos Órgãos Seccionais do SISP:

I - cumprir e fazer cumprir, por meio de políticas, diretrizes, normas e projetos seccionais,
as políticas, diretrizes e normas emanadas do Órgão Setorial do SISP a que estão vinculados;

II - subsidiar o Órgão Setorial do SISP a que estão vinculados na elaboração de


políticas, diretrizes, normas e projetos setoriais; e

III - participar dos encontros de trabalho programados para tratar de assuntos


relacionados ao SISP.

o
Art. 8 Compete aos Órgãos Correlatos do SISP:

I - subsidiar a unidade de tecnologia da informação de seu respectivo Órgão Setorial ou


Seccional no cumprimento das políticas, diretrizes e normas gerais relativas ao SISP;

II - subsidiar a unidade de tecnologia da informação de seu respectivo Órgão Setorial ou


Seccional na elaboração de políticas, diretrizes, normas e projetos setoriais ou seccionais; e

III - participar dos encontros de trabalho programados para tratar de assuntos


relacionados ao SISP.

o
Art. 9 A Secretaria de Logística e Tecnologia da Informação do Ministério do
Planejamento, Orçamento e Gestão expedirá as normas necessárias à implantação e ao
funcionamento do SISP.

Art. 10. Este Decreto entra em vigor na data de sua publicação.

o
Art. 11. Fica revogado o Decreto n 1.048, de 21 de janeiro de 1994.

o o
Brasília, 11 de outubro de 2011; 190 da Independência e 123 da República.

DILMA ROUSSEFF
Miriam Belchior

Este texto não substitui o publicado no DOU de 13.10.2011


INSTRUÇÃO NORMATIVA Nº 04 de 12 de novembro de 2010.

Dispõe sobre o processo de contratação de Soluções de


Tecnologia da Informação pelos órgãos integrantes do
Sistema de Administração dos Recursos de Informação
e Informática (SISP) do Poder Executivo Federal.

A SECRETÁRIA DE LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO, no uso de


suas atribuições que lhe confere o Decreto nº 7.063, de 13 de janeiro de 2010, e tendo em vista o
disposto na Lei nº 8.666, de 21 de junho de 1993, na Lei nº 10.520, de 17 de junho de 2002, no Decreto
nº 1.048, de 21 de janeiro de 1994, no Decreto nº 2.271, de 7 de julho de 1997, no Decreto nº 3.555, de 8
de agosto de 2000, no Decreto nº 3.931, de 19 de setembro de 2001, no Decreto nº 5.450, de 31 de maio
de 2005, e no Decreto nº 7.174, de 12 de maio de 2010, resolve:

Art. 1º As contratações de Soluções de Tecnologia da Informação pelos órgãos e entida-


des integrantes do Sistema de Administração dos Recursos de Informação e Informática - SISP serão dis-
ciplinadas por esta Instrução Normativa.
Art. 1º As contratações de Soluções de Tecnologia da Informação pelos órgãos e entida-
des integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação - SISP serão dis-
ciplinadas por esta Instrução Normativa. (Redação dada pela Instrução Normativa Nº 2, de 14 de fevereiro de 2012)

Parágrafo único. O disposto nesta Instrução Normativa não se aplica:

I - às contratações em que a contratada for órgão ou entidade, nos termos do art. 24, inciso
VIII da Lei nº 8.666, de 1993, ou Empresa Pública, nos termos do art. 2º da Lei nº 5.615, de 13 de
outubro de 1970, modificado pela Lei nº 12.249, de 11 de junho de 2010; e

II - às contratações cuja estimativa de preços seja inferior ao disposto no art. 23, inciso II,
alínea "a" da Lei nº 8.666, de 1993.

Capítulo I

DAS DISPOSIÇÕES GERAIS

Art. 2º Para fins desta Instrução Normativa, considera-se:

I - Área Requisitante da Solução: unidade do órgão ou entidade que demande a


contratação de uma Solução de Tecnologia da Informação;

II - Área de Tecnologia da Informação: unidade setorial ou seccional do SISP, bem como


área correlata, responsável por gerir a Tecnologia da Informação do órgão ou entidade;
III - Equipe de Planejamento da Contratação: equipe envolvida no planejamento da
contratação, composta por:

a) Integrante Técnico: servidor representante da Área de Tecnologia da Informação,


indicado pela autoridade competente dessa área;

b) Integrante Administrativo: servidor representante da Área Administrativa, indicado pela


autoridade competente dessa área;

c) Integrante Requisitante: servidor representante da Área Requisitante da Solução,


indicado pela autoridade competente dessa área;

IV - Gestor do Contrato: servidor com atribuições gerenciais, técnicas e operacionais


relacionadas ao processo de gestão do contrato, indicado por autoridade competente;

V - Fiscal Técnico do Contrato: servidor representante da Área de Tecnologia da


Informação, indicado pela autoridade competente dessa área para fiscalizar tecnicamente o contrato;

VI - Fiscal Administrativo do Contrato: servidor representante da Área Administrativa,


indicado pela autoridade competente dessa área para fiscalizar o contrato quanto aos aspectos
administrativos;

VII - Fiscal Requisitante do Contrato: servidor representante da Área Requisitante da


Solução, indicado pela autoridade competente dessa área para fiscalizar o contrato do ponto de vista
funcional da Solução de Tecnologia da Informação;

VIII - Preposto: funcionário representante da contratada, responsável por acompanhar a


execução do contrato e atuar como interlocutor principal junto à contratante, incumbido de receber,
diligenciar, encaminhar e responder as principais questões técnicas, legais e administrativas referentes ao
andamento contratual;

IX - Solução de Tecnologia da Informação: conjunto de bens e serviços de Tecnologia da


Informação e automação que se integram para o alcance dos resultados pretendidos com a contratação;

X - Requisitos: conjunto de especificações necessárias para definir a Solução de


Tecnologia da Informação a ser contratada;

XI - Documento de Oficialização da Demanda: documento que contém o detalhamento da


necessidade da Área Requisitante da Solução a ser atendida pela contratação;

XII - Análise de Viabilidade da Contratação: documento que demonstra a viabilidade


técnica e econômica da contratação;

XIII - Plano de Sustentação: documento que contém as informações necessárias para


garantir a continuidade do negócio durante e após a implantação da Solução de Tecnologia da
Informação, bem como após o encerramento do contrato;

XIV - Estratégia da Contratação: documento contendo a definição de critérios técnicos,


obrigações contratuais, responsabilidades e definições de como os recursos humanos e financeiros serão
alocados para atingir o objetivo da contratação;

XV - Análise de Riscos: documento que contém a descrição, a análise e o tratamento dos


riscos e ameaças que possam vir a comprometer o sucesso em todas as fases da contratação;

XVI - Plano de Inserção: documento que prevê as atividades de alocação de recursos


necessários para a contratada iniciar o fornecimento da Solução de Tecnologia da Informação;

XVII - Ordem de Serviço ou de Fornecimento de Bens: documento utilizado para solicitar


à contratada a prestação de serviço ou fornecimento de bens relativos ao objeto do contrato;

XVIII - Termo de Recebimento Provisório: declaração formal de que os serviços foram


prestados ou os bens foram entregues, para posterior análise das conformidades de qualidade baseadas
nos Critérios de Aceitação;

XIX - Termo de Recebimento Definitivo: declaração formal de que os serviços prestados


ou bens fornecidos atendem aos requisitos estabelecidos no contrato;

XX - Critérios de Aceitação: parâmetros objetivos e mensuráveis utilizados para verificar


se um bem ou serviço recebido está em conformidade com os requisitos especificados;

XXI - Gestão: conjunto de atividades superiores de planejamento, coordenação,


supervisão e controle, relativas às Soluções de Tecnologia da Informação que visam garantir o
atendimento dos objetivos do órgão ou entidade; e

XXII - Plano Diretor de Tecnologia da Informação - PDTI: instrumento de diagnóstico,


planejamento e gestão dos recursos e processos de Tecnologia da Informação que visa atender às
necessidades tecnológicas e de informação de um órgão ou entidade para um determinado período.

Art. 3º Em consonância com o art. 4º do Decreto nº 1.048, de 1994, o órgão central do


SISP elaborará, em conjunto com os órgãos setoriais e seccionais do SISP, a Estratégia Geral de
Tecnologia da Informação - EGTI para a Administração direta, autárquica e fundacional do Poder
Executivo Federal, revisada e publicada anualmente, para servir de subsídio à elaboração dos PDTI
pelos órgãos e entidades integrantes do SISP.
Art. 3º Em consonância com o art. 4º do Decreto nº 7.579, de 2011, o órgão central do
SISP elaborará, em conjunto com os órgãos setoriais e seccionais do SISP, a Estratégia Geral de
Tecnologia da Informação - EGTI para a Administração direta, autárquica e fundacional do Poder
Executivo Federal, revisada e publicada anualmente, para servir de subsídio à elaboração dos PDTI
pelos órgãos e entidades integrantes do SISP. (Redação dada pela Instrução Normativa Nº 2, de 14 de fevereiro de 2012)

Art. 4º As contratações de que trata esta Instrução Normativa deverão ser precedidas de
planejamento, elaborado em harmonia com o PDTI, alinhado ao planejamento estratégico do órgão ou
entidade.

Parágrafo único. Inexistindo o planejamento estratégico formalmente documentado, será


utilizado o documento existente no órgão ou entidade, a exemplo do Plano Plurianual ou instrumento
equivalente, registrando no PDTI a ausência do planejamento estratégico do órgão ou entidade e
indicando os documentos utilizados.

Art. 5º Não poderão ser objeto de contratação:


I - mais de uma Solução de Tecnologia da Informação em um único contrato; e

II - gestão de processos de Tecnologia da Informação, incluindo gestão de segurança da


informação.

Parágrafo único. O suporte técnico aos processos de planejamento e avaliação da


qualidade das Soluções de Tecnologia da Informação poderá ser objeto de contratação, desde que sob
supervisão exclusiva de servidores do órgão ou entidade.

Art. 6º Nos casos em que a avaliação, mensuração ou fiscalização da Solução de


Tecnologia da Informação seja objeto de contratação, a contratada que provê a Solução de Tecnologia da
Informação não poderá ser a mesma que a avalia, mensura ou fiscaliza.

Art. 7º É vedado:

I - estabelecer vínculo de subordinação com funcionários da contratada;

II - prever em edital a remuneração dos funcionários da contratada;

III - indicar pessoas para compor o quadro funcional da contratada;

IV - demandar ao preposto que os funcionários da contratada executem tarefas fora do


escopo do objeto da contratação;

V - reembolsar despesas com transporte, hospedagem e outros custos operacionais, que


devem ser de exclusiva responsabilidade da contratada;

VI - prever em edital exigências que constituam intervenção indevida da Administração na


gestão interna dos fornecedores; e

VII - prever em edital exigência que os fornecedores apresentem, em seus quadros,


funcionários capacitados ou certificados para o fornecimento da Solução, antes da contratação.

Capítulo II

DO PROCESSO DE CONTRATAÇÃO

Art. 8º As contratações de Soluções de Tecnologia da Informação deverão seguir três


fases:

I - Planejamento da Contratação;

II - Seleção do Fornecedor; e

III - Gerenciamento do Contrato.

Seção I
Planejamento da Contratação

Art. 9º A fase de Planejamento da Contratação terá início com o recebimento pela Área de
Tecnologia da Informação do Documento de Oficialização da Demanda, a cargo da Área Requisitante da
Solução, que conterá no mínimo:

I - necessidade da contratação, considerando os objetivos estratégicos e as necessidades


corporativas da instituição, bem como o seu alinhamento ao PDTI;

II - explicitação da motivação e demonstrativo de resultados a serem alcançados com a


contratação da Solução de Tecnologia da Informação;

III - indicação da fonte dos recursos para a contratação; e

IV - indicação do Integrante Requisitante para composição da Equipe de Planejamento da


Contratação.

§ 1º Após o recebimento do Documento de Oficialização da Demanda, a Área de


Tecnologia da Informação indicará o Integrante Técnico para composição da Equipe de Planejamento da
Contratação.

§ 2º O Documento de Oficialização da Demanda será encaminhado à autoridade


competente da Área Administrativa, que deverá:

I - decidir motivadamente sobre o prosseguimento da contratação;

II - indicar o Integrante Administrativo para composição da Equipe de Planejamento da


Contratação, quando da continuidade da contratação; e

III - instituir a Equipe de Planejamento da Contratação, conforme exposto no art. 2º, inciso
III.

§ 3º A Equipe de Planejamento da Contratação deverá acompanhar e apoiar, no que for


determinado pelas áreas responsáveis, todas as atividades presentes nas fases de Planejamento da
Contratação e Seleção do Fornecedor.

Art. 10. A fase de Planejamento da Contratação consiste nas seguintes etapas:

I - Análise de Viabilidade da Contratação;

II - Plano de Sustentação;

III - Estratégia da Contratação;

IV - Análise de Riscos; e

V - Termo de Referência ou Projeto Básico.

Parágrafo único. Os documentos resultantes das etapas elencadas nos incisos I a IV


poderão ser consolidados em um único documento, a critério da Equipe de Planejamento da Contratação.
Art. 11. A Análise de Viabilidade da Contratação será realizada pelos Integrantes Técnico
e Requisitante, compreendendo as seguintes tarefas:

I - definição e especificação dos requisitos, conforme os arts. 12 e 13 desta Instrução


Normativa, a partir da avaliação do Documento de Oficialização da Demanda e do levantamento de:

a) demandas dos potenciais gestores e usuários da Solução de Tecnologia da Informação;

b) soluções disponíveis no mercado; e

c) análise de projetos similares realizados por outros órgãos ou entidades da


Administração Pública;

II - identificação das diferentes soluções que atendam aos requisitos, considerando:

a) a disponibilidade de solução similar em outro órgão ou entidade da Administração


Pública;

b) as soluções existentes no Portal do Software Público Brasileiro


(http://www.softwarepublico.gov.br);

c) a capacidade e alternativas do mercado, inclusive a existência de software livre ou


software público;

d) a observância às políticas, premissas e especificações técnicas definidas pelos Padrões


de Interoperabilidade de Governo Eletrônico - e-PING e Modelo de Acessibilidade em Governo
Eletrônico - e-MAG, conforme as Portarias Normativas SLTI nº 5, de 14 de julho de 2005, e nº 3, de 7
de maio de 2007;

e) a aderência às regulamentações da Infraestrutura de Chaves Públicas Brasileira - ICP-


Brasil, conforme a Medida Provisória nº 2.200-2, de 24 de agosto de 2001, quando houver necessidade
de utilização de certificação digital; e

f) a observância às orientações, premissas e especificações técnicas e funcionais definidas


pelo Modelo de Requisitos para Sistemas Informatizados de Gestão Arquivística de Documentos - e-
ARQ Brasil, quando o objetivo da solução abranger a gestão de documentos arquivísticos digitais e não
digitais, conforme Resolução do CONARQ nº 25, de 27 de abril de 2007;

g) o orçamento estimado;

III - análise e comparação entre os custos totais de propriedade das soluções identificadas,
levando-se em conta os valores de aquisição dos ativos, insumos, garantia e manutenção;

IV - escolha da Solução de Tecnologia da Informação e justificativa da solução escolhida,


que contemple, no mínimo:

a) descrição sucinta, precisa, suficiente e clara da Solução de Tecnologia da Informação


escolhida, indicando os bens e serviços que a compõem;
b) alinhamento em relação às necessidades de negócio e requisitos tecnológicos; e

c) identificação dos benefícios a serem alcançados com a solução escolhida em termos de


eficácia, eficiência, efetividade e economicidade;

V - avaliação das necessidades de adequação do ambiente do órgão ou entidade para


viabilizar a execução contratual, que servirá de subsídio para o Plano de Inserção, abrangendo no que
couber:

a) infraestrutura tecnológica;

b) infraestrutura elétrica;

c) logística;

d) espaço físico;

e) mobiliário; e

f) outras que se apliquem.

Parágrafo único. A Análise de Viabilidade da Contratação será aprovada e assinada pela


Equipe de Planejamento da Contratação.

Art. 12. Compete ao Integrante Requisitante definir, quando aplicáveis, os seguintes


requisitos,:

I - de negócio, que independem de características tecnológicas e que definem as


necessidades e os aspectos funcionais da Solução de Tecnologia da Informação;

II - de capacitação, que definem a necessidade de treinamento, de carga horária e de


materiais didáticos;

III - legais, que definem as normas com as quais a Solução de Tecnologia da Informação
deve estar em conformidade;

IV - de manutenção, que independem de configuração tecnológica e que definem a


necessidade de serviços de manutenção preventiva, corretiva, evolutiva e adaptativa;

V - temporais, que definem datas de entrega da Solução de Tecnologia da Informação


contratada;

VI - de segurança, juntamente com o Integrante Técnico; e

VII - sociais, ambientais e culturais, que definem requisitos que a Solução de Tecnologia
da Informação deve atender para estar em conformidade com costumes, idiomas e ao meio ambiente,
dentre outros.

Art. 13. Compete ao Integrante Técnico especificar, quando aplicáveis, os seguintes


requisitos tecnológicos:
I - de arquitetura tecnológica, composta de hardware, software, padrões de
interoperabilidade, linguagens de programação, interfaces, dentre outros;

II - de projeto e de implementação, que estabelecem o processo de desenvolvimento de


software, técnicas, métodos, forma de gestão, de documentação, dentre outros;

III - de implantação, que definem o processo de disponibilização da solução em ambiente


de produção, dentre outros;

IV - de garantia e manutenção, que definem a forma como será conduzida a manutenção e


a comunicação entre as partes envolvidas;

V - de capacitação, que definem o ambiente tecnológico dos treinamentos a serem


ministrados, os perfis dos instrutores, dentre outros;

VI - de experiência profissional da equipe que projetará, implementará e implantará a


Solução de Tecnologia da Informação, que definem a natureza da experiência profissional exigida e as
respectivas formas de comprovação dessa experiência, dentre outros;

VII - de formação da equipe que projetará, implementará e implantará a Solução de


Tecnologia da Informação, que definem cursos acadêmicos e técnicos, formas de comprovação dessa
formação, dentre outros;

VIII - de metodologia de trabalho;

IX - de segurança da informação; e

X - demais requisitos aplicáveis.

Parágrafo único. Os requisitos tecnológicos citados neste artigo deverão ser especificados
em conformidade àqueles definidos no art. 12.

Art. 14. O Plano de Sustentação será elaborado pelos Integrantes Técnico e Requisitante,
contendo no mínimo:

I - recursos materiais e humanos necessários à continuidade do negócio;

II - continuidade do fornecimento da Solução de Tecnologia da Informação em eventual


interrupção contratual;

III - atividades de transição contratual e encerramento do contrato, que incluem:

a) a entrega de versões finais dos produtos e da documentação;

b) a transferência final de conhecimentos sobre a execução e a manutenção da Solução de


Tecnologia da Informação;

c) a devolução de recursos;
d) a revogação de perfis de acesso;

e) a eliminação de caixas postais;

f) outras que se apliquem.

IV - estratégia de independência do órgão ou entidade contratante com relação à


contratada, que contemplará, pelo menos:

a) forma de transferência de conhecimento tecnológico; e

b) direitos de propriedade intelectual e direitos autorais da Solução de Tecnologia da


Informação sobre os diversos documentos e produtos produzidos ao longo do contrato, incluindo a
documentação, os modelos de dados e as bases de dados, justificando os casos em que tais direitos não
vierem a pertencer à Administração direta, autárquica e fundacional do Poder Executivo Federal.

Parágrafo único. O Plano de Sustentação será aprovado e assinado pela Equipe de


Planejamento da Contratação.

Art. 15. A Estratégia da Contratação será elaborada a partir da Análise de Viabilidade da


Contratação e do Plano de Sustentação, contendo no mínimo:

I - indicação, pelo Integrante Técnico, da Solução de Tecnologia da Informação a ser


contratada;

II - definição, pelo Integrante Técnico, das responsabilidades da contratada que não poderá
se eximir do cumprimento integral do contrato mesmo havendo subcontratação;

III - indicação, pela Equipe de Planejamento da Contratação, dos termos contratuais,


observado o disposto nos §§ 1º e 2º deste artigo, sem prejuízo do estabelecido na Lei nº 8.666, de 1993,
relativos a:

a) fixação de procedimentos e Critérios de Aceitação dos serviços prestados ou bens


fornecidos, abrangendo métricas, indicadores e valores mínimos aceitáveis;

b) quantificação ou estimativa prévia do volume de serviços demandados ou quantidade de


bens a serem fornecidos, para comparação e controle;

c) definição de metodologia de avaliação da qualidade e da adequação da Solução de


Tecnologia da Informação às especificações funcionais e tecnológicas;

d) garantia de inspeções e diligências, quando aplicáveis, e suas formas de exercício;

e) forma de pagamento, que será efetuado em função dos resultados obtidos;

f) cronograma de execução física e financeira;

g) definição de mecanismos formais de comunicação a serem utilizados para troca de


informações entre a contratada e a Administração; e
h) definição clara e detalhada das sanções administrativas, de acordo com os arts. 86, 87 e
88 da Lei nº 8.666, de 1993, juntamente com o art. 7º da Lei nº 10.520, de 2002, observando:

1. vinculação aos termos contratuais;

2. proporcionalidade das sanções previstas ao grau do prejuízo causado pelo


descumprimento das respectivas obrigações;

3. as situações em que advertências ou multas serão aplicadas, com seus percentuais


correspondentes, que obedecerão uma escala gradual para as sanções recorrentes;

4. as situações em que o contrato será rescindido por parte da Administração devido ao


não atendimento de termos contratuais, da recorrência de aplicação de multas ou outros motivos;

5. as situações em que a contratada terá suspensa a participação em licitações e


impedimento para contratar com a Administração; e

6. as situações em que a contratada será declarada inidônea para licitar ou contratar com a
Administração, conforme previsto em Lei;

IV - elaboração, pelos Integrantes Administrativo e Técnico, do orçamento detalhado em


preços unitários, fundamentado em pesquisa no mercado, a exemplo de contratações similares, valores
oficiais de referência, pesquisa junto a fornecedores ou tarifas públicas;

V - elaboração, pelo Integrante Requisitante, da estimativa do impacto econômico-


financeiro no orçamento do órgão ou entidade, com indicação das fontes de recurso;

VI - elaboração, pela Equipe de Planejamento da Contratação, dos seguintes modelos de


documentos:

a) termo de compromisso, contendo declaração de manutenção de sigilo e respeito as


normas de segurança vigentes no órgão ou entidade, a ser assinado pelo representante legal da
fornecedor; e

b) termo de ciência da declaração de manutenção de sigilo e das normas de segurança


vigentes no órgão ou entidade, a ser assinado por todos os empregados da contratada diretamente
envolvidos na contratação;

VII - definição, pelo Integrante Técnico, dos critérios técnicos de julgamento das
propostas para a fase de Seleção do Fornecedor, observando o seguinte:

a) a utilização de critérios correntes no mercado;

b) a Análise de Viabilidade da Contratação;

c) a possibilidade de considerar mais de um atestado relativo ao mesmo quesito de


capacidade técnica, quando necessário para a comprovação da aptidão;

d) a vedação da indicação de entidade certificadora, exceto nos casos previamente


dispostos em normas do governo federal;
e) a vedação de pontuação com base em atestados relativos à duração de trabalhos
realizados pelo licitante;

f) a vedação de pontuação progressiva de mais de um atestado para o mesmo quesito de


capacidade técnica; e

g) a justificativa dos critérios de pontuação em termos do benefício que trazem para a


contratante.

§ 1º Os documentos descritos no inciso VI do caput devem ser entregues pela contratada,


devidamente assinados, na reunião inicial descrita no art. 25, inciso I, alínea “b”.

§ 2º A aferição de esforço por meio da métrica homens-hora apenas poderá ser utilizada
mediante justificativa e sempre vinculada à entrega de produtos de acordo com prazos e qualidade
previamente definidos.

§ 3º É vedado contratar por postos de trabalho alocados, salvo os casos justificados


mediante a comprovação obrigatória de resultados compatíveis com o posto previamente definido.

§ 4º Nas licitações do tipo técnica e preço, é vedado:

I - incluir critérios de pontuação técnica que não estejam diretamente relacionados com os
requisitos da Solução de Tecnologia da Informação a ser contratada ou que frustrem o caráter
competitivo do certame; e

II - fixar os fatores de ponderação das propostas técnicas e de preço sem justificativa.

§ 5º Nas licitações do tipo técnica e preço, deve-se:

I - incluir, para cada atributo técnico da planilha de pontuação, sua contribuição percentual
com relação ao total da avaliação técnica; e

II - proceder a avaliação do impacto de pontuação atribuída em relação ao total de pontos,


observando se os critérios de maior peso são de fato os mais relevantes e se a ponderação atende ao
princípio da razoabilidade.

§ 6º A Estratégia da Contratação será aprovada e assinada pela Equipe de Planejamento


da Contratação.

Art. 16. A Análise de Riscos será elaborada pela Equipe de Planejamento da Contratação
contendo os seguintes itens:

I - identificação dos principais riscos que possam comprometer o sucesso dos processos de
contratação e de gestão contratual;

II - identificação dos principais riscos que possam fazer com que a Solução de Tecnologia
da Informação não alcance os resultados que atendam às necessidades da contratação;

III - mensuração das probabilidades de ocorrência e dos danos potenciais relacionados a


cada risco identificado;

IV - definição das ações previstas a serem tomadas para reduzir ou eliminar as chances de
ocorrência dos eventos relacionado a cada risco;

V - definição das ações de contingência a serem tomadas caso os eventos correspondentes


aos riscos se concretizem; e

VI - definição dos responsáveis pelas ações de prevenção dos riscos e dos procedimentos
de contingência.

§ 1º A análise de riscos permeia todas as etapas da fase de Planejamento da Contratação e


será consolidada no documento final Análise de Riscos.

§ 2º A Análise de Riscos será aprovada e assinada pela Equipe de Planejamento da


Contratação.

Art. 17. O Termo de Referência ou Projeto Básico será elaborado a partir da Análise de
Viabilidade da Contratação, do Plano de Sustentação, da Estratégia da Contratação e da Análise de
Riscos.

§ 1º O Termo de Referência ou Projeto Básico será elaborado pela Equipe de


Planejamento da Contratação e conterá, no mínimo, as seguintes informações:

I - definição do objeto, conforme art. 11, inciso IV, alínea “a”;

II - fundamentação da contratação, conforme art. 9º, incisos I e II e art. 11, inciso IV;

III - descrição da Solução de Tecnologia de Informação, conforme art. 15, inciso I;

IV - requisitos da solução, conforme art. 11, inciso I;

V - modelo de prestação de serviços ou de fornecimento de bens, conforme art. 13, inciso


VIII;

VI - elementos para gestão do contrato, conforme art. 15, inciso III, arts. 25 e 26;

VII - estimativa de preços, conforme art. 15, inciso IV;

VIII - adequação orçamentária, conforme art. 15, inciso V;

IX - definições dos critérios de sanções, conforme art. 15, inciso III, alínea “h”; e

X - critérios de seleção do fornecedor, conforme art. 15, inciso VII.

§ 2º A Equipe de Planejamento da Contratação avaliará a viabilidade de parcelamento da


Solução de Tecnologia da Informação a ser contratada, em tantos itens quanto sejam tecnicamente
possíveis e suficientes.

§ 3º A Equipe de Planejamento da Contratação avaliará, ainda, a necessidade de licitações


e contratações separadas para os itens que, devido a sua natureza, possam ser divididos em tantas
parcelas quantas se comprovarem técnica e economicamente viáveis, procedendo-se à licitação com
vistas ao melhor aproveitamento dos recursos disponíveis no mercado e à ampliação da competitividade
sem perda da economia de escala, conforme disposto no art. 23, § 1°. da Lei n° 8.666/93.

§ 4º O Termo de Referência ou Projeto Básico será assinado pela Equipe de Planejamento


da Contratação e aprovado pelas autoridades competentes.

Art. 18. É obrigatória a execução da fase de Planejamento da Contratação,


independentemente do tipo de contratação, inclusive nos casos de:

I - inexigibilidade;

II - dispensa de licitação ou licitação dispensada;

III - criação ou adesão à Ata de Registro de Preços; e

IV - contratações com uso de verbas de organismos internacionais, como Banco Mundial,


Banco Internacional para Reconstrução e Desenvolvimento, e outros;

Art. 19. O Termo de Referência ou Projeto Básico, a critério da Área Requisitante da


Solução ou da Área de Tecnologia da Informação, poderá ser disponibilizado em consulta ou audiência
pública, a fim de avaliar a completude e a coerência da especificação dos requisitos, a adequação e a
exequibilidade dos critérios de aceitação.

Seção II

Seleção do Fornecedor

Art. 20. A fase de Seleção do Fornecedor observará as normas pertinentes, incluindo o


disposto na Lei nº 8.666, de 1993, na Lei nº 10.520, de 2002, no Decreto nº 2.271, de 1997, no Decreto
nº 3.555, de 2000, no Decreto nº 3.931, de 2001, no Decreto nº 5.450, de 2005 e no Decreto nº 7.174, de
2010.

Parágrafo único. Em consequência da padronização existente no mercado de Tecnologia


da Informação, é recomendada a utilização da modalidade Pregão para as contratações de que trata esta
Instrução Normativa, conforme os arts. 1° e 2° da Lei nº 10.520, de 2002, preferencialmente na forma
eletrônica, de acordo com o Decreto nº 5.450, de 2005.

Art. 21. A fase de Seleção do Fornecedor terá início com o encaminhamento do Termo de
Referência ou Projeto Básico pela Área de Tecnologia da Informação à Área de Licitações.

Art. 22. Caberá a Área de Licitações conduzir as etapas da fase de Seleção do Fornecedor.

Art. 23. Caberá a Área de Tecnologia da Informação, com a participação do Integrante


Técnico, durante a fase de Seleção do Fornecedor:

I - analisar as sugestões feitas pelas Áreas de Licitações e Jurídica para o Termo de


Referência ou Projeto Básico e demais documentos;
II - apoiar tecnicamente o pregoeiro ou a Comissão de Licitação na resposta aos
questionamentos ou às impugnações dos licitantes; e

III - apoiar tecnicamente o pregoeiro ou a Comissão de Licitação na análise e julgamento


das propostas e dos recursos apresentados pelos licitantes.

Art. 24. A fase de Seleção do Fornecedor se encerrará com a assinatura do contrato e com
a nomeação do:

I - Gestor do Contrato;

II - Fiscal Técnico do Contrato;

III - Fiscal Requisitante do Contrato; e

IV - Fiscal Administrativo do Contrato.

§ 1º As nomeações descritas neste artigo serão realizadas pela autoridade competente da


Área Administrativa, observado o disposto nos incisos IV, V, VI e VII do Art. 2º;

§ 2º Os Fiscais Técnico, Requisitante e Administrativo do Contrato serão,


preferencialmente, os Integrantes da Equipe de Planejamento da Contratação;

§ 3º A Equipe de Planejamento da Contratação será automaticamente destituída quando da


assinatura do contrato.

Seção III

Gerenciamento do Contrato

Art. 25. A fase de Gerenciamento do Contrato visa acompanhar e garantir a adequada


prestação dos serviços e o fornecimento dos bens que compõem a Solução de Tecnologia da Informação
durante todo o período de execução do contrato e compreende as seguintes tarefas:

I - início do contrato, que abrange:

a) elaboração do Plano de Inserção da contratada, observando o disposto no art. 11, inciso


V desta norma, pelo Gestor do Contrato e pelos Fiscais Técnico, Administrativo e Requisitante do
Contrato, que contemplará no mínimo:

1. o repasse à contratada de conhecimentos necessários à execução dos serviços ou ao


fornecimento de bens; e

2. a disponibilização de infraestrutura à contratada, quando couber;

b) realização de reunião inicial convocada pelo Gestor do Contrato com a participação dos
Fiscais Técnico, Requisitante e Administrativo do Contrato, da contratada e dos demais intervenientes
por ele identificados, cuja pauta observará, pelo menos:

1. presença do representante legal da contratada, que apresentará o preposto da mesma;


2. entrega, por parte da contratada, do termo de compromisso e do termo de ciência,
conforme art. 15, inciso VI; e

3. esclarecimentos relativos a questões operacionais, administrativas e de gerenciamento


do contrato;

II - encaminhamento formal de Ordens de Serviço ou de Fornecimento de Bens pelo


Gestor do Contrato ao preposto da contratada, que conterão no mínimo:

a) a definição e a especificação dos serviços a serem realizados ou bens a serem


fornecidos;

b) o volume de serviços a serem realizados ou a quantidade de bens a serem fornecidos


segundo as métricas definidas em contrato;

c) o cronograma de realização dos serviços ou entrega dos bens, incluídas todas as tarefas
significativas e seus respectivos prazos; e

d) a identificação dos responsáveis pela solicitação na Área Requisitante da Solução.

III - monitoramento da execução, que consiste em:

a) confecção e assinatura do Termo de Recebimento Provisório, a cargo do Fiscal Técnico


do Contrato, quando da entrega do objeto resultante de cada Ordem de Serviço ou de Fornecimento de
Bens;

b) avaliação da qualidade dos serviços realizados ou dos bens entregues e justificativas, de


acordo com os Critérios de Aceitação definidos em contrato, a cargo dos Fiscais Técnico e Requisitante
do Contrato;

c) identificação de não conformidade com os termos contratuais, a cargo dos Fiscais


Técnico e Requisitante do Contrato;

d) verificação de aderência aos termos contratuais, a cargo do Fiscal Administrativo do


Contrato;

e) verificação da manutenção das condições classificatórias referentes à pontuação obtida


e à habilitação técnica, a cargo dos Fiscais Administrativo e Técnico do Contrato;

f) encaminhamento das demandas de correção à contratada, a cargo do Gestor do


Contrato;

g) encaminhamento de indicação de sanções por parte do Gestor do Contrato para a Área


Administrativa;

h) confecção e assinatura do Termo de Recebimento Definitivo para fins de


encaminhamento para pagamento, a cargo do Gestor e do Fiscal Requisitante do Contrato, com base nas
informações produzidas nas alíneas “a” a “g” deste inciso;
i) autorização para emissão de nota(s) fiscal(is), a ser(em) encaminhada(s) ao preposto da
contratada, a cargo do Gestor do Contrato;

j) verificação das regularidades fiscais, trabalhistas e previdenciárias para fins de


pagamento, a cargo do Fiscal Administrativo do Contrato;

k) verificação da manutenção da necessidade, economicidade e oportunidade da


contratação, a cargo do Fiscal Requisitante do Contrato;

l) verificação de manutenção das condições elencadas no Plano de Sustentação, a cargo


dos Fiscais Técnico e Requisitante do Contrato;

m) encaminhamento à Área Administrativa de eventuais pedidos de modificação


contratual, a cargo do Gestor do Contrato; e

n) manutenção do Histórico de Gerenciamento do Contrato, contendo registros formais de


todas as ocorrências positivas e negativas da execução do contrato, por ordem histórica, a cargo do
Gestor do Contrato;

IV - transição contratual, quando aplicável, e encerramento do contrato, que deverá


observar o Plano de Sustentação.

§ 1º No caso de substituição ou inclusão de empregados por parte da contratada, o


preposto deverá entregar termo de ciência assinado pelos novos empregados envolvidos na execução
contratual, conforme art. 15, inciso VI.

§ 2º Para cada contrato, deverá haver pelo menos uma Ordem de Serviço ou de
Fornecimento de Bens, ou tantas quantas forem necessárias para consecução do objeto contratado.

Art. 26. No caso de aditamento contratual, o Gestor do Contrato deverá, com base na
documentação contida no Histórico de Gerenciamento do Contrato e nos princípios da manutenção da
necessidade, economicidade e oportunidade da contratação, encaminhar à Área Administrativa, com pelo
menos 60 dias de antecedência do término do contrato, documentação explicitando os motivos para tal
aditamento.

Art. 27. Os softwares resultantes de serviços de desenvolvimento deverão ser catalogados


pela contratante e, sempre que aplicável, disponibilizados no Portal do Software Público Brasileiro de
acordo com o regulamento do Órgão Central do SISP.

Capítulo III

DAS DISPOSIÇÕES FINAIS

Art. 28. Aplica-se subsidiariamente às contratações de que trata esta norma o disposto na
Instrução Normativa nº 2, de 30 de abril de 2008, que disciplina as contratações de serviços gerais.

Art. 29. As Áreas de Compras, Licitações e Contratos dos órgãos e entidades apoiarão as
atividades da contratação, de acordo com as suas atribuições regimentais.

Art. 30. As normas dispostas nesta Instrução Normativa deverão ser aplicadas nas
prorrogações contratuais, ainda que de contratos assinados antes desta IN.

Parágrafo único. Nos casos em que os ajustes não forem considerados viáveis, o órgão ou
entidade deverá justificar esse fato, prorrogar uma única vez pelo período máximo de 12 (doze) meses e
imediatamente iniciar novo processo de contratação.

Art. 31. Esta Instrução Normativa entrará em vigor a partir de 2 de janeiro de 2011.

Art. 32. Esta Instrução Normativa revogará a Instrução Normativa SLTI/MP nº 4, de 19


de maio de 2008, em 2 de janeiro de 2011.

MARIA DA GLÓRIA GUIMARÃES DOS SANTOS

Você também pode gostar