Emanuel Felipe .NET » Padrões Web http://emanuelfelipe.net/blog Desenvolvimento web, blogging, linux e um pouco mais. Wed, 01 Oct 2008 19:47:47 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 Lista de checagem para acessibilidade http://emanuelfelipe.net/blog/lista-de-checagem-para-acessibilidade/ http://emanuelfelipe.net/blog/lista-de-checagem-para-acessibilidade/#comments Wed, 18 Jun 2008 03:12:23 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/?p=230 Recentemente encontrei uma lista de checagem para acessibilidade na web muito interessante, ela pode ser encontrada na língua inglesa no formato PDF ou formato de texto, o documento não é a solução definitiva para acabar com os problemas de acessibilidade, mas ainda sim é muito útil como ponto de partida. Segue abaixo uma tradução livre do documento escrito originalmente por Aaron Cannon.

Você pode fazer o download da lista nos links abaixo ou apenas ler o restante do artigo.

Marcação

  • Separe estrutura de apresentação e use marcação adequada para a estrutura. Exemplo: Use  <ul> e <ol> para listas ao invés de um <br> após cada item.
  • Cabeçalhos do HTML como <h1>, <h2>, <h3> e assim por diante são muito úteis para usuários sem visão. Marque adequadamente as seções da página e o corpo do documento com cabeçalhos semânticos ao invés de fazer outro elemento parecer um título por CSS.
  • Dê títulos descritivos e com significado preciso para as páginas utilizando a tag <title>.
  • Indique o idioma principal do documento usando o atributo lang na tag <html>, também o utilize em outras tags do documento caso apresentarem conteúdo em idioma diferente do principal. Exemplo: <span lang="es">Hola</span> significa Olá.
  • Forneça um link “Pular para o conteúdo” no topo do documento para que seja possível pular toda a navegação indo direto para o conteúdo.
  • Sempre indique cabeçalhos em tabelas usando a tag <th>, e associe todas as células a seus respectivos cabeçalhos.
  • Assegure-se de oferecer uma ordem lógica para a navegação com tecla tab utilizando o atributo tabindex. (Mas se seu código HTML já estiver na ordem adequada não é preciso utilizar este atributo.)

Aparência Visual & Conteúdo

  • Certifique-se que a página continua utilizável com as imagens desabilitadas. (Isso inclui verificar se o contraste continua suficiente para leitura sem as imagens de fundo.)
  • Certifique-se que a página se mantém usável quando o usuário aumenta o texto até duas vezes o tamanho original.
  • Certifique-se que cada elemento na página possa ser alcançado e controlado pelo teclado.
  • Sempre que possível escreva cabeçalhos descritivos e textos de links que podem ser compreendidos fora do contexto (nada de links “clique aqui”).
  • Assegure-se que seu conteúdo tem bom contraste com o fundo, até para usuários daltônicos ou com pouca visão.
  • Não use elementos que pisquem mais de três vezes por segundo.
  • Não esconda o indicador de foco. Quando um usuário usar a tecla tab para navegar deve ficar aparente qual elemento está em foco.
  • Não exija que os usuários percebam fontes, cores ou outros estilos visuais para entender o significado. Nada de “A palavra destacada no parágrafo anterior é a mais importante”, ou “Itens marcados em vermelho são erros e precisam ser corrigidos”, a menos que a palavra ou itens sejam indicados de algum outro modo.

Conteúdo Dinâmico

  • Não use eventos em JavaScript que alterem radicalmente a página ou carreguem uma página inteiramente nova quando acionados.

Imagens e Multimídia

  • Assegure-se que todas as imagens possuam o atributo alt, deixando o texto em branco caso a imagem seja apenas decorativa (ex: alt="").
  • Adicione o atributo alt mesmo que as imagens sejam também links.
  • Seja breve com o conteúdo do atributo alt (ex: “Catedral de Notre Dame”), mas forneça detalhes quando eles derem significado (ex: “Filho em pé com sua mãe nos braços”).
  • Forneça transcrições, legendas e/ou tradução em linguagem de sinais para todo conteúdo de áudio e vídeo com falas.
  • Forneça uma versão descrita de um vídeo quando a descrição é necessária para usuários sem visão entenderem o conteúdo. (O áudio descrito pode ser distribuído com o conteúdo do vídeo ou como um arquivo de áudio apenas.)
  • Certifique-se que todos os vídeos, caso não iniciem automaticamente, tenham um controle de início acessível.
  • Quando o texto pode ser renderizado pelo navegador tão bem como apresentado em uma imagem, evite usar imagens para o texto. (Técnicas de Image Replacement costumam ser uma alternativa aceitável, mas considere também as traduções quando utilizar texto em ou como imagens.)
  • Evite Captchas a não ser que você não tenha alternativa, e mesmo assim ainda tente evitá-los. No entanto se você realmente não tem saída, forneça um Captcha alternativo em áudio.

Formulários

  • Sempre rotule todos os campos de formulários com a tag <label>. Se um campo do formulário não tiver texto específico de rotulo na página, adicione um, e esconda por CSS ou use o atributo title.
  • Use áreas (<fieldset>) com legendas (<legend>) para associar com botões de seleção e caixas de checagem. Exemplo: Um formulário pergunta “Sexo:” e oferece os botões de seleção “Masculino” e “Feminino”, “Sexo:” ficaria em uma tag <legend> e todos os três elementos (a tag <legend> e os dois botões de seleção) ficariam dentro da tag <fieldset>.
  • Identificar todos os erros de valores que foram enviados (indo além de apenas imagens ou ícones), e colocar a notificação de erro próxima ao campo correspondente, ou em destaque no topo da página e com um link para o campo em questão.
  • Forneça links de ajuda ou instruções sobre como preencher os campos quando necessário.
  • Não permita que os usuários completem ações importantes sem confirmação ou possibilidade de desfazerem.
  • Evite utilizar elementos do HTML de formas não semânticas, como elementos de formulários para navegação ou links para envio de formulários.

Testando

  • Valide sua marcação com o validador do W3C. Se sua página não passar no teste pode existir uma boa razão para isso.
  • Teste todas as páginas com simuladores de daltonismo. (Recomendados: Color Oracle e Vischeck.)
  • Teste todas as páginas com um avaliador de acessibilidade, mas apenas após fazer tudo o que pode para assegurar a acessibilidade da página (como seguir estas recomendações).
  • Tenha suas páginas analisadas por um perito em acessibilidade.
]]> http://emanuelfelipe.net/blog/lista-de-checagem-para-acessibilidade/feed/ 0 Cuidado! Este livro pode ser perigoso para a web http://emanuelfelipe.net/blog/cuidado-este-livro-pode-ser-perigoso-para-a-web/ http://emanuelfelipe.net/blog/cuidado-este-livro-pode-ser-perigoso-para-a-web/#comments Wed, 12 Mar 2008 22:00:33 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/cuidado-este-livro-pode-ser-perigoso-para-a-web/ Surgiu recentemente no WaSP a idéia de rotular alguns livros que podem ser perigosos para a web, sejam livros antigos ou com conceitos que vão contra acessibilidade e padrões web.

Existem diversos livros que ensinam a estruturar layouts com tabelas, escrever (X)HTML não semântico, construir sites não acessíveis e criar páginas com código proprietário que funcionam apenas em navegadores sem suporte a padrões.

WaSP Street Team

A idéia é orientar que o livro rotulado não é recomendado e que há uma lista de outros muito melhores indicados pelo WaSP (em inglês). Não é simples livrar as bibliotecas públicas e de instituições de livros ruins, mas cada um pode imprimir os rótulos (em inglês), colocar nas devidas obras e evitar que mais mentes inocentes sejam corrompidas por elas.

O objetivo depende totalmente de pessoas dispostas a participarem, isso torna a idéia um pouco utópica e talvez não gere grandes resultados. Mas não deixa de ser uma iniciativa legal. É possível verificar a participação de algumas pessoas por este grupo no Flickr.

]]> http://emanuelfelipe.net/blog/cuidado-este-livro-pode-ser-perigoso-para-a-web/feed/ 3 Boas vindas ao Email Standards Project http://emanuelfelipe.net/blog/boas-vindas-ao-email-standards-project/ http://emanuelfelipe.net/blog/boas-vindas-ao-email-standards-project/#comments Tue, 04 Dec 2007 17:55:50 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/boas-vindas-ao-email-standards-project/ Baseado na idéia do Web Standards Project surgiu o Email Standards Project, o objetivo é atingir os clientes de e-mail ao invés dos fabricantes de navegadores para que também sigam algumas recomendações importantes.

Email Standards Project logo

Os fundadores colocam que o e-mail em HTML traz mais resultados e oferece uma experiência melhor ao usuário, a importância de estabelecer padrões estaria em criar e-mails com código limpo (assim com carregamento rápido), mais acessíveis e com renderização igual independente de cliente de e-mail.

É um caminho muito longo até que todos os grandes clientes de e-mail se adequem ao Email Acid Test, isso se levarem o projeto a sério. O melhor que podemos fazer para ajudar é divulgar o projeto e apoiar, será um ótimo ganho para a maioria se os objetivos forem alcançados.

Mas o e-mail em HTML ainda me parece bastante distante, ao menos para quem deseja formatações semânticas através de CSS, por enquanto devo me contentar com texto puro, ou então com apenas uma ou duas tags dentro dos e-mails.

]]> http://emanuelfelipe.net/blog/boas-vindas-ao-email-standards-project/feed/ 1 Semântica em abreviações e acrônimos http://emanuelfelipe.net/blog/semntica-em-abreviaes-e-acrnimos/ http://emanuelfelipe.net/blog/semntica-em-abreviaes-e-acrnimos/#comments Wed, 25 Jul 2007 07:06:42 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/semntica-em-abreviaes-e-acrnimos/ A semântica é de extrema importância na web, quando se da um pouco de sentido a informação ela se torna ainda mais poderosa. No caso da internet temos interações entre aplicações, facilidade para achar o conteúdo que procura entre outras inúmeras vantagens. Apesar de dizerem que a Web 3.0 será a web semântica eu prefiro dizer que a nossa web precisa ser semântica.

Apesar de nossas linguagens de marcação ainda serem bem limitadas e estarem evoluindo muito lentamente – XHTML 2 e HTML 5 não me parecem uma realidade muito próxima – existem diversos pontos onde não as aplicamos semântica em nossos documentos atuais, são eles as abreviações e os acrônimos representados pelas tags <abbr> e <acronym> respectivamente.

Sua aplicação é muito simples, sempre que você escrever alguma forma de abreviação em seu documento basta como Av. para Avenida basta colocar em seu código <abbr title="Avenida">Av.</abbr>. Com acrônimos não é muito diferente, quando quiser falar de XML que significa eXtensible Markup Language o código fica <acronym title="eXtensible Markup Language">XML</acronym>.

São coisas simples assim que tornam seu conteúdo mais rico e acessível, quando se acrescenta significado também é acrescentando valor. É seguindo este pensamento que poderemos ter aplicações cada vez mais inteligentes facilitando nossas vidas.

Dica: quem utiliza o Windows Live Writer pode utilizar o Acronyms Plugin, uma mão na roda para não ter que ficar editando código.

]]> http://emanuelfelipe.net/blog/semntica-em-abreviaes-e-acrnimos/feed/ 3 Não me faça digitar WWW http://emanuelfelipe.net/blog/no-me-faa-digitar-www/ http://emanuelfelipe.net/blog/no-me-faa-digitar-www/#comments Mon, 16 Jul 2007 10:13:12 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/no-me-faa-digitar-www/ Conhecendo meus leitores sei que não faz sentido algum explicar o que é WWW, e nem quero falar de conceitos mas sim de algo que me irrita muito: sites cujo os endereços não funcionam sem o deprecado WWW.

Não há motivo algum para digitar quatro caracteres a mais – o ponto também conta – em cada site que eu queira visitar mas ainda sim a maioria das pessoas digita, apesar disto ser problema delas e não meu. Acontece que o problema passa a ser meu também quando tento acessar um gvt.com.br ou tim.com.br e recebo o desagradável erro 404.

Qualquer hospedagem – ou seja lá quem controle o seu domínio – que se preze deve saber lidar com WWWs e a ausência deles de modo que não haja diferença alguma para o usuário. Os donos de sites devem se preocupar também pois escolher um endereço – com ou sem os dablius - para ser o principal é importante em termos de SEO, e é possível – eu diria obrigatório – redirecionar quem acessa pelo outro.

Os exemplos que citei acima são de empresas arrogantes que não se importam em agradar o cliente, em uma inversão de papéis nós clientes que nos tornamos submissos a elas, logo não espero que mudem nem acredito que venham a perder um cliente por esse motivo, mas nem todas as empresas podem se dar ao luxo de desagradar assim. (Espero não ter deixado muito evidente que não gosto da TIM e que a GVT tem um serviço horrível)

E por curiosidade existe até um movimento sobre o assunto, o no-www onde há inclusive dicas de como corrigir esse problema, não entrarei no assunto pois não domino configurações de DNS e servidores web e nem é esse o foco do blog.

]]> http://emanuelfelipe.net/blog/no-me-faa-digitar-www/feed/ 6 Quirks mode e Standards mode: Entendendo os modos de renderização http://emanuelfelipe.net/blog/quirks-mode-e-standards-mode-entendendo-os-modos-de-renderizao/ http://emanuelfelipe.net/blog/quirks-mode-e-standards-mode-entendendo-os-modos-de-renderizao/#comments Fri, 18 May 2007 14:08:53 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/quirks-mode-e-standards-mode-entendendo-os-modos-de-renderizao/ Se você é do período sombrio da web, quando Netscape e Internet Explorer finalmente resolveram implementar o CSS (mesmo que não respeitando padrão algum), não deve ter boas lembraças de como os browsers renderizavam suas páginas. Apenas mais tarde os padrões do W3C ganharam força e os navegadores tiveram de implementá-los.

Netscape Internet Explorer Opera

Surgiu então um problema, com a renderização obedecendo os padrões muitos sites “quebrariam” por serem projetados para navegadores antigos. A solução foi que browsers novos passassem a ter dois modos de renderização: o Quirks mode e o Standards mode, também conhecido por Strict mode (existe ainda o Almost Standards mode, que é uma pequena variação do Standards mode).

Sites antigos continuariam sendo renderizados “corretamente” (do ponto de vista de como foram projetados) através do Quirks mode, que obedece regras sem muito sentido criadas no passado pelos browsers. Enquanto sites novos poderiam usufruir dos padrões criados pelo W3C pois seriam tratados pelo Standards mode. O navegador ficou responsável por escolher o modo apropriado através do Doctype usado (ou ausência de um). Veja uma tabela com possíveis declarações de Doctype e seu resultado em cada navegador.

O Quirks mode hoje é uma dor de cabeça para muitos desenvolvedores, é preciso estar ciente de qual modo de renderização está sendo usado em seu site para evitar problemas “misteriosos”. Muitas vezes o Internet Explorer volta a usar o Quirks mode por detalhes como uma declaração XML ou mesmo um comentário antes do Doctype, se você desenvolve seguindo os padrões isso pode facilmente quebrar seu layout.

(Almost) Standards mode é a melhor opção para seu projeto, embora os browsers novos tenham suporte ao Quirks mode é muito complicado e pouco produtivo trabalhar com ele por não ser realmente padronizado. E mesmo utilizando o Standards mode seu site ainda deve ficar “legível” em navegadores antigos.

Leitura recomendada:

]]> http://emanuelfelipe.net/blog/quirks-mode-e-standards-mode-entendendo-os-modos-de-renderizao/feed/ 3 HTML ou XHTML, qual escolher? http://emanuelfelipe.net/blog/html-ou-xhtml-qual-escolher/ http://emanuelfelipe.net/blog/html-ou-xhtml-qual-escolher/#comments Fri, 04 May 2007 20:52:47 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/html-ou-xhtml-qual-escolher/ Essa é uma questão antiga, muitos gostam de considerar o HTML ultrapassado e usam XHTML por ser “sua versão melhorada”. Esse raciocínio não está errado, mas que a verdade seja dita: seu XHTML provavelmente é interpretado como HTML.

Acha estranho? Quando você declara a seguinte tag: <meta http-equiv="content-type" content="text/html; charset=utf-8" />, está dizendo para seu documento ser interpretado como HTML (por mais que tenha escrito em XHTML).

Não se sita mal, (ainda) não considero viável servir documentos como XHTML real nessa web que está sempre sendo atrasada por alguns. Isso não é motivo para abandonar o XHTML e voltar a escrever HTML, somente para algumas pessoas as quais eu respeito a opinião. É interessante continuar escrevendo e validar seu XHTML, de preferência com o DocType Strict.

Você se educa seguindo as rigorosas normas de criação do XHTML e só tende a ganhar com isso, terá mais chances de escrever um código semântico, limpo e organizado (não que no HTML você não possa, a diferença é que o XHTML praticamente te obriga a isso).

Leitura recomendada: XHTML:

]]> http://emanuelfelipe.net/blog/html-ou-xhtml-qual-escolher/feed/ 4 Trabalhando com Comentários Condicionais http://emanuelfelipe.net/blog/trabalhando-com-comentarios-condicionais/ http://emanuelfelipe.net/blog/trabalhando-com-comentarios-condicionais/#comments Tue, 13 Mar 2007 19:09:30 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/2007/03/13/trabalhando-com-comentarios-condicionais/ Todos que desenvolvem seguindo os padrões do W3C já estão cansados de ver seus trabalhos ficarem ótimos no Firefox, no Opera e outros navegadores com boa adoção dos padrões. Mas quando chega a hora de testar no Internet Explorer quase sempre surgem problemas para resolvermos.

Partindo do ponto que você implementou o design de seu site por CSS as correções para o IE devem ir também na folha de estilos, então você apela para o uso de hacks que impedem seu código de validar e comprometem seu layout em versões futuras do Internet Explorer. E agora?

Agora você pode esquecer aquele monte de hacks e passar a usar comentários condicionais. Eis um artigo em português bem completo falando deles.

O que quero ensinar é a criar uma folha de estilos exclusiva para o Internet Explorer (por exemplo: ie.css) e incluí-la através dos maravilhosos comentários condicionais da seguinte forma:

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="css/ie.css"></link>
<![endif]-->

Lá você poderá realizar todos os ajustes necessários apenas para o IE sem prejudicar a aparência em outros navegadores e muito menos arruinar a validação de seu código.

Mas ainda há um problema, o Internet Explorer 7 já interpreta corretamente alguns valores mas não o suficiente para não precisar de correções. A solução: como seu ie.css não é examinado pelo validador, você pode usar hacks como colocar _ (underline) antes de cada atributo, exemplo:

margin:10px;
_margin:20px;

Nesse caso o Internet Explorer 7 lê o primeiro atributo e ignora o segundo, e as versões anteriores interpretam os dois, mas aplicam o segundo pois sobrepõem o primeiro. Eu gosto de trabalhar assim, sem misturar as gambiarras de compatibilidade com meu CSS principal.

Vale lembrar que novas versões do Internet Explorer tendem a atender melhor os padrões, então utilize os comentários condicionais e hacks com cautela para que isso não venha a quebrar seu layout em versões futuras.

]]> http://emanuelfelipe.net/blog/trabalhando-com-comentarios-condicionais/feed/ 6