• Fácil de usar: o uso da interface deve ser intuitivo, com recursos de fácil reconhecimento e elementos que não dificultem a navegação, leitura, interpretação, clique, etc.
• Fácil de aprender: uso de termos, ícones, padrões de interface e recursos de ajuda que possibilitem novos usuários reconhecer e facilmente aprender como utilizar a interface. Consistência é fundamental neste quesito.
• Fazer com que o usuário não cometa erros: neste quesito entram entram dicas, ajuda, validação, boas mensagens de erro e outros recursos que possam prevenir a ocorrência de erros e ajudar o usuário na correção dos mesmos.

Mas, na prática, como podemos implementar estes princípios? Neste artigo apresento algumas dicas simples de usabilidade que podemos praticar efetivamente durante o rotina de desenvolvimento do HTML e do CSS.

Facilitando a leitura com line-height

Um espaçamento adequado entre linhas permite que as pessoas possam ler um texto com maior facilidade e mais rapidamente. O espaçamento não pode ser muito reduzido, pois pode deixar o texto “amontoado”, nem muito extenso, caso contrário as pessoas terão dificuldade de encontrar a próxima linha.
Particularmente recomendo utilizar espaçamento de 1.5 relativo ao tamanho da fonte, ou seja, se você utilizar fonte de 12px, o espaçamento entre as linhas será de 18px. No CSS, controlamos o espaçamento entre linhas com o

.

Utilize margins e paddings para distinguir itens

Espaços em branco entre os elementos da página podem ser usado a favor da usabilidade e também da arquitetura de informação do seu site. Creio que muitos já devem ter passado pela situação de alguém falar o seguinte a respeito de um site que você fez: “Ah, mas esse conteúdo X não tem a ver com o Y? É porque estava tudo junto então achei que tinha a ver”.
Os espaços entre itens permite identificar quais elementos estão relacionados e quais são distintos. Portanto, utilize

e/ou

mais generosas para afastar elementos que sejam distintos e aproxime os elementos que estejam relacionados, evitando erros de interpretação e mesmo de utilização de alguns recursos presentes na página. Isto serve principalmente para:

• Estabelecer relação entre títulos e texto
• Identificar rótulo de formulário e o campo a qual ele se refere
• Imagens e o respectivo conteúdo textual
• Páginas que tenham múltiplos formulários ou outros recursos com botões de ação que possam fazer com que o usuário clique em um determinado botão pensando ser relativo a outro recurso

O logo deve ser clicável

Por uma convenção que foi sendo consolidada ao longo do anos, os usuários tendem a clicar no logotipo para retornar à página inicial e é frustrante quando isso não ocorre, pois já é uma ação que o usuário espera ao clicar no logo. Independente do logo ser uma imagem ou um background dentro de uma outra tag, deve-se colocar um link para a página inicial do site.

Textos que não são links não devem ser sublinhados

Atualmente, nem todo link precisa estar sublinhado para transmitir a ideia de link, mas todo texto sublinhado ainda transmite a ideia de link. É intuitivo o usuário clicar em uma palavra sublinhada esperando acessar uma página (imagine então se, além de sublinhado, o texto estiver em azul, como já vi em alguns lugares). Portanto, é aconselhável que, para dar ênfase em palavras nos textos, sejam utilizadas as tags

,

que já têm essa função.

Atributos “alt” e “title” para imagens

O atributo

para a tag

tem a função de fornececer um texto alternativo caso a imagem não seja carregada ou caso um browser leitor de tela esteja analisando o conteúdo da página. Por isso, é importante que este texto tenha uma boa descrição sobre o conteúdo da imagem. Mas em algumas imagens é interessante que ela não somente tenha um texto alternativo, mas que também exiba uma dica descritiva da imagem ao passar o mouse sobre ela. Isto é muito útil, por exemplo, ao utilizar ícones que indiquem ações, status ou representem link para algum conteúdo sem o uso de um texto descritivo junto à imagem. Para isso, podemos utilizar o atributo

do HTML.

Associando label à campos de formulário

A tag

serve para associar um rótulo a um campo de formulário. Mas muitos desenvolvedores esquecem de realizar essa associação através do atributo

, que deve remeter ao

do campo de formulário.
A principal vantagem dessa associação é permitir que o usuário selecione o campo do formulário ao clicar no

, o que facilita muito especialmente no caso de campos do tipo

ou

, pois aumenta a região clicável, ajuda diminuir o tempo e a chance de erros para selecionar estes campos.

Destaque o campo ativo do formulário com :focus

Quando um usuário estiver preenchendo um formulário, ele deve perceber claramente em qual campo está inserindo os dados, pois somente mostrar o cursor dentro do campo pode não ser suficiente.
Para isso, pode-se utilizar a pseudo-classe

no CSS para o seletor de

, que possibilita aplicar um estilo ao elemento quando ele recebe foco para receber dados do teclado, como uma borda mais espessa ou de outra cor e um background diferenciado, como no exemplo abaixo:

/* Campos no estado normal possuem um background neutro e uma borda clara */
input.text, select, textarea
{ background: #FFF; border: 1px solid #999; }

/* Campos no estado :focus possuem um background diferenciado e uma borda de maior destaque */
input.text:focus, select:focus, textarea:focus
{ background: #FFC; border: 2px solid #D8A561; }

A usabilidade possui muitos outros critérios a serem trabalhados durante todo o processo de desenvolvimento de uma interface para a web, mas no dia-a-dia podemos melhorar a experiência do usuário através de pequenos detalhes.

Posts Relacionados

• Experiência deve ter começo, meio e fim
• O que é Usabilidade?
• Convertidos do Tableless
• Bem vindo a Xangri-lá – Parte 2
• Vote no Especialista em Usabilidade para Presidente

Graceful Degradation e Progressive Enhanced

Procurar querer dar uma boa experiência para todos os dispositivos utilizados pode se tornar um problema, já que a variação de aparelhos e hardware é muito maior quando comparado com o mundo dos desktops.
Sabemos que, para um site normal, é seguro ter uma largura de 990px. Sabemos que com essa largura, o site vai ficar bem diagramado em diversas resoluções, começando em 1024.
Mas nos aparelhos móveis não temos essa métrica. A variação dos tamanhos das telas é muito maior. Os aparelhos e a forma de uso de cada um são muito diferentes.

Eu não gosto de nivelar os sites por baixo. Pelo menos não hoje. Há muitas possibilidades de fazermos um bom trabalho de user experience, mas não o fazemos, porque há alguns perfis de usuário, que infelizmente temos que prever no escopo. Por isso sou a favor do Graceful Degradation e do Progressive Enhanced.

Fornecer a melhor experiência possível para todas as camadas de usuários. Esse é o alvo para a utilização do Graceful Degradation e do Progressive Enhanced. 
Se nivelarmos o visual e as funcionalidades do site/sistema por baixo, iremos prejudicar demais os usuário “de alto escalão”. Para entender melhor, imagine um usuário de Safari Mobile acessando um site customizado para Internet Explorer Mobile.

Versionamento Especifico

Já é prática antiga criar versões dos sites para um sistema, aplicação ou dispositivo específico. Fazíamos isso na guerra dos browsers e fazemos isso hoje para alguns browsers antigos. Versionar um site é uma das saídas mais simples para resolver um grande problema. Como a quantidade de dispositivos de acesso está crescendo, a necessidade de haver uma versão do site para estes dispositivos é mais que normal. O HTML é uma linguagem feita para que seja acessada por diversos meios. Hoje, os meios de acesso são bem escassos, consigo pensar apenas em Desktops e Aparelhos de mão (celulares e smartphones). Você consegue pensar em mais alguns outros?
Embora não sejam maioria, os consoles estão aumentando sua presença online. Aparelhos como XBOX e Playstation estão se tornando cada vez menos restritos para jogos, e estão indo muito além do que poderíamos imaginar um dia. O XBOX já anunciou sua integração com Facebook e Twitter. Embora este tipo de acesso seja ainda muito limitado e controlado pelas fabricantes dos consoles, imagine, como seria a experiência de acessar a internet que temos hoje por um Playstation ou XBOX. Eu acharia sem graça. É uma interface totalmente diferente da comum. Mesmo se tentássemos levar a mesma experiência atual com os desktops para estes dispositivos, na minha opinião, estaríamos subutilizando-os.
A mesma coisa pode acontecer com aparelhos como o Surface da Microsft. Eu não imagino um usuário abrindo um navegador como o Firefox, IE ou Opera no Surface e utilizando-o para navegar na internet como fazemos hoje. Não encaixa. É algo diferente, mais interativo, divertido. E atenção aqui: quando digo interativo, não estou querendo dizer que tudo deverá ser feito com Silverlight ou Flash, pelo contrário. O HTML 5 e o CSS 3 estão vindo para acabar com esse mito.

Também não estou dizendo que talvez você fará uma versão dos seus sites para cada novo dispositivo que aparecer. Pelo contrário. Estou dizendo que eles serão necessários de acordo com o público de cada site, e de cada negócio.

Até hoje os desenvolvedores e também os donos de sites, tem uma dificuldade muito grande em criar ou decidir se é útil ou não desenvolver uma versão dos sites para mobiles. Imagine quando a cartilha de meios de acesso aumentar.

A Globo.com e também outros grandes sites enfrentam o mesmo problema: decidir quem vai e quem fica. Decidir qual aparelho será priorizado e qual receberá apenas uma versão de texto.
Claro que com o tempo, as limitações de cada aparelho serão mínimas e as características de cada um serão bem parecidas. Isso diminuiria muito o trabalho de desenvolvimento e aumentaríamos a quantidade de acesso, pelo simples fato de que estaríamos dando quase que a mesma experiência para uma quantidade maior de dispositivos.

Outro ponto importante, mas consolador, é que há motores de renderização muito bons hoje em dia. Vide Gecko e Webkit. Ambos de código livre e que recebem sugestões e modificações do mundo inteiro. Por exemplo, os aparelhos da Nokia e também o Chrome utilizam o Webkit como base para seus softwares de acesso. Isso faz com que consigamos manter o controle de nosso desenvolvimento e nos dá uma visão melhor de todo o horizonte de possibilidades.

Você, como desenvolvedor, tem a obrigação de viver um pouco mais além. Não pense que iremos escrever HTML e CSS para todo o sempre. E mesmo que for, serão linguagens totalmente diferentes de como as conhecemos hoje.

Conhecendo os browsers e seus motores

Os browsers estão ainda muito longe de melhorar a forma com que lidamos e navegamos com a web. Nenhum deles trouxe nos últimos anos uma inovação capaz de fazer com que melhoremos nossa experiência online. Eles ainda estão engatinhando muito e parte da culpa não é deles. O W3C se mostrou muito lerdo nos últimos 11 anos. Eles acordaram muito tarde para as reais necessidades dos desenvolvedores. A comunidade por sua vez, sacudiu todo o W3C, tomando a iniciativa e começando um novo evanlegismo em pról do HTML 5 e do CSS 3. Isso fez com que o W3C entendesse melhor o que os desenvolvedores precisavam para que a web inteira fosse privilegiada.
Os browsers por sua vez, aproveitaram toda essa mudança, e começaram uma nova guerra, em silêncio. O suporte aos Padrões dos principais browsers do mercado está invejavelmente avançada. Há browsers como o Internet Explorer que sempre serão atrasados, mas que felizmente estão acordados também para as novas atualizações do mercado.

Mesmo assim, acho que o foco não se deve dar em browsers específicos, acho que nossa atenção deve ser voltada para os Motores de Renderização. Hoje, os principais são:

• Gecko
  Motor com código aberto. É utilizado nas aplicações da Mozilla: SeaMonkey, Camino, Firefox, Thunderbird etc. Gecko é um motor herdado do antigo Netscape, baseado no Mosaic.
Depois da Guerra dos Browsers, a Netscape doou o motor de renderização para a comunidade, que culminou na criação da Mozilla.
  
• Presto
  Motor proprietário da Opera Software. A Opera é uma das empresas que mais inovam no mercado de browsers. Embora eles tenham tecnicamente um dos melhores browsers para desktops, a versão mobile é a mais utilizada. Eles tem duas versões: Opera Mobile, para smartphones e Opera Mini, para celulares mais básicos. A Opera também está muito presentes em outros mercados fora da web.
• Webkit
  Motor com código aberto, é utilizado hoje em aplicações como Safari, Safari Mobile e Chrome, browser do Google.
É o mais novo motor de renderização do mercado. Foi criado pela Apple, baseando-se no motor de renderização KHTML, que estava só presente em browsers para Linux, como o Konqueror. Aproveitando que o KHTML é um sistema OpenSource, a Apple modificou todo o seu código, fazendo melhorias e aperfeiçoando-o para criar seu browser o Safari. 
A Apple fez várias outras modificações posteriores em cima desta primeira versão. Deu o nome de Webkit, e hoje, conduz o desenvolvimento dessa plataforma.
• Trident
  É o motor proprietário da Microsoft. É utilizado em aplicações como Outlook e claro, no Internet Explorer. Eles estão criando um novo motor, que é utilizado no Internet Explorer 8 e posteriores.
Embora o Trident fora o primeiro a suportar completamente a primeira versão do CSS, atualmente ele é o motor de renderização mais atrasado. A Microsoft vem fazendo um bom trabalho para tentar recuperar essa má fama, mas mesmo assim, os outros motores do mercado estão muito além.

Quando conhecemos o motor de renderização dos browsers, e sabemos quais suas limitações, não precisamos nos preocupar com a quantidade de browsers criados. O Google lançou o seu browser chamado Chrome, baseado em Webkit. Embora fosse um novo browser, isso não deveria assustar os desenvolvedores, já que é o mesmo motor utilizado no Safari. Logo, a renderização dos dois é muito parecida. Não é uma preocupação a mais, pelo contrário.
A mesma coisa se aplica aos browsers para mobiles dos sistemas da Nokia e também do iPhone. Ambos utilizam Webkit para renderizar as páginas. Isso dá liberdade para a criação de interfaces mais elaboradas, tornando a experiência de usuário mais interessante em dispositivos móveis.

Já o Internet Explorer, com seu motor de renderização se mostra um inimigo dos desenvolvedores. Embora a Microsoft esteja trabalhando arduamente em um novo código, as versões antigas deste motor ainda assombra a muitos desenvolvedores. E infelizemente, em alguns projetos, precisamos dar um passo para trás por conta da massa de acessos feitos por este motor.
A mesma história se aplica para a versão do Internet Explorer Mobile. O suporte crítico aos Padrões Web faz com que os aparelhos com este sistema se tornem obsoletos quando se trata de experiência online.

Entenda a importância dos motores de renderização. Eles tem um papel fundamental no comportamento do mercado e faz com que avancemos no desenvolvimento web.

No final tudo dá certo. Ou não.

A web está passando por uma transação infinita. A cada dia ela ganha mais foco na mídia, mais atenção das empresas, tanto grandes, quanto pequenas. Sempre que um novo dispositivo é criado, um novo nicho de usuários surge, com novas maneiras e costumes de navegação. É impossível agradar a todos. Por isso é importante estabelecer prioridades. Um bom caminho é ajudar no desenvolvimento e compartilhamento de sistemas que ajudam a web a avançar. “Muda, porque quando a gente muda, o mundo muda com a gente.” Gabriel O Pensador.

Posts Relacionados

• Conteúdo, Flash e HTML
• Ah, o maravilhoso mundo real
• Aonde nos leva a morte do Internet Explorer 6?
• Adobe: The Expressive Web
• CSS1K

Graceful Degradation é algo que vemos todos os dias. Trata-se de um método comum em dias onde a Internet é muito mais que um simples computador ligado no telefone. Acho que resumidamente, podemos dizer o que exatamente é Graceful Degradation com a frase:

Graceful degradation means that your Web site continues to operate even when viewed with less-than-optimal software in which advanced effects don’t work.

Peter-Paul Koch em Fluid Thinking

Esse assunto é bastante velho, mas que volta à tona nestes dias de campanhas contra o IE6 e outros browsers antigos. Eu mesmo já falei para ignorar totalmente o Internet Explorer 6, mas não é tão fácil assim. Eu posso ignorar aqui no Tableless, onde os usuários são de um nicho específico, mas eu não posso ignorar esse público quando se trata de um produto que é feito para o meu cliente. O cliente do meu cliente utiliza IE6. E ignorá-los significa fazer meu cliente perder dinheiro. Isso está fora de questão.
Então, se seguirmos este raciocínio, pense bem: podemos cometer este erro com outros tipos de usuários. Por exemplo, se seu site não pode ser bem visto em dispositivos móveis ou se não é bem acessado por leitores de tela.

É tudo sobre acessibilidade

Engana-se aquele que acha que acessibilidade é apenas sobre cegos e outras pessoas com alguma necessidade fisica. É claro que esse público merece uma atenção especial, que muitas vezes é tristemente ignorada. Mas quando falamos sobre acessibilidade, temos que entender que há outros grupos que se encaixam nesse assunto.
Quando um visitante não consegue acessar seu site por causa da resolução, ou por meio de algum dispositvo, ou por algum sistema de voz etc, estamos falando de acessibilidade.

Temos que prever visitantes com necessidades diversas. Há pessoas que passam a maior parte do tempo viajando. Por isso é muito difícil ler emails ou trabalhar conectado por notebook ou computador decente. Por isso ela passa a maior parte do tempo utilizando aparelhos móveis. Não por que ela queira, mas por causa da sua necessidade.
Se negligenciarmos o acesso desse tipo de público, cometemos um erro grave de acessibilidade. O mesmo para um simples visitante que não consegue acessar seu website por causa da sua resolução. Ele usa 800×600 porque precisa e não porque quer. Embora haja alguns que nem sabem o que é resolução.
Necessidade. Acessibilidade é tudo sobre a necessidade das pessoas.

Meios de acesso a Internet

Se as pessoas acessam a Internet, elas acessam por meio de um dispositivo especifico. Se ela é cega ou tem algum ou outro problema de visão, ela acessa o site por um leitor de tela. Se ela viaja muito ou fica muito tempo presa no trânsito, utililza dispositivos móveis.
Hoje em dia não existem muitos meios de acesso a Web. Se não acessamos por um computador ou um dispositivo móvel, acessamos com o que?
Outros meios de acesso a Internet estão nascendo. Na verdade novos usos para o acesso a Internet estamos surgindo e com estes novos usos, surgem novos meios de acesso. Vide o Surface da Microsof. É um meio totalmente diferente de interagir com a Web. Mas é um novo meio.

Mas e o Graceful Degradation?

Problemas com compatibilidades sempre existiram e creio que nunca deixarão de existir. Pelo contrário. Esses problemas serão mais comuns embora fiquem mais fáceis de resolver. Não serão apenas probleminhas entre browsers (os browsers existirão em tempos futuros?), mas também entre dispositivos.

Acontece muito hoje: tentamos acessar um serviço por um determinado browser, e somos aconselhados a utilizar outro browser porque o serviço não é compativel ou não funciona bem no nosso browser predileto.
Isso tira qualquer um do sério. O site deveria funcionar em qualquer browser. Para exemplificar: se em um meio de acesso eu não consigo utilizar bordas arredondadas nos elementos, os elementos apareceriam sem as bordas arredondadas. Isso não deveria prejudicar minha experiência de uso. Eu perderia um pouco no Design, mas conseguiria utilizar o serviço sem problemas.

A idéia do Graceful Degradation é exatamente essa: dar a melhor experiência possível ao dispositivo/meio que o usuário estiver utilizando sem prejudicar a acessibilidade.

Os usuários do IE6 por exemplo podem ficar sem bordas arredondas, position fixed, sombras e pngs semi-transparentes, mas eles precisam acessar e utilizar perfeitamente o site, com a melhor experiência que é possivel dar a este browser.

Mesma coisa é aplicada aos dispositivos móveis. Estes dispositivos normalmente não tem os mesmos recursos de um desktop. É tudo diferente, desde o poder de processamente até o tamanho das coisas. Então imaginar que o uso do sistema/site será parecido como se fosse acessado por PC, é um erro.

É um erro também se fizermos um site pensando em dispositivos menos capazes mas não nós lembrarmos do grupo de usuarios que acessam seu site com dispositivos mais completos e modernos. É engraçado porque pensamos sempre no usuário que está no pior cenário. Mas aquele usuário que não seria um problema pra nós, pode se tornar o pior deles.

Um exemplo disso é quando usuários de iphone acessam sites inteiros feitos em Flash. Sabemos que é uma limitação do aparelho. Mas estes usuários estão crescendo e seu cliente pode estar ali. Normalmente ninuem coloca uma versão diferente da do Flash. Logo, estes usuários simplesmente são ignorados. Imagine a frustação.

Resumidamente, Graceful Degradation é dar a melhor experiência que você conseguir para o usuário.
Se ele utiliza o último lançamento da Apple ou se ele utiliza um Nokia 6111 com Opera Mini. Ele precisa ter a melhor experiência que é possível dar dentro dos limites de cada dispositivo.
Obviamente que vice não vai prever todos os tipos de usuário. Mesmo porque seria impossível fazer isso. Novamente eu digo o óbvio: faça um estudo de público-alvo é importante.

Para complementar seu estudo:

• Fault-tolerant System
  
• Graceful Degradation Dan’s Web Tips
• Graceful Degradation – CSS3.info
• Graceful Degradation Progressive Enhancement

Posts Relacionados

• Performance do seu CSS
• Ah, o maravilhoso mundo real
• Prepare-se para a Revolução
• Lançado Firefox 3.5
• Porque só para o iPhone?

Todos os dias sites e mais sites são publicados na internet e nenhum deles com um padrão de nomenclatura de classes e ids que possamos utilizar para extrair informação de maneira inteligente. O HTML 4.01 é a versão atual da linguagem básica da Web, e não é atualizado a alguns anos. Esses detalhes de semântica não podem ser supridos para sempre por tecnologias como o Microformats. A versão 5 do HTML tende a suprimir essas necessidades e também atualizar pontos antigos do HTML 4, por exemplo, formulários.

Como disse no começo deste post, a estrutura de um site não é óbvia para as máquinas. Não existe nenhum padrão de construção dos elementos para indicar o que é o cabeçalho e o que é o rodapé, por exemplo. No HTML 5, iremos utilizar um padrão de tags que nos ajudará a marcar estas estruturas. Uma estrutura conhecida é mais ou menos assim:

...
...
...
...
...

Na estrutura acima, utilizei alguns nomes de classes e ids que costumamos utilizar no dia-a-dia. eu mesmo não utilizo a classe POST, uso mais CONTENT ou algo parecido. A estrutura do HTML acabará com isso. A idéia é substituir esse amontoado de DIVS por elementos que se encarreguem dessas funções, um exemplo da estrutura serial esse:

...



      ...
  

• O elemento header define o cabeçalho. Nav define o menu ou a navegação do site.
• Article define uma parte da página que tem uma composição de formulários, textos etc. Por exemplo, pode ser um post de forum, blog, comentários etc.
• O elemento Section define uma seção do layout em um determinado element. Ele pode conter um header e também um footer se preciso.
• O elemento aside consiste em envolver informações que tem algo a ver com o conteúdo principal do site. Pode ser um menu lateral, um sidebar padrão com menu, banner, busca etc…
• Footer define o rodapé do elemento ou do layout.

Entenda que agora, qualquer elemento pode ter seu conteúdo separado por seções com o elemento section. Note também que os elementos podem ter também um header e um footer independentes do resto do layout. Como na imagem.

Uma dúvida comum entre os desenvolvedores é como fazer a estruturação e distribuição das tags de títulos (h1 até h6). Por exemplo, se eu utilizei já a tag H1 no logo do site, poderei utilizar para o título do artigo? Se repetirmos muitas vezes as mesmas tags de títulos, a importância que cada título tem sobre o outro se perderá. O Google poderá indexar de forma diferente e etc.
No HTML 5 esse problema ser resolverá, porque cada section que você inicia, você poderá começar novamente uma nova ordem de títulos. Por exemplo:

Logo


Título do artigo

texto
Subtitulo

Mais texto

Dessa forma você conseguirá definir exatamente qual a importância de cada título e os leitores de tela, sistemas de busca e outras aplicações conseguirão fazer uma separação mais eficaz dos elementos textuais.

Entenda que os divs não irão deixar de existir. Você os usará em casos muito específicos, por exemplo, para fazer caixas de destaque:

Destaque 1

Texto


Destaque 1

Texto

Nesse caso estou usando os DIVs apenas por motivos de formatação. Ali não caberia um article, porque o conteúdo não é uma redação de um post, artigo e etc… Também não caberia uma section porque eu já agrupei este conteúdo dentro de uma section pai.

Para saber mais sobre isso, leia: The Elements Of HTML 5.
Irei escrever outros artigos sobre a inserção de vídeo e audio no código e uma série de outros assuntos interessantes sobre HTML 5. E o que você acha disso tudo? Deixe seu comentário!

Posts Relacionados

• Ah, o maravilhoso mundo real
• HTML 5, novos elementos e atributos.
• Sections: elemento article – Parte 4
• Sections: elemento nav – Parte 2
• Sections: seções do HTML5 – Parte 1