A equipe da Turbosite compartilha esse conhecimento com a postagem abaixo.

A medida tipográfica EM

O EM, também chamado de quadratim, é uma medida tipográfica. Antigamente, quando as fontes eram feitas de prensas de metal, 1 EM correspondia a largura de corpo quadrado da letra M maiúscula. O nome é derivado da pronúncia fonética, em inglês, dessa letra.

EM é uma unidade de medida relativa, ou seja, que varia proporcionalmente de acordo com o contexto. É muito útil em CSS por que é possível definir as margens e espaçamentos também em um tamanho proporcional. O que já não funciona com medidas fixas como pixels ou pontos. Quando você define a tipografia de um site no padrão EM, conforme o tamanho da letra aumenta o mesmo acontece com os elementos afiliados ao texto. 1 EM normalmente equivale a 16 pixels, ou seja, a medida que o browser considera como padrão para textos. Utilizar EM é uma questão de acessibilidade, pois pessoas com dificuldade de leitura podem aumentar e diminuir livremente o tamanho do texto de maneira proporcional. O que dá mais liberdade para o usuário, sem quebrar o seu layout! Para quem preferir trabalhar em pixels, tem uma linha simples de CSS que vai facilitar a sua vida.

body {
font-size: 62.5%;
}

Bem, a lógica é simples: se 16 pixels = 100%, 10 pixels é igual a 62.5%. (16 x 0.625 = 10). Então é só definir este valor como padrão para todo o documento. Utilizando esta regrinha 1em passa a ser equivalente a 10px, o que torna bem mais fácil calcular os valores a partir de uma base decimal. É só pegar o seu valor em pixels, andar uma casa para a esquerda e colocar um ponto. Um texto de 14px, por exemplo, seria equivalente a 1.4em. Já um header com 36px seria equivalente a 3.6em. Também existe a calculadora px to em, caso você queria trabalhar diretamente com a medida EM.

 

O que é um grid?

Se você ainda não sabe, nós recomendamos a leitura do livro da coleção Design Básico, volume 6, dos autores Gavin Ambrose e Paul Harris. Mas basicamente um grid é um conjunto de linhas bases que fornecem uma estrutura para o seu layout (ou qualquer outro tipo de peça gráfica). A seguir vamos explicar como transformar um grid fixo de 960px em um grid flexível.

 

Do fixo ao relativo

Vamos supor que você recebeu do designer que trabalha com você o seguinte mock-up no Photoshop:

É um layout bem simples. Uma sidebar de 300px e uma área de conteúdo de 660px. Tudo isso dentro de um wrap de 960px. Se fossemos construir usando o método de layout fixo o CSS ficaria assim:

.wrap {
width:960px;
margin: 0 auto;
}
 
.sidebar {
width: 300px;
float: left;
}
 
.principal {
width: 660px;
float: right;
}

 

Grid Flexível

Para a maior parte das coisas na vida não existe uma fórmula mágica. Felizmente para construir um grid flexível existe: objeto ÷ contexto = resultado. Parece meio difícil, mas é fácil de pegar o jeito.

Vamos voltar ao nosso layout. Precisamos calcular o valor em porcentagem da sidebar e da área de conteúdo em relação ao valor total do site (960px). Esse wrap seria, neste caso, nosso contexto. Vamos começar pela sidebar. Nosso primeiro objeto alvo! Seguindo a fórmula a conta ficaria assim: sidebar ÷ wrap = resultado. Para descobrir a porcentagem é necessário multiplicar o resultado por 100. Vamos começar pela largura da sidebar. 300 ÷ 960 = 0.3125. Não arredonde esse número… Apenas coloque o ponto duas casas para a direita e acrescente o sinal de porcentagem. Ou seja: 31.25%.

.sidebar {
width: 31.25%; /* 300px / 960px */
float: left;
}

Bem, para descobrir o tamanho relativo da div .principal a mecânica é a mesma. Objeto ÷ contexto = resultado. 660 ÷ 960 = 0.6875. Andando duas casas pro lado chegamos em 68.75%. E essa é a largura da nossa div .principal.

.principal {
width: 68.75%; /* 660px / 960px */
float: right;
}

Você deve ter notado que deixamos os valores originais em pixel comentados. Isto não é obrigatório, mas é um bom recurso para facilitar no caso de alguma alteração no futuro.

 

Como lidar com o texto

Você recebe um novo arquivo com as seguintes especificações: tamanho da fonte 16px, entrelinha 24px e 40px de margem. Ok, vamos converter isto para medidas relativas. Como definimos o font-size lá no começo para 62.5% a medida do texto é o mais fácil: 1.6em.

p {
font-size: 1.6em; /*16 pixels*/
}

Uma coisa meio óbvia mas que é importante lembrar sobre a relatividade é que ela é, bem, relativa. Se o contexto muda, o objeto alvo também muda. Como o nosso font-size é 1.6em o espaçamento entre as linhas tem que ser calculado com base neste novo número. Lembra da fórmula objeto ÷ contexto = resultado? Ela também vai servir para o texto. 2.4 ÷ 1.6 = 1.5. Ou seja, 1.5em. Como não estamos trabalhando com porcentagem não é necessário multiplicar por 100.

p {
font-size: 1.6em; /*16 pixels*/
line-height: 1.5em; /*24 pixels*/
}

Vamos ao espaçamento. Você poderia perfeitamente indicar padding como 40px. Mas não usamos nenhum pixel até agora… Pra que estragar, né? Sem contar que talvez um espaçamento de 40px fique grande demais em um celular com a tela pequena como o Blackberry. Então vamos continuar com as medidas proporcionais!

 

Sobre margins e paddings

Isso parece repetitivo, mas lembre-se que o contexto sempre muda. E esta é uma regrinha importante de se lembrar:

1.  Quando você utilizar o parâmetro margin pra definir um elemento o seu contexto é a largura do container pai (neste caso a div .principal).
2. Quando você utilizar o parâmetro padding para definir um elemento o contexto é o tamanho do próprio elemento.

Com isso em mente vamos especificar o padding do nosso texto. Como o parágrafo está na medida EM, vamos deixar o padding como EM também! 40 ÷ 16 = 2.5em

p {
font-size: 1.6em; /*16 pixels*/
line-height: 1.5em; /*24 pixels*/
padding: 2.5em; /*40 pixels*/
}

 

Alguns sistemas prontos

Antes de apelar tente fazer na prática. É mais fácil do que parece! Mas se você absolutamente não consegue fazer contas ou precisa de muita agilidade no seu projeto dá para utilizar um sistema de grid adaptável pré desenvolvido…

 

1140 CSS Grid

Um sistema simples e fácil de usar é o 1140 CSS Grid System desenvolvido por Andy Taylor. É um grid de 12 colunas considerando um container máximo 1140 pixels. Cada coluna tem uma classe formada pelo seu número em inglês + o sufixo col. Exemplo: .onecol, .twocol, .threecol e assim por diante. Estas colunas podem ser utilizadas em qualquer combinação que some 12 no final. Posso usar 6 vezes em uma fileira a classe .twocol, em outra posso usar três vezes a .fourcol, doze vezes a .onecol e assim por diante. O legal é que você não precisa se preocupar com contas ou com margem. Tudo se adapta elasticamente.

 

Skeleton

Skeleton é um boilerplate responsivo com um “esqueleto” básico de CSS para os seus layouts.

 

Golden Grid System

Um grid dobrável de 18 colunas. O Golden Grid acompanha um script muito útil com linhas guias para você visualizar a estrutura do grid no browser enquanto desenvolve.

 

Tiny fluid Grid

Um grid super leve! O Tiny Fluid Grid é legal por que você pode customizar (dentre as opções do site) o número de colunas, o tamanho das margens e a largura mínima e máxima do container.

 

Inuit.css

Um framework super completo. O inuit.css combina webstandarts, um ótimo reset para o CSS e um grid responsivo. É necessário instalar um plugin para gerar o grid.

 

Less Framework

O Lessframework contém de grid mais adaptável. Existem quatro estados estáticos do layout: 320, 480, 768, e 992 pixels. O grid perde ou ganha colunas de acordo com as mudanças da tela, mas o tamanho das colunas sempre fica o mesmo.

 

FrameLESS

O FrameLESS é um grid responsivo sem ser fluído. Funciona assim: o grid “cresce” para os lados coluna por coluna ao invés de pixel por pixel. Um conceito muito legal, mas para usar você precisa conhecer LESS – uma linguagem de folhas de estilo dinâmica.

 

the SEMANTIC grid

Isso mesmo! Um grid semântico para quem odeia sujar o código com classes como .onecol. É necessário saber usar LESS, SASS ou Stylus.

 

GuideGuide

Quem é designer sabe que lidar com grids no Photoshop é um pé no saco. Esse plugin facilita MUITO a sua vida. Você pode criar um grid super personalizando especificando exatamente onde você quer cada linha guia. Muito útil! Só lembrando que se você usa OSX é necessário fazer esta atualização para oAdobe Extension Manager.

 

 

Design fluído ou design responsivo?

Muita gente confunde os dois conceitos! Design fluído, ou design liquido, é uma técnica de desenvolvimento web que também utiliza medidas relativas para que o layout de um site possa aumentar ou diminuir de tamanho de acordo com o tamanho da área de visualização. Bem, nesse sentido é muito semelhante ao design responsivo. Mas as semelhanças acabam por aqui. No caso do design responsivo, não se trata apenas de esticar ou encolher os elementos visuais do site, e sim de adaptar a experiência de navegação de acordo com as necessidades de cada tipo de mídia. E estas mudanças vão muito além do tamanho do grid.

Vamos imaginar, por exemplo, que você está no meio da rua e precisa descobrir o endereço ou telefone de um restaurante. Você saca o seu smartphone do bolso e tem uma péssima surpresa: a recepção da área é horrível! O sinal da internet só pega em modo EDGE (conexão mais lenta que a 3G). Depois de alguns minutos, que pareceram séculos, o site do restaurante até abre no seu celular… mas como ele é liquido a sidebar ocupa 30% da tela. Os links do menu são tão pequenos que você não consegue nem clicar! A experiência é tão frustrante que você até desiste de encontrar o endereço e decide comer em outro lugar!

Mas, se o site do nosso restaurante imaginário fosse responsivo, o menu lateral poderia ser transplantado para o topo do site, com os links com um tamanho maior pensando em uma interface touch! Ou, para aproveitar ainda mais o espaço, o menu poderia ser um campo de formulário tipo select. Super prático! Alguns elementos como imagens grandes meramente decorativas poderiam ser substituídos por versões menores e mais leves (ou nem existir). Isto tudo sem a necessidade de um novo html em uma versão mobile.

 

Dica para estudos

Lembra o Ethan Marcotte, o cara que inventou o design responsivo? Então, ele tem um livro muito completo sobre esse assunto: A Book Apart, Responsive Web Design.

Como surgiu o conceito

Faça uma experiência. Tente aumentar ou diminuir muito a janela deste blog. Reparou como o conteúdo se re-organizou de acordo com o tamanho do browser? Em um tamanho pequeno, as imagens e o texto diminuiram proporcionalmente. Para aproveitar melhor o espaço, a sidebar se transformou em um menu superior. Já em uma janela maior o layout ganhou uma coluna extra. Se você acessar esse blog de um celular ou tablet vai reparar em outras adaptações. Tudo pensando em melhorar a sua experiência de navegação. Isto é design responsivo.

Mas como surgiu o conceito? Tudo começou com um artigo do blog A List Apart assinado por Ethan Marcotte no comecinho de 2010. Logo no inicio do artigo somos apresentados a Christopher Wren, um arquiteto inglês. Christopher disse uma vez que a arquitetura é uma arte que “objetiva a eternidade”. Afinal, todo arquiteto que se preze quer construir um prédio que seja admirado (e habitado) por séculos… Quer um exemplo prático? O coliseu de Roma foi construído no ano 79 e ainda é uma das maiores atrações turísticas do mundo. A imagem abaixo é a primeira versão do Twitter, lançado em julho de 2006. Aposto que o serviço não seria tão popular se a interface não tivesse sido atualizada… O Design Digital não tem a permanência da arquitetura. Na verdade, projetar para internet é já estar desatualizado daqui a duas semanas!

O Problema

Se você tem 20 anos ou mais provavelmente se lembra daquela época: um passado não muito distante, um tempo em que era obrigatório ter um computador para acessar a internet. As coisas evoluíram bastante e hoje as pessoas utilizam tablets, smartphones, televisores… Já vi por aí até banheiras conectadas a rede. A questão é que impossível prever como acessaremos a internet no futuro. E não é só a capacidade de cada aparelho que varia. Você pode até querer eleger uma categoria como alvo principal: desktops, por exemplo. Mas ainda vai ter as diferenças entre sistemas operacionais, browsers, resoluções de tela… Não podemos partir do pressuposto que todos se conectam através dos mesmos aparelhos. Mas através do Design Responsivo é possível garantir a acessibilidade do conteúdo independente do meio que o usuário utilizar para acessa-lo.

960 pixels não são mais suficientes

A maior parte dos desenvolvedores para web trabalha da seguinte maneira: cria-se uma divisão principal de largura fixa que funciona como um container (ou wrap). Ou seja, todo o site acontece dentro desta divisão, impedindo que tudo se espalhe desordenadamente pelo monitor. Esta divisão foi criada para que tivéssemos mais controle do design. Como a maior parte dos monitores eram da resolução 1024×768 foi padronizado 960 pixels como a largura ideal para um site. E isso funcionou bem. Por um tempo…

Na verdade os dispositivos foram evoluindo tão rápido que acabamos ficando para trás nesta corrida. Você já viu como um site de 960 pixels parece pequeno em um iMac de 21”? Todo aquele espaço vazio… E em uma televisão de 42”? Ignorar estas mudanças é um tiro no pé.

As telas com resolução menor também não podem ser ignoradas. E se você pensa que desenvolver uma versão mobile para o seu site é uma perda de tempo esta muito enganado. Uma pesquisa internacional comprovou que os smartphones ultrapassaram os computadores pessoais em vendas. Em 2010!  Tentar fazer um layout diferente para cada aparelho também é loucura… São tantos sistemas operacionais e browsers diferentes que dá até crise de ansiedade nos pobres desenvolvedores. Eleger apenas um, como o iPhone por exemplo, é privilegiar os donos de uma determinada marca e negar acesso a uma quantidade enorme de outros usuários… É! 960 pixels não são mais suficientes… E agora?

Conheça os Media Queries

A solução proposta por Marcotte é criar um design que *responda* de maneira diferente de acordo com o dispositivo. Desta forma os sites não estariam desatualizados tão freqüentemente, pois não seria mais necessário tentar adivinhar quais formatos de dispositivos serão inventados no futuro. É só uma questão de formatar o conteúdo de acordo com o tamanho e o tipo. Podemos fazer isto através de uma ferramenta chamada Media Queries.

Imagine uma galeria de arte. Cada visitante gostaria de apreciar obras de um determinado estilo… Os Media Queries são como os funcionários da galeria. Eles direcionam cada visitante para uma sala diferente, de acordo com o que eles gostam mais de observar. Media Queries, em uma tradução livre consulta de mídia, são expressões que direcionam o visitante do seu site para uma folha de estilos diferente se acordo com o dispositivo que ele estiver utilizando. Isto já era possível em CSS2 através da função Medias Types… Antes você podia determinar o tipo de dispositivo: móvel (handheld), screen (monitores), print (impressão), etc. Mas com a chegada do CSS3, a funcionalidade Media Queries tornou-se uma ferramenta muito mais precisa.  É possível definir não apenas o tipo de dispositivo, mas também o tamanho, orientação, resolução, proporção… Desta forma você pode ter um “alvo” muito mais específico. Você pode, por exemplo, definir o estilo para uma tela (screen only) com largura mínima de 768 pixels e máxima de 1024 com orientação paisagem (landscape). E, tcharam, aí está um conjunto de estilos perfeitos para iPads “deitados”. Através dos operadores *not*, *end* e *only* as possibilidades de determinação são muito grandes.

O Futuro

O design responsivo não é a solução absoluta para tudo, mas é um caminho a ser seguido, testado, remodelado… A constante mutabilidade da web trás problemas como os apresentados aqui. Isto pode ser considerado uma desvantagem para quem almeja a eternidade, como os arquitetos, mas para nós tem um sabor único. Designers, desenvolvedores, programadores tem algo que a maior parte das outras profissões não tem: espaço para mudança e transformação. Nós somos os responsáveis pela criação das bases para o futuro aqui e agora. O design responsivo pode não ser a solução definitiva, mas está nas nossas mão criar o conceito que seja. Espaço para isso não falta.

Hoje, se você tem interesse em criar uma  página acessível à vários ambientes, apenas adaptar o layout à variações de resolução não basta. Algumas metodologias devem ser revistas para uma completa adequação. Eventos gerenciados pelo DOM, como key press, mouse over e mouse out, não funcionam muito bem em dispositivos móveis. Enquanto conteúdos que são ativados por meio de alguma ação, não serão bem aproveitados para usuários com alguma deficiência, por exemplo.

Alguns tópicos serão levantados durante esse artigo, envolvendo questões quanto á portabilidade e acessibilidade.

Independência de dispositivo

Eventos que funcionam somente pelo mouse são um grande problema para a acessibilidade, pois nem todas as pessoas conseguem utilizar o mouse. Quem utiliza leitor de tela, por exemplo, navega exclusivamente pelo teclado. Pessoas com determinados tipos de deficiência física poderão não ter a habilidade de usar o mouse convencional e poderão utilizar teclados e mouses adaptados. Por isso, todas as funções de uma página devem ser dispositivo-independentes, ou seja, devem funcionar pelo mouse, teclado ou outro dispositivo. Além disso, o foco do teclado não deve ficar fixado ou “preso” em algum elemento, pois o usuário deve poder percorrer toda a página pelo teclado facilmente. Valendo lembrar que em dispositivos móveis, muitos eventos são inexistentes.

Como exemplo, aquele popover que aparece na página, coma opção de fechar ao click de um botão gera uma excelente usabilidade, mas uma acessibilidade terrível para usuários que não conseguem alcançar aquele botão. Uma simples adição de código aplica à tecla “ESC” do teclado a ação de fechar o popover.

window.onload = function(){
	document.onkeydown = function(e){
		// tecla ESC
		if(e.keyCode==13){
			fecha_popover();
		}
	}
}

Se forem utilizados eventos de JavaScript específicos para mouse, devem ser utilizados os correspondentes para teclado:

Adequar a navegação da página pela tecla “TAB” do teclado é outra dica importante. Ordene o conteúdo da sua página para que este tipo de navegação passe apenas por conteúdos utilizáveis, como formulários e links.

Por fim, sempre teste o site navegando por todo o conteúdo somente pelo teclado, com setas e “TAB”, e em diferentes navegadores.

Alterações temporais do conteúdo

É muito comum a utilização de conteúdos que se movem, como os slideshows. Esse tipo de elemento não deve mover-se automaticamente, pois o usuário é quem deve decidir se quer “rolar” o conteúdo ou não. Assim, devem ser oferecidos controles para iniciar, pausar e reiniciar tais rolagens. Esses controles devem ser acessíveis também pelo teclado e devem estar bem descritos, para quem utiliza leitor de tela.

Atualização e redirecionamento automáticos

Quando ocorre uma mudança, atualização ou redirecionamento repentino na página, o usuário pode sentir-se confuso ou desorientado, especialmente se estiver utilizando algum recurso de Tecnologia Assistiva, como um leitor de tela, por exemplo. Isso ocorre em páginas com atualização ou redirecionamento automáticos. A atualização automática periódica – muito utilizada por canais de notícias – é comumente realizada através do uso do o atributo http-equiv com conteúdo “refresh” do elemento meta no HEAD do documento.

Em páginas onde a atualização é absolutamente necessária, o usuário deverá ser informado que a página é atualizada automaticamente.

Quanto ao redirecionamento automático, o mesmo deve ocorrer de forma transparente para o usuário. Ou seja, não devem ser utilizadas marcações para redirecionar a uma nova página, como o uso do atributo http-equiv com conteúdo “refresh” do elemento META.

Limite de tempo

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. Essa recomendação não se aplica a eventos em que o limite de tempo é absolutamente necessário. Deve-se lembrar que, em ambos os casos, o limite de tempo deve ser informado.

Ao especificar o tempo limite para o usuário conclua a ação, não se deve tomar como modelo um desktop conectado a teclado e mouse convencionais. Dispositivos móveis mostram uma ergonomia mais precária, comparadas ao desktop, exigindo um esforço maior e mais prolongado para resolver algumas ações. Deficiências motoras retardam a conclusão de alguns trabalhos na página da web. É importante adequar o tempo levando em conta o dispositivo que o usuário esteja utilizando, e a dificuldade que usuários possam ter concluir trabalhos convencionais.

Intermitência de tela

Não apenas pela acessibilidade, mas também pelo bom gosto. 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. Além disso, elementos piscantes podem causar desconforto, desatenção e confusão para os usuários.

A importância do contraste para usuários com Daltonismo

A deficiência de cor vermelho/verde é o tipo mais comum de Daltonismo. Por isso, deve-se evitar a utilização de contrastes entre essas duas cores.

• Utilizando combinação de cores verde/vermelho: com a deficiência de cor não é possível perceber o contraste entre as cores.

• Utilizando combinação de cores verde/lilás: mesmo com a deficiência de cor, ainda é possível perceber o contraste.

Elementos ocultos na tela

É bastante comum, e deixa a página “inteligente”, ocultar texto que devem ser mostrar apenas se o usuário desejar velos. Mutas vezes por alguma ação do mouse over  aplicada a um ícone de ajuda, por exemplo, para configurar uma capacidade de aprendizagem. Porém, dependendo método aplicado ao elemento para esconde-lo da página, aplicativos de leitores de tela não conseguem alcançar o conteúdo. Dependendo do método, a acessibilidade à aquela ajuda, não exite.

Abaixo é mostrado os diferentes métodos para esconder um elemento da página, e sua reação aos aplicativos leitores de tela.

Elementos ocultos na tela

Por fim, para a avaliar se sua página é Web acessível, existem ferramentas automáticas que auxiliam na avaliação de acessibilidade. O aplicativo eMAG sugere um passo a passo para avaliar a acessibilidade de um site:

1. Validar os códigos de conteúdo HTML e folhas de estilo;
2. Verificar o fluxo de leitura da página, utilizando um navegador textual ou um software leitor de tela;
3. Checar o fluxo de leitura das páginas sem estilos, sem scripts e sem as imagens;
4. Verificar as funcionalidades disponíveis na barra de acessibilidade, como atalhos e contraste;
5. Efetuar a validação automática de acessibilidade, através de avaliadores automáticos;
6. Realizar a validação manual, com uso de checklists de validação humana.

Um recurso bastante útil na avaliação de acessibilidade de um site são as extensões para navegadores para análise de acessibilidade:

• Para Firefox: Accessibility Evaluation Toolbar (link para um novo site)
• Para Google Chrome: Accessibility Developer Tools (link para um novo site)
• Para Internet Explorer: Web Accessibility Toolbar for Internet Explorer (link para um novo site)

Artigo Retirado de Curso eMAG – gov.br