Falamos sobre a Acesso Digital e respondemos a várias perguntas do Eduardo sobre Acessibilidade na web. Falamos algumas coisas também sobre acessibilidade em geral, mas a ênfase foi realmente na web.

Rolou também alguma coisa sobre padrões web, semântica e outras coisas relacionadas.

Falamos bastante (até um pouco demais, eu diria) e, mesmo assim não conseguimos responder a todas as perguntas que estavam na pauta, mas o podcast ficou bem interessante e vale à pena dar uma conferida.

Escute o podcast em “Acessibilidade e padrões web com Bruno e Maq” no Tudo que eu quero saber.

Mas, o que é uma Jornada de conhecimento?

Segundo o site do evento, é:

[um] Programa híbrido composto de:

[1] um dia presencial intensivo com imersão total no tema da jornada, explorando seus conceitos básicos, principais questões e experiências;

[2] fórum de discussão na web, coordenado pelo(s) instrutor(es), para aprofundamento do tema através de trabalhos, pesquisas e casos de interesse dos participantes.

A Jornada sobre Acessibilidade na web vai ser apresentada pela equipe Acesso Digital (sem a presença deste que vos fala — recentemente reintegrado à equipe — por causa da triste incapacidade de estar em dois lugares ao mesmo tempo): Horácio Soares, Leda Spelta e MAQ.

Você pode ver os detalhes na página sobre o evento.

Isso mesmo, os caras vão criar uma aplicação, desde o projeto até o design e programação, usando MySQL, Python, HTML, CSS, JavaScript/AJAX, SVN e outras coisas mais, em um evento de um dia, que vai ajudar você a entender como trabalha uma equipe super produtiva de desenvolvimento web.

E se você comprar um curso online de acessibilidade até o dia 16 de agosto, você garante a sua vaga pro CodeShow, inteiramente e completamente de graça, sem pagar um centavo a mais por isso.

E, claro, não é só isso. Em geral, ao comprar o curso online, você tem acesso à apostila, tira dúvidas por email e online (via skype) por 15 dias. Acontece que o curso está passando por um processo de expansão e vamos incluir vídeos, mais exemplos práticos e exercícios e, se você comprar o curso agora, no período promocional, vai ter seu acesso liberado por mais 15 dias assim que o novo material estiver pronto.

Melhor que isso, meu amigo, nem facas ginsu.

Ah, e eu vou estar presente no CodeShow e, se o pessoal deixar, vou dar algumas dicas sobre acessibilidade na aplicação que será desenvolvida.

E é isso. Vai lá e compra o curso de acessibilidade e nos vemos no CodeShow, dia 17 de agosto, às 9h da madrugada, se eu conseguir acordar.

É a essa pergunta que estamos tentando responder neste vídeo, que será foi lançado dia 24, quinta-feira, no SENAC Rio (Veja maiores detalhes).

Ainda não falei nada sobre a Acesso Digital por aqui. Acesso Digital é um grupo formado há pouco mais de um ano, por conta de uma concorrência para reformulação de um site de uma grande empresa. Perdemos a concorrência, mas o grupo continuou em frente, com o intuito de estudar, divulgar, fomentar e implementar a acessibilidade na web brasileira.

A idéia é prestar serviços diversos relacionados à acessibilidade, como análise, desenvolvimento, capacitação e consultoria e mostrar que, cada vez mais, acessibilidade não é altruísmo e que apesar de ter, sim, um lado social muito importante, é economicamente viável e deve ser considerado por todos que quiserem fazer negócios pela web.

Infelizmente, por alguns problemas, como falta de tempo, estou temporariamente afastado do grupo, atuando apenas como consultor em projetos. Espero mudar isso em breve e voltar a me envolver mais com estas pessoas que me ensinaram tanto e com quem já passei agradáveis momentos e, claro, alguns “arranca-rabos” eventuais.

Um dos passos para mostrar a importância da acessibilidade foi a produção deste vídeo, que apesar do amadorismo dos atores (como atores, claro), foi produzido por profissionais com uma qualidade muito acima do que imaginávamos conseguir.

Aliás, cabe aqui um parêntese. Fazer um vídeo desse tipo não é nada fácil. Você tem, sim, que decorar suas falas, repetir sabe-se lá quantas vezes cada tomada, aguentar um spot de luz de sei lá quantos watts esquentando sua cara. Mas, no fim das contas, o resultado vale muito a pena. Tenho hoje um respeito especial pela profissão de ator…hehe

O vídeo conta com as “atuações” de MAQ, Leda Spelta, Horácio Soares e deste que vos fala.

Abaixo o trailer do vídeo completo, com legendas, para você ter uma idéia do que se trata assistir. O lançamento oficial será nesta foi quinta-feira, 24 de março, com direito a apresentação, mesa redonda e participação da equipe Acesso Digital e diversos profissionais da área. Infelizmente, não vou poder pude comparecer.

O vídeo foi produzido pelo João e pela Eliane, da 30 Frames. Veja o vídeo no UOL Vídeos e a página sobre o vídeo no site da Acesso Digital.

E isso não beneficia apenas os cegos, usuários de leitores de tela, como muitos pensam. Muitos grupos de usuários têm dificuldades sérias ou total impossibilidade de usar o mouse. Além dos cegos, pessoas com problemas de coordenação motora, mal de parkinson, paralisia cerebral, e até mesmo usuários de alguns dispositivos móveis. Isso para citar apenas alguns.

Juntando-se esses grupos, temos uma quantidade muito grande de usuários e clientes em potencial — idosos, por exemplo, entram em alguns desses grupos, e estão em número cada vez maior — que podem estar deixando de comprar seu produto ou consumir a informação que você publica porque seu site requer o uso do mouse para funcionar de maneira satisfatória.

Um recurso que frequentemente causa problemas àqueles que não podem — ou até mesmo não querem, por que não? — usar o mouse são os famosos menus dropdown.

A maioria das técnicas para criação de menus dropdowns hoje em dia usa apenas CSS para os browsers de verdade e um pouquinho de JavaScript para o IE6. Técnicas como a suckerfish, por exemplo, muito popular, por ser simples e por ter sido publicada no A List Apart, funcionam dessa maneira.

Basicamente, criamos listas não-ordenadas aninhadas. Ou seja, um submenu é marcado como uma lista dentro de um item de lista. Esses submenus são escondidos via CSS e só são exibidos quando se passa o mouse por cima do item de menu que o contém.

<ul id="menu">
<li><a href="/">Início</a></li>
<li><a href="/servicos">Serviços</a>
<ul>
<li><a href="/servicos/design">Design</a></li>
<li><a href="/servicos/prog">Programação</a></li>
</ul>
</li>
</ul>

Este código acima representa a marcação típica de um menu dropdown moderno. O CSS, sem grandes formatações seria mais ou menos assim:

ul{ list-style:none; }
#menu li {
float:left;
position:relative;
}
#menu li ul {
display:none;
position:absolute;
top:0.9em;
left:0;
margin:0;
padding:0;
}
#menu li:hover ul { display:block; }

Este código criaria um menu dropdow funcional (feio demais, mas funcional) nos browsers mais modernos, como Firefox, Opera, Safari e IE7. Como já disse, para o IE6 seria necessário um pouco de JavaScript, mas não vou colocar isso aqui. Vejam o suckerfish para entender como funciona.

O que nos importa aqui é o fato de que este menu dropdown é funcional apenas se o usuário estiver usando um mouse. Além do submenu nunca ser exibido para aqueles que estão navegando com o teclado, os itens desse submenu são removidos do índice de tabulação (tabindex) da página e nunca se chega a eles usando a tecla tab (ou qualquer outro recurso).

Mas, como resolver isso, você me pergunta. Bem, usando apenas HTML e CSS, creio que não haja nenhuma solução. Pelo menos não que eu conheça (se conhecer alguma, me conte, por favor).

Porém, usando-se JavaScript, é possível fazer com que os submenus sejam exibidos usando-se apenas o teclado.

Você pode querer argumentar que, ora, estamos falando de acessibilidade, como você vem agora querer me enfiar um JavaScript goela abaixo? O fato é que, na maioria das situações onde esse menu ficaria inacessível via teclado, o usuário tem o JavaScript habilitado no browser.

Pense comigo, só vamos ter problemas caso o browser do cara tenha suporte a CSS. Ou seja, estamos falando de browsers gráficos. São muito poucos os casos onde há suporte a CSS e não há suporte a JavaScript. Isso, praticamente, só ocorre quando o usuário deliberadamente desabilita o JavaScript ou usa o modo de segurança alta do IE, por exemplo.

Browsers de texto (lynx ou webvox, por exemplo) vão sempre exibir os submenus, por motivos óbvios. Dispositivos móveis, salvo raras excessões, não vão interpretar a propriedade display do CSS, portanto, também vão exibir os submenus.

Sendo assim, podemos usar o JavaScript como recurso para habilitar o uso dos menus dropdown para a quase totalidade de nossos usuários. Lembrem-se, 100% é apenas uma meta, raramente (praticamente nunca, na verdade) factível.

Como seria esse script? Bem, se não houvesse o IE (e estou falando do IE7 também, neste caso), seria muito, muito simples. Algo assim:

<script type="text/javascript">
var lis = document.getElementsByTagName('li');
for (var i = 0, li; li = lis[i]; i++){
li.onfocus = function(){
var ul = this.getElementsByTagName('ul')[0];
if (ul)
ul.style.display = 'block';
}
li.onblur = function(){
var ul = this.getElementsByTagName('ul')[0];
if (ul)
ul.style.display = '';
}
}
</script>

Ou seja, quando uma LI que contiver uma UL receber o foco, o submenu é exibido. Ao perder o foco, o menu é escondido novamente. Simples, não? Porém, o IE existe e é o líder do mercado, e é usado por grande parte dos usuários de leitores de tela também. Portanto, esse script só resolve uma parte do problema.

No IE não há o evento onfocus para itens de lista. Portanto, para que nosso menu funcione no IE — e, claro, continue funcionando nos outros browsers –, precisamos fazer com que o submenu apareça quando o link do item do menu de primeiro nível receber o foco e que desapareça quando o último link do submenu perder o foco. Vejam:

<script type="text/javascript">
var lis = document.getElementsByTagName('li');
for (var i = 0, li; li = lis[i]; i++){
var link = li.getElementsByTagName('a')[0];
if (link){
link.onfocus = function(){
var ul = this.parentNode.getElementsByTagName('ul')[0];
if (ul)
ul.style.display = 'block';
}
var ul = link.parentNode.getElementsByTagName('ul')[0];
if (ul){
var ullinks = ul.getElementsByTagName('a');
var ullinksqty = ullinks.length;
var lastItem = ullinks[ullinksqty - 1];
if (lastItem){
lastItem.onblur = function(){
this.parentNode.parentNode.style.display = 'none';
}
lastItem.parentNode.onblur = function(){
this.parentNode.style.display = '';
}
}
}
}
}
</script>

Sim, o código está longe de ser elegante, mas você pode melhorá-lo na hora da implementação. O fato é que funciona.

Vejam um exemplo (com um pouquinho a mais de CSS pra melhorar levemente a aparência).

Com uma medida muito simples, conseguimos melhorar a experiência de uso de nossos sites para um número bastante grande de usuários. Agora você não tem mais motivo para dizer que seu submenu não funciona com o teclado. Vamos lá, é muito simples pra você deixar de fazer.

Há uma implementação de menus dropdown completamente acessível feita pelo Brothercake. Chama-se Ultimate Dropdown menu e é bem completo, suporta vários níveis de menu, etc. Vale a pena conferir.

Conhece uma maneira mais fácil de fazer a mesma coisa? Achou algum erro no meu código? Vamos conversar.

PS: A falta de identação nos códigos de exemplo é cortesia do Zoundry (que é excelente, apesar desse pequeno problema). Alguém aí sabe como fazer essa identação? Não, a identação que ele tem, usando blockquote não serve.

Esta funcionalidade de zoom foi primeiro implementada pelo Opera (de repente me parece que tudo que há de interessante nos browsers modernos foi inventado pelo Opera…) e o efeito é muito mais agradável e efetivo do que simplesmente redimensionar o texto e deixar o layout da página quebrar, se for o caso.

Para quem não sabe do que estou falando, explico: ao dar um zoom em uma página, todos os elementos daquela página (incluindo as imagens) são redimensionados na mesma proporção, mantendo assim o design intacto, além de possibilitar que textos pequenos em imagens possam ser lidos sem problemas. Claro, o design é mantido intacto até certo ponto, porque fatalmente uma hora as coisas vão ficar grandes demais para caber confortavelmente na tela.

Com o Internet Explorer 7 aderindo a esse, chamemos assim, “movimento”, acende-se uma luz no fim do túnel para os designers que se preocupam com acessibilidade nas páginas que criam. Se todos os browsers se comportassem dessa maneira, não precisaríamos mais nos preocupar em usar unidades relativas de tamanho de fonte, por exemplo.

Claro, isso não é coisa pra daqui a uma semana, já que a migração para uma nova versão do Internet Explorer não é feita da noite para o dia por todos os usuários e, como bem sabemos, nem todos os usuários vão realmente migrar para a última versão. Portanto ainda teremos que nos preocupar em fornecer aos usuários uma maneira simples de redimensionar os textos, caso não consigam ler confortavelmente a página.

Porém, o maior problema é que o Firefox, que é o meu browser favorito e que tem tido um crescimento bastante grande nos últimos tempos, não tem a funcionalidade de zoom. E eu acho que é hora de mudar isso.

Se o pessoal da microsoft conseguiu fazer isso com o internet explorer, que é notoriamente um browser cheio de falhas, o pessoal da mozilla consegue, com certeza, fazer a mesma coisa, com o pé nas costas. Por que não?

Então, fica aqui a minha súplica para o pessoal que cuida do desenvolvimento do Firefox: implementem a opção de zoom em páginas web. Não precisa ser a única opção, pode-se manter o redimensionamento apenas de texto para aqueles que o prefiram. Mas é importantíssimo ter o zoom como opção. E digo mais, é mais importante ainda ter essa funcionalidade estampada na cara do usuário, sem que ele tenha que descobrir teclas de atalho ou itens escondidos no menu. O modelo usado pelo IE7 é um bom começo, com botõezinhos bem destacados na barra de status.

Vamos lá, Mozilla, o IE não pode ficar à frente do Firefox em nada. Aproveitem que a implementação deles não é 100%, já que gera barras de rolagem indesejáveis, e façam uma implementação ótima, se possível, melhor que a do Opera (ok, acho que não é possível, mas…).

E vocês, concordam que o zoom é mais interessante que o redimensionamento de texto? Não? Por quê? Acho que isso precisa ser discutido.

Na época, o FIR foi levado à fogueira e deixou de ser recomendado pelos especialistas no assunto, pois o artifício de se esconder o conteúdo de um SPAN usando display:none esconderia o conteúdo também de leitores de tela, notadamente do JAWS, um dos mais (talvez o mais) usados leitores de tela do mundo.

Como leitores de tela são extremamente difíceis de usar por pessoas que enxergam e como tinha gente importante dizendo que isso funcionava assim e ponto e que tinham testado e etcetera e tal, nunca me preocupei em verificar com minhas próprias mãos (e ouvidos) se isso era realmente verdade.

Acontece que estou desenvolvendo um site para um português, que é cego. Ele me pediu que, em algumas partes do site, usasse uma função em JavaScript para alternar um determinado conteúdo (estilo toggle). Como os conteúdos são pequenos, não precisei usar nada de AJAX, simplesmente deixá-los carregados (e escondidos) no HTML e, de acordo com a ação do usuário, esconder um elemento e mostrar outro. Simples assim.

Fui na onda de que o display:none iria esconder o conteúdo do JAWS…e me dei mal.

O cliente insistia em me dizer que o lance não funcionava e eu não entendia porque. Segundo ele, o leitor de tela (sim, o JAWS) estava lendo todo o conteúdo, mesmo o que deveria estar escondido.

Peguei um café e comecei a pensar. O que poderia estar errado?

Simples, o JAWS ignora, sim, um determinado conteúdo escondido via display:none, a não ser que você declare este display:none apenas para mídias visuais (screen, por exemplo).

Veja bem. Em geral, quando aplicamos uma folha de estilos CSS a um HTML, esquecemos de declarar a(s) mídia(s) (ou media type) a que este CSS deve ser aplicado. Exemplo: <link rel="stylesheet" type="text/css" href="/c/estilo.css">

Usando o código acima, o estilo será aplicado independente da mídia. Se ela tiver suporte a CSS, este será aplicado. Ponto.

O mesmo aconteceria caso usássemos: <style type="text/css">@import url(/c/estilo.css);</style>

O código acima costuma ser usado por aqueles que desejam que seu CSS seja ignorado por browsers antigos, como o Netscape 4, por exemplo.

Só que faz tempo que uso outro artifício para esconder meus CSS das velharias (já que o método acima pode causar o que chamamos de FOUC). Declaro dois media types, separados por uma vírgula e um espaço. Assim: <link rel="stylesheet" type="text/css" href="/c/estilo.css" media="screen, projection">

E era isso que eu estava usando no site a que fiz referência acima. Retirei os media types e, voilà, o JAWS passou a ignorar o conteúdo escondido pelo display:none.

Claro, não quero dizer que você não deva declarar media types ao aplicar um CSS a uma página. Longe disso. O lance é criar um outro CSS, apenas com os display:none que devam ser interpretados por leitores de tela e aplicar ao conteúdo sem declarar a mídia. (Preciso verificar se funcionaria usando a mídia aural).

Se alguém tiver disposição e condições de testar isso em outros leitores de tela, por favor, me conte os resultados para que eu publique aqui como referência.

Voltando ao FIR, acho que ele continua não sendo uma boa forma de image replacement. Não porque torne o conteúdo inacessível para leitores de tela, mas por outros motivos, como não funcionar em situações onde haja suporte a CSS e não haja suporte a imagens.

Moral da história: por mais que especialistas te digam que alguma coisa é assim e ponto final, é sempre bom dar uma olhadinha e fazer os testes você mesmo para verificar. Eles podem estar errados, mesmo que seja apenas em parte.

É indiscutível a importância do W3C e das tecnologias desenvolvidas e recomendadas por seus membros desde o início da web.

Porém, de uns tempos pra cá, eles têm realmente pisado feio na bola. Não em tudo, mas em pontos vitais, fundamentais para que a web continue evoluindo.

Esses pontos são, principalmente:

Acessibilidade

Joe Clark escreveu, há 3 meses, no a list apart, um artigo em que mostra como o WCAG 2 é falho em diversos aspectos. Principalmente pelo fato de não requerer mais que uma página, para ser considerada acessível, utilize código semântico e válido.

Isso no meio de tantos outros problemas, que tornam o WCAG 2 simplesmente impossível de se aplicar no mundo real.

Além disso, mostra como o processo de desenvolvimento de uma especificação é burocrático e até mesmo — o que é uma baita surpresa quando se trata de um grupo (o WAI) totalmente dedicado a acessibilidade — inacessível para pessoas com alguns tipos de deficiência, como cegos e surdos, por exemplo, cujas presenças e opiniões deveriam ser considerados de suma importância nas reuniões e conferências durante o processo de desenvolvimento do WCAG.

Como ele disse, o processo é falho, quebrado, e, dessa forma, é impossível que o resultado tabém não seja.

Marcação e validação de código

O Zeldman, velho conhecido de quem trabalha com padrões web, abriu a discussão mais recente sobre o W3C, comentando a saída de um membro do grupo de QA do consórcio.

Tanto o texto do Zeldman quanto o email de despedida do Björn Hörmann (o membro em questão), mostram falhas terríveis do W3C em manter o desenvolvimento e o funcionamento de ferramentas importantíssimas como o validador de HTML, e em ouvir o que dizem e pedem os desenvolvedores (tanto os mais “distantes” como eu e você quanto os mais “próximos”, envolvidos no desenvolvimento de tecnologias em diversos grupos dentro do W3C).

Björn relata que, em diversos casos, não há conversação entre dois grupos distintos, e isso torna o processo de verificação e garantia de qualidade praticamente impossível.

O maior problema é que parece que isso acontece nos grupos de trabalho que cuidam do desenvolvimento de linguagens de marcação e das ferramentas de validação, ambos de suma importância para todo e qualquer desenvolvedor web do mundo.

***

Há outros problemas. Mas as duas área acima e seus problemas são os que mais me interessam, portanto vou ficar apenas nelas.

O fato é que pessoas influentes têm sistematicamente exposto e discutido falhas muito graves do W3C. Falhas de organização, falhas técnicas, falhas de comunicação.

Se o W3C não trabalha em prol dos desenvolvedores, bem, qual o papel do W3C então? Por que devemos seguir padrões criados, mantidos e recomendados por uma organização que, ao que parece, tem trabalhado mais em favor dos interesses de grandes corporações — que injetam dinheiro no consórcio — do que em favor de quem faz e consome a web?

Claro que não estou dizendo que devemos parar de nos preocupar com semântica, ou que devemos voltar ao tempo dos layouts feitos com tabela, ou desenvolver tudo com flash, java e afins. Apenas que o W3C não é supremo e inquestionável. Não podemos abaixar a cabeça e dizer amém a tudo que eles produzem e recomendam. É preciso avaliar cada caso.

E não é de hoje que tem gente descontente com os rumos tomados pelo W3C. E isso tem sido extremamente saudável, pois, de alguma forma foi esse descontentamento que fez com que fossem criados grupos de desenvolvimento “alternativos”, como o WHATWG e o pessoal dos microformatos.

O WHATWG (que tem o Ian Hickson como editor) trabalha no que, já há algum tempo, eu acho que é a nossa linguagem de marcação do futuro: O Web Applications 1.0, também conhecido como HTML5 ou XHTML5.

Não vou entrar em detalhes sobre o HTML5 aqui, não é esse o propósito do artigo. Basicamente o HTML5 é uma extensão ao HTML e ao DOM, que adiciona diversas funcionalidades interessantes para o desenvolvimento de aplicações web. Você pode ver algumas demonstrações simples do que pode ser feito com o HTML5. Alguns deles (o “Repetition model” e o “datetime”) já são implementados pelo Opera 9.

Prometo que em breve escreverei em um artigo meus motivos para acreditar que o HTML5 (e não o XHTML 2) é a linguagem de marcação que vamos usar daqui a alguns anos.

E os Microformatos (cujo principal nome é Tantek Çelik), como já discutimos no podcast #8 do BlogBits, são uma opção pé-no-chão para transformar a web de hoje em uma web semântica, usando o conhecimento que já temos hoje.

Ao invés de esperar pelo W3C, esses dois grupos meteram a mão na massa, criaram seus próprios padrões, padrões aplicáveis no mundo real e, principalmente, no mundo de hoje.

Fiquemos de olho. Abaixo vão alguns links que você deve seguir para saber mais sobre o W3C e seus problemas:

• Jeffrey Zeldman – An Angry Fix
• Eric Meyer – Angry Indeed
• Molly Holzschlag – Angry, Not: Zeldman, Meyer, and Fair Concerns About the W3C
• Joe Clark – To Hell with WCAG 2
• Björn Hörmann – Leaving W3C QA Dev
• Molly Holzschlag – Misplaced Anger: A Rebuttal to Zeldman’s Criticism of the W3C
• mark Pilgrim – W3C and the Overton window
• W3C QA Weblog – A Peaceful Ear

Por quê? Porque quando você torna o seu site acessível você está simplesmente maximizando a exposição do seu produto e/ou serviço. Pensar em acessibilidade não é ser bonzinho, é enxergar no público não-padrão e com necessidades especiais, potenciais consumidores para o que você está vendendo.

No fim das contas, quem ganha mais com acessibilidade não são os cegos, daltônicos, deficientes em geral, usuários de dispositivos móveis, etc. Quem ganha mais é você, que vai passar a ter um público imensamente maior e mais diverso que antes.

Quando se fala em acessibilidade, a maioria das pessoas pensa nos cegos. E muita gente tem a noção — errada, claro — de que cegos não compram, por exemplo, livros, televisões, quadros, ingressos para cinema ou teatro ou qualquer outro produto que seja essencialmente ou primariamente visual. Isso é uma tremenda besteira. Primeiro porque produtos, como no caso da televisão, primariamente visuais, são sim utilizados por pessoas cegas, ora por que não? E produtos essencialmente visuais, como livros (excetuando-se os escritos em braile, claro), podem não ser utilizados por eles, mas isso não impede que comprem para dar de presente, por exemplo.

E, bem, isso falando apenas das pessoas cegas. Além delas, quando fazemos um site, temos que pensar em outros tipos de usuários. Usuários de dispositivos móveis, por exemplo.

Imagine que um potencial cliente para o seu produto entre no seu site e tente, inutilmente, efetuar uma operação de compra. O que ele vai fazer? Mandar um email pra você pedindo encarecidamente que você o considere como consumidor? Bem, ele pode até fazer isso, mas não encarecidamente e não sem antes ter dado uma bela banana pra você e comprado o produto no site do concorrente.

Portanto, pessoal, vamos começar a nos preocupar com acessibilidade, mas de uma maneira diferente. Não nos sentindo altruístas por estar incluindo um público marginalizado na web, mas sim sendo inteligentes para enxergar que quanto mais gente acessa um site, maiores as chances deste cumprir o seu objetivo, seja ele vender, informar, fazer propaganda ou outro qualquer.

E não vale o velho argumento de que ninguém acessa o meu site via PDA ou celular. Ninguém acessa porque você não deixa. Abra a porta e veja quanta gente está sentada na soleira esperando para entrar no seu estabelecimento digital.