Esta é a forma como a especificação DOM define um “DOM”:

O Document Object Model (DOM) é um Application Programming Interface (API) para HTML válido e documentos XML bem formatados. Ele define a estrutura lógica dos documentos e o modo como um documento é acessado e manipulado.

Em outras palavras, o DOM é uma forma padrão para permitir que as linguagens de programação interajam com documentos HTML / XML. O W3C fornece, o que é chamado de linguagem de vinculações, para o ECMAScript. Isto significa que as funcionalidades definidos na especificação DOM foram implementadas nessa linguagem.

ECMAScript é uma “uniformização” da língua (script) dos “homens das cavernas” – Netscape JavaScript e Microsoft JScript para que todos os browsers possam compreender instruções escritas usando o ECMAScript.

Agora, existem três grandes “dialetos” do ECMAScript: JavaScript (Firefox / Chrome / Safari), JScript (IE), e ActionScript (Adobe Flash / Flex). Estes são chamados dialetos como suporte a código escrito antes da normalização e fornecem alguns recursos não disponíveis no ECMAScript ou em outros dialetos.

Os navegadores fornecem uma implementação das interfaces do DOM que permite ECMAScript (ou dialetos suportados) interagirem com o DOM de um documento XML/HTML. Assim, a maioria dos browsers decentes, lançado conforme os padrões, dizem qual ECMAScript é suportado para cada versão do seu navegador.

O DOM de uma página HTML tem uma “árvore-como estrutura” quando visualizadas. É importante notar que o DOM não representa o conteúdo do HTML, mas representa apenas objetos através dos quais o conteúdo pode ser acessado. Esses objetos são modelados após a marcação que existe na página HTML. As relações, funções, comportamentos e atributos desses objetos são identificados pelo DOM.

Bom, é isso! Você normalmente não precisa de saber sobre interfaces DOM principalmente se você trabalhar com uma biblioteca JavaScript. Mas se você estiver interessado, Quirksmode (http://www.quirksmode.org) tem uma excelente introdução ao DOM.

Se você não é desenvolvedor deve se perguntar nesse momento:

“- Eu não sou desenvolvedor, devo me perguntar nesse momento se preciso mesmo saber sobre meta tags?”

Bom, sim e não.  Você não precisa necessariamente saber onde aplica-las no código, mas tem que saber como funcionam e para que servem pois pode existir um campo específico para isso no seu publicador.

Existem algumas dúzias de meta tags que se pode usar no código mas, uma vez que a proposta é não sair do básico do SEO, vamos falar somente das mais importantes nessa série de textos. Aliás, vamos falar uma coisa que pouca gente aborda em textos sobre SEO: em geral as pessoas dão enfase à aplicação, enquanto aqui pretendo falar o real porquê  de usa-las de forma x ou y.

Palavras Chave – Keyword

As keywords são declaradas no topo das páginas e servem basicamente para enfatizar para nossos amigos buscadores sobre o que estamos falando no nosso texto. Há muitos e muitos anos, quando as estrelas eram jovens e Yahoo e Cadê já eram antigos, elas foram o principal campo de consulta dos robots de pesquisa. No código aparecem similar a isto aqui, dentro das tag de head:

<meta name="keywords" content="festa,sandices,quadrinhos" />

A relevância das palavras chave não é mais tão importante quanto já foi por causa dos espertinhos da Web: o camarada ia lá nas keywords dele e lançava “Sabrina Sato pelada, putaria, bunda”.  Daí o buscador ia lá todo feliz fazer a classificação e entregava o resultado pro usuário e, este último, frustrado, descobria que o texto era sobre coleções de selos do século 20 ao invés da referida moça desnuda.  Quem perdia credibilidade nessa história? O buscador, é claro.

Mas aí? Vale a pena usar?

Mas mesmo com essa falta de crédito, o uso bem feito de keywords pode ajudar um pouco na relevância da sua página. Tenha em mente que as palavras usadas nas keywords devem estar contidas no texto, se possível mais de uma vez ou, se não for o caso, ser um sinônimo ou estar estritamente correlacionada ao assunto em questão. Mesmo que você monte um set de palavras que pareçam favorecer o texto, tenha em mente que a má escolha delas pode detonar o seu posicionamento no buscador – logo, se não tiver certeza que aquelas são as melhores escolhas, PREFIRA NÃO USAR NENHUMA KEYWORD. Keywords que não tenham nenhuma ou que tenham pouca conexão com o texto prejudicam ao invés de ajudar.

Exemplo: você escreveu um texto sobre sorvete de jaca e em algum momento disse “seria legal que a Kibon lançasse o sorvete de jaca”.  “Sorvete” e “jaca” seriam palavras importantes como keyword, já Kibon, sendo citado uma única vez no texto e sem nenhuma informação relevante além da menção,  se usada como palavra chave seria a âncora que afundaria tua página por posições e mais posições – afinal, você disse pro buscador que seu texto era relevante sobre isso, ele acreditou, e te classificou na seção “textos relevantes da kibon” e não no “textos relevantes sobre sorvete de jaca”, que era seu assunto principal.

Reciclagem de keywords pode?

“-Entendi, tio Vespa. Posso então escolher as mesmas 5 keywords fodonas e pô-las em todo meu sáite?”

NÃO! Keywords repetidas em várias páginas é como dizer que todo seu site é uma imensa redundância, mesmo que isso não seja verdade. Se o site não tem uma forma rápida de “taguear” todas as páginas, use a regra do não usar nada ou aplique palavras chave apenas no que for conteúdo novo. Você pode usar a mesma palavra várias vezes, mas nunca no mesmo conjunto. Se numa pagina você usou “água, fogo, terra” na próxima poderia usar “água, fogo, ar” que não teria problema – mas nunca “água, fogo, terra” pra duas ou mais.

Outro ponto importante é a quantidade de keywords usadas, evite usar mais do que 5. Muitas keywords poluem o código e caem na regra que citei no texto anterior, “se todo mundo é especial então ninguém é especial”, mandando a relevância pro brejo.

Alguns sistemas, em especial blogs, tem aproveitado a capacidade de gerar tags dos publicadores para reaproveitar o tagueamento nas Keywords. Já vi gente que defende que essa reciclagem não é boa – buscadores são entidades ariscas e não gostam de redundância, ainda mais se for na mesma página. Eu discordo disso por um fato muito simples: keywords são palavras texto, simples, separados por vírgula, enquanto as tags são as mesmas palavras mas com um fatorzinho diferente: elas estão linkadas, logo não estão totalmente redundantes, estão complementando informação já citada – então acredito que não seja algo realmente prejudicial, embora acredite que seja melhor variar um pouco a informação de uma e de outra por questão de aumentar abrangência.

Bom, creio que a respeito de Keywords é o que há de principal a se falar. No próximo episódio falaremos a respeito de meta description. Até!

A palavra “Deficiente visual” é abrangente demais – podemos falar de daltônicos, míopes (que é meu caso, por exemplo), hipermétropes, fotofóbicos e etc, e não é objetivo falar sobre tudo isso nesse artigo. Logo, acho que usar a palavra “cego” (que não vejo por onde possa ser ofensiva) define muito bem o tipo de usuário com o qual estamos preocupados.

Por que essa preocupação? Veja bem, isso não é “bondade”, diria até que está mais para uma obrigação. Além, é claro, de permitir igual acesso ao máximo de pessoas possível, lembre-se que é mais um recurso que pode aumentar o número de usuários e, por consequência, fideliza-los.

Internet acessível

Há toda uma gama de recursos atualmente que auxiliam pessoas com necessidades especiais a ter acesso à internet. Estes aparatos podem variar de simples varinha para auxiliar pessoas com movimentos restritos até complexos hardwares para cegos-surdos que convertem textos para braile.

No caso específico dos cegos, o recurso mais comum é o Screen Reader – que nada mais é do que um programa que converte palavras para áudio. Infelizmente, segundo um vídeo no Webaim, percebe-se a grande maioria dos websites não é escrito de forma que possa ser facilmente compreendido por estas ferramentas.

Acessibilidade: por onde começar?

Acima de tudo, acessibilidade tem em seu princípio a regra de ouro de qualquer programa ou aplicação web, a regra KISS! (Keep it simple, stupid! – ou em tradução livre “mantenha isso simples, estúpido!”). Quanto mais robusto e simples o seu código, melhor a qualidade do texto “narrado” pelo Screen Reader. Evite usar scripts complexos no corpo da página, gambiarras que sujem o código (em especial POGs de crossbrowser) e atributos desnecessários.

Seu site precisa ser navegável via teclado

Um cego nunca usará o mouse para navegar uma vez que ele não teria como saber onde posicionar o cursor, o que o obriga a navegar basicamente usando o TAB e enter do teclado. Pode parecer estúpido citar isso aqui uma vez que, à primeira vista, parece um pensamento óbvio – mas é fato que são poucos os desenvolvedores e designers param e pensam a respeito das implicações que isso traz para a interface, tanto no design quanto na construção html/css.

Linearidade

Quando construir a página certifique-se que todo o conteúdo está disposto de forma linear, de forma que com o css desabilitado o texto esteja sequencial. Muitas vezes, por questão de facilitar o alinhamento crossbrowser, é comum inverter dois boxes de posição e ajusta-los via css. Isso faz com que o Screen Reader leia boxes de forma invertida também.

O melhor teste para ver se a linearidade está correta é desabilitar o css do Browser e checar como o texto se alinha na página – o ideal é que os boxes fiquem um abaixo do outro.

Vá direto ao ponto

Esta é a coisa mais simples que pessoas poderiam fazer para melhorar a acessibilidade de um site e que infelizmente não é difundida o suficiente: ao montar a página coloque no topo um link “ir direto para o conteúdo” e linka-lo à uma ancora no ponto que o texto começa. Este link não necessariamente precisa ter visual, ele pode ser escondido de forma que só é acessivel pelo screen reader. Dica: eu não tenho certeza se os screen readers mais modernos entendem quando o bloco está com “display:none”, então, por via das dúvidas, uma sugestão de código para esconder este link é o seguinte:

.escondeLink {

position:  absolute;

display:block;

margin-top:  -4000px;

}

Repare que desta forma você não “apagou” o link da página, somente tirou-o da área visual do browser.

O ideal para aplicação desta ancora é que ela esteja logo após a abertura da tag BODY. Um exemplo de como deve ser usado pode ser visto no próprio http://www.webaim.org .

Outra preocupação para não ter problema com os robôs do google, é fazer uma indicação explícita que esses links não devem ser indexados, já que as âncoras podem ser interpretadas como uma nova URL:

<a rel="nofollow" href="http://afronteirafinal.com#conteudo">
A Fronteira Final
</a>

Cuidado com chamadas nos links e comandos JavaScript

Esta regra é similar à aplicada a SEO: evite criar links que não deixem claro seu destino. Evite ao máximo “clicando aqui”, “clique”, etc.

Sempre dê preferência por ser específico, usando coisas como por exemplo “Conheça o site A Fronteira Final” à “Conheça o site a fronteira Final clicando aqui“. Cegos e buscadores agradecerão por este simples cuidado.

Outra coisa a respeito dos links é que eles TEM QUE APONTAR PARA ALGUM LUGAR. Evite chamar funções javascript nos links pois isso tende a confundir os Screen Readers e outros softwares de interpretação. E lembrando: dependendo da forma como o comando JS responde, pode ser que ele iniba a navegação via teclado.

Efeitos OnMouseOver e OnMouseOut

Só para enfatizar o tópico anterior, eventos relacionados a ações do mouse estão entre os grandes vilões da acessibilidade. Tenha sempre em mente que estes dois comandos ou qualquer outro evento relacionado diretamente à captura de mouse devem ser descartados se afetarem a navegação via teclado ou proporcionarem qualquer tipo de informação que só possa ser assimilada de forma visual.

Alt nas imagens

Outra regrinha que também vale para SEO: sempre coloque a descrição correta nas imagens do seu site de forma clara e concisa. Escrever “Circo” ao invés de “Foto do Cirque du Soleil em apresentação no Morumbi” é algo que pode fazer muita diferença quando você não tem a referência visual.

Cor/imagem como informação

Evite ao máximo usar qualquer informação que dependa de cor, imagem ou animação para compreensão plena do texto. Se não houver como escapar, tente criar algum recurso textual (alt, legenda, um parágrafo falando o que é o signo acima) que amenize ao máximo este problema. Tente usar este tipo de recurso apenas no ambito da estética.

Tabelas e formatos especiais

Evite a todo custo tabelas complexas. O Screen Reader vai tentar le-la da esquerda para a direita, ficando difícil de compreender o tipo de conteúdo que ela contém.

Outro cuidado é com formatos diferenciado como os Microformatos. Pode usar sem medo, desde que os Microformatos sejam aplicados de forma correta.

Tabelas, quando necessárias, devem ser escrita de forma semanticamente correta para que o Screen Reader, evitando qualquer confusão para a interpretação de Screen Readers ou qualquer outro recurso. Veja o exemplo abaixo:

<table><caption>texto</caption>
<thead>
<tr>
<th> texto</th>
<th> texto</th>
<th> texto</th>
<th> texto</th>
</tr>
</thead>
<tfoot>
<tr>
<th> texto</th>
<th> texto</th>
<th> texto</th>
<th> texto</th>
</tr>
</tfoot>
<tbody>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
<tr>
<th> texto</th>
<td>texto</td>
<td>texto</td>
<td>texto</td>
</tr>
</tbody>
</table>

Outro formato que merece cuidado é o formulário, que deve ter todos os campos, labels e teclas de acesso nos lugares corretos.

<form id="form" method="post" action="#">
<fieldset>

<legend>Dados pessoais</legend>
<label for="nome">Nome</label>
<input id="nome" name="nome" type="text" title="Nome" alt="Nome" tabindex="1" accesskey="n" />
<label for="email">E-mail</label>
<input id="email" name="email" type="text" title="E-mail" alt="E-mail" tabindex="2" accesskey="e" />
</fieldset>
<fieldset>

<legend>Destinatário</legend>
<label for="departamento">Selecione o departamento</label>
<select id="departamento" name="departamento" title="Departamento" tabindex="3">
<optgroup label="Departamento 01">
<option value="nomefunc01" title="Nome do funcionário 01">Nome do funcionário 01</option>
<option value="nomefunc02" title="Nome do funcionário 02">Nome do funcionário 02</option>
</optgroup>

<optgroup label="Departamento 02">
<option value="nomefunc01" title="Nome do funcionário 01">Nome do funcionário 01</option>
<option value="nomefunc02" title="Nome do funcionário 02">Nome do funcionário 02</option>
</optgroup>
</select>
</fieldset>
<fieldset>
<legend>Mensagem</legend>

<label for="mensagem">Escreva sua mensagem</label>
<textarea id="mensagem" name="mensagem" cols="100" rows="10" title="Escreva sua mensagem" tabindex="4" accesskey="m"></textarea>
<input id="enviar" name="enviar" type="submit" value="Enviar" title="Enviar" alt="Enviar" tabindex="5" accesskey="s" />
</fieldset>
</form>

Para saber mais

Seguindo essas regras simples a qualidade do seu site aumentará bastante mas, como em tudo que se relaciona com internet, é um assunto “saco sem fundo”, daqueles que quanto mais você estuda mais tem a estudar. Alguns sites para procurar mais informação à respeito:

http://www.webaim.org/ – citado duas vezes no texto, é uma organização focada em acessibilidade e possuí material vastíssimo sobre o assunto.

http://brasilmedia.com/Acessibilidade-na-Web.html – A Brasil Média pegou parte do material do Webaim e verteu para o português.

http://www.acessibilidadelegal.com/ Um bom site em português também, mas este com produção própria de artigos. Vai um pouco mais fundo nos tópicos levantados neste artigo.

http://www.w3c.br/index-3dez-1.htm – Quer entender como um cego navega? A W3C lançou um hotsite que simula esta experiência.

http://imasters.uol.com.br/artigo/12814 – Ótimo artigo de Horácio Soares sobre como realizar os testes de usabilidade, com vários links e referências de programas, validadores e sites com orientações valiosas.

Padronização para elementos comuns em sites

Qual a vantagem real disso? Um desenvolvedor esperto perceberá que, usando ou criando os devidos plugins, a extração e conversão de dados para qualquer formato em uma página é muito mais fácil. Um exemplo interessante disso é o hCard, que permite puxar e exportar dados cadastrais ou eventos em um formato reconhecível por qualquer gerenciador de e-mails  (seja online, seja um outlook da vida).  Num futuro pode-se até pensar em browsers que já venham com funções nativas voltadas que use este tipo de recurso, valendo-se de APIs como o Google Maps ou o Yahoo Maps, por exemplo.

E claro, como toda padronização, ela auxilia na usabilidade,  pois facilita a vida de vários “interpretadores” (screen readers, browsers, aplicativo Air, etc) na forma de usar a informação fornecida.

Melhora na qualidade para indexadores de busca

Não encontramos dados do quanto de relevância os buscadores estão a dar para os microformats, embora tanto o Google quanto Yahoo já tenham anunciado suporte. De qualquer forma, o fato dos algorítimos de busca interpretarem qualquer coisa como texto (mesmo que sejam tags), já indica que os microformatos por si só são “alimentadores de relevância” por natureza.

Um exemplo que pode ser visto é este:  quando realizamos uma esta busca no Google, um dos resultados apresentados (o terceiro, logo abaixo do título) já possui quantidade total de reviews a respeito do estabelecimento procurado.  Isto é possível graças ao hReview que, como o proprio nome sugere, serve para destacar uma opinião sobre um produto, serviço ou quaquer outra coisa.

Humanamente “entendível”

Ao contrário de outros formatos de proposta similar, os microformats tem como conceito ser primeiro compreensível por seres humanos e somente depois por máquinas.  A sintaxe é muito mais intuitiva, mais simples de compreender e memorizar. Acredito que essa é de longe sua principal vantagem sobre o RDFa, por exemplo, que não só é um código mais complexo como ainda por cima possui uma série de padrões diferenciados. Outra vantagem sobre RDFa é que os microformatos permitem ao desenvolvedor a escrever BEM menos código, mantendo uma sintaxe simples, limpa e totalmente intelígivel para qualquer outra pessoa que mexa no código depois – mesmo que não familiarizada com estas definições (no futuro pretendemos entrar novamente no assunto RDFa x microformatos, agora não é o momento).

Aplicável ao HTML 5, XHTML 2

As próximas versões de HTML e XHTML tem, entre outras propostas, aplicar para a web do futuro o conceito de Web Semântica (aquela história de que toda informação deve ser um ‘pacote completo’ de dados e referências, manja?), o que vai suprir parte da necessidades propostas pelos Microformats. Embora muita gente já esteja usando estas definições, a web ainda não está pronta para lidar com eles – Por que não usar os microformatos, que não impactarão em absolutamente nada na codificação e já são aceitos e usados? Ele não conflitará em absolutamente nada com HTML 5 ou XHTML 2 e, de lambuja, ainda ajudará os buscadores a indexar e classificar seu site de forma bastante precisa.

Problemas com microformats

Em 2008 a BBC renunciou ao uso dos microformatos por conta do formato hCalendar. Este formato cria um problema de acessibilidade por usar a tag abbr como marcador e não como uma abreviação propriamente, o que confunde boa parte dos screen readers. Num contexto normal, ela seria usada assim:

<abbr title="Organização Mundial de Saúde">O.M.S</abbr>

Um screen reader habilitado para ler siglas por extenso leria este trecho como “Organização Mundial de Saúde”.

No caso do hCalendar, a tag é usada da seguinte forma:

<abbr title="20070312T1700-06">March 12, 2007 at 5 PM</abbr>

O screen reader não leria como data,  mas sim  “Vinte milhões, sete mil e trezentos e 12 TÊ mil e setecentos traço zero seis”.  Já existe um fix para isso sugerido pela própria Microformats.org (que são os pais da criança), usar span no lugar de abbr.

Até onde testamos e pesquisamos este foi a única problema registrado. Usamos o FANGs para emular a acessibilidade para deficientes visuais.

Mas é só isso?

Por enquanto sim. O assunto é extenso demais para ser tratado num único post – num futuro não muito distante voltaremos a ele e nos aprofundaremos em pontos mais específicos. Enquanto isso não ocorre, a lista abaixo fornece uma bela gama de coisas para brincar. Divirta-se!

Microformatos – Referências

http://microformats.org – site oficial do projeto. Todas referências, exemplos, geradores automáticos, wiki e lista de discussão estão lá.

http://en.wikipedia.org/wiki/Microformat – tópico na wikipédia, a informação técnica resumida.

https://addons.mozilla.org/pt-BR/firefox/addon/4106 – Operator, ADD-on do firefox que detecta e importa dados de microformatos. Tem alguns problemas ainda, mas já dá uma bela visão de usos.

https://addons.mozilla.org/pt-BR/firefox/addon/402 – FANGS: um emulador de screen reader. Infelizmente, após a atualização do Firefox para a versão 3.5 ele perde a compatibilidade. Espero que resolvam logo este problema, estava usando-o para uma pesquisa de acessibilidade.

http://www.semanticfocus.com/blog/entry/title/microformats-vs-rdf-how-microformats-relate-to-the-semantic-web/ – Artigo que aprofunda-se um pouco na discussão a respeito do formato RDFa vs Microformats.

http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippets.html – mostra a implementação feita pelo google para o formato hReview

http://www.google.com/search?q=Drooling+Dog+BarBQ – Link para a busca com o resultado do google.