Nos dias 23 e 24 de abril aconteceu em Londres, no Google Campus, o Workshop do W3C sobre Dados Abertos. Organizado pelo Phill Archer, em parceria com o recém lançado Instituto de Open Data (ODI) e a Open Knowledge Foundation, o evento teve como objetivo discutir, alinhar e pensar estratégias para o futuro do OpenData no mundo.

O primeiro painel já aconteceu “quebrando tudo”. Foram apresentados 4 papers, do governo britânico, do governo holandês, de uma pesquisadora da UNDP e de um pesquisador da IBM.

O tema foi “Open Data: Promessas e expectativas”

O primeiro a falar foi o John Sheridan, que é o Head of e-services no Departamento de Informações Públicas do Governo Britânico (OPSI). A fala dele foi toda centrada na idéia de que o movimento de OpenData e governo digital ainda está no começo. Fez uma comparação com a revolução industrial e defendeu que todos ainda estão tateando em como lidar com dados e em como trabalhar uma cadeia para eles, seja envolvendo governo ou não. A parte mais legal foi quando ele disse os governos só soltam dados para hackatons ou para aparecer na imprensa, mas esquecem de manter a cadeia de abertura de dados sustentável. Ele contou que o trabalho dele é garantir, através de leis e de práticas, realizadas ao MESMO TEMPO, que os dados sejam confiáveis (API’s abertas e certificadas) e contínuos (coleta estruturada, pensando na abertura desde o começo)

Mais: ouça aqui um podcast com o cara falando sobre isso.

A segunda fala foi da Millie Begovic Radojevic. Ela trabalha para as nações unidas e trouxe um experimento muito interessante com dados do Banco Mundial. Ela (que fez o PHD dela em análise de redes na internet) usou o Tulip, um software que ajuda no desenho de gráficos de relações e, cruzando dados da UNDP com os do Banco Mundial usando phyton para otimizar, conseguiu traçar informações variosas pro trabalho dela com nações em desenvolvimento. Nos slides dela, mostrou alguns exemplos que comparam o Brasil com a Venezuela e outros países, mostrando quantas empresas costumam receber financiamento para construir infraestrutura. Os resultados, que a gente que é brasileiro, já conhece muito bem, são impressionantes porque deles pode-se concluir muita coisa, além de utilizar como base para políticas de desenvolvimento, em termos de foco e gestão de recursos para países.

Mais: Aqui tem um post dela explicando tudo sobre o projeto.

O terceiro foi o Tim Davies. Ele atualmente é coordenador de pesquisa em Open Data na WWW Foundation. A apresentação dele é sobre como medir e observar para comprovar os impactos do Open Data na vida das pessoas. A preocupação dele é o uso do open data para solucionar problemas reais. O objetivo do projeto é pesquisar as diferenças de impacto e de contexto que existem entre os principais países do mundo para ajudar o movimento de Open Data a se tornar mais efetivo para os cidadãos e governos.

Mais: O blog dele é bem legal. Um dos projetos de pesquisa liderados por ele propõe criar padrões mundiais para contratos. É o Open Contracts, que faz muito sentido: em um mundo globalizado onde várias empresas prestam serviços para vários governos do mundo, nada melhor que padronizar para facilitar a prestação de contas e transparência envolvendo estes contratos.

O quarto speaker foi o Paul Suijkerbuijk, que é o Project Lider no portal de Open Data da Holanda e Ministry of Internal Affairs/KOOP. Falou sobre confiança nos dados que estão sendo abertos e sobre a pertinência e relevância desses dados perante as pessoas que vão usar esses dados. Explicou que a estratégia que eles tem utilizado para tentar mostrar para os empresários que os dados abertos pelo governo tem valor econômico e também social é agregar valor aos dados através da Linked Data iniciative. Também pretende, com o projeto de dados linkados fazer com que o próprio governo perceba o valor da abertura de dados. Eu achei surpreendente o engajamento e conhecimento técnico do ministro. Realmente ele sabe do que está falando e entende as soluções que a equipe dele está adotando. Achei genial.

Mais: site Open Data NEXT (Netherland)

O ultimo dos palestrantes que abriram o primeiro dia de Workshop foi o Bob Schloss, da IBM. Por um acaso descobri depois que ele também está envolvido com o grupo que coordena o ManyEyes, da IBM.  e isso faz todo sentido porque ele apresentou três princípios que a pesquisa dele tem como norte para o trabalho com dados abertos que focam justamente no usuário dos dados:
1. Incentivos: muitos dados disponíveis, de várias áreas, de maneira acessível e disponível, para motivar através da transparência o uso e reuso de dados;
2. Confiança e segurança na hora de garantir a qualidade dos dados. Isso significa que o governo precisa assegurar que os dados que está abrindo são realmente os dados que ele utiliza para tomar decisões, precisa garantir a anonimização das pessoas envolvidas com os dados, precisa ter boas leis para garantir que os dados sejam precisos e que os cidadãos não possam criar uma onda de processos contra os governos, indagando sobre a natureza ou qualidade ou especificidade dos dados, (no caso brasileiro, duvido que algum cidadão vá gastar sua vida entrando com um processo contra o governo com relação à dados abertos, mas…)
3. Deixar claro de onde vem os dados pra que a política de uso e reuso não resulte em problemas jurídicos e insegurança com relação às fontes de dados.

Impressões sobre o primeiro painel: soluções palpáveis e tangíveis de governo ou instituições para sociedade (e não o contrário) – preocupações com documentação, técnica, consistência, pertinência e confiabilidade dos dados para mostrar para os prováveis clientes dos governos e entidades (cidadãos?) que abrir dados é benéfico para a sociedade como um todo. A importância de uma legislação focada e consistente em dados abertos e dados linkados, a importância dos governos manterem a mente aberta sobre tudo o que for desafio e não enxergarem como barreira. 

Logo depois o Jim King, inventor do PDF fez uma fala fantástica, que pode ser resumida em uma só frase “pdf não é um formato para dados. É um formato para documentos”. Explicou ainda que as pessoas estão acostumadas a fechar pdfs para trocar documentos pela web, mas que os pdfs podem ser construídos com metadados e, se utilizados de maneira correta, podem ajudar na transparência pública.

Mais: blog dele na adobe, só sobre o pdf

Porque a fala do Jim King foi legal? Porque nos alerta para o uso adequado das ferramentas. Imaginem se tudo o que está hoje em pdf estivesse em documentos word (e em suas várias versões diferentes). Eu não sou lá muito de defender a Adobe, mas não existe outro formato de documento que permita encapsulamento com segurança no controle de versão e imagens vetoriais (sim, o pdf guarda imagens em vetor! é xml!). Se o pdf nao existisse e não fosse tão bem documentado e desenvolvido, o mundo seria do pacote Office. Aí sim eu queria ver a galera reclamando de dados fechados…

O próximo post vai contar mais sobre o workshop. Aguardem o compilado…

O Workshop pôde ser acompanhado pelo Twitter, via hashtag #odw13, pelo canal no irc #odw, além de estar com todos os papers e apresentações disponíveis online no site do Workshop.

Quando o computador tornou-se realmente pessoal, o desenvolvimento de softwares cresceu exponencialmente. Uma enorme demanda de aplicativos surgia para aquele produto enorme, com monitor CRT e velocidade de processamento muito menor do que o telefone celular que está no seu bolso.

Esses aplicativos traziam novidades e surgiam para resolver problemas que ainda não tínhamos. Com o tempo, passamos a nos familiarizar com a interface desse dispositivo mas hoje, olhando para trás, é possível entender como naquela época desenvolvíamos um software pensando na máquina, e não na pessoa que faria o uso dela.

Com base nessa pequena introdução nostálgica, gostaria de fazer uma rápida analogia sobre o desenvolvimento do design responsivo de hoje com os softwares de vinte anos atrás.

Uma das grandes balelas era que podíamos fazer várias coisas ao mesmo tempo. Essa reportagem do Fantástico de 1991 mostra bem como a indústria queria nos vender a produtividade a qualquer preço, mesmo sabendo que não fazemos duas coisas ao mesmo tempo (ou você já conseguiu escrever um texto e atualizar uma planilha sem dar um ALT/Command Tab?) ou então, quando fazemos (como assistir a dois vídeos na mesma tela) não aproveitamos totalmente seu potencial.

Já na web de hoje em dia temos que nos preocupar ao carregar uma página com conteúdo desnecessário no dispositivo móvel. Não adianta querer que nosso usuário faça diversas coisas ao mesmo tempo pois vai tirar a atenção do que é realmente necessário. Se a pessoa navega por um dispositivo móvel procurando uma pizzaria, ela quer saber o endereço, ou telefone, cardápio ou preços. Uma animação em Flash não vai ter utilidade nesse momento (na verdade, nunca teve). Burocratizar o acesso no momento que o usuário mais precisa é algo que pode custar o retorno desse usuário à sua página.

Você já deve ter lido artigos sobre as iconografias em softwares. O clássico nessa categoria é o ícone de salvar dos softwares mais antigos que era representado por um disquete. Este artigo mostra que o disquete não é o único dos problemas que temos com iconografia.

Agora olhe para o dispositivo no qual está lendo esse texto. Existe uma entrada de disquete nele? Possivelmente não e é a mesma situação quando publicamos um “clique aqui” nas nossas páginas. O termo clique veio do uso do mouse, que desapareceu dos dispositivos móveis (inclusive a seta/cursor que ficava na tela). Mesmo selecionando links e acionando dispositivos com o dedo, continuamos chamando essa ação de “clicar”. O problema é quando pensamos no “clicar”, “passar o mouse”, “selecionar” para criar aplicações que não nos permitem esse recurso. Hoje nosso contato com alguns dispositivo são as pontas dos dedos, mas sabemos que isso é apenas uma questão de tempo.

E por falar em links, antigamente todos eles deveriam aparecer na primeira página do nosso site. De preferência sem barra de rolagem, claro. Hoje estamos cada vez mais eliminando conteúdo desnecessário das páginas principais e permitindo que o usuário consiga buscar e até mesclar informações que sejam relevantes, muito melhor do que deixá-lo procurando conteúdo na página principal. Veja por exemplo como era a página principal do “Cadê?” em 2000 comparada com a interface do Google de hoje.

Todos os exemplos que citei foram para reforçar a teoria de desenvolvimento com foco no ser humano. Não sabemos quais os dispositivos que permitirão o acesso ao nosso site/aplicação no futuro. Qual foi a sua reação quando encontrou no seu analitics o primeiro usuário de tablet ou de videogame navegando na sua página? E como será a nossa reação quando encontrarmos um relógio ou uma máquina de lavar dentro das estatísticas?

Essas comparações podem parecer um pouco absurdas, mas mostram o quanto o software sempre esteve mais relacionado com a máquina do que com o usuário. Enquanto tratarmos o usuário como um operador de um sistema burocrático, teremos que escrever enormes documentações sobre como operar esse sistema, que deve ser mais intuitivo e menos complicado como eram há 20 anos atrás. E isso é o nosso dever. Transformar a experiência do usuário em nossas páginas o foco principal do desenvolvimento web.

Tenho falado bastante da importância da acessibilidade na web, especialmente na estrutura e semântica do código HTML: cabeçalhos, tabelas, textos alternativos em imagens e muitos outros recursos para deixar o markup robusto e acessível. Mas todos eles são elementos podem ser manipulados pelo CSS de uma página e por isso devemos ter certos cuidados com a acessibilidade deles.

Softwares leitores de tela já são capazes de identificar elementos de formatação visual das páginas que não foram declaradas no HTML e sim no CSS, como tipo e cor de fonte por exemplo. Por esse motivo existem questões relacionadas a acessibilidade que estão diretamente ligadas ao CSS da sua página e vão muito além do uso de cores nas suas páginas Web.

Gostaria de elencar aqui alguns pontos importantes para a criação de páginas web acessíveis voltados diretamente ao uso do CSS, mas antes de começar vale lembrar da máxima de sempre separar as camadas de estrutura (HTML) da apresentação (CSS) da sua página web. Faça toda a formatação visual/layout dentro do CSS e deixe o HTML para a estrutura do seu documento.

Contraste

Sua paleta de cores deve prever o contraste adequado entre os elementos da página, e tudo isso deve ser considerado no seu CSS. Fundos e elementos devem um contraste de pelo menos 4,5:1 para uma visualização adequada. O E-mag publica em sua última página uma tabela de referência para textos em preto ou branco com fundos coloridos que auxilia muito essa tarefa.

Pseudo elementos :before e :after

Servem para inserir conteúdo adicional antes e depois de determinados elementos em sua página web via CSS. Esse recurso deve ser utilizado com cuidado pois nem todas as tecnologias assistivas/leitores de tela conseguem ler os conteúdos inseridos antes ou depois do texto. O ideal é utilizar pseudo-elementos apenas para uso estético e design e não para inserir conteúdo importante da sua página web. Existe um ótimo artigo da Lucica Ibanescu explicando e mostrando como os leitores de tela interagem com pseudo-elementos.

Links

É importante que o seu usuário saiba que aquele texto em destaque é um link e não precise ficar vasculhando a página para procurar um texto com link para outra página. Jacob Nielsen publicou em 2004 um artigo com orientações para a criação e customização de links em sua página, como por exemplo não sublinhar textos que não são links e usar cores diferentes para links visitados.

Convulsões

O WCAG 2.0 deixa bem claro que devemos ter cuidado para não criar conteúdos que possam causar convulsões em usuários com fotossensibilidade, como telas que piscam muito rápido ou efeitos luminosos estroboscópicos. Com a possibilidade de fazer animações em CSS3, essa recomendação também serve para a criação de efeitos nas folhas de estilo.

Conteúdo invisível

Existem diversas formas de esconder o conteúdo de uma página web. Alguns deles podem ser acessados por tecnologias assistivas por isso vale a pena verificar se o que você quer esconder em sua página deve ou não ser lido por softwares leitores de tela. Este artigo de Jonathan Snook explica bem cada uma das técnicas.

Foco nos elementos

Localizar onde está o foco em uma navegação via teclado de uma página cheia de links é uma tarefa complicada quando o foco não dá destaque para o elemento selecionado. Destacar o foco dos elementos beneficia não só pessoas que navegam por links mas auxilia o preenchimento de formulários, facilitando a localização do foco em determinados campos.

Viu como acessibilidade no CSS vai muito além de questões com cores? Posicionamento de elementos, tamanho de fontes e linhas também devem ser considerados no seu projeto web. Vale lembrar que hoje desenvolvemos pensando em uma plataforma da web, a Open Web Platform e não somente no HTML5 ou no CSS3. A Web de hoje vai muito além do código HTML e sua acessibilidade deve ser ampliada para toda a sua plataforma para que a web seja efetivamente para todos.

O ano de 2012 ficou marcado para o meu histórico profissional. Nesse ano pude perceber como a comunidade web é unida e como as pessoas que me inspiraram a seguir esse caminho estão mais próximas e acessíveis do que eu poderia imaginar. Esse ano foi um ano de grandes realizações: Prêmio Nacional de Acessibilidade, criação do Grupo de Trabalho de Acessibilidade na Web, Conferência Web W3C Brasil, TPAC, Participação em diversos eventos e muitas outras conquistas, mas a maior delas foi trazer para perto do W3C Brasil os grandes nomes que inspiraram minha vida profissional.

Meu momento “Epic Win” foi conhecer pessoalmente e trocar algumas palavras com Sir Tim Berners-Lee, o criador da Web. Em uma conversa de alguns minutos conseguimos falar sobre WWW2013, Rio de Janeiro e sobre coisas que ele esperava da conferência e desse país que ele já visitou algumas vezes. Foi ótimo conversar com o homem que criou esse universo chamado web, e que sem sua criação eu provavelmente  estaria trabalhando fazendo CD-Roms interativos utilizando Director.

Gostaria também de falar sobre algo marcante na Conferência Web W3C Brasil 2012. Essa conferência tem a cara da comunidade de desenvolvimento. Todos os nomes envolvidos na organização e nas palestras são consagrados no mundo do desenvolvimento, mas eu gostaria de comentar sobre a importância do Keynote Speaker da conferência.

Lembro no meu início de carreira, em meados do ano 2000 quando eu ia assistir aos tradicionais “Encontros Nacionais de Webdesign” para ver o que os grandes nomes ligados a Web estavam fazendo. Eu já tinha assistido pelo menos duas palestras do Luli Radfaher, que no início dos anos 2000 já tinha escrito dois livros sobre design para Web. Chama-lo para participar de uma conferência do W3C Brasil foi um marco na minha vida e prova como a Web é capaz de nos aproximar das pessoas que nos inspiram.

Por falar em livros, não posso deixar de citar o grande dinossauro da Web. Foi nesse ano que eu conheci pessoalmente o Maujor na BrazilJS. Bater um papo com o homem que escreveu os livros que praticamente todos nós desenvolvedores lemos durante a nossa carreira foi incrível. Os livros do Maujor sempre foram como aquelas cartilhas básicas que todos devem ler antes de entrar para a escola. Além de um grande escritor e conhecedor da web, é uma figura sensacional. Fiquei extremamente feliz em participar de um vídeo especial de final de ano na sua presença (e de outros grandes nomes da Web).

Usei muitas referências da Web para estudar e aprender um pouco mais sobre desenvolvimento. Lá pelo ano de 2004, enquanto eu desenvolvia aquele monte de páginas em tabelas  encontrei um website de alguém que convertia sites  para o novo conceito (na época) chamado Tableless, e que também publicava artigos sobre Web Standards. Hoje o Tableless é uma referência em padrões web e ser convidado pelo Diego Eis para escrever posts para esse site, que ajudou a construir minha carreira, é uma honra.

Outra grande referência da qual pude fazer parte foi o IMasters. Lí muitos artigos e discuti nos fórums desse site nos primórdios da internet enquanto estudava para trabalhar com Web. Hoje também tenho textos publicados lá e uma ótima parceria com todos.

Mas acho que a grande vitória do ano foi aproximar mais a comunidade de desenvolvimento ao W3C Brasil. Eu poderia citar uma lista enorme de pessoas que trabalharam junto conosco nos Grupos de Trabalho, na participação da Webbr, nos eventos dos quais participamos e nos diversos projetos que fizemos em conjunto nesse ano, mas esse post ficaria gigantesco. A essas pessoas, que também chamo de mestres, também dedico esse post com muito carinho.

Eu não sou um grande apreciador de doces, mas uma das minhas sobremesas preferidas é o popular creme de mamão papaia com licor de cassis. Sempre achei que essa era a combinação perfeita para uma sobremesa, especialmente no calor. Mas o mamão papaia é um grande injustiçado. Se você perguntar para qualquer pessoa o nome de uma sobremesa feita com mamão papaia, com certeza a grande maioria vai dizer “creme de papaia com licor de cassis”. Falta de criatividade? Pois é. O mesmo acontece com a API de Geolocalização do HTML5.

Sim, a API de Geolocalização (documentação mantida pelo W3C Geolocation Working Group) acaba sendo sub-aproveitada em diversos projetos. Faça pesquisa rápida no escritório ou uma busca pelo Google que você vai se deparar com uma grande quantidade de exemplos utilizando Geolocalização baseadas simplesmente na interface do Google Maps para obter sua localização atual. Uma ótima utilização da API, mas não a única.

Da mesma forma que existem diversas de receitas de sobremesa utilizando mamão papaia, existem diversas aplicações interessantes para o uso da API de Geolocalização. Basta exercitar a criatividade. Não estou dizendo que uma aplicação que identifica minha localização seja inútil. Pelo contrário. Consigo identificar serviços e estabelecimentos próximos de forma muito precisa. Mas podemos ir um pouco além.

Veja este exemplo de Trip Meter. Utilizando a API de Geolocalização você consegue identificar sua localização inicial e comparar com a localização final e ainda incrementar com o tempo percorrido, pontos turísticos interessantes, etc. Nesse mesmo exemplo, você pode fazer um cruzamento de dados e calcular a previsão do tempo da cidade que você está passando nesse exato momento. Muito útil para acompanhar todo o seu itinerário de viagem.

Mas e no meu dia-a-dia, como fazer uso da API de Geolocalização de uma forma mais útil? Bem, você pode criar um website de venda de produtos que pode utilizar a localização do usuário para determinar o custo do frete, ou um conversor de moedas extrangeiras por exemplo. Pode ainda criar um sistema para verificar disponibilidade de vagas em hotéis ou aluguel de casas conforme a localização do usuário. Pode parecer estranho uma pessoa chegar a uma cidade sem ter hotel reservado, mas não é. Uma pesquisa feita em 2010 pelo site MalaPronta.com mostra que 67% dos usuários do site fazem a reserva do hotel com menos de 30 dias de antecedência. Já uma pesquisa feita pelo website Trip Advisor aponta que grande parte de seus usuários utilizam dispositivos móveis para planejar suas viagens. Ainda sobre viagens, outra pesquisa mostra que hospedes preferem Wifi do que qualquer outro serviço do hotel. A internet móvel possibilita aplicações inimagináveis na web.

E como anda o suporte a API de Geolocalização nos dispositivos? Bem, seu status atual de Canditata a Recomendação no W3C pode dar uma idéia. Fazendo uma rápida pesquisa pelo CanIUse.com podemos ver que mais de 80% dos navegadores pesquisados dão suporte a API (inclusive os browsers de dispositivos móveis). Mas e sobre a minha privacidade? A especificação é bem clara: User agents must not send location information to Web sites without the express permission of the user. A escolha de permitir ou não o compartilhamento da sua localização está nas mãos do usuário.

Fazer uso dos recursos do HTML5 é muito mais simples do que se imagina. Com um pouco de JavaScript você pode começar a brincar e fazer experimentos com essa API identificando latitude, longitude e integrando com o Google Maps para começar. Esse é apenas o primeiro passo.

Você vai ver que utilizar a API de Geolocalização do HTML5 é mamão com açúcar (Desculpe. Não podia deixar esse trocadilho fora do post).

Durante a semana de 29 de outubro a 2 de novembro acontece o TPAC – A plenária técnica do W3C internacional onde são discutidos os detalhes dos padrões durante cinco dias, com grande parte dos grupos de trabalho reunidos presencialmente para garantir o desenvolvimento da Web.

Eu e a Yaso participamos de algumas sessões durante esses dois dias, especificamente das reuniões dos grupos de CSS e Protocols and Formats. Gostariamos de resumir rapidamente alguns pontos importantes das reuniões.

CSS WG

O dia começou com uma rápida discussão sobre Auto-Generation, baseado por essa contribuição ao grupo. O objetivo era discutir as regiões que ocupam mais espaço do que o conjunto fixo de regiões, se nesse caso deveriam ser criadas novas regiões automaticamente ou não. Foi sugerido que ele deveria ser tratado como qualquer outro elemento que receba uma grande quantidade de conteúdo e foi decidido que as regiões devem manter o processo de manipulação de quantidades arbitrárias de conteúdo em uma cadeia região, mesmo no caso de uma quebra de página como qualquer outro elemento.

Em seguida os Chairs do grupo de HTML5 se juntaram a reunião para discutir questões do HTML5 relacionadas ao CSS. Paul Cotton e Philippe Le Hegaret indagaram ao grupo sobre determinadas especificações que poderiam ficar fora do HTML5 caso o grupo não as fechasse em tempo hábil. A discussão partiu para um ponto de colaboração mútua e que ambos os grupos se aproximarão mais para alinhar detalhes dos dois padrões.

A sequência da reunião foi para o fechamento de “bugs”. Alguns deles tiveram a seguinte conclusão: O BUG 15824 sobre se regiões devem ou não criar um novo contexto de empilhamento. Foi decidido manter a especificação, onde todas as regiões criam contexto de empilhamento para os elementos fluírem entre eles.

O próximo tema abordado foi CSS Masking, que define como esconder certos conteúdos utilizando máscaras. Ficou decidido que seriam incluídos alguns novos valores a especificação.

Foram discutidos ainda alguns tópicos relacionados a CSS e SVG. Existe um interesse de integração futura maior do CSS com SVG, apesar de algumas diferenças dificultarem essa integração. Mais adiante essa discussão continuaria.

Partindo para animações, foi discutida a questão de mudanças dinâmicas em propriedades de animação ou keyframes. Depois de diversas discussões sobre performance e como lidar com pausas e re-início de animações, foi decidido que o @keyframe pode ser alterado dinamicamente. Ainda sobre animações, foi discutido se deve-se definir o ativamento de eventos para animações em execução no pseudo-elementos. Em uma rápida discussão, foi decidido que ele deve ser uma cópia sobre a informação do pseudo-elemento de eventos de transição para eventos de animação. Um último ponto sobre animações foi a questão de duplicar os nomes de animação, baseado nessa questão sobre a repetição de “animation-name” na lista de animações. Foi decidido que o comprimento da “animation-name” deve ser autoritária. Outras propriedades de animações também são ajustados no seu comprimento. No caso de encontrar múltiplos nomes de animação, o último vence. A discussão continuou porque não parecia muito claro como isso resolveria o problema e mais testes foram sugeridos, mas foi decidido que propriedades de animação devem ter valores iniciais e finais de progresso considerados.

No dia seguinte a discussão sobre animações continuou. Foram discutidas questões sobre propriedades de tipos de animações e elementos que possam ser animados. A reunião passou por pontos de gradiente em CSS, SVG e finalmente para cores, e foi decidido que animações com cores devem ser em espaços já pré-multiplicados.

Um ponto interessante do segundo dia foi a discussão da seleção de um texto dentro de um elemento. Foi colocado que se uma elipse estiver destacada, o texto deveria ser selecionado também, pois é esperado pelo usuário, mesmo que isso hoje não aconteça com todos os navegadores. Dessa forma, o grupo decidiu que no caso de uma elipse que esteja selecionada, o texto também deve ser selecionado.

A reunião continuou, abordando detalhes sobre CSS3, especialmente em SVG e Math, como por exemplo a questão de se adicionar ‘display: svg’ e ‘display: math’ ou algo parecido quando necessário em algum ponto. Outros pontos foram discutidos e decididos detalhadamente de forma detalhada durante o dia.

Os logs do IRC do grupo de CSS estão nos links abaixo:

• Log das reuniões do WG-CSS – Primeiro dia (em inglês)
• Log das reuniões do WG-CSS – Segundo dia (em inglês)

Protocols and Formats WG

O grupo de Protocols and Formats é composto por membros da Iniciativa de Acessibilidade do W3C (WAI). Durante dois dias eles discutiram tópicos de relevância para a acessibilidade na Web e promoveram testes em especificações de WAI-ARIA para garantir sua acessibilidade.

No primeiro dia o grupo discutiu a possibilidade de acrescentar um recurso de alto contraste (high-contrast) dentro do CSS. O objetivo é possibilitar que desenvolvedores possam fazer modificações de contraste em media queries. Foi comentado que não seria razoável que os desenvolvedores proporcionassem diversos tipos de alto contraste ao usuário, como exemplifcado neste website. Foram discutidas algumas possibilidades de configurações e valores de atributos de contraste e até a possibilidade de trocar imagens de fundo quando utilizado o modo de alto contraste @media screen.

A discussão ainda deve continuar sobre sua implementação, que deve seguir para o Grupo de Trabalho de CSS.

Durante a tarde a reunião seguiu para testes de WAI-ARIA. Foram feitos diversos testes exaustivos para verificar a acessibilidade de certos papéis (roles), estados (states) e propriedades (properties). Os testes foram feitos em ambiente restrito, mas foi possível entender como criar exemplos simples para testar elementos utillizando WAI-ARIA. Conseguimos acessar as áreas de teste e levar para o Brasil exemplos que possam ajudar a criar um repositório e um ambiente para testes das tecnologias discutidas pelo W3C nesse grupo.

No segundo dia a reunião deu continuidade aos testes do dia anterior. Eles tinham mais de 700 testes para fazer em exemplos de documentação, que pudemos acompanhar o processo. O mais interessante é que além de tecnologias para validar código e a acessibilidade do elemento, pessoas com deficiência participaram testando e comentando sobre como cada novo elemento/atributo poderia (ou deveria) se comportar no acesso de determinada tecnologia assistiva/navegador.

Developers MeetUp

Na noite de 2a feira, o W3C promoveu um Developers MeetUp, no centro de Lyon. Foi um evento não só do TPAC, mas com a comunidade de desenvolvimento web de Lyon. Durante o evento, ocorreram algumas apresentações muito interessantes relacionadas a novas tecnologias e experimentos utilizando a invenção de Tim Berners-Lee.

Uma delas, da empresa 109Labs foi o projeto Oh My Toast, que utiliza a web semântica para juntar fotos e informações para o usuário gerar um album de fotos recheado de informação relacionada.

A apresentação seguinte contou uma breve história do web design fluído. De forma bem divertida e ilustrada, foi apresentado como o CSS se comporta desde sua criação com tamanhos de telas e resoluções diferentes, até chegar no que chamamos hoje de “Design Responsivo”. A navegação por essa apresentação não será completa se você não redimensionar a janela do seu navegador enquanto assiste.

Logo em seguida foi apresentado o Tea ebook Open Reader. Um modelo de leitor de e-books totalmente aberto, utilizando padrões da Open Web. O mais interessante desse projeto é a comparação feita pelo apresentador com os aplicativos fechados: O HTML5 tem grandes vantagens em seu uso, como não necessitar de instalação, atualizações instantâneas e não ter necessidade de pagar uma taxa para as lojas de aplicativos (dentre outras vantagens).

A open web continuou sendo destaque na apresentação seguinte. Na palestra HTML5 is Sexy Criss Milles da Opera mostrou diversas aplicações utilizando recursos da Open Web. Algumas delas foram um Piano e uma persiana em CSS3, um vídeo com legendas sincronizadas e experimentos utilizando GetUserMedia, como esse Photo Booth e esse bigode em webcam. Tudo muito interessante, mas bem próximo dos experimentos que foram apresentados na Conferência Web W3C Brasil 2012. Isso significa que estamos no caminho certo.

Em seguida, foram apresentados alguns cases utilizando renderização 3D dentro do browser. Jogos que antigamente precisavam de placa aceleradora de vídeo e instalação de dezenas de megabytes hoje rodam dentro de um browser na web.

As últimas apresentações da noite foram voltadas para mobile web. A primeira delas mostrou algumas aplicações que utilizam a especificação de DeviceOrientation para manipular páginas web. Em uma delas o apresentador manipulava seu telefone celular enquanto exibia um resultado dentro de um browser em outro computador. Muito interessante, mas mais um experimento que pôde ser visto durante a Conferência Web W3C Brasil 2012. Para encerrar a noite, representantes da Mozilla apresentaram seu sistema operacional para telefones celulares desenvolvido em HTML5. O recado dado por eles era: Tudo o que é desenvolvido para esse dispositivo é livre e aberto.

Após as apresentações, tivemos a oportunidade de nos apresentarmos oficialmente a Tim Berners-Lee como membros do W3C Brasil e parte do time que organiza a conferência WWW2013. Conversamos um pouco sobre Dados Abertos e da iniciativa brasileira de incluir o tema na Lei de Acesso à Informação, além de falar da ótima participação de Jeanne Holm no Decoders e na Conferência do W3C Brasil.

Por último, a Developer Relations Lea Verou apresentou a plataforma para documentação das principais ferramentas da Open Web. O objetivo foi apresentar mais claramente para os desenvolvedores a importância desse tipo de iniciativa e especialmente espalhar esse tipo de documentação pelo mundo. Tradução colaborativa foi um grande pedido para os desenvolvedores de todo mundo, especialmente do Brasil.

Por trás de uma máquina, alguém faz perguntas sem sentido, com a intenção de descobrir se você é uma pessoa ou robô. Não estou falando do interrogatório do caçador de andróides, entre Rick Deckard e Rachael durante uma sequência do filme Blade Runner, de 1982. Estou falando de um ser humano que está fazendo uma compra em uma loja online em 2012. Estou falando do CAPTCHA.

O CAPTCHA, acrônimo de “Completely Automated Public Turing test to tell Computers and Humans Apart” é um teste cognitivo criado para evitar que robôs preencham campos de formulários, especialmente para o envio de spams. Segundo a definição da Wikipedia, “Como os computadores são incapazes de resolver o CAPTCHA, todo usuário que incorpora uma solução correta é presumidamente humano”, significa que quem passar no teste do formulário é um humano, certo? Errado.

Em 2011, uma equipe da Universidade de Standford desenvolveu técnicas para quebrar os mais conhecidos CAPTCHAs disponíveis na web, e o resultado foi assustador: 66% dos “Captchas” usados pelo Authorize.net foram quebrados pela técnica e quase todos os desafios do site da CNN foram solucionados. Resumindo, estamos permitindo que robôs acessem o conteúdo que devia estar disponível somente para as pessoas.

Esse artigo da Lêda Spelta e do Horácio Soares da Digital Acesso explica com detalhes as diversas barreiras que os CAPTCHAs criam em nome da segurança. São várias técnicas ineficazes criadas para proteger o sistema de invasores e robôs que estão barrando o acesso de seus usuários. Nesse mesmo artigo os autores abordam com mais profundidade detalhes sobre outras pesquisas e estudos e comentam sobre a decisão da BBC de abolir o CAPTCHA de suas páginas.

Além da grande barreira de acessibilidade, já que os CAPTCHAs tradicionais não costumam ser acessíveis, novas modalidades de CAPTCHA mais difíceis vem sendo criados para evitar que robôs consigam acessar seus formulários, mas alguns exemplos mostram que isso está se tornando mais difícil para o usuário tambem.

É o caso desse exemplo, desenvolvido em um formato de “jogo” para facilitar a conclusão das tarefas. Ele é inacessível para um usuário que não consegue utilizar um mouse, como uma pessoa com deficiência visual ou tetraplegia. Para minimizar essa questão, os desenvolvedores criaram um ícone de acessibilidade, que pede para o usuário escutar um som incompreensível e digitar alguma palavra em uma caixa de texto.

Enquanto algumas empresas buscam técnicas cada vez mais complexas para evitar que robôs acessem o conteúdo da sua página, algumas optam por fazer o mais simples e acessível. É o caso do formulário de contato do Instituto Faber Ludens, que utiliza uma pergunta simples em modo texto para verificar se não somos robôs preenchendo um campo de formulário. Um usuário que utiliza um software leitor de tela, por exemplo, consegue facilmente preencher esse campo. A mesma criatividade para desenvolver CAPTCHAs inacessíveis pode trazer ótimas soluções para garantir a segurança dos sistemas sem barrar o acesso das pessoas.

A web é feita de pessoas e para pessoas. O acesso a informação de qualquer lugar é uma vitória que hoje nós temos que comemorar. Estamos construindo uma web para as pessoas que deve ser segura, mas que não deve criar barreiras de acesso para os seres humanos. Quem sabe, muito antes desse futuro não tão distante previsto por Ridley Scott, eu não tenha mais que provar para uma máquina que eu sou um ser humano.

Lembro que em meados de 2005 eu começava minha carreira de designer de interfaces cuidando do que se tornaria  a multimídia da Agência Brasil, produzindo sites, infográficos e visualizações para a agência de notícias do governo. Naquela época a gente ouvia falar do W3C através do difícil e temperamental selo validador de acessibilidade – tableless estava recém entrando na moda. ActionScript era arroz com feijão, o Flash comia solto e as tabelas também, porque simplesmente não tínhamos como fazer diferente ainda.

Mais de cinco anos se passaram desde então. Enquanto eu tentava virar uma designer de verdade, o mundo mudou rápido: os smartphones se transformaram na principal atração para desenvolvedores; a Apple enforcou o Flash; os EUA e a União Européia entraram em crise e ficaram pobres; o agile veio tomar conta dos ambientes de desenvolvimento; Steve Jobs morreu, Dados Abertos governamentais tornaram-se o centro das atenções desde que Obama abriu os dados dos Estados Unidos e o Brasil passou a ganhar prêmios internacionais de produção de vinho. É exatamente nesse mundo de cabeça para baixo que começo a trabalhar no W3C Brasil.

Cartinha da Adobe pra Apple

A estrutura do W3C é bem parecida com a de qualquer outra comunidade de Software Livre: nada é hierárquico o suficiente para gerar concentração de poder e tudo é  livre. Funciona com base na boa e velha lista de discussão e do bom e velho IRC.

O W3C existe da vontade de manter a internet cada vez mais aberta, livre e acessível para que possa continuar sendo uma plataforma de troca de conhecimento, comunicação e inovação. É uma rede de pessoas e instituições interessadas em gerar benefícios para todos a partir da internet livre, aberta e acessível.

O escritório do W3C aqui no Brasil conta com uma equipe pequena, mas multi-disciplinar: Reinaldo Ferraz, o popstar-acessibilidade; Caroline Burle, a especialista em politicas internacionais; Eduardo, o estagiário e o Vagner Diniz, nosso gerente que mais parece o Dr. House abrasileirado.

W3C contra a parede

É uma infinidade de projetos, todos interessantes, cada um cuida de alguns vários. Entre Dados Abertos e a Open Web Plattform o lema é “internet aberta para todos”.  É sempre bom navegar por ai pra conhecer mais sobre tudo isso.

W3C Dr. House

Enfim, trabalhar no W3C Brasil é um desafio interessante. Ainda mais nesse momento onde a web se espalha com ares de ficção científica em equipamentos ubíquos, no contexto de um país onde ainda existe uma grande parte da população que nem sequer tem telefone analógico. É quase como escavar a parede, escalando.

Pra quem quiser saber mais sobre o W3C Brasil, aqui vai link para os Grupos de Trabalho, nosso Twitter, a página no Facebook, links para os padrões de A a Z e link pro site do evento internacional do ano que vem (a WWW13, no Rio de Janeiro). Até eu preciso navegar para entender melhor o tamanho do W3C no mundo, mas enquanto ainda não consigo resumir tudo em um desenho, me resta estudar…

Ontem presenciei um momento histórico para a web brasileira. Um momento que vai ficar guardado na minha memória e no meu coração como um dos grandes momentos da minha vida. Foi a cerimônia de premiação do primeiro Prêmio Nacional de Acessibilidade na Web, o todos@web. Um marco na história da web brasileira que tive a honra e o prazer de fazer parte. Gostaria de compartilhar um pouco os sentimentos envolvidos nesse grande momento da web brasileira.

Fiquei muito feliz de ver o rosto de muita gente conhecida que sempre esteve envolvida com a acessibilidade, mas fiquei mais feliz ainda de ver tantos rostos novos. Novos para mim, mas que já fazem grandes trabalhos em favor da acessibilidade na web. Trabalhos que eu nunca tinha visto e que surpreenderam a todos. Foi uma experiência incrível ver tanta gente trabalhando para um bem comum: A acessibilidade na Web.

Ela foi a grande estrela da noite: A acessibilidade na web. Foi vendo as lágrimas de algumas pessoas durante o evento pude notar o impacto de uma premiação como essa. Cada pessoa que vinha conversar e parabenizar pelo prêmio vinha com um enorme sorriso, como se previamente me dissesse “pode contar comigo!”. A nossa luta ganhou novos militantes.

E militantes é a palavra certa, e também muito interessante. Lembro-me quando meu amigo Carlinhos Cecconi me disse uma vez que “trabalhar no W3C é uma militância”. Concordo plenamente com suas palavras. É impossível se envolver com o trabalho do W3C sem mergulhar de corpo e alma em cada projeto, e é assim que me sinto quando participo de algo tão importante como esse prêmio. Um militante que ganhou uma batalha.

Ainda não ganhamos a guerra, mas ganhamos novos guerreiros para lutar pela acessibilidade na web. Militantes que fazem parte de governos, agências e até voluntários. Tudo isso pela paixão que move as pessoas em tornar o mundo um lugar melhor, e se pudermos fazer a nossa parte dentro da web, acho que já estamos dando um grande passo.

Os grandes vencedores desse primeiro Prêmio Nacional de Acessibilidade na Web já foram divulgados. São grandes trabalhos e ações que provam que existem pessoas que lutam por uma web justa, e especialmente, por uma web para todos.

Por isso a noite de ontem foi especial. Para quem é um aproximado pela acessibilidade na web, sabe do que eu estou falando. Que venha o Segundo Prêmio Nacional de Acessibilidade na Web!

Você se lembra do filme De Volta para o Futuro? Nele, Marty McFly, um adolescente que vive em 1985, viaja ao passado e interfere no namoro dos seus pais. Ao final do filme, depois de voltar do passado, o seu amigo e cientista Doctor Brown o chama para viajar ao futuro e evitar que seu filho se envolva em altas confusões. Esse é o início do segundo filme, que leva Marty McFly, sua namorada e o Doctor Brown trinta anos no futuro.

Isso mesmo, Marty e seus amigos pousarão seu famoso DeLorean daqui três anos, mais precisamente no dia 26 de outubro de 2015.

Infelizmente eles não encontrarão skates flutuantes, tênis que se amarram sozinhos e carros voadores, mas encontrarão um futuro onde pessoas compartilham interesses em redes sociais, manipulam e conectam dados de qualquer assunto em qualquer lugar pelos mais diversos dispositivos.

A grande novidade será a web. Marty chegará em um mundo dominado pela interoperabilidade, pelo acesso a informação em qualquer lugar e em qualquer dispositivo. A discussão de que o HTML5 é o futuro da web vai ser coisa do passado, algo bem 2011. O HTML5 estará cada vez mais presente nas páginas e sistemas web e muito mais incorporada aos dispositivos. Especialistas acreditam que pelo menos 50% das aplicações comerciais para dispositivos móveis sejam baseadas em HTML5 em 2015.

Para quem tinha como grande anúncio tecnológico de 1985 o lançamento do Windows 1.0, Marty se surpreenderá com o que ele mesmo será capaz de fazer com um computador. Jogos baseados em HTML5 crescerão mais ainda em 2015, sem que ele precise instala-los em seu computador. Aliás, ele não estará preso somente ao computador. Telefones celulares, tablets e outros dispositivos que hoje nós nem imaginamos que existirão em 2015 nos permitirão acesso a web. Televisões, aparelhos de som e até geladeiras já acessam a rede hoje em 2012, e o que podemos esperar para daqui três anos? Mesmo que Hill Valley seja uma cidade pequena, será muito simples ter acesso a um local ou dispovitivo com acesso a web.

Marty também nem precisaria comprar o tal Almanaque de Esportes, que causou tanto problemas em seu retorno a 1985. Uma rápida busca na web daria todas as informações necessárias sobre resultados dos jogos de qualquer campeonato passado. Mesmo o velho Biff poderia ter impresso alguns resultados de almanaques online em 2015 para ajudar a sí mesmo no passado. Dados conectados de diversas fontes facilitariam ainda mais o acesso a essas informações.

Enfim, Marty chegaria em um mundo muito diferente da realidade de 1985, onde a maioria dos telefones celulares tem câmera e boa parte deles com um GPS embutido, e o acesso a informação estará disponível por esses telefones, dispositivos esses que já tem muito mais processamento que certos computadores de 1985.

Se você encontrar Marty passeando aí por perto em 2015, convide-o para participar da sua rede social, mas lembre-se: Nunca chame um McFly de “franguinho”.