Tableless - Padrões Web com Pastel e Caldo de Cana

Posts da TAG ‘acessibilidade’

Quem precisa de versão mobile?

Parece ser um erro comum dos novatos criar versões diferentes do mesmo site.

O ano era 1997. Eu e e todo mundo que eu conhecia usávamos Netscape Navigator. Foi o ano em que, pela primeira vez, fiz um site sozinho. Tudo, atendi o cliente, preparei textos, fotos, fiz o layout, se é que se pode chamar aquilo de layout, criei uma conta no Geocities e publiquei. Em seguida entrei no Yahoo! e cadastrei o site, para que aparecesse nas buscas.

Depois de alguns dias recebi um e-mail do Yahoo! dizendo que o site não poderia ser publicado no diretório porque não funcionava no Internet Explorer. Continuar lendo »

27 Comentários

Sites para Dispositivos Móveis - MediaType

Felizmente, com a ajuda dos Web Standards, o trabalho para criar um site ficou muito mais fácil, rápida e o mais importante, divertida.
Hoje, você troca de layout a hora que quiser, sem se preocupar em ter que refazer todo o código e programação. Eles já estão feitos, por que ter que recriá-los? Então, você troca apenas 1 arquivo CSS, e seu site muda completamente, sem dor de cabeça, apenas mudando a lente de formatação.

E com as qualidades do CSS, também se tornou fácil fazer várias vesões de um mesmo site para diversas medias. O que eu quero dizer com isso? Muito simples… Antes, se você quisesse prover para seu visitante uma versão do seu site para imprimir, você faria uma versão do seu layout mais enxuta, sem as informações que se tornariam desnecessárias uma vez impressas. Teria que refazer o HTML, tirar partes de código e etc… Hoje, você simplesmente cria um CSS para a media de impressão, e pelo CSS oculta os objetos que você quiser. Muito mais fácil, muito mais prático.

Do mesmo jeito que você faz uma versão do CSS para site ser impresso, você fará uma folha de estilo para os HandHelds. Ou seja, o camarada que entrar usando um dispositivo móvel, terá uma versão totalmente compatível, e sem informações que não lhe é interessante quando está usando esse dispositivo.
A mecanica é mesma. Com CSS você oculta as informações não são interessantes para o usuário de mobiles. Por exemplo, se o cidadão acessar o site da UOL com um mobile, não é interessante para ele, ver boa parte de cabeçalho do UOL. Como por exemplo os links de ASSINE UOL ou links para o BATE-PAPO. Essas informações seriam facilmente ocultadas.

Você fará então, várias versões de CSS para vários tipos de Medias. Usará o mesmo XHTML, sem tocar em nenhum código de programação, manipulando totalmente o site para se adequarem às Medias desejáveis.
Suas tags para linkar os arquivos CSS ficarão desta maneira:

Screen: Para Desktops: <link rel=”stylesheet” type=”text/css” href=”screen.css” media=”screen” />
Print: Para Impressão: <link rel=”stylesheet” type=”text/css” href=”print.css” media=”print” />
HandHelds: Para HandHelds, PDA´s, etc: <link rel=”stylesheet” type=”text/css” href=”handheld.css” media=”handheld” />

Perceba que em todas as linhas, há um atributo MEDIA. É com esse atributo que diremos ao navegar onde ele deve aplicar o CSS. Se o camarada visita o site com um dispositivo móvel, com um navegador que seja de acordo com os Padrões (óbvio), vai usar automáticamente para renderizar o site, o CSS de HandHelds, em vez de Screen. Você não terá trabalho para fazer um script que chaveia nem nada parecido, como fazem alguns sites hoje em dia. Esse chaveamento será feito automáticamente, pelo navegador.

Trabalho? Quase zero. Você teve apenas que criar um novo CSS, escondendo objetos, diminuindo e modificando outros. Alguns mais ousados, farão uma versão que segue o estilo do site visto por desktops, mas mais direcionado a usuários de Mobiles, deixando mais confortáveis.

Compare as duas imagens abaixo. Usei como modelo o site do Opera, eles fizeram um belo trabalho. Primeiro, um screeshot do site visto de um monitor, com MediaType Screen.

Agora, confira o mesmo site, só que visto com o CSS destinado a HandHelds. Perceba as diferenças e veja que eles ocultaram boa parte das informações, como por exemplo, aquela chamada enorme sobre o download do Opera 8.5, que é interessante apenas para os usuários de Desktop, não para usuários de Mobiles.

Eles aproveitaram também para rebuscar o design para esses dispositivos. A experiência do usuário, com certeza será satisfatória. É confortável de navegar. Você pode trabalhar melhor outras partes do desenvolvimento, como por exemplo, estudos de usabilidade. Você tem toda liberdade que o CSS pode lhe dar.

Propriedades CSS mais usadas

Todas as propriedades do CSS estarão disposníveis para o uso na manipulação para qualquer media. Claro, na media screen é que você usará mais largamente os mais variados tipos de propriedades que o CSS concede. Na media screen, as propriedades que você mais usará será a WIDTH, HEIGHT e DISPLAY.

Width e Height são propriedades que serve para definir largura e altura, respectivamente. Elas tem duas variação, onde você define qual largura/altura máxima que dado objeto pode ter. São elas max-width e max-hight.
Então, você definirá no CSS de handheld, qual a largura máxima, que por exemplo, o body deverá ter.

body {max-width: 240px;}

Já a propriedade display, será muito usada para ocultar os objetos. Muitas informações que aparecem em alguma parte do layout, muitas vezes não são úteis para os usuários de mobiles, portanto, ocultar essas informações é um favor que você faz para os usuários.

Há algo sobre o assunto no site do Opera, não custa nada dar uma olhada… Visite e leia.

Testando

Você não precisa ter um dispositivo móvel para conseguir saber como seu site se comportará. Basta simplesmente usar o sistema de SSR do Opera, ele é ativado apertando a combinação de teclado SHIFT + F11.
Se você já tem um CSS para media de HandHeld, ele ativará automáticamente esse CSS no SSR.

Meu conselho é você primeiro tudo testar o site sem CSS para HandHeld para ter uma noção de como ele será exibido sem formatação específica. Depois, aplique um CSS para HandHelds, e compare a diferença. Veja como você tem mais controle sobre o layout.

E atenção… Não são todos os browsers que tem um sistema tão bom quanto o Opera. E, hoje em dia, apenas o Opera e o MiniMo (uma versão do Mozilla para mobiles) tem amplo suporte de CSS. O resto dos browsers tem pouca ou quase nenhum suporte. O IE para HandHeld por exemplo, não tem tanto suporte quanto os outros dois, por exemplo, ele não reconhece MediaTypes.

Vamos nos dar mais atenção a esse mercado. Ele está crescendo e a cada ano surgem novas possibilidades. É um ramo que cresce rápido, e não vai demorar muito você ver qualquer pessoa na rua visitando algum site para consultar um mapa ou procurar qualquer tipo de informação. É muito importante que os desenvolvedores atentem para esse grande caminho.

6 Comentários

Procrastinar a Acessibilidade pode ser perigoso

Acabei de ler o artigo “Acessibilidade Web: 7 mitos e um equívoco” escrito pela Lêda Spelta do AcessoDigital. Um artigo que só quem entende profundamente o tema, poderia escrever com tanta clareza.
Mesmo assim, quero fortalecer o que ela disse no artigo e enfatizar mais o que já venho dizendo aqui.

No artigo a Lêda fala sobre aqueles mitos (desculpinhas esfarrapadas, em vez de mitos, na minha opinião) que profissionais sem conhecimento básico e falta de curiosidade, sempre dizem quando ouvem a palavra acessibilidade.

Já disse isso aqui e em algumas palestras: damos uma série de desculpas para não ter trabalho demais, principalmente quando achamos que fazer um site acessível dá um trabalho terrível e não tráz retorno algum. Sempre deixamos para segundo plano ou para a próxima atualização do site. Acontece que esse é um assunto que simplesmente não pode ser procrastinado como geralmente fazemos.
Acessibilidade é coisa séria e grande engano se você acha que o trabalho de acessibilidade destinam-se apenas para cegos ou para pessoas com qualquer deficiência visual. Ela envolve uma série de grupos de usuário, e cada grupo com tem sua particularidade.

Infelizmente ainda estamos deixando em segundo plano essa tal de acessibilidade… Na maioria das vezes um simples “alt” faz a diferença. E ainda assim, pode servir como desculpa para não fazer um trabalho mais rebuscado.
O desenvolvedor coloca os alts nas imagens, um link para pular direto para o conteúdo, um menu acessível e acha que o trabalho de acessibilidade está terminado. Embora essas coisas ajudem muito, o trabalho não é completo. Embora seja uma iniciativa interessante.

No último mito que a Lêda descreve - que na verdade não é mito, mas sim, um conceito pré formado pela maioria dos profissionais - é a seguinte: “Meu site é direcionado a um público específico; ele não interessa a todos os grupos de usuários.”
Ela dá pelo menos 4 exemplos matadores sobre esse pensamento tacanho.
Se você vai fazer um site que vende monitores, você pode pensar não precisa fazer um site para cegos porque, afinal de contas, um monitor pode não fazer muita diferença para alguém que não enxerga. Mas e se esse alguém tiver um filho designer ou fotógrafo? Ele não pode entrar o seu site para escolher um monitor de presente para o filho?

16 Comentários

Sobre Internet Explorer para Mobile - Breve impressão

Desde que adquiri um MotoQ (se lê MotoQUIU) eu venho usando o Opera Mobile como browser padrão. Ao contrário da versão pra desktops, o Opera Mobile é pago. Por este motivo, quando a data expirou, eu resolvi usar por um tempo o Internet Explorer.
Descobri que a forma com que o IE Mobile renderiza as páginas é tão boa quanto a do Opera Mobile. A velocidade de navegação também é ótima.

O Opera usa muito um sistema que eles chamam de SSR,que em teoria, melhoraria (ou pelo menos tentaria) a visualização de sites em dispositivos móveis. Acontece que esse modo deixa o site muito, mas muito feio. Neste caso, tive a impressão de que o Internet Explorer renderiza melhor os sites que não foram feitos para mobile.

Para quem quer dar uma ajuda para o pessoal que usa browsers mobiles, existe uma metatag chamada MobileOptimized:

<meta name="MobileOptimized" content="sualargura" />

Essa metatag é usada principalmente pelo Internet Explorer Mobile para otimizar melhor o site quando visto de SmartPhones, PocketPCs, etc. O valor colocado ali no atributo “content” deve ser a largura que o browser deve limitar seu layout quando visto de um mobile.

Aviso aos navegantes: fazer image-replacement usando text-indent não funciona no IE para Mobiles. Parece que ele não reconhece o text-indent, o que faz com que o texto fique por cima do logo.

A qualidade de rederização das fontes também achei melhor que a do Opera Mobile. Achei as fontes muito mais nítidas e legíveis.

Uma coisa ruim que achei o IE para Mobiles é a falta de abas. Isso seria muito útil. Normalmente estou sempre visitando e usando mais de dois sites simultâneamente. E sair de um para visitar o outro é uma alterativa terrível. Isso sim me faria voltar para o Opera.

11 Comentários

Site em Ajax? Site em Flash? Pergunta ruim.

Recebi há poucos dias um email que me deixou intrigado. Um amigo descrevia um site que vai construir em breve e me perguntava: você acha que devo fazê-lo em Ajax? Essa é uma pergunta ruim. A boa pergunta seria: onde, nesse site, eu deveria usar Ajax?

Enquanto os cabeças-pequenas ficam discutindo se devem fazer ou não site em Flash, o Flickr faz um site HTML, com um excelente slideshow em Flash. Deixe-me perguntar: o YouTube é um “site em Flash”? O Google Video? E o Charges.com.br? Não? Uma vez que o uso de Flash era inevitável, porque não fizeram logo o site todo em Flash? Porque, amiguinhos, Flash é bom para umas coisas, HTML é bom para outras. Eis uma lição que precisamos aprender: não ao radicalismo, nem oito, nem oitenta.

HTML é a ferramenta ideal se você quer que as pessoas consigam usar o botão voltar, adicionar bookmarks, mandar o endereço para os amigos, selecionar e copiar texto, imprimir a página, encontrar seu conteúdo no Google e etc. Claro, dá para fazer quase tudo isso funcionar com Flash ou Ajax, mas com HTML você faz isso sem trabalho nenhum. Está pronto. Basta escrever bom HTML que o resto acontece sozinho. Além disso, HTML tem um custo de desenvolvimento muito reduzido em relação ao Flash. Custo de desenvolvimento, amigos, se mede em horas de trabalho. Gerar formulários, buscas, listagens e relatórios é muito mais fácil em HTML do que em Flash. Se você usa um desses frameworks modernosos então, nem se fala.

Por outro lado, Flash é bom para algumas outras coisas. Por exemplo, se você vai publicar vídeo numa página web, Flash é hoje a opção mais leve, simples e compatível. Ajax, por sua vez, é excelente para evitar refreshs e modifica o modelo de interação com a página. Então não precisamos escolher entre um “site em Flash” e um “site em Ajax” em detrimento de um “site comum, em HTML”.

Para ajudar meu amigo, vou publicar aqui algumas coisas que levo em consideração ao escolher onde usar Javascript e Ajax em um site. Entenda que isso não é uma verdade absoluta, há provavelmente muito mais coisas que você pode levar em consideração, em que eu talvez nunca tenha pensado. Hoje, eu penso no seguinte:

Acessibilidade: o bom Javascript não quebra a acessibilidade do bom HTML (posso falar mais sobre isso outro dia.) Mas isso pode dar algum trabalho. É preciso levar em conta a importância da acessibilidade para aquela aplicação específica. Sim, acessibilidade pode não ser importante para determinadas aplicações. Por exemplo, o Google Maps é inacessível a deficientes visuais e a qualquer um que não consiga usar um mouse. Quem aí vai dizer que eles fizeram uma escolha errada? Mas, para a maioria das aplicações, acessibilidade é importante, e é preciso pensar nisso antes de planejar nosso Javascript.
Modelo de interação: você pode torcer o nariz, mas as pessoas estão acostumadas com o modelo de interação com páginas: clica - espera um pouquinho - carrega uma nova página. Elas sabem usar os recursos do navegador feitos para esse modelo, como a barra de endereços, os bookmarks, e o botão voltar. Ah, o que seria de nós sem o botão voltar? Então, eu uso Javascript sem medo onde é claro para as pessoas que elas estão interagindo com a mesma página, no modelo “aplicação”. Mas evito usá-lo onde possa dar a impressão de que estão navegando para outra página. Caso contrário, elas vão tentar usar o botão voltar e o resto todo. Você leu certo, “evito” não quer dizer que eu nunca faça, só tento ser muito parcimonioso. O nosso Tutorial de Ajax (e também a continuação) foi feito em Ajax por motivos didáticos. Navegando nele você vai sentir falta do botão voltar e de poder usar bookmarks.
Custo x benefício: convenhamos, HTML comum funciona bem para a maioria das coisas, e realmente muito bem para algumas. É a ferramenta ideal, por exemplo, para publicar um site de conteúdo, como esse aqui. Um portal de notícias, um blog, um manual de produto, etc. Usando Ajax você pode fazer com que, ao navegar em um site assim, seja recarregada apenas a parte principal, com o conteúdo. Menus, cabeçalho e rodapé permanecem. Mas será que vale a pena? Trabalhando com padrões web, com seu CSS, javascript e imagens no cache, você vai economizar quanto em banda com esse Ajax? Aqui no Tableless economizaríamos cerca de 15 Kb por página. Por outro lado, teríamos que incluir um bocado de Javascript colocar esse Ajax para funcionar, e manter funcionando coisas como o botão voltar. Sendo que cada visitante vê em média 2 páginas (1,95 para ser mais exato) isso dificilmente representaria alguma economia em banda. E daria um bocado de trabalho.

Logo, meu conselho é: não faça sites “em Ajax”, nem sites “em Flash”. Faça sites com os padrões web, e use Ajax ou Flash onde isso for realmente ajudar seus usuários.

32 Comentários

Acessibilidade: ou seu site tem ou não tem.

Acessibilidade é um assunto muito, mas muito importate. Cansamos de discutir técnicas e outros pontos que precisamos fazer para ter um site acessível. Todos, na maioria das vezes, estão de acordo com tudo o que é falado. Acontece que nem sempre colocamos em prática na vida real, ou porque faltou tempo, ou porque o produto ficaria caro, ou qualquer outra desculpinha.

O pessoal da Acesso Digital criou um vídeo que mostra, a queima roupa, as dificuldades que pessoas com dificuldade motora e visual tem ao acessar a internet. Vendo de perto as dificuldades, podemos mensurar os benefícios que 4 ou 5 linhas de código a mais trariam.

O vídeo mostra alguns problemas com suas simples soluções. Você pode aplicar hoje ainda essas soluções e criar um hábito de implementar essas técnicas na implementação do site.

Abaixo, veja o vídeo na íntegra e de sua opinião.

41 Comentários

Portais do governo serão adaptados para cegos

Ótima notícia, já estava na hora… mas não entendi essa parte:

A secretaria vai fornecer um software, chamado “Silvinha”, que foi desenvolvido em conjunto com a organização não-governamental Acessibilidade Brasil.

Será que é um Silvinha modificado? Porque se não, a secretaria não vai fornecer nada.

Existem vários meios de você melhorar a acessibilidade do seu site sem utilizar esses tipos de validadores (que na maioria das vezes não ajudam em nada).
Para melhorar a acessibilidade para os deficientes visuais, por exemplo, a melhor forma é conhecer o mundo deles. Já experimentou navegar sem o mouse? Não? Então tente.
Depois de tentar, instale algum programa leitor de tela como o Jaws, coloque o bicho para falar e desligue o monitor, tente navegar no seu próprio site com teclado e o monitor desligado.
Se você não é cego e não experimentou fazer isso, tente. Você vai ter uma pequena sensação do que é navegar às cegas.

10 Comentários

Google Reader para Wii

E eis que o Google lançou uma versão do Google Reader para Nintendo Wii. Você pode ler uma análise interessante no ZD Net ou ver por você mesmo em http://www.google.com/reader/wii.

A versão para Wii funcionou muito bem em meu Firefox e, com textos e menus grandes, me parece bastante boa para que eu possa usá-la quando estiver com meu notebook conectado à TV.

Ver esse treco me fez pensar em duas coisas. Primeiro, que aplicações será que precisam de uma versão específica para cada ambiente e plataforma em que for rodar? O Google Reader, por exemplo, tem versões para desktop, mobile e Wii. Eu, como usuário do Google Reader mobile e do Gmail HTML, posso afirmar que no caso de aplicações complexas como o Google Reader e o Gmail ter versões alternativas faz toda a diferença. Mas, para acessar por exemplo blogs e outros sites de conteúdo, tenho usado o Opera Mobile sem nada de especial. Mesmo outras aplicações, como as ferramentas administrativas da Visie, eu acesso normalmente no mobile. Usuários de Wii, PlayStation, WebTVs, Opera Mobile, Nokia Mobile Browser e outros trecos semelhantes, por favor, se manifestem aqui nos comentários. Faz muita diferença ter uma versão específica para a sua plataforma, uma versão “reduzida” ou você usa as versões desktop de suas aplicações mesmo?

A segunda pergunta é: quanto tempo leva para fazer uma versão Wii/PS/mobile de um site? Se você trabalha com bom CSS, vai só alterar alguma coisa no javascript para funcionar com os atalhos específicos da plataforma e escrever um novo CSS, certo?

9 Comentários

Não troque todas as suas imagens por background!

Às vezes é bom repetir os fatos básicos, principalmente porque tem sempre gente chegando e começando a aprender.

Uma dúvida muito comum, que eu vejo se repetir há alguns anos, é onde usar e onde não usar imagens no background via CSS. Para quem está chegando agora, a questão básica é que existem duas maneiras de se fazer uma imagem aparecer na tela. Cada uma delas tem suas vantagens e desvantagens e é melhor usada para um fim específico. Mas muita gente usa apenas um método ou o outro.

Uma delas é inserir uma tag HTML:

<img src="seta.gif" alt="Prosseguir" />

A outra é inserir essa imagem como background de uma tag qualquer através do CSS:

a.prosseguir { background: white url(seta.gif) top left no-repeat; }

As diferenças entre eles, embora não apareçam à primeira olhada no site, são substanciais. Experimente, por exemplo, desligar o CSS daqui do Tableless. Você vai ver que todas as imagens que compôem o layout, incluindo logotipo e as sombras laterais, vão desaparecer. Vão sobrar apenas umas imagenzinhas do Feedburner e da barra lateral direita.

Quem trabalha com tabelas geralmente usa apenas o primeiro método. Infelizmente muita gente aprendendo a construir layouts Tableless com CSS, ao aprender o segundo método, tem abandonado completamente o uso da tag img. É um exagero comum entre os novatos, assim como abandonar completamente o uso da tag table.

Por que o Diego escolheu algumas imagens para ir no meio do código HTML e outras para inserir como background CSS? A regra é simples, como todo o resto na dobradinha XHTML+CSS, imagens que fazem parte de seu conteúdo vão no HTML, imagens que são apenas elementos de layout vão no CSS.

Veja, por exemplo, este meu post sobre o Performancing. Há, no topo e no rodapé, dois gradientes. Experimente desligar o CSS. Você vai ver que algumas imagens foram mantidas. Todas elas fazem parte do conteúdo da página:

O banner para o Workshop Produtividade Web 2.0.
O screenshot do Performancing.
A setinha para cima do Rec6 e a corretinha do Linkk.
O banner do Firefox
Minha foto.

Há outra maneira, que talvez você ache mais simples, para explicar isso. Imagine-se fazendo o redesign do site. Todas as imagens que você deve manter exatamente como estão são conteúdo. Todas as que você vai querer mudar são layout. Veja isso no exemplo acima. Você não muda um banner, a foto do autor do site ou o screenshot de um programa porque fez um redesign em seu site. Mas, claro, bordas, sombras, fundos, chanfros, linhas separadoras, logotipos, tudo isso pode mudar.

Uma última coisa em que você pode pensar é na indexação pelo Google Bot. Ao fazer uma pesquisa de imagens, você vai querer que as pessoas encontrem em seu site um screenshot de programa, a foto de uma celebridade, um diagrama de explicação de uma teoria ou uma foto de um animal. Mas as imagens decorativas só vão atrapalhar.

Há ainda um terceiro caso que pode confundí-lo, que é o image replacement. Mas sobre isso o Diego já escreveu bastante.

24 Comentários

Sobre Internet Banking

O Bruno falou sobre o internet banking do bradesco. E eu não sou contra a posição dele. Já vi por dentro o internet banking do Itaú, Bradesco, Real e Unibanco (versão antiga) e realmente o melhor que vi até agora foi o do Itaú.

O ponto mais crítico na minha opinião - não é nem o fato de nenhum deles seguirem ao pé da letra os padrões web - é a compatibilidade. Não tenho o que reclamar do Itaú. Funciona em Firefox e Safari, pra mim já é o bastante. Entretanto, o do Bradesco por exemplo, tem uma certa dificuldade em funcionar em browsers modernos, tenho que ter um Internet Explorer por perto para fazer qualquer consulta besta.

Sem comentar sobre os outros pontos deficientes nestes sistemas… Certamente seriam sanados simplesmente abordando os Padrões Web. Mas como sempre, devem existir grandes barreiras a serem vencidas para colocar isso em prática. Talvez, a melhor saída, seria fazer uma grande mudança. Nestes casos, abordar uma nova metodologia muitas vezes é complicado. O desenvolvimento começa a ficar muito enroscado. Por isso uma grande mudança é necessária de vez em quando para que bases melhores possam ser criadas possibilitando oportunidades para modificações menos dolorosas posteriormente.

20 Comentários

Voltar para o topo

Outros posts

Aprenda