Javascript como deve ser

Algumas razões para se usar javascript:

• Interatividade;
• Validação de dados;
• Processamento de informação;
• Efeitos visuais.

Como o javascript oferece um sem fim de possibilidades, a má utilização de um dos itens acima pode ser perigosa e determinante para o resultado insatisfatório de um projeto.

E este perigo está diretamente ligado à acessibilidade do javascript. É importante lembrar que páginas não devem depender de scripts. Scripts devem, apenas, incrementar seus resultados.

Javascript acessível?

Sim, é possível! Pensemos como se todas as páginas não usassem javascripts. Qual seria a alternativa para algo que invariavelmente um javascript faria? Complicado não? Porém não impossível.

Algumas regras

• Não restringir apenas o uso do mouse para algum script;
• Usar eventos independentes¹ de dispositivo (onFocus, onBlur, onSelect e onChange, por exemplo)
• Não comprometer a navegação pelo teclado em qualquer seção de uma página;
• Oferecer alternativas para situaçõs em que o javascript não esteja habilitado;
• Usar DOM ao invés de DHTML; e
• Usar javascript unobtrusivo.

¹ – Eventos independentes são eventos que podem ser acionados tanto por mouse, quanto por teclado, sem que o resultado seja comprometido.

Javascript maduro é o que há!

Do DHTML ao DOM, do javascript acoplado ao javascript unobtrusivo, dos scripts convencionais às APIs e libraries. O javascript notoriamente está sendo levado à sério.

Incrementado a acessibilidade com javascript maduro

Atualmente, existem diversas formas de se incrementar um javascript tradicional. Algumas são simples, como a adição de addEvents para observar eventos de elementos, outras mais complexas, como a escolha da library adequada para um projeto. E essa escolha tende a ser difícil, pois a gama de alternativas é grande: JQuery, Prototype, Mochikit, Dojo Toolkit, YUI, Ext JS… Ufa! Ainda esqueci outros, com certeza.

Conclusão

Está comprovado que é possível usar javascript de forma inteligente e acessível. E, como digo para qualquer outro recurso: o uso ou não de uma determinada alternativa depende, antes de tudo, da característica fim do projeto. Não fará sentido usar uma library apenas para validar um formulário. Em contrapartida, é quase que imprescindível o seu uso em uma aplicação baseada em Web. ;)

A solução se trata de formulários baseados em grid layout. Usa solução simples, que usa um punhado de CSS e alguns conceitos de acessibilidade para formulários.

Princípios básicos de acessibilidade em formulários

• Utilizar <label> para o texto descritivo (título) de cada campo;
• Associar este <label> ao campo à que o título se refere (ex. <label for="txtnome"> Nome </label> ou <label> Nome <input type="text" name="txtnome" id="txtnome" /></label>);
• Colocar todo título acima do campo à que ele se destina;
• Ordenar campos por tabindex;
• Usar accesskeys; E por aí vai.

A idéia veio das tabelas!

A solução mais prática para criar formulários acessíveis, seria, então, colocar cada controle um abaixo do outro, formando, assim, um extenso formulário a ser navegado. A partir daí, nasceram os questionamentos: e para os campos pequenos, como UF e datas? Ficariam um abaixo do outro também? Não seria uma idéia legal ter um formulário não muito grande, com uma rolagem desnecessária.

Num tempo não muito distante (aliás, hoje ainda se faz isso), muitos web designers usavam/ usam tabelas para separar os campos de seus formulários. Visualmente ficam trabalhos realmente muito bem feitos, mas quando nos deparamos com a marcação, nascem os problemas.
O Web Standards Project, num artigo sobre acessiblidade em formulários, arremata:

Another accessibility gotcha with forms is that they are invariably set out using tables to achieve a nice grid-like effect. This is not always an automatic accessibility problem, but it can be – a table layout is irrelevent to a screen reader which effectively reads the content in the order it appears in the source code. [...]

Pois é, tabelas podem complicar a vida misturando a ordem dos controles na marcação. Então, por que não criar uma solução tableless?

Criando o grid

Para explicar os grids para formulários, criei um grid de aproximadamente 81px para cada coluna. Assim sendo, num formulário de 750px de largura é possível usar até 9 campos por linha.

¹ – O uso do <BR /> é importante para o caso de linhas que precisam ser quebradas antes do seu fim. Por exemplo, ter de quebrar a linha imediatamente depois de usar um label x-mall

A grande sacada do alinhamento é deixar os labels “soltos” na marcação e separar, apenas, as quebras de linha com <BR />¹. O CSS tratará do resto, usando classes específicas para cada tamanho de label. As possibilidades são²:

• X-small label (81px);
• Small label (2 * x-mall + margens);
• Large label (4 * x-mall + margens);
• X-large label (6 * x-mall + margens);
• Full label (Aproximandamente x-mall * 9 colunas).

² – Não foram levados em conta na contagem os ajustes de tamanho que foram necessários para o IE 6 (argh).

Como criar uma linha

1. <label class="small">Cidade * <input type="text" class="textfield" /></label>
2.    <label class="x-small">Número * <input type="text" class="textfield" /></label>
3.    <label class="large">Complemento * <input type="text" class="textfield" /></label>
4.    <label class="x-small">Estado *
5. <select class="select">
6.   <option value="RJ">RJ</option>
7.   <option value="SP">SP</option>
8.   <option value="MG">MG</option>
9.   <option value="ES">ES</option>   
10. </select>
11. </label><br />

Isso resulta em

Agora, o resultado final

Crie seu próprio formulário

Fique livre para usar a minha solução. Baixe os arquivos que resultaram nas imagens de exemplo.

¹ – Para quem não entendeu, a frase diz: “seria demasiado difícil entender cada frase escrita”.

Pois é, assim como nossos antepassados pensaram inteligentemente ao desenvolver nossa grafia com espaçamento entre as palavras, nós, designers, também precisamos pensar inteligentemente ao dispor texto em um design. A dica aqui não vale só para o webdesign: qualquer forma de design com elementos textuais pode se valer dessa prática.

Espaço em branco como elemento do design

Um estudo realizado em 2004 mostra o quão importante é a correta utilização dos espaços em branco. No estudo, foram realizados testes de performace de leitura por usuários levando em conta quatro tipos de layout compostos de texto. De todos os layouts, o que compunha uma melhor definição tipográfica (margens e espaço entre linhas) foi, indiscutivelmente, a melhor solução de disposição de texto em performace de leitura e em capacidade de compreensão pelos leitores. Para os textos sem margens (aqueles que ficam colados nas laterais da viewport do browser, por exemplo), a peformace de leitura caiu substancialmente.

Espaço em branco, na realidade, é uma alusão aos espaços sem preenchimento textual e/ ou de imagem – que não compõe o design – que podem ser utilizados para melhor organizar a área ativa do site, ou seja, é toda área que é parte do design (seja em branco ou não) que não influe na interação com o usuário.

Usar espaço em branco não necessariamente é ter falta de conteúdo

É notório que quanto menos conteúdo, mais fácil se torna organizar os componentes de um layout. Conseqüentemente, mais fácil se torna, também, separar estes componentes em toda a área do layout. Acredito que esta realidade acaba por contaminar o pensamento que alguns webdesigners têm sobre layouts de muito conteúdo, fazendo com que sites do gênero sejam criados com dados enfileirados e empilhados, sem a preocupação com a segmentação e, principalmente, a separação destes. É importante lembrar que, quanto mais conteúdo se têm a diagramar, mais cuidado se deve tomar com a separação deste no layout. Nestes casos, os espaços em branco passam de parte meramente decorativa do layout, para parte imprescindível na construção de uma boa usabilidade e acessibilidade do mesmo. ;)

Atualização 2007/01/09: Mark Boulton acada de postar um artigo sobre espaços em branco no A List Apart. Vale a pena dar uma conferida.

Hora de Wireframes

Os wireframes, atrelado ao Design de Interação definido na fase de escopo, são, acredito eu, os principais elementos de qualquer projeto.

O Design de Interação trata de relacionar todo o fluxo que as páginas do projeto terão e os wireframes vêm como uma transformação visual para o diagrama criado. Tendo a base das páginas que serão necessárias (Design de Interação), agora é só desenhar uma estrutura visual para o conteúdo das páginas (wireframes), colocando os elementos do layout em locais específicos, levando em conta sua importância e relevância.

Costumo desenhar meus wireframes inicialmente em papel e depois prototipar estes desenhos em XHTML e CSS. Defino, assim, alguns mockup’s e templates para o projeto.

Os wireframes em XHTML são mais amplos por possibilitarem a definição de fatores que os em gráfico não possibilitam. O estudo da tipografia e a implementação das cores são alguns destes fatores.

Desenhar Wireframes é uma arte, pois deve-se tomar muito cuidado no posicionamento de cada elemento no canvas do layout. É importante sempre levar em conta fatores como Acessibilidade e Usabilidade.

Modelando o Banco de Dados

A fase de modelagem de banco de dados é outra que poderia ser adiantada, porém fazer uma modelagem logo no início pode causar sérios transtornos (não tenha dúvidas que depois de desenhar os wireframes muitas coisas mudam na estrutura de banco de dados). Um campo que nasce, uma chave que se move, sempre há o que reavaliar.

Os wireframes darão boa base para a estrutura que o banco de dados deve ter. Então, basta organizar as tuplas que porventura já estiverem criadas, adicionar as tuplas que nasceram no meio do caminho e definir os campos para cada uma delas. Costumo fazer esse processo também desenhando à mão, mas depois é sempre bom passar tudo isso para um DER mais bem detalhado.

Apresentando resultados

A cara do projeto acaba de nascer! Temos wireframes em papel ou em gráfico, templates e a modelagem do banco de dados. Chegou a hora de apresentar resultados.

Quando o trabalho se trata de um freelance, cuidados na apresentação devem ser tomados. Talvez não seja interessante mostrar wireframes em papel, a não ser que os desenhos tenham uma boa cara. De qualquer forma, acho mais interessante apresentar os templates em XHTML. Já no meio corporativo, onde os resultados podem ser discutidos entre os colegas e a chefia, vale qualquer um dos papéis, desde que bem organizados.

Neste momento um ciclo se inicia até a chegada num consenso para a apresentação ideal que o projeto deve ter. Revisões naturalmente podem surgir.

Relacionados

• Processo de criação web
• Processo de criação web: o escopo
• Processo de criação web: a identidade
• Processo de criação web: a diagramação
• Processo de criação web: o desenvolvimento

Com base no diagrama do processo de criação web postado no artigo anterior, apresento as características da primeira fase.

Coleta de dados

É o primeiro contato com o cliente. Essa fase inicial acaba tendo uma cara de palestra, porque à medida que o cliente vai passando seus desejos, nós temos que mostrar quais serão as formas que eles podem ser criados e, naturalmente, o que pode ou não ser criado, mas como diz o ditado que o cliente pode tudo, eu troco por o que deve ou não ser criado.

A parte de coleta de dados, por ser o início de tudo, deve ser capaz de adquirir o maior número de informação possível do negócio do cliente. Depois, com todos os pontos identificados e organizados, começamos a pensar na forma de criação das próximas etapas.

Natureza do projeto

Projetos mais simples nos dão mais liberdade de fala, assim conseguimos agregar idéias ao cliente com mais facilidade, já com projetos mais robustos, não há outro jeito, reuniões e entrevistas serão necessárias para definir os pontos de implementação.

Caso de uso

O caso de uso é algo que costumo usar para melhor documentar o projeto. Mostrar ao cliente tudo aquilo que foi entendido nos encontros é uma forma de passar comprometimento com aquilo que deve ser feito. A apresentação do caso de uso serve para acertar os desencontros de informação.

Arquitetura da Informação nesse processo

A Arquitetura da Informação é item essencial no desenvolvimento de qualquer projeto no decorrer de todas as suas fases. Nesta parte inicial, de declaração de escopo e identificação de funcionalidades, a Arquitetura da Informação, através do Design da Informação, serve como um meio de melhor apresentação de tudo aquilo que foi coletado.

A AI, basicamente, é o estudo da Ciência da Informação e da Interação Humano-Computador, ou seja, o ato de focar o trabalho na forma com que o usuário irá interagir com o produto final. Isso inclui Usabilidade e Acessibilidade por exemplo.

Criar um Design de Interação também é fator de suma importância, pois ele é responsável pelo link entre Arquitetura da Informação e o Design Gráfico (área verde do Diagrama do processo de criação web).

Bom… O que importa nesta etapa inicial é o bom senso. Escutando tudo o que o cliente tem a dizer e mostrando os prós e contras de implementar este ou aquele recurso.

Relacionados

• Processo de criação web
• Processo de criação web: o escopo
• Processo de criação web: a identidade
• Processo de criação web: a diagramação
• Processo de criação web: o desenvolvimento

Pois bem. Eis que eu testei a ramonpage.com em meu Nokia via WAP com navegador Openwave (versão 6.2.3.2).

Confesso que fiquei feliz com o que vi, pois tive a certeza que os recursos de acessibilidade que utilizei não foram em vão.

Itens que podem ter facilitado a boa apresentação

• Design leve: Boa navegabilidade no WAP e sem estourar memória.
• Pular para conteúdo: Este recurso é muito útil quando se está em uma navegação linha-a-linha.
• Marcação XHTML: Montei uma marcação de modo que o conteúdo tivesse uma ordenação lógica (Header » Menu » Content » Sidebar » Content-extra » Footer) além de colocar hr para separar as áreas principais (Header » Content » Footer).

Espero que quando eu colocar em prática os futuros recursos para este site, eu consiga manter este padrão de acessibilidade.