Emanuel Felipe .NET 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 http://emanuelfelipe.net/blog/http://emanuelfelipe.net/blog/wp-content/themes/emanuelfelipe/imagens/feed-image.pngEmanuel Felipe .NET Lista de checagem para acessibilidade http://feedproxy.google.com/~r/emanuelfelipe/~3/sCXMHySN47o/ 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 http://emanuelfelipe.net/blog/lista-de-checagem-para-acessibilidade/ 4 motivos para não cobrar menos do que seu trabalho vale http://feedproxy.google.com/~r/emanuelfelipe/~3/oSMhr_QpDr4/ http://emanuelfelipe.net/blog/4-motivos-para-nao-cobrar-menos-do-que-seu-trabalho-vale/#comments Wed, 28 May 2008 12:13:04 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/?p=226 Muitos web designers enfrentam problemas de competitividade na busca por trabalho e acabam optando por cobrar menos sem perceberem que isso pode ter conseqüências desagradáveis, minando a própria carreira. Inspirado neste artigo em inglês e baseado em minhas experiências vou abordar algumas das razões para se ter um cuidado especial com os valores que se cobram.

1. Cobrar menos é ganhar menos

Você pode até ganhar mais se o fato de cobrar pouco te ajudar a pegar mais trabalhos, mas a verdade é que você terá que trabalhar muito mais para ganhar uma mesma quantia que ganharia cobrando preços coerentes. Se o valor de sua hora de trabalho cai é um mau sinal, não se iluda.

2. Prepare-se para clientes desagradáveis

Muitos clientes em potencial não chegarão a você por conhecerem suas habilidades ou experiência mas sim por saberem de seus preços abaixo da média. Esses são os que geralmente não entendem a relação custo versus qualidade e irão pedir algo muito bom por um preço muito baixo.

3. A qualidade de seu trabalho é questionada

Enquanto preços muito baratos podem passar a imagem de serviço de baixa qualidade, preços coerentes podem ajudar na imagem de seu serviço e atrair clientes que valorizem mais seu trabalho (mas que mesmo assim não pretendem lhe dar dinheiro de graça). Outro detalhe é que cobrando pouco você aceita que seu trabalho vale pouco.

4. A qualidade de seu trabalho de fato pode cair

Quando você não está satisfeito com o projeto e o valor que está recebendo pode acabar pensando “com o que estou ganhando não preciso fazer melhor que isso” e acaba entregando algo com qualidade inferior ao seu melhor. Eu já pensei isso e acredito que muitos outros profissionais também.

Conclusão

Saber cobrar valores coerentes é muito mais importante do que parece, algumas das conseqüências de cobrar preços muito baixos são ganhar menos, atrair clientes desagradáveis e prejudicar sua carreira. Prefira ser contratado por suas habilidades e experiência explicando quais soluções pode oferecer e porque vale a pena pagar bem por elas.

Geralmente você só vai conseguir alcançar seus melhores resultados se receber um pagamento justo para isso, sem contar que ser bem pago por realizar bons trabalhos pode fazer muito bem para o ego, algo importante para uma profissão que depende bastante da criatividade.


]]> http://emanuelfelipe.net/blog/4-motivos-para-nao-cobrar-menos-do-que-seu-trabalho-vale/feed/ 8 http://emanuelfelipe.net/blog/4-motivos-para-nao-cobrar-menos-do-que-seu-trabalho-vale/ Cuidado: Anti-spams podem acabar antiusuários http://feedproxy.google.com/~r/emanuelfelipe/~3/ZZuZ0hwKEoI/ http://emanuelfelipe.net/blog/cuidado-anti-spams-podem-acabar-antiusuarios/#comments Mon, 14 Apr 2008 10:46:11 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/cuidado-anti-spams-podem-acabar-antiusuarios/ O spam não é uma praga recente na história da internet, quem utiliza email já sofre com ele há alguns anos e quem desenvolve sites e sistemas sabe que formulários devem ter proteção contra ele. O problema é que muitas das proteções para deter spambots prejudicam também aos usuários.

Como é possível decifrar caracteres em imagens via software, a solução que muitos adotam em seus captchas (imagens com texto aleatório para se redigir) é complicar a imagem com rabiscos e distorções, os resultados são imagens difíceis de decifrar até mesmo por humanos. Veja o exemplo do RapidShare:

Captcha usado no RapidShare

Imagens aleatórias misturadas com o texto complicam bastante a leitura e induzem a erros, mas se sua visão for baixa as coisas podem ser ainda piores. Quem nunca errou várias vezes seguida uma confirmação assim?

Outro problema também bastante sério é a acessibilidade, o cadastro do Windows Live Hotmail tenta contornar este problema dando a opção de ouvir um áudio ao invés de utilizar a imagem:

Captcha com opção de som usado no cadastro do Windows Live Hotmail

Particularmente não ouvi som algum tanto no Firefox como no Internet Explorer, e também se deve levar em conta que este recurso é complexo e de difícil implementação.

É necessário estudar possibilidades que vão alem de combater o spam, que não atrapalhem o usuário quando ele pretende cadastrar-se, entrar em contato por um formulário ou postar um comentário. Existem soluções mais humanas e inteligentes para barrar o spam.

Fazer perguntas simples que qualquer um seja capaz de responder é uma alternativa que vem se espalhando principalmente em blogs. Veja uma lista de perguntas muito utilizadas:

  • Quanto é 2 + 2?
  • O Fogo é quente ou frio?
  • A chuva é seca ou molhada?

As possibilidades são inúmeras. Mas lembre-se de informar ao usuário a razão desta pergunta (impedir o spam), uma nota ao lado ou por perto resolve. O problema desta solução é que não tem utilidade para sites muito visados por spammers, se tiverem interesse em atacar exclusivamente a ele fica fácil quebrar esta proteção.

Outra solução bastante inteligente e complexa é o uso de Honeypots, neste caso armadilhas voltadas a detectar spambots. Na web podem ser campos escondidos que apenas um bot preencheria facilitando a identificação de spam sem exigir nada do usuário. Um exemplo seria:

<label for="campo">
Isto é um Honeypot, esconda-o por CSS e avise que deve ficar em branco
</label>
<input type="text" name="campo" id="campo" />

Se o campo receber algum dado provavelmente será spam. Mas este método assim como o anterior é fácil de ser quebrado se seu site é um alvo exclusivo.

Não existe solução definitiva de combate ao spam, não é possível detectar automaticamente todos, mas com as medidas certas podemos barrar uma boa quantidade deles e não prejudicar o usuário. Soluções simples como perguntas e honeypots são as melhores opções para a maioria dos sites, apenas os mais visados como RapidShare e Windows Live Hotmail ainda dependem do velho captcha.


]]> http://emanuelfelipe.net/blog/cuidado-anti-spams-podem-acabar-antiusuarios/feed/ 1 http://emanuelfelipe.net/blog/cuidado-anti-spams-podem-acabar-antiusuarios/ Cuidado! Este livro pode ser perigoso para a web http://feedproxy.google.com/~r/emanuelfelipe/~3/JeatJuX2sNA/ 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 http://emanuelfelipe.net/blog/cuidado-este-livro-pode-ser-perigoso-para-a-web/ 403day – Uma péssima iniciativa http://feedproxy.google.com/~r/emanuelfelipe/~3/A1B4O-BMLkY/ http://emanuelfelipe.net/blog/403day-uma-pessima-iniciativa/#comments Sat, 23 Feb 2008 18:57:12 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/403day-uma-pessima-iniciativa/ O 403day é uma péssima iniciativa que está circulando pela internet, a idéia é que no dia 4 de Março de 2008 os desenvolvedores bloqueiem o acesso via Internet Explorer em seus sites. Não passa de uma idéia infeliz de desenvolvedores que não pensam em seus usuários.

O Internet Explorer é sim uma pedra no sapato dos desenvolvedores, mas o que se pede é no mínimo absurdo. Bloquear visitantes que usem o IE é tão ridículo quanto um site não funcionar no Firefox ou Opera, e aposto que não sou o único que odeia quando isso acontece.

O usuário não tem culpa alguma se o navegador que veio instalado por padrão em seu sistema operacional atrapalha nosso trabalho, então qual a razão de descontar a raiva nele? Não crucifiquem as pessoas erradas.

Simplesmente não sigam esse movimento, existem outras maneiras mais inteligentes de ajudar como convencer amigos e familiares a trocarem seus navegadores, ou até mesmo fazer propaganda do Firefox em seu site ganhando comissões do AdSense.


]]> http://emanuelfelipe.net/blog/403day-uma-pessima-iniciativa/feed/ 4 http://emanuelfelipe.net/blog/403day-uma-pessima-iniciativa/ Quem lembra do Joost e seus convites? http://feedproxy.google.com/~r/emanuelfelipe/~3/Cdv7WnELn3Q/ http://emanuelfelipe.net/blog/quem-lembra-do-joost-e-seus-convites/#comments Mon, 10 Dec 2007 00:58:54 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/quem-lembra-do-joost-e-seus-convites/ Após causar muitos comentários entre blogs do mundo todo, e fazer com que pessoas ficassem loucas atrás de um convite para experimentar o beta, será que o Joost emplacou? Parece que não.

Não há dúvidas que a idéia dos convites fez a popularidade do programa decolar, mas parece que ele não foi capaz de agradar muito. Reclamaram que havia pouco conteúdo disponível e a qualidade também não ajudava muito, particularmente mal consegui assistir alguns minutos de qualquer programação que escolhesse.

É importante fazer seu produto conhecido, mas após isso ele deve agradar o usuário. O contrário acontece com muitas distribuições de linux e algumas aplicações que originam do sistema do pinguim, como o Miro (antigo Democracy), que eu concordo quando ele diz ser melhor que o Joost.

Apenas me pergunto quem ainda usa o Joost, ou então se existem pessoas que preferem o Joost mesmo após conhecer o Miro.


]]> http://emanuelfelipe.net/blog/quem-lembra-do-joost-e-seus-convites/feed/ 4 http://emanuelfelipe.net/blog/quem-lembra-do-joost-e-seus-convites/ Boas vindas ao Email Standards Project http://feedproxy.google.com/~r/emanuelfelipe/~3/NW4jEiILNLk/ 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 http://emanuelfelipe.net/blog/boas-vindas-ao-email-standards-project/ Modelo de Briefing http://feedproxy.google.com/~r/emanuelfelipe/~3/M_XiRoURsbQ/ http://emanuelfelipe.net/blog/modelo-de-briefing/#comments Mon, 26 Nov 2007 20:53:03 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/modelo-de-briefing/ O briefing é uma etapa importantíssima do desenvolvimento web, suas informações possibilitam os desenvolvedores a criarem produtos que atendam as expectativas dos clientes e principalmente, que gerem bons resultados.

Meses atrás coloquei em prática a idéia de criar um modelo de briefing em modo colaborativo, convoquei desenvolvedores através da WD Design e uma boa quantidade se ofereceu a ajudar. Mas infelizmente não houve resultado positivo, alguns dias depois o documento estava esquecido.

Olhando aquele documento totalmente desestruturado e abandonado resolvi reestruturá-lo para então compartilhar aqui já que pode ser útil para alguns leitores. Não existe modelo de briefing que atenda as necessidades de todos, portanto sinta-se a vontade para modificar ou utilizar apenas algumas partes deste documento.

Minha única recomendação é não tornar o documento muito extenso, não é muito vantajoso fazer seu cliente responder um formulário imenso e cansativo.


]]> http://emanuelfelipe.net/blog/modelo-de-briefing/feed/ 29 http://emanuelfelipe.net/blog/modelo-de-briefing/ Site nos padrões não significa site bom http://feedproxy.google.com/~r/emanuelfelipe/~3/SN1QS8RSEUA/ http://emanuelfelipe.net/blog/site-nos-padres-no-significa-site-bom/#comments Mon, 05 Nov 2007 02:52:22 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/site-nos-padres-no-significa-site-bom/ Desenvolver sites seguindo fielmente as recomendações do W3C (que agora tem um escritório no Brasil) e trabalhando com tecnologias de última geração são argumentos muito utilizados por agências e desenvolvedores mais antenados, mas apesar de serem pontos importantes, nenhum deles garante o sucesso de uma página na web.

Antes de pensar nas tecnologias a serem utilizadas em um projeto é necessário compreender qual a solução que o projeto deve oferecer, seja ampliar os negócios de uma loja vendendo também pela internet, oferecer um serviço que facilite a vida do usuário ou uma infinidade de outros objetivos possíveis. O desenvolvimento deve ser focado em soluções antes de tecnologias.

Uma maneira efetiva de alcançar este objetivo é investir em usabilidade, facilitar ao máximo a vida do visitante é aumentar as chances de se obter resultados positivos. Design bom não é algo bonito (visto que beleza é relativa), design bom é aquele fácil de usar e que passa a imagem desejada.

Ao desenvolver um projeto concentre-se em criar soluções que atinjam os objetivos do cliente ou da iniciativa. Documentos em XHTML válidos e uma aplicação construída com Ruby on Rails podem facilitar para os desenvolvedores, mas pouca diferença fazem para o usuário ou seu cliente.


]]> http://emanuelfelipe.net/blog/site-nos-padres-no-significa-site-bom/feed/ 8 http://emanuelfelipe.net/blog/site-nos-padres-no-significa-site-bom/ Pense nas possibilidades ao exibir dados http://feedproxy.google.com/~r/emanuelfelipe/~3/7252EpJI2Gg/ http://emanuelfelipe.net/blog/pense-nas-possibilidades-ao-exibir-dados/#comments Wed, 24 Oct 2007 15:34:48 +0000 Emanuel Felipe http://emanuelfelipe.net/blog/pense-nas-possibilidades-ao-exibir-dados/ Hoje me deparei duas vezes seguidas com o mesmo erro, uso de plural para descrever o número um. Primeiramente o popular Rec6 se esqueceu de um detalhe em seu contador de votos: caso o artigo contenha apenas um voto (que é a contagem inicial após ser enviado), mas o que mais me surpreendeu foi a segunda ocorrência que estava na página inicial da Apple, onde dizia 1 hours, veja você mesmo:

Página inicial da Apple contendo 1 hoursPágina inicial do Rec6 com 1 votos

Frequentemente vejo erros semelhantes na contagem de comentários de alguns blogs, e com o WordPress isso é muito fácil de ser resolvido. A Template Tag comments_number possui parâmetros diferentes para três casos: nenhum comentário, um comentário e n comentários. Uma solução elegante com sua utilização seria comments_number('Nenhum Comentário', '1 Comentário', '% Comentários'); em seu tema.

Erros como estes podem resultar em um ponto negativo na credibilidade do site e até mesmo quebrar o layout. É sempre importante examinar todas as possibilidades de exibição e tratá-las adequadamente com instruções condicionais.


]]> http://emanuelfelipe.net/blog/pense-nas-possibilidades-ao-exibir-dados/feed/ 0 http://emanuelfelipe.net/blog/pense-nas-possibilidades-ao-exibir-dados/