Desenvolva aplicações web com suporte multi-idioma

Estou em uma nova fase da minha vida profissional,  aprendendo um pouco de ASP.NET, Jquery, enfim, tentando ser uma Front End completa. Estou gostando até, tenho aprendido bastante coisa. Afinal, acho que um HTMLer hoje em dia tem que ser um Front End completo, um desenvolvedor de interface. Enfim, isso fica em algum outro post. Hoje venho apresentar alguma coisinha que aprendi em ASP.NET e achei válido, pra colocarmos nosso site/sistema e vários idiomas.

Utilizando Resources

Habitualmente, as aplicações usam imagens e strings como ícones para barras de ferramentas ou menus, texto de menus e texto de labels. Alterar estes strings e imagens pode ser realmente “feio” e trabalhoso se você os colocou diretamente no código-fonte. Para alterar estes strings e imagens da forma mais fácil possível sem ter que procurá-los e alterá-los diretamente em seus códigos-fontes, você pode colocá-los em arquivos separados e então mudá-los em um único local.

O Framework .NET e o CLR (Common Language Runtime) oferecem grande apoio e este tipo de abordagem através da utilização de embebed resources (recursos embutidos).

O principal uso de resources é para localização. Utilizando arquivos de resource, você pode definir valores para as principais propriedades dos controles (como o text de um controle label) em diferentes arquivos – um para cada idioma que sua aplicação tenha suporte. Cada um destes resources contém strings (pares: chave/valor) para as propriedades localizadas em cada controle traduzido dentro do idioma correspondente.

Os arquivos de resource também podem ser usados com outra finalidade, porém não irei discutí-las neste momento.

Os conteúdo destes resources ficam armazenados habitualmente em arquvos .resx, que nada mais são do que arquivos XML contendo valores strings ou referência a arquivos externos. Ao compilar sua aplicação esses arquivos (strings e referências) são adicionados junto com o binário de sua aplicação.

Existem dois tipos de arquivos de resource:Local e Global que estão descritos abaixo:

Local Resources

Os resources locais são específicos para uma única página web e devem ser usados apenas para provê versões da página em diferentes idiomas.

Os resources locais devem ser armazenados no subdiretório App_LocalResources localizado dentro do mesmo diretório da página web, ou seja, deve-se existir um subdiretório App_LocalResources em cada diretório.

Os arquivos de resource são nomeados utilizando o formato: [.idioma].resx . Abaixo um exemplo de arquivos de resource válidos para diferentes idiomas para a página Default.aspx:

Default.aspx.resx – Arquivo base do resource, este arquivo será utilizado quando nenhum outro idioma for encontrado.

Default.aspx.de.resx – Resource para Alemão (A abreviatuta para Alemão é de).

Default.aspx.en.resx – Resource para o idioma inglês. (abreviatura para inglês é en).

Default.aspx.pt-BR .resx – Resouce para idioma Português (Brasil) especificamente (a abreviatura para o idioma português usado no Brasil é “pt-BR”)

Como o propósito de nossa aplicação é utilizar o recurso de multi-idiomas em todo o site não vamos utilizar resources do tipo local.

Global Resources

Os resources globais podem ser lidos de qualquer página ou código no web site. Você deve utilizar apenas os resources globais quando precisar acessar um único resource em múltiplas paginas web. Os resources globais devem ser armazenados no diretório App_GlobalResources na raiz da aplicação.

Os resources globais devem ser nomeados usando o formato [.idioma].resx. Abaixo um exemplo de arquivos de resources globais válidos:

MeuResource.resx – Arquivo padrão de resource. Será usado quando nenhum arquivo de resouce for localizado para o idioma atual.

MeuResource.en-US.resx – Arquivo de Resource para o idioma IngLês – Estados Unidos.

MeuResource.it-IT.resx – Arquivo de Resource para o idioma italiano –Itália.

Usar resources locais para definir automáticamente os valores dos controles é chamado de “implicit localization”. Através da “explicit localization” você define as propriedades dos controles manualmente associando-os com os arquivos de resource globais. o ASP.NET então automáticamente provê a tradução cultural para os usuários finais.

Para utilizar a localização explícita (explicit localization), crie primeiro um arquivo padrão de resource e então crie os arquivos de resource para cada idioma individualmente. Finalmente, associe as propriedades dos controles para os resources.

Após a descrição de o que é, e como funciona um arquivo de resource, vamos finalmente começar a criação de nossa aplicação.

No nosso exemplo, vamos utilizar os idiomas: Alemão, Francês, Inglês, Italiano e claro o nosso Português.

Para saber o código identificador de cada idioma, acesse a lista de identificadores aqui.

Criação dos arquivos de Resource Globais.

Para criar um arquivo de resource global siga os passos abaixo:

1. No Solution Explorer, clique com o botão direito do mouse na raiz do web site e então clique em Add ASP.NET Folder e depois em App_GlobalResources.
2. Clique com o botão direito do mouse em App_GlobalResources e então clique em Add New Item.
3. Na tela Visual Studio installer templates, clique em Resource File.
4. Na caixa de texto Nome, digite qualquer nome que queira utilizar seguido da extensão .resx. (No nosso exemplo usamos Idioma.resx).
5. Dê um duplo clique no novo resource para abri-lo no Visual Studio. Será exibido uma tabela. Adicione valores para o idioma e então clique em Salvar.
6. Copie e cole o arquivo de resouce para criar outros arquivos em diferentes idiomas. Para cada idioma adicione o identificador imediatamente antes da extensão .resx. Por exemplo, para o idioma espanhol, o arquivo deverá ser nomeado para Idioma.es-ES.resx.

Associando as propriedades do controle com o resource

Assim que os arquivos de resource foram definidos, você pode associar as propriedades do controle (como Label.Text) com o resource global e automaticamente o ASP.NET irá exibir o texto correto para o idioma do usuário.

Para associar as propriedades do controle com o resource global, adicione a o código <%$ Resource:ClassKey, ResourceKey %>. na propriedade que deseja utilizar o arquivo de resource.

Ex:

<asp:Label ID=”lblExemplo” runat=”server” Text=” <%$ Resources:Idioma,TextoExemplo %>”> </asp:Label>

Caso queira alimentar a propriedade programaticamente, siga o exemplo abaixo:

lblExemplo.Text = Resources.Idioma.TextoExemplo;

Se as propriedades do resource não estiverem disponível em tempo de desenvolvimento, você pode usar a função GetGlobalResourceObject, como abaixo:

lblExemplo.Text = GetGlobalResourceObject(”Idioma”, “TextoExemplo”).ToString();

Definindo a cultura (idioma) atual

É possível definir dois tipo de propriedades para definir a cultura, são elas:

Culture: Determina o resultado de funções dependentes de cultura, como formatos de datas, números e moeda. Você só pode definir esta propriedade usando o formato linguagem-região (como pt-BR) não é possível definir a propriedade apenas com a linguagem (pt).

UICulture: Determina qual cultura será carregada na página. Você pode definir apenas a linguagem (pt).

Para definir estas propriedades, você deve sobrescrever o método InitializeCulture. Após definir as propriedades Culture e UICulture, você deve chamar o método base.InitializeCulture.

No nosso exemplo, criamos uma página base (PageBase) onde sobrescrevemos o método InitializeCulture:

protected override void InitializeCulture()

{

string c = Idioma;

UICulture = c;

Culture = c;

base.InitializeCulture();

}

Com isso você já pode utilizar o recurso multi-idioma em seus projetos web.

Em nosso exemplo, definimos uma master page com um dropdown onde é possível alterar o idioma da página em tempo de execução.

Logo abaixo, o link com o código-fonte completo de nossa aplicação exemplo com suporte multi-idioma.

Download: GlobalizationExample.rar

Citação do Blog: http://roniedias.wordpress.com/2009/04/03/globalization-desenvolva-aplicacoes-web-com-suporte-multi-idioma/

Bom pessoal, por hoje é só.. Tenho mais coisas pra comentar do que venho aprendendo.. em breve posto aqui..

1a. Conferência Web W3C Brasil

A Conferência Web W3C Brasil foi criada para oferecer ao público brasileiro um amplo fórum anual de discussão e debate sobre a evolução da Web, a padronização de suas tecnologias e o impacto dessas tecnologias na sociedade e na cultura. A Conferência reunirá pesquisadores, desenvolvedores, usuários, empresas, agências digitais, mídia e todos aqueles que são apaixonados pela Web e que têm algo a oferecer, usar e debater.

A 1a. Conferência Web W3C Brasil 2009 será realizada em São Paulo, SP, nos dia 23 e 24 de novembro, no Blue Tree Towers Morumbi no bairro do Brooklin. Acesse os links para obter informações sobre o local, hotéis da região, chamada de trabalhos ou sobre como se inscrever para participar da conferência da web brasileira.

Chamada para trabalhos

Você pode ser um palestrante da 1a. Conferência Web W3C Brasil! Se você tem um caso prático e inovador de uso da web, ou fez uma pesquisa cujos resultados merecem ser compartilhados com toda a comunidade web brasileira, ou ainda tem o “pulo do gato” para ensinar em um tutorial, então atenda a nossa Chamada de ‘Papers’, Casos de uso e Tutoriais.

O Comitê de Programa vai selecionar as submissões mais relevantes para compor a programação da Conferência. Mais detalhes em Chamada de trabalhos.

Entre na comunidade da conferência no Facebook e fique por dentro.

• nth-child
• Canivetes na web
• HTML 5 – Semântica e o que é importante na web
• Navegando com a jQuery
• Web Standards Project – WaSP

Eu pretendo ir, estou analisando possibilidades de tirar folga do trabalho para estes dias e hotéis. Agente se vê por lá.

Lançamento da primeira rede social acessível

É com grande honra que apresento a nova rede social acessível do Brasil. O Acesse veio para revolucionar, para permitir que as pessoas normais convivam mais com os deficientes e com o mundo dos paraolímpico. Muito bom de ter participado na criação deste projeto na minha empresa, QX3 juntamente com o Instituto Superar . O prazo foi curto, algumas noites viradas na criação deste, porém a vontade da equipe  de fazer um projeto beneficiando tanto deficientes como não deificientes fizeram que nos esforçassemos cada vez mais.

Foi um caminho longo, não é fácil colocar todas as diretrizes de acessibilidade, deixar o código ssemântico, e além disso criarmos um visual bonito e limpo no site, mas enfim, conseguimos deixar a rede social acessível a todos. É bom olhar e perceber que todos se benficiaram, todos gostaram. Mas enfim, não é só isso, estamos projetando novas funcionalidades para a rede social, sempre no intuito de facilitar a acessibilidade para todos.

Além disso, a rede social está validada nos principais navegadores e nos leitores de tela (Jaws e DOSVOX).

Uma matéria saiu no Globo Esporte sobre o projeto:  Paraolímpicos ganham comunidade virtual adaptada às suas necessidades

É claro que, projeto da casa, fiz questão de me cadastrar e participar da rede social. Me procurem pelo meu nome ” Taynara Jaegger “.

Acesse – http://www.acesse.org.br

Table ou No table?

 

Semana passada tive um problema com margens renderizadas com difereça nos navegadores,  precisariamos que no site tivesse um body com fundo para que ele se repetisse acordo com o conteudo/tamanho de cada página do site, infelizmente descobri da pior maneira que as margens além de serem renderizadas diferente nos navegadores, isso também é afetada em cada versão de browser, então um “backgorund-position” com hacks era ineficaz.

Então após várias tentativas com divs envolvendo o conteudo, declarar no css o html e o body com 100% as páginas que possuiam scroll não herdava todo fundo, e adivinha, colocamos uma tabela somente para estrturar essa parte e o que aconteceu? Em um toque de mágina o site ficou perfeito, o fundo se adequando a todos os navegadores e o site ficou fluidosem problema algum.

Tive alguns problemas com não usar tabelas para estruturar sites, alguns clientes colocavam muito mais conteudo do que era permitido, mas a idéia de nosso projetos não é essa, tornar sites fixo e sim com conteudo fluido, para que um dia possamos colocar mais ou menos conteudo e o site continuar do  mesmo jeito.

Mando um post do meu chefe sobre ter ou não tabela, Ele retratou esta matéria em uma comunidade interna da nossa empresa, incentivado pelo problema que tivemos acima.

 

 

Resolvi lançar esse assunto pois tenho percebido que, em muitos projetos, estamos gastando um tempo danado, talvez muito maior do que o necessário, apenas para deixar o site todo tableless. Eu concordo que o modelo de formatação por tabela seja ultrapassado semanticamente, mas ao mesmo tempo ele nos dá uma confiança muito grande de que o que estamos construindo é realmente sólido. É como uma parede de alvenaria comparada à uma de gesso. Na parede de alvenaria podemos pendurar o que quisermos: armários, quadros, etc. Na de gesso, se não usarmos uma bucha especial, corremos o risco daquela parede desmoronar. A tabela nos tira a vantagem do design fluido e da flexibilidade de adaptar a mesma informacao de formas completamente diferentes. Em compensacao sabemos de antemao que, se uma pagina foi concebida para ter determinado layout, ela realmente vai ter aquele layout. E sejamos praticos, em 99,99% da vezes ela nao tem que ter layout diferente daquele em que foi concebida. Sera que realmente vale a pena gastar aquelas horas, dias ou semanas a mais, so pra ter essa falsa “flexibilidade”. A ponta do lapis provavelmente vai dizer que nao. O mais sensato me parece ser, antes de iniciarmos qualquer projeto, sentarmos todos juntos e definir uma estrategia de montagem, junto com equipe de html, design e comercial, e definir o caminho mais balanceado para atingir o que foi efetivamente vendido para o cliente.

via @postarek

Eu acho ideal termos sim tabelas pra estruturação de sites, assim conseguimos sempre ter um site fluido, mas como tabela não é acessível, não podemos descartar que o conteúdo em si precisa estar o mais lipo possível com ‘tabless’.

Enfim pessoas, postem suas opinioes!

Diferença entre HTML 4 e HTML 5 e algumas observações

Pegando carona num artigo do Treina Web, estou postando algumas diferenças de html 4 pra html 5 e abaixo algumas observações.

O html 5 veio realmente para facilitar nossa vida, usando-o, estamos simplificando nosso código, com isso conseguimos ter uma melhor manutenção do nosso site.

Peguei um exemplo de código de Blog citado no Treina Web para mostrá-lo a vocês. Este blog possui uma página simples de qualquer blog, cabeçalho, rodapé ,alguns posts, uma seção de navegação e uma barra lateral.

Em html 4:

<html>
<head>
    <title>BLOG - TreinaWeb: Webstandards e programação WEB e Desktop</title>
</head>
<body>
    <div id="page">
        <div id="header">
            <h1>
                <a href="/blog/">Blog TreinaWeb: Webstandards e programação WEB e Desktop</a></h1>
        </div>
        <div id="container">
            <div id="center">
                <div id="post-102">
                    <h2>
                        <a href="/page-test-2/">Page Test 2</a></h2>
                    <div>
                        <p>
                            Texto Aqui</p>
                    </div>
                </div>
                <div id="post-101">
                    <h2>
                        <a href="/page-test/">Teste 1</a></h2>
                    <div>
                        <p>
                            Texto Aqui</p>
                    </div>
                </div>
            </div>
            <div>
                <div>
                    <a href="/blog/page/2/">« Posts antigos</a>
                </div>
                <div>
                </div>
            </div>
        </div>
        <div id="right">
            <ul id="sidebar">
                <li>
                    <h2>
                        Informações</h2>
                    <ul>
                        <li><a href="/blog/politica/">Politica</a></li>
                        <li><a href="/blog/listas/">Listas</a></li>
                    </ul>
                </li>
                <li>
                    <h2>
                        Arquivos</h2>
                    <ul>
                        <li><a href='/blog/2009/04/'>Abril 2009</a></li>
                        <li><a href='/blog/2009/03/'>Março 2009</a></li>
                        <li><a href='/blog/2009/02/'>Fevereiro 2009</a></li>
                        <li><a href='/blog/2009/01/'>Janeiro 2009</a></li>
                    </ul>
                </li>
            </ul>
        </div>
        <div id="footer">
            <p>
                BLOG - TreinaWeb © 2009</p>
        </div>
    </div>
</body>
</html>

Em html 5:

<html>
  <head>
    <title>BLOG - TreinaWeb: Webstandards e programação WEB e Desktop</title>
  </head>
  <body>
    <header>
      <h1>
        <a href="/blog/">Blog TreinaWeb: Webstandards e programação WEB e Desktop</a>
      </h1>
    </header>
    <section>
      <article>
        <h2>
          <a href="/page-test-2/">
            Page Test 2
          </a>
        </h2>
        <p>Texto Aqui</p>
      </article>
      <article>
        <h2>
          <a href="/page-test/">
            Teste 1
          </a>
        </h2>
        <p>Texto Aqui</p>
      </article>
      <nav>
        <a href="/blog/page/2/">« Posts antigos</a>
      </nav>
    </section>
    <nav>
      <ul>
        <li>
          <h2>Informações</h2>
          <ul>
            <li>
              <a href="/blog/politica/">Politica</a>
            </li>
            <li>
              <a href="/blog/listas/">Listas</a>
            </li>
          </ul>
        </li>
        <li>
          <h2>Arquivos</h2>
          <ul>
            <li>
              <a href='/blog/2009/04/'>Abril 2009</a>
            </li>
            <li>
              <a href='/blog/2009/03/'>Março 2009</a>
            </li>
            <li>
              <a href='/blog/2009/02/'>Fevereiro 2009</a>
            </li>
            <li>
              <a href='/blog/2009/01/'>Janeiro 2009</a>
            </li>
          </ul>
        </li>
      </ul>
    </nav>
    <footer>
      <p>BLOG - TreinaWeb © 2009</p>
    </footer>
  </body>
</html>

Sim, o código ficou mais simples e limpo, com isso não precisamos acrescentar divs, mais classes, etc.. Os elementos adicionados foram:

• section: Uma seção, como um capítulo ou parte de um livro.
• header: O cabeçalho da página mostrada.
• footer: O rodapé da página mostrada, como uma assinatura de e-mail.
• nav: Uma coleção de links.
• article: Um artigo, uma entrada independente, em um blog, revista, jornal, e assim por diante.

Então, ficou ou não de fácil  de entendimento e consequentimente de fácil manutenção. Por enquanto isso ainda é um esboço do html5, ainda não saiu a versão final. Mas se nota o quanto tornou nossa vida mais fácil.

O html 5 é focado sempre na web semântica, onde toda tag terá um significado, não sendo necessária a criação de várias divs, porque teremos tags para cada elemento da página.

A Apple foi a primeira a introduzir o html5 no Iphone e logo após no Safari 4, logo depois o Google aplicou no Android e no Chrome 2.

Com a chegada do html5 os dias de dependência do Flash para visualizar vídeos nas páginas acabaram, um bom exemplo disso é o http://www.youtube.com/html5 (Você precisa ter Firefox 3.5, Google Chrome 2, Safari 4, Opera 10  instalado), acabando com esta dependência , assitir vídeos ficou mais acessível podendo controlá-lo com o teclado.

Agora o tratamento de acessibilidade, com o html5, serão recurso nativo do html, e não como um recurso “extra”, facilitando a acessibilidade, também temos melhores resultados com motores de buscas, pois eles priorizam sempre a semântica do site.

Muitas novidades por aí no novo HTML, enquanto isso vamos estudando para podermos colocar em prática.

O usuário Pedro Rogério levantou uma questão que não tinha posto , era sobre o DOCTYPE, resolvi então fazer uma atualização sobre:

O DOCTYPE para documentos HTML 5 não necessita mais de um DTD, sendo assim, o doctype fica da seguinte forma:

<!DOCTYPE html>

Acessibilidade na Web: o caminho das pedras

Semana que vem é semana de Conip, Congresso de Informática e Inovação na Gestão Pública. E este ano, o W3C Brasil participa com um tutorial bastante útil: como construir sites acessíveis, com base no publica o EMMA (Extensible MultiModal Annotation), padrão que promove interações na Internet através de uma série de meios, além do teclado e do mouse…

mais sobre este evento: http://www.circuitodeluca.com/2009/06/acessibilidade-na-web-o-caminho-das.html

Metodologias Ágeis para AI

Fugindo um pouco do foco do blog estou postando sobre metodologia ágeis na área de arquitetura da informação.

Na empresa onde trabalho, estamos aderindo ao scrum (metodologia ágil de gerenciamento de software).

O scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto.

Formamos uma equipe com pessoas de cada área para desenvolver nosso projeto, tendo essa união podemos ao longo do projeto discutir melhorias.

No scrum, temos entregas frequentes do projeto para que o cliente  analise seu projeto ao longo de seu desevolvimento sugerindo mudanças.

Estudando um pouco sobre metodoligia ágil e arquitetura da informação, encontrei esse slide bem interessante, nele cita o sucesso da empresa 37 signals na área de arquitetura da informação com scrum, sempre focando no resultado final para o usuário.

Espero que gostem:

Captcha é inacessível e fácil de burlar

CAPTCHA é uma aplicação baseada em leitura de texto ou tarefas de percepção visual utilizada para a segurança de um site, impedindo que bots entrem no sistema.

Captchas são inacessíveis, alguns mostram uma imagem para que visualizemos e assim digitarmos seu conteúdo termos acesso ao sistema ou site, a pessoa com deficiência visual não consegue visualizar aquela imagem, portanto não acessa a página na qual precisaria acessar.

Muitas das vezes pessoas com boa visão também não consegue visualizar alguns captchas, como é o caso da imagem abaixo que é um captcha para entrar no gmail para caso erramos o login ou senha, com muito custo conseguimos visualizar o que está escrito na imagem para digitarmos e validarmos nosso acesso.

Para suprirem essa necessidade, alguns captchas usam também um áudio de apoio, porém usuários com deficiência auditiva também não consegue acessar, partindo do principio que é muito dificil de identificar a imagem de um captcha. Tentando solucionar alguns problemas, alguns captchas possuem javascript para perguntas matemáticas ou de perguntas de sentido comum, porém eles podem ser burlados facilmente por spammers, cracks ou hackers, eles conseguem ser lidos por inteligência artificial.

Existem alguns projetos como BREAKING, AICAPTCHA e PWNTCHA que demonstram que a maioria desses sistemas que se utilizam de reconhecimento ótico de caracteres podem ser quebrados por computadores. Na realidade temos até a tecnologia OCR, que leem imagem e transformam em um texto, assim como acontece quando scaneamos algo e conseguimos “pegar” textos da imagem escaneada. No Google facilmente encontramos maneiras de se burlar um captcha, segue o link com uma lista para isto: http://migre.me/12Kg

Alguns exemplos de captchas está neste endereço: http://www.oddee.com/item_96665.aspx .Todos eles não são acessíveis e fáceis de serem burlados.

Se vendo que o captcha é algo inacessível e fácil de se burlar porque muitos desenvolvedores ainda insistem em tê-lo em seus sistemas? Porque não procuramos outros meios de fazer nossa web mais segura sem também tenhamos que deixar de lado os deficientes visuais, usuários de mobile entre outros.

Criando e mantendo páginas XHTML válidas

1. Escolhendo o tipo de DOCTYPE APROPRIADO.

Todas as páginas ASP.NET criadas dentro do Visual Studio 2005 recebem automaticamente o DOCTYPE para o XHTML 1.0 Transitional. Caso seja necessário utilizar qualquer outro DOCTYPE a página deverá ser editada manualmente.

Segue abaixo os quatro DOCTYPES padrões:

XHTML 1.0 Transitional

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

XHTML 1.0 Strict

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

XHTML 1.0 Frameset

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN”

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>

XHTML 1.1

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN”

“http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>

1. Como descrever elementos e atributos de forma válida

Alguns detalhes devem ser observados para que os elementos e atributos sejam descritos de forma válida dentro do DOCTYPE selecionado.

É importante ressaltar que estas regras se aplicam apenas aos elementos digitados manualmente nas páginas ASP.NET, uma vez que os componentes internos geram automaticamente um código XHTML válido.

Desta forma, os itens que devem ser considerados são os seguintes:

Todos os nomes de elementos e atributos devem ser digitados em caixa-baixa. O XML, sobre o qual as páginas XHTML são montadas, é case-sensitive, ou seja, existe uma diferença entre os elementos <p> e <P>. Apenas a primeira forma é válida.

Sempre coloque os valores dos atributos dentro de aspas simples ou duplas. Você pode configurar o Visual Studio 2005 para colocar as aspas automaticamente, usando a opção do menu Tools, Options, Format.

Todos os elementos que não sejam vazios devem ter uma tag de abertura e outra de fechamento. Por exemplo, se você tem uma tag de abertura <p>, você obrigatoriamente deve ter uma tag de fechamento </p>.

Não podem existir tags sobrepostas. Você pode embutir tags umas nas outras, mas não pode inverter as sua ordem de fechamento. Por exemplo, o código abaixo é válido:

               <b><i>Conteúdo</i></b>

Já o código abaixo é inválido

               <i><b>Conteúdo</i></b>

Todos os atributos precisam ter um valor, mesmo quando a sua sintaxe pareça estranha. Por exemplo, a tag <input checked /> é um código XHTML inválido, uma vez que o atributo checked não tem um valor. Esta tag deveria ser escrita na forma de <input type=”checkbox” checked=”checked” />.

1. Os códigos em Javascript escritos dentro das tags <script> e </script> devem ser envolvidos dentro de uma seção CDATA, conforme o exemplo abaixo.

          <script>
           /* <![CDATA[ */

           function isLess(a, b) {
           if (a < b)
           return true;
           }
          /* ]]> */
        </script>

Isso acontece pelo fato de que se você utilizar caracteres especiais como < ou & dentro do seu código Javascript, eles podem ser interpretados como a marcação do começo de uma tag XHTML

WCAG 2.0 e algumas observações

Estou no grupo Acesso Digital, lá vejo coisas bem interessantes quanto a acessibilidade na web.
Presenciei uma discussão sobre o WCAG 2.0 e alguns “furos” sobre ele. Um amigo do grupo teve dúvidas em relação alguns itens do WCAG 2.0, e nosso amigo MAQ (Marco Antonio Queiroz), grande mago da acessibilidade, deu sua opinião, achei bem bacana essa discussão no grupo.

Aqui estão alguns regras para o WCAG 2.0, e abaixo as opiniões do MAQ que achei bem válidas:

2.4.4 Finalidade do Link (Em Contexto): A finalidade de cada link pode
ser determinada a partir apenas do texto do link ou a partir do texto
do link juntamente com o respectivo contexto do link determinado de
forma programática, exceto quando a finalidade do link for ambígua
para os usuários em geral. (Nível A)

MAQ – Um clique aqui ou saiba mais tem SEMPRE uma finalidade indeterminada por sua
expressão. Eles só existem dentro de um contexto, pois ninguém “clica ali”
caso não saiba onde está e para que está clicando. A única coisa que poderia
“pegar” seria o conceito de “para as pessoas em geral”, pois as pessoas em
geral, com excessão dos cegos, quando navegam vendo a tela conhecem o
contexto. Pois bem, como eles estão fazendo acessibilidade também para
pessoas cegas, acredito que entre “as pessoas em geral” estejam as pessoas
cegas. Portanto, se pessoas cegas não podem perceber sentido no texto de um
link “Clique aqui” sem sair do link para saber em que vai clicar, o texto do
2.0 se transformaria e teria sentido. A ambiguidade, na verdade, nem
existiria, o que existe é mesmo a indefinição. A questão real é: quem vai
incluir as pessoas cegas na expressão “para as pessoas em geral”? Eu juro
que cegos também são gente, também juro que são pessoas, mas a generalidade
e a inclusão de pessoas cegas entre pessoas em geral é que é duvidosa. Será
que eles pensaram em público alvo e acharam que em algumas circunstâncias o
texto do link fora de contexto seria completo? Não acredito que eles tenham
sido tão ingênuos ou desconhecedores da realidade. Na verdade, acredito que
alguns links possuam sentido dentro de qualquer contexto e seja a isso que
ele se refere. Por exemplo: “contato”, “Home”, (eu prefiro Muié), Quem somos
etc. Acredito também que o clique aqui e o saiba mais esteja contemplados
nesse item quando ele diz que, se o texto do link perder o sentido, que ele
deve vir acompanhado do contexto do link, tipo: Saiba mais sobre o decreto
5296. De qualquer forma, eles precisam aprender a escrever, já que, desde
1999 eles ainda não entenderam como fazer isso!

2.4.9 Finalidade do Link (Apenas o Link): Está disponível um mecanismo
para permitir que a finalidade de cada link seja identificada a partir
apenas do texto do link, exceto quando a finalidade do link for
ambígua para os usuários em geral. (Nível AAA)

MAQ – Acredito que aqui eles deviam estar ameaçados de morte pelos adoradores do
saiba mais, unidos aos adoradores do “Veja mais” e ainda do Clique aqui, ou
ainda do “não clique aqui, não saiba mais e não veja nada, já que isso é
comum em você”. Entretanto, vamos dar um crédito aos caras… Quem sabe eles
não estavam pensando em mudar o texto do 1.0 quando este dizia que para
diferenciar um link de outro com mesmo texto, poderia colocar nos links um
atributo title e o caso estaria resolvido? Só se esqueceram que a maioria
dos leitores de tela do mundo não lêem title e que, o único que lê, o
brasileiro Virtual Vision, o faz por defeito, pois apesar de ler o title do
link não lê o texto do link quando o title existe. Talvez ainda estivessem
pensando em colocar um span com uma class para fora da tela, dando
continuidade ao texto do link e chamando isso de mecanismo, o que nós
chamaríamos do maior quebra galho da história oficial e a de por baixo dos
panos.

Achei bem bacana as opiniões dele porque realmente acho que muitos desenvolvedores, designers, redatores, irão achar que realmente pode ter algum contexto para usar o “Saiba Mais” , “Clique aqui” , “Veja mais” .. Continuando não incluindo os deficientes visuais na questão da acessibilidade.

Tenho receio quanto ao seguidores do W3C acharem que acessibilidade é só seguir o WCAG.
Na verdade acessibilidade em um site é algo a ser aprimorado junto com as novas tecnologias e não somente seguir alguns padrões, precisamos de ter as novas tecnologias acessíveis a todos.

Me aprimorarei num estudo mais completo sobre WCAG 2.0 e postarei aqui para tirar eventuais dúvidas.