Wikipédia:Esplanada/propostas/As páginas precisam ser acessíveis e semanticamente corretas! (13mai2012)

As páginas precisam ser acessíveis e semanticamente corretas! (13mai2012)

Proposta

Proposta resumida: que tal aumentar a importância de Wikipédia:Acessibilidade? Como isso pode ser feito?

Proposta detalhada: apesar de ser recomendado que o conteúdo da Wikipédia seja acessível, há páginas destacadas contendo partes que não cumprem requerimentos. Por exemplo, em certos casos há pouquíssimo contraste entre a cor do texto e a cor do fundo, o que é reprovado pelas orientações de acessibilidade do conteúdo web (WCAG, em inglês - e ainda não há um artigo em português). Isso pode ser verificado por meio de ferramentas como esta.

Citando o Redrose64: cores são legais, desde que não causem problemas de acessibilidade. Mas infelizmente não é o que ocorre nos artigos sobre o carnaval:

Será que os leitores devem ser punidos por causa das cores escolhidas para "representar" as escolas? (que talvez sejam boas para serem identificadas de longe mas certamente NÃO para serem usadas em uma enciclopédia!)

Atualmente é isso o que ocorre:

  • São usadas cores incompatíveis em GRCES Independente Tricolor#Carnavais
  • Ocorre o mesmo em GRES União da Ilha do Governador#Carnavais
  • As referências, que são essenciais, ficam praticamente invisíveis no artigo sobre GRCES Príncipe Negro
  • O mesmo tipo de problema se repete em todos, digo quase todos, os artigos sobre Carnaval e é incentivado pelo "manual do estilo"
  • Usam-se códigos obsoletos (como por exemplo as tags depreciadas <font>, <center> e <big>, ou os atributos color e bgcolor ), e toleram-se assinaturas que propagam o seu uso (é só olhar as esplandas)
  • Formata-se o texto com códigos que foram feitos para fins semânticos (e não estéticos) em vez de usar CSS para isso.
  • Muitas tags são abertas (digamos, com <span>) sem jamais serem fechadas apropriadamente (no exemplo, com </span>). Isso provavelmente impedirá a sua edição com o Editor Visual, por exemplo, já que o código wiki está incorreto)

Uma das propostas de reformulação da visão do movimento Wikimedia diz o seguinte:

"Imagine a world where every person has free access to the sum of all knowledge. That is our goal."

Se esse for o caso, e o objetivo for mesmo garantir esse "acesso", pelos exemplos acima ainda há muito o que fazer.

Algumas possibilidades:

  1. Não incentivar violações dos princípios de acessibilidade?
  2. Na falta de tempo/vontade/conhecimento para escolher cores apropriadas, deve-se preferir as cores usuais?
  3. Tornar a acessibilidade algo primordial para que uma página seja destacada?
  4. Criar predefinições (de manutenção) para marcar páginas que tenham partes inacessíveis?   Feito: {{Problemas de acessibilidade}}
  5. Proibir o uso de códigos obsoletos nas assinaturas?
  6. Melhorar a documentação relacionada à acessibilidade?
  7. Alguma outra coisa?

Helder 14h30min de 13 de maio de 2012 (UTC)[responder]

As ferramentas podem ser adicionadas a Wikipédia:Escolha do artigo em destaque/Ferramentas para artigos em destaque. WP:Acessibilidade já é uma recomendação, por isso pode ser usada para avaliar artigos destacados. Pode ser acrescentado algo em WP:AD?, mas na verdade julgo que era melhor simplificar o texto ali (tem uma secção para Wikificação e outra para ligações internas, mas segundo WP:WKF são a mesma coisa) e remeter para o guia de estilo. WP:Acessibilidade, aliás, deveria estar no livro de estilo. GoEThe (discussão) 20h38min de 13 de maio de 2012 (UTC)[responder]
Seria tão bom se existisse um bot a rodar (automaticamente?) sempre q se abrisse uma nova EAD e verificar algumas coisas mais automáticas, como uso de font (depreciada), o padrão de cores (pela mesma conta q essa ferramenta indicada), tamanho do artigo, links para desambig, nº de imagens (em fair-use e em licença livre), talvez uma lista de palavras a evitar (só para alguém conferi-las), links quebrados, existência de seção (subseção) sem ref, refs mal formatadas (só a url), padronização de datas nas refs (umas com 01-01-2011 outras 1 de janeiro de 2011), etc, etc, e colocasse um relatório direto na EAD. Assim quem fosse olhar a EAD já saberia q essas coisas já foram avaliadas e podiam se concentrar no resto (completo / português). E o proponente teria uma avaliação mais imediata dessas coisas podendo arrumar logo os problemas mais fáceis. Rjclaudio msg 02h24min de 14 de maio de 2012 (UTC)[responder]
Isso parece mais ou menos o mesmo que a "avaliação automática"...
A lista não seria Wikipédia:Palavras a se tomar cuidado? Helder 21h29min de 14 de maio de 2012 (UTC)[responder]
Sim essa lista mesmo, achei q tinha um redirect.
A ideia é +- a avaliação automática, só que não seria uma avaliação no sentido de dar uma nota automática para a qualidade do artigo, seria indicadores e um relatório na EAD para ajudar a avaliação humana. Se tiver um bot rodando sempre nas EADs para ver se o artigo tem os itens depreciados e avisando o resultado na EAD os usuários nunca mais iriam precisar olhar isso na EAD, poderiam fazer outras coisas. Temos a ferramenta no toolserver q verifica se tem algum link externo quebrado, se um bot verificasse isso e colocasse o report na EAD seria mais fácil (não teria nenhuma EAD em q isso não fosse verificado) e evitaria trabalho dobrado (não precisada cada votante clicar no link para ver, e tendo algo errado alguém corrige e marca q tá corrigido). Se no relatório do bot falasse q tem algo de errado, isso não iria impugnar a EAD nem nada, seria apenas uma avaliação do bot, um comentário como de qualquer outro usuário, e os outros votantes iriam avaliá-lo e melhorar o artigo se fosse o caso. Ao menos me parece q ajudaria, e teria uma recepção / utilidade maior q a avaliação automática atual para os níveis 1-4 (q não é um comentário/relatório é uma avaliação mesmo). Rjclaudio msg 22h00min de 14 de maio de 2012 (UTC)[responder]
Em relação as possibilidades já elencadas concordo com todas mas acho que faz bem dividir o problema em partes para facilitar o tratamento. Começaria apenas pelo primeiro e o segundo que é uma consequência direta.OTAVIO1981 (discussão) 13h19min de 14 de maio de 2012 (UTC)[responder]
Sou a favor da remoção das tabelas coloridas. A predefinição {{Info/Carnaval}} já possui campo para cores, a poluição visual artigos sobre escolas de samba é horrível. Já removi uma vez, mas como no caso citado acima um "IP" apareceu e recolocou. Fabiano msg 22h30min de 14 de maio de 2012 (UTC)[responder]
Citação: Não deve ser utilizada nessa tabela nenhuma cor que não uma das cores oficias da escola, a menos que para evitar poluir o visual do artigo ou impossibiliar a leitura. Deve ser dada preferência à combinação de uma tonalidade mais clara com outra mais escura. Em casos onde uma escola possua somente cores claras ou somente cores escuras entre as saus cores oficiais, poderá ser ignorada esta regra a fim de beneficiar a visualização do conteúdo. escreveu: «Manual»
Não vejo como problema o Manual, porque ele mesmo já diz que se ferir a acessibilidade "poderá ser ignorada esta regra" Concordo que seria o caso em GRES União da Ilha do Governador e GRCES Príncipe Negro, mas basta mudar as tonalidades escolhidas. Em GRCES Independente Tricolor não vi problemas, se bem que não entendi porque essas cores, se as cores da escola são "vermeho, preto e branco", segundo o artigo. Também não vi muitos problemas com o artigo da Mancha onde o verde e o vermelho não fazem contraste com o outro. Helder, ao invés de retirar como fez, bastaria mudar o verde pra um tom mais claro, assim não ofuscaria o azul-escuro das notas de rodapé, ou se não fosse suficiente, retirava o fundo verde e punha apenas a fonte verde sobre um fundo branco. O resto eu não entendi qual seria a mudança. Mário Henrique (discussão) 13h07min de 17 de maio de 2012 (UTC)[responder]
O par de cores "#FFCC66" e "#FF0000" (que foi usado no GRCES Independente Tricolor) não passa em nenhum dos testes de Acessibilidade Web realizados com esta ferramenta.
Acho que quem foge do padrão (que é acessível) é que deve se dar ao trabalho de procurar cores não padrão que sejam (no mínimo) adequadas (isso se houver um bom motivo para fugir do padrão, o que não é o caso). Não vejo um motivo válido para que se faça um carnaval de cores nas páginas de uma enciclopédia (séria). Além disso, trocar a formatação padrão das tabelas por "aquilo" que está lá, piora muito a qualidade das versões impressas em escala de cinza (alguma outra enciclopédia tem esse "bom gosto" para a escolha de esquemas de cores? E se tiver, será que alguma editora deixaria isso passar para a versão final? Duvido muito...).
PS: Se quiserem podemos fazer um apelo à autoridade e pedir umas dicas para alguém que entenda dessas coisas (o mw:User:Trevor Parscal, por exemplo, que mudou o esquema de cores dos "diffs" recentemente). Helder 14h56min de 17 de maio de 2012 (UTC)[responder]
Não existe nenhum motivo para as tabelas serem coloridas. A informação consta na Infobox, o que considero suficiente. Sou a favor das tabelas adotarem a cor padrão como é feito em todos os outros artigos. OTAVIO1981 (discussão) 16h37min de 17 de maio de 2012 (UTC)[responder]
  • No artigo GCERES Protegidos da Princesa a tabela de enredos é de quase impossível leitura, em SBCC Império da Zona Norte adota preto para se tornar legível porém as cores da escola são amarelo, branco e prata. Este tipo de coisa foi debatido na época em que cada clube de futebol tinha uma tabela de cores no topo da página com campos diferenciados a gosto de cada torcedor, a colocação da predefinição {{Info/Clube de futebol}} criou um padrão, não vejo uma razão que justifique as tabelas coloridas. O gosto pessoal de "enfeitar" as páginas, não é uma razão suficiente para manter. A seção enredos deve chamar atenção pelo seu conteúdo e não pelo impacto visual que causam nos artigos prejudicando principalmente os leitores. Fabiano msg 22h25min de 18 de maio de 2012 (UTC)[responder]
    Concordo com as propostas, e com o que tem sido dito, ainda que defenda que isto possa ser levado mais longe. A wikipédia portuguesa parece uma árvore de Natal. A legibilidade não se aplica apenas ao uso de cores contrastantes. Aplica-se ao uso de qualquer cor injustificadamente. Está mais que provado cientificamente, e acho que ninguém tem o desplante de contestar isto. que a melhor leitura possível é obtida num texto preto sobre fundo branco ou, em alternativa, texto branco sobre fundo azul para quem apresente dificuldades de visão, sobretudo astigmatismo.
    Partindo desta base, toda e qualquer inclusão de cor devia ser mais do que justificada porque está a quebrar um dos princípios básicos da legibilidade e design gráfico, citado acima. Sem uma justificação plausível e lógica, toda a inclusão de cor deveria ser suprimida. "Gostar" ou "fica bonito e diferente", tal como disse o Fabiano, não são razões. "Ter cores ligadas ao tema", como as cores das escolas de carnaval, ou infoboxes de televisão verdes só porque sim. também não são justificação. O texto e as caixas devem ser o mais próximas possível do padrão de leitura, e o destaque de cor deve ser dado às imagens ou gráficos que existam no artigo.
    Há evidentemente, justificações plausíveis, mas que são muito poucas. Uma tebela pode conter células verdes e vermelhas se isso ajudar à percepção imediata dos valores sim/não em tabelas comparativas como, por exemplo, aqui. A {{Info/Taxonomia}} faz também recurso de um código internacional de cores consoante os reinos das espécies; mas isso é uma coisa sistematizada e não ao gosto do freguês. A en.wiki tem isto tudo padronizado e sistematizado. As infoboxes são todas iguais em termos gráficos e qualquer inclusão de cor tem que ser mais do que justificada, e quase sempre não o é. A info/futebol parece-me um bom exemplo de uma coisa bem conseguida, sobretudo quando o maior problema da pt.wiki é lidar com histeria de fãs e bairrismo, que querem encher tudo com as cores do que gostam, pouco se importando com o conjunto da wikipédia.
    Proponho que saia daqui uma recomendação muito mais ampla, em vez de uma que simplesmente se refira às "cores contrastantes". Proponho que em todos os aspectos gráficos dos artigos (texto, infoboxes e tabelas) seja adoptado o conjunto de cores com melhor legibilidade (letras pretas sobre fundo branco ou creme claro), exigindo aprovação e consenso relativamente ao uso de outras cores, e nunca em tabelas excepto o verde/vermelho do caso do sim/não. Polyethylen (discussão) 23h31min de 18 de maio de 2012 (UTC)[responder]
      Concordo com tudo o que foi dito acima, e deixo mais um exemplo: {{30 Rock}} (ver aqui), em que um editor insiste em mudar a cor das ligações internas do azul/vermelho padrão para tudo preto... EuTugamsg 21h55min de 21 de maio de 2012 (UTC)[responder]
Já passou um bom tempo desde q a proposta foi criada. O que vai sair daqui? Tem consenso para alguma mudança? No mínimo dos mínimos as cores dos Links internos não devem ser modificadas, e vamos mudar a {{30 Rock}} para aplicar a nova (na verdade devia ser antiga) regra. Rjclaudio msg 16h23min de 9 de junho de 2012 (UTC)[responder]
Note que se não for permitido alterar a cor do texto dos links, será preciso alterar a cor do fundo para que fique com contraste suficiente com o azul usado por padrão.
Por hora eu tentei pelo menos remover alguns usos de códigos HTML obsoletos que aparecem no "manual de estilo" usado nos artigos sobre o carnaval (sem alterar a aparência da tabela). Mas ainda faltaram algumas remoções. Também falta remover os problemas com o contraste entre as cores das letras e do fundo da tabela. Tentei fazer as alterações por meio de expressões regulares (indiquei no sumário de cada edição) para que elas pudessem ser reutilizadas para fazer isso em massa nos artigos, pois é muito repetitivo. Só que não vai ser fácil, pois há grandes chances de encontrar falsos positivos...
Talvez devêssemos pedir para que um robô coloque a tag {{wikificação}} na seção "Carnavais" de todos os artigos sobre o carnaval que contenham "<font", "bgcolor" e/ou "align", pois aparentemente todas as tabelas precisarão do mesmo tipo de correção que fiz hoje (entre outras). Helder 21h18min de 9 de junho de 2012 (UTC)[responder]
Citação: Helder escreveu: «Note que se não for permitido alterar a cor do texto dos links, será preciso alterar a cor do fundo para que fique com contraste suficiente com o azul usado por padrão.» - isso significa que só se pode escolher uma cor de fundo que dê um bom contrate para o azul padrão. Continuamos mantendo a proibição de alterar a cor dos links. Transformar em regra então, onde que escrevo isso, lá em Acessibilidade mesmo? Rjclaudio msg 12h17min de 15 de junho de 2012 (UTC)[responder]
Acho que isso pode ser colocado na Wikipédia:Acessibilidade, e mencionado em qualquer outro manual do estilo específico de algum wikiprojeto (como o do carnaval) em que use cores diferentes do padrão, ou faça alguma menção ao assunto. Helder 19h30min de 15 de junho de 2012 (UTC)[responder]
Tudo bem se for solicitado que um robô coloque a tag de wikificação em casos como este? Helder 18h46min de 27 de junho de 2012 (UTC)[responder]
  • Bem, eu concordo que há tabelas com cores exageradas ou inapropriadas. No entanto, sou contra retirar todas as cores de todas as tabelas, pois essa decisão, que vai causar forte impacto visual, não pode ser decidida assim, num pequeno tópico da Esplanada. Por outro lado, sou a favor de remover códigos obsoletos, como os que foram retirados pelo Helder, e um bot para por tags de wikificação em todos esses artigos onde os códigos estão obsoletos seria muito interessante. Todos deveriam ser wikificados seguindo o modelo do Helder. BelanidiaMsg 10h17min de 12 de junho de 2012 (UTC)[responder]
    Apesar de estar melhor, eu ainda não chamaria aquilo de "modelo", pois com tantas diferenças em relação ao formato padrão usado nas wikis, o código fica monstruoso, ao contrário do que ocorreria se fossem utilizadas classes CSS como a "wikitable" (disponível no próprio MediaWiki), ou outras criadas especificamente para a Wikipédia lusófona (no Mediawiki:Common.css) por serem amplamente utilizadas em grande parte dos artigos. Mas isso não é possível se cada artigo usar um formato diferente, como nos relacionados ao carnaval.
    O que é preciso para que este tópico deixe de ser pequeno? Divulgar em algum outro lugar? Transformar em votação? Helder 19h30min de 15 de junho de 2012 (UTC)[responder]
    Não vejo nenhuma razão para votação e nem que a remoção das "árvores de natal multicoloridas" possa trazer lago negativo para o projeto. As páginas da Wiki devem ser acessíveis a todos os leitores, que presumo com uma certa doze de certeza estão interessados nos textos e não nos jogos de cores utilizados que tem como único objetivo de enfeitar as páginas. Fabiano msg 23h49min de 15 de junho de 2012 (UTC)[responder]
Aliás não entendo para que colocar cores nas tabelas dos artigos de escola de samba, esteticamente fica horrível, e na prática não tem benefício algum, e vale a mesma coisa para outras páginas, como artigos de vários clubes de futebol, e séries como o "Power Rangers". Mas se necessário, poderiam ao menos utilizarem cores mais suaves, como as utilizadas nas tabelas de medalhas dos artigos dos Jogos Olímpicos. Eric Duff disc 03h39min de 17 de junho de 2012 (UTC)[responder]

  Concordo Eu até hoje ainda não havia consultado nenhum daqueles artigos sobre escolas de samba, mas ao ler esta proposta fiquei (negativamente) impressionado com o uso abusivo que se tem feito das cores, naqueles artigos. Em qualquer enciclopédia séria, as cores de cada escola de samba seriam exibidas apenas na ilustração da logomarca ou da bandeira da escola, e pronto. Não no corpo do texto e/ou em tabelas e afins. Fica esteticamente horrível, pouco legível (consequentemente pouco acessível) etc. Ainda que se tente argumentar que as cores são usadas para "destacar a identidade da escola", ou algo de semelhante natureza, não se justifica fazer o que vem sendo feito, porque, além da questão da acessibilidade e da estética, o artigo não pertence à escola e não é uma página pessoal ou da escola, mas um artigo enciclopédico. E a mesma lógica vale para todos os artigos sobre bandas de música e quaisquer outras escolas, agremiações, associações, grupos, clubes, confederações etc. que porventura sejam ou venham a ser identificadas por algum grupo de cores e, por conta disto, o(s) autor(es) dos respectivos artigos wikipédicos porventura tenham colorido o todo ou parte daqueles artigos com as tais (respectivas) cores. Não dá mesmo.Sampayu msg 19h59min de 1 de julho de 2012 (UTC)[responder]

Cores

Falando em cores, os (todos) anexos de episódios tem algumas cores, uma cor para cada temporada, e a escolha das cores não tem relação alguma com a série, é bem aleatória. Tem isso até nos anexos destacados, como Modern Family, iCarly e Star Trek: The Original Series. Nesse último a segunda temporada está em azul, o que atrapalha ver que tem referências. Tb é para retirar o carnaval ali, deixando só uma cor? Uma cor padrão para esses casos? Ou ali o detalhe é 'pequeno' e pode ficar? Rjclaudio msg 20h06min de 1 de julho de 2012 (UTC)[responder]

Esses exemplos não parecem ser tão graves, pois além de ser (bem mais) discreto em comparação com as tabelas do carnaval, aparentemente a cor está sendo usada para facilitar a distinção entre as partes do artigo que falam sobre cada temporada, mas essa informação (isto é a "separação entre as temporadas") já é transmitida ao leitor de outra forma, a saber, por meio da organização do conteúdo em seções (uma para cada temporada), com as tags que atribuem este significado ao texto: <h3>isto</h3> (que é o mesmo que ===isto===).
Os links para as referências realmente ficam pouco perceptíveis sobre aquele fundo azul. Mas para esse problema, há algumas opções:
  1. Aumentar o contraste entre os dois tons de azul, deixando o do fundo um pouco mais claro (inclusive, isso poderia ser sugerido nas outras wikis, pois usam a mesma cor)
  2. Mover a referência para um lugar mais adequado (as células de dados que precisam de referências, em vez das células de cabeçalho), onde permanece em uso o fundo branco.
  3. Uma alternativa mais radical seria apresentar essa informação ao leitor como na wiki alemã: sem incluir formatação supérflua, e aproveitando ao máximo as folhas de estilo (no caso, a definição da classe "wikitable") que os leitores já são obrigados a baixar quando acessam qualquer artigo (inclusive os artigos em que as classes não são usadas!).
Por outro lado, ainda não vi sequer um artigo de escola de samba que fosse diferente do tipo de coisa que na wiki inglesa seria marcado com {{Colorido demais}}. Na verdade, por aqui talvez {{Cuidado! Não tente ler sem óculos escuros!}} seria um nome mais apropriado para uma predefinição similar. Helder 03h15min de 3 de julho de 2012 (UTC)[responder]
Não vejo problema nenhum as cores ficar de acordo com a escola, acho que tem muitas coisas do Projeto Carnaval a serem debatidas, do que isso. como: Os critérios de notoriedade, pois tem usuários aqui na wikipédia, que se baseiam em critérios que não se compoem com as de carnaval. ecom os critérios de notoriedade sobre carnaval com certeza eles veriam na hora para eliminar por votação.ok!!!---Biantez msg 0h07min de 9 de julho de 2012 (UTC)
Isto aqui não é uma discussão relativa de modo exclusivo ao projeto carnaval e sim ao projeto em geral. A acessibilidade serve para os leitores e não exclusivamente para usuários do projeto. Até agora nenhum argumento em favor as árvores de natal foi diferente de "eu gosto", "eu não vejo problemas", "eu", "eu" e "eu". O projeto não é feito para os "eus" e sim para os leitores e entre eles tem os que tem problemas visuais que devem ser respeitados na hora de se formatar a Wikipédia. Fabiano msg 00h15min de 9 de julho de 2012 (UTC)[responder]
Com base nesta lista de páginas que usam mais do que 10 tags <font>, dá para perceber que não é só nos artigos sobre o carnaval que há problemas e exageros na formatação. Há uns 1700 artigos na lista, e a maioria é sobre carnaval ou futebol. Apesar de "uso de HTML obsoleto" ser diferente de "uso de cores problemáticas", ambas as coisas parecem ocorrer nos mesmos tipos de artigo, então ocorrências do primeiro tipo de coisa servem como indício de artigos que podem ter o segundo problema. Helder 00h49min de 9 de julho de 2012 (UTC)[responder]
Eu não tou perguntando se e do projeto carnaval, o que estava dizendo que não faz sentido discurssar sobre cores de tabelas, ao invés dos critérios de notoriedade, que são mais importante e mais importante do que se essas cores não condiz ou não? ok!!!---Biantez msg 2h52min de 9 de julho de 2012 (UTC)
Citação: Biantez escreveu: «Não vejo problema nenhum as cores ficar de acordo com a escola, acho que tem muitas coisas do Projeto Carnaval a serem debatidas, do que isso.» Repetindo isto não tem relação com critérios de qualquer coisa e sim de questões técnicas de funcionamento da Wikipédia em benefício de seus leitores. Fabiano msg 21h18min de 9 de julho de 2012 (UTC)[responder]
Por outro lado, também não faz sentido discutir a notoriedade de algo que não se consegue ler. Helder 14h55min de 19 de julho de 2012 (UTC)[responder]
Acho que o mais sensato é fazer o que está dito na seção sobre cores das navboxes no manual de estilo da wiki inglesa. O terceiro item, em particular, indica o que fazer em relação às cores que identificam o tema do artigo:

Uma cor "apropriada e representativa", quando destinada a identificar-se com o logotipo ou a marca da organização, deve usar a cor acessível mais proeminente da logo. Por exemplo, a Template:Pink Panther deveria estar usando um fundo com a cor F6D4E6 (a cor do corpo da Imagem:Pink Panther.png) em vez de E466A9 (a cor de fundo daquela imagem). Uma cor representativa também pode ser aquela presente na infobox de um artigo (se houver uma). Por exemplo a navbox associada com Registro Nacional de Lugares Históricos (NRHP)s e outras categorizações relacionadas deveria se adequar a legenda de cores do NRHP da Wikipédia.

Na ausência de uma cor apropriada, usam-se as cores usuais das navboxes.
Em relação às cores dos links, en:Wikipedia:Link color diz:

Os links devem ser claramente identificáveis como links pelos leitores, então não tente disfarçar um link como se fosse texto normal nem usar cores estranhas nos links sem nenhuma boa razão para isso. Ver também as recomendações sobre o contraste e as cores das navboxes.

Helder 14h55min de 19 de julho de 2012 (UTC)[responder]
Talvez devêssemos copiar/adaptar o guia para a escolha de cores e recomendar o seu uso por quem alterar o esquema padrão de cores do MediaWiki (em artigos e em páginas importantes como Wikipédia:Portal comunitário, os portais, etc..). Isso também ajudaria a garantir que o esquema resultante tivesse cores consistentes entre si. Helder 15h53min de 19 de julho de 2012 (UTC)[responder]

Tabelas

Vi que Don't Wanna Go Home, atual EAD, tem o align=center/left nas tabelas da seção "Desempenho nas tabelas musicais", então deve ter vários artigos de música com isso. Me parece algo simples de detectar, então eu poderia arrumar com meu script. Como q arruma isso? Rjclaudio msg 01h39min de 2 de julho de 2012 (UTC)[responder]

Fiz a correção desse problema naquele artigo (mencionei no sumário as expressões regulares que usei para facilitar). Helder 16h25min de 2 de julho de 2012 (UTC)[responder]

O align q foi depreciado tb é do q aparece no início das tabelas, como em {| class="wikitable" style="text-align:center" , ou só os que aparecem nas linhas das tabelas? Rjclaudio msg 01h43min de 2 de julho de 2012 (UTC)[responder]

Todos os usos do atributo "align=..." estão depreciados. Geralmente pode-se usar style="text-align: ..." no lugar (text-align, não está depreciado). Helder 16h25min de 2 de julho de 2012 (UTC)[responder]

Fiz mais algumas melhorias e simplificações na tabela que serve de exemplo tem sido usada como base nos artigos sobre o carnaval. Apesar de estar um pouco mais próxima de se tornar um modelo, ainda há alguns problemas que precisam ser resolvidos em relação ao uso indevido de HTML para fins de formatação (em vez de usá-lo para dar significado/semântica ao conteúdo):

  1. Qual a finalidade que se pretende alcançar colorindo as tabelas daquele jeito? Há alguma?
    1. Se houver, o uso de cores é o melhor que se pode fazer em uma enciclopédia? (eu acho que não!)
    2. Caso seja, ainda assim é preciso garantir:
      1. Que as cores escolhidas para o fundo e para o texto tenham um contraste suficiente (as do exemplo não têm!)
      2. Que o tal objetivo seja alcançado mesmo que a página seja vista sem as cores (lembrem-se das versões impressas, dos leitores de tela, das pessoas com problemas de visão, e que se os desenvolvedores da versão mobile da Wikipédia decidirem remover todos os estilos em linha das páginas, deveríamos ser capazes de transmitir a informação relevante para o leitor)
      3. Que a solução escolhida seja aplicável a todos os artigos, para que não se misture o código das páginas com estilos em linha em vez de classes CSS que possam ser definidas no MediaWiki:Common.css (e que sejam úteis não só no caso dos artigos sobre o carnaval, pois o CSS global é carregado em todos os artigos, mesmo os que não utilizam as classes definidas lá!). Por exemplo, não faria sentido definir uma classe para cada cor (se todas as variações de cor/estilo estão sendo utilizadas apenas para destacar algumas linhas em relação às demais, crie-se por exemplo UMA classe "destaque" com UM estilo específico a ser usado quando for preciso DESTACAR linhas de tabelas por algum motivo).
      4. Que continua sendo possível distinguir os links para páginas existentes e inexistentes (que, por padrão, são vermelhos)
  2. Nessas tabelas sobre o carnaval, a sintaxe "!", que serve para indicar quais linhas de uma tabela representam uma célula de cabeçalho da mesma (em HTML, <th>s) em vez de uma célula de dados, está sendo usada para formatar em vez de para dar significado (isto é, está sendo ignorada a semântica dessas tags e criando-se diversos "cabeçalhos" para as linhas correspondentes aos anos em que as escolas foram campeãs, sendo que isso já é indicado em uma das células da linha).
  3. Esqueci de algum problema?

Helder 14h58min de 2 de julho de 2012 (UTC)[responder]

A título de curiosidade: com o que foi corrigido na tabela que está no manual de estilo do carnaval, o tamanho do código wiki do artigo GRES Em Cima da Hora passou de 43119 para 25299 bytes, o que representa uma redução de mais de 40%! E isso foi em um único artigo! Helder 16h47min de 2 de julho de 2012 (UTC)[responder]

Tabela de exemplo

Peço desculpas, mas não serie melhor adotar algo mais simples e com menos poluição visual como por exemplo:

Unidos da Wikipédia
Ano Colocação Grupo Enredo Carnavalesco Ref.
2045 Campeã Principal e Anexos Por uma Wikipédia legível Alguém de bom senso "Acessibilidade"
  • Cores somente no título; o resto todo num padrão simples e acessível a qualquer pessoa que deseje adicionar novas informações nos artigos e não tem a menor noção de como formatar estas árvores de natal em tamanho menor, como a que foi adicionada no projeto carnaval para servir de exemplo. Fabiano msg 03h40min de 3 de julho de 2012 (UTC)[responder]
Já seria muito melhor!
Mas o Brion levantou uma questão que parece ser mais problemática que as cores em artigos como estes: o leiaute feito com as tabelas não escala bem para quem usa a versão mobile da Wikipédia.
PS: note que as células da última linha não deveriam começar com "!" (pois não são cabeçalhos) mas sim com "|" (são apenas céluas de dados). Isso provavelmente fica mais perceptível para quem usa leitores de tela[carece de fontes/testes]. Helder 04h04min de 3 de julho de 2012 (UTC)[responder]

Que tal este? Ou qualquer formato que deixe o mínimo de cores e mais fácil edição. Fabiano msg 05h24min de 3 de julho de 2012 (UTC)[responder]

Unidos da Wikipédia
Ano Colocação Grupo Enredo Carnavalesco Ref.
2045 Campeã Principal e Anexos Por uma Wikipédia legível Alguém de bom senso "Acessibilidade"
Fiz uns ajustes no seu segundo exemplo:
  • Removi o atributo obsoleto "width="100%"" e defini a propriedade "width:100%" no estilo em linha (atributo style);
  • Removi a propriedade "text-align: left;", já que mesmo sem ela o texto das células continua alinhado à esquerda (deve ser o padrão), o que a torna supérflua.
  • Troquei "colspan="10"" por "colspan="6"", pois só há 6 colunas na tabela
  • Troquei #ffffff por #fff, pois são equivalentes e a segunda versão é mais curta (e isso faz mais diferença quando a cor é alterada muitas vezes)
Há algum motivo específico para que o conteúdo das tabelas tenha um tamanho menor?
Convém observar que se for feita essa redução (no exemplo, "font-size: 85%;"), não deverá ser usada a tag <small> dentro das células, porque as reduções de tamanho se acumulam, e isso diminuiria a legibilidade do texto.
Também seria bom escurecer um pouco mais o azul (talvez #04B em vez de #06C?) Helder 12h52min de 3 de julho de 2012 (UTC)[responder]

Quais estilos de tabela nós temos definido no nosso commons? Tem alguma página mostrando exemplos dos estilos que temos? Não dá para aproveitar nenhum dos estilos atuais, precisaria criar outro? Se formos criar, qual nome seria? Rjclaudio msg 14h49min de 3 de julho de 2012 (UTC)[responder]

Toda instalação do MediaWiki vem com a wikitable, a "mw-collapsible" e companhia (cujo uso não se restringe às tabelas), a "sortable" a "mw-datatable" (exemplo), a "filehistory" e a "mw_metadata" (usadas somente nas descrições das imagens - exemplo) e por aí vai.... Mas cada wiki pode definir classes adicionais que se aplicarão ao projeto como um todo. Aqui na Wikipédia lusófona a MediaWiki:Common.css atualmente só possui três classes que alteram o formato padrão das tabelas: a "navbox", a "metadata", e a antiga "prettytable" (que foi depreciada em favor da "wikitable", que por usa vez foi incorporada ao próprio software MediaWiki em março de 2009). Mas notem que elas tem em comum o fato de que são úteis à maior parte dos artigos (a ponto de justificar a sua presença nos artigos que não as utilizam - ainda não há como definir folhas de estilos que sejam carregadas apenas em algumas páginas). As folhas de estilos específicas dos skins (MediaWiki:Vector.css e MediaWiki:Monobook.css) não têm nenhuma classe relacionada às tabelas no momento.
Se for para definir novas classes, é bom ter em mente que o nome deve refletir o significado (semântica) daquilo que for marcado com tais classes (descrevendo o conteúdo), e não com a aparência (pois essa pode mudar com o tempo). Então, por exemplo, coisas como "aviso", "nota", "erro" são nomes aceitáveis, enquanto que "sublinhado", "vermelho" e "bordas-coloridas" não são. Ver [1] para mais detalhes sobre isso.
Helder 17h17min de 3 de julho de 2012 (UTC)[responder]
Unidos da Wikipédia
Ano Colocação Grupo Enredo Carnavalesco Ref.
2045 Campeã Principal e Anexos Por uma Wikipédia legível Alguém de bom senso "Acessibilidade"

A cores para mim são dispensáveis, se for como o modelo acima já está ótimo. Nos modelos anteriores copiei as cores do modelo sugerido no projeto carnaval. Como já citei anteriormente a {{Info/Carnaval}} já apresenta a opção para colocação de cores é isto é mais do que suficiente na minha opinião. Fabiano msg 22h32min de 3 de julho de 2012 (UTC)[responder]

Aqui o exemplo de como ficaria a adoção deste modelo. Fabiano msg 22h46min de 3 de julho de 2012 (UTC)[responder]
Nossa, ficou bem mais agradável de se ler o artigo, aliás eu até tiraria aquele laranja da tabela de enredos. Eric Duff disc 02h16min de 22 de julho de 2012 (UTC)[responder]
De fato. A relação de contraste entre as duas cores está bem abaixo do aceitável (1.76, sendo que a WCAG exige no mínimo 4.5). Helder 13h31min de 22 de julho de 2012 (UTC)[responder]

Há consenso então? Posso aplicar nas tabelas do carnaval? Rjclaudio msg 21h05min de 24 de julho de 2012 (UTC)[responder]

Assinaturas

Adicionei em Wikipédia:Regras para assinaturas a regra

"5. Acessibilidade: A assinatura deve seguir as regras de acessibilidade."

Assim não precisa repetir todas as regras de acessibilidade nas regras para assinatura.

Coloquei em Wikipédia:Acessibilidade#Tags depreciadas uma lista de códigos depreciados no HTML 5 (pela fonte q o Helder indicou lá no início).

Então vamos começar a mudar as assinaturas? Aviso na esplanada/anúncios + predef de aviso? Rjclaudio msg 20h18min de 1 de julho de 2012 (UTC)[responder]

Concordo com avisar, pois o que temos de gente usando a tag <font> não é brincadeira. !Silent (discussão) 20h38min de 1 de julho de 2012 (UTC)[responder]
Fato! Helder 21h38min de 1 de julho de 2012 (UTC)[responder]
É melhor avisar sim.
O único "porém" é que quando se usa estilos em linha (isto é, "style=...", em vez de classes e estilos definidos nas folhas de estilo globais e pessoais) é que quem altera a cor do texto do link da assinatura com [[link|<span style="color:cor;background:#fff;">texto</span>]] não tem como mudar a cor do sublinhado padrão (que está no link <a>, não no <span>!) que aparece ao passar o mouse (por algum motivo obscuro a cor definida na <font color="..."> sobrescrevia a da <a>). Mas isso não é desculpa para usar códigos obsoletos, na minha opinião (e se a pessoa se incomodar com o sublinhado, é só definir um CSS pessoal - não há um concurso de beleza das assinaturas). Parece que os devs têm intenção de permitir a <a> no código wiki, e se isso ocorrer o <span> provavelmente deixará de ser necessário para alterar a cor do texto.
Em todo caso, acho que é bom colocar no aviso um exemplo típico do que precisarão alterar nas assinaturas, isto é, dizer que em vez de coisas como
<font color="black" face="Verdana" size="3">Fulano</font>
deve ser usado algo como
<span style="color:#000;background:#fff;font:122% Verdana;">Fulano</span>
pois a primeira versão usa 4 coisas depreciadas: font, color, face e size. Helder 23h02min de 1 de julho de 2012 (UTC)[responder]
É bom reforçar que sempre que se altera a cor do texto, é preciso definir a cor do fundo para garantir que haverá contraste entre as duas (pois há quem use um tema/skin em que as cores são invertidas, e a cor do seu texto poderia tornar-se indistinguível da cor preta usada no fundo nesses temas). O tema padrão do MediaWiki já faz isso, mas quem insiste em fugir do padrão é responsável por garantir que não há perda de acessibilidade do conteúdo. Helder 13h41min de 22 de julho de 2012 (UTC)[responder]
Fiz uns ajustes na lista de tags que inseriu, incluí também alguns exemplos de atributos obsoletos. Helder 21h38min de 1 de julho de 2012 (UTC)[responder]
PS: Acho que é sensato proibir somente as tags que são obsoletas tanto em HTML4 (atualmente em uso nas wikis) quanto em HTML5, pelo menos até que estejamos efetivamente utilizando HTML5 nas wikis da WMF. Por exemplo, <big> era considerado válido em HTML4, mas deixou de ser no HMTL5. Então é melhor não proibir (ainda). Helder 21h46min de 1 de julho de 2012 (UTC)[responder]
Bom, conforme informado no café dos progradores as páginas da Wikipédia passaram a ser produzidas em HTML5 desde a semana passada. Helder 18h56min de 23 de setembro de 2012 (UTC)[responder]

Como fica os arquivos de discussões passadas? Vai ficar sem acessibilidade mesmo, ou teria q criar um bot para tornar as assinaturas antigas mais acessíveis? Rjclaudio msg 21h58min de 1 de julho de 2012 (UTC)[responder]

Bom, nem todas as alterações são triviais para automatizar a conversão, mas as que forem poderiam ser colocadas nas listas de tarefas complementares que os bots realizam quando já estão fazendo alguma coisa nas páginas. Helder 22h02min de 1 de julho de 2012 (UTC)[responder]

Monitoramento das páginas com problemas de acessibilidade

Já que não parece haver dúvidas quanto a existência de artigos pouco acessíveis (e não são poucos), criei a {{Problemas de acessibilidade}} para marcar especificamente os problemas de acessibilidade (em vez da wikificação em geral), e colocar as páginas problemáticas na Categoria:!Páginas com problemas de acessibilidade. Vou pedir para que um robô coloque-a nas páginas relacionadas ao carnaval que tiverem códigos depreciados como "<font", "bgcolor", "align", etc... Helder 18h09min de 1 de julho de 2012 (UTC)[responder]

Fiz o pedido na coordenação robótica. Helder 20h11min de 1 de julho de 2012 (UTC)[responder]
Inclui alguns códigos depreciados no meu scriptawb (o regex q sugeriu na coordenação robótica), vou distribuir a tag de acessibilidade em alguns artigos aleatórios q for passando. Se tiver um regex mais completo, q pegue mais problemas, só avisar q adiciono. Rjclaudio msg 21h33min de 1 de julho de 2012 (UTC)[responder]
Há alguma cópia pública do seu script? Helder 19h04min de 17 de julho de 2012 (UTC)[responder]
Nops. Eu tinha umas no megaupload mas depois q acabou por lá. Recomenda algum lugar para eu fazer o upload e manter atualizado? Rjclaudio msg 19h11min de 17 de julho de 2012 (UTC)[responder]
Em que formato está? Qual é o tamanho? Não tem como ser mantido em uma página wiki? Helder 19h26min de 17 de julho de 2012 (UTC)[responder]
xml, cerca de 3,5 mb, pelo tamanho fica ruim manter na wiki, demora para abrir / editar / atualizar. Rjclaudio msg 19h37min de 17 de julho de 2012 (UTC)[responder]
Talvez no http://code.google.com/hosting/createProject ou algum outro serviço com controle de versão (github?). Helder 20h01min de 17 de julho de 2012 (UTC)[responder]
Coloquei em http://code.google.com/p/rjclaudio-awb/downloads/list . Rjclaudio msg 23h35min de 17 de julho de 2012 (UTC)[responder]
Agora há também um gadget (Wikipédia:Scripts/APC), mas falta incluir essas correções e atualizações de sintaxe. Helder 14h43min de 16 de novembro de 2012 (UTC)[responder]

Aprimoramento da documentação interna

Acrescentei mais algumas informações no manual do estilo, a respeito da alteração do estilo padrão da fonte (cores, tamanhos, etc...). Imagino que isso não seja controverso. Helder 20h11min de 1 de julho de 2012 (UTC)[responder]

Mencionei a acessibilidade nos livros de estilo de alguns WikiProjetos ([2] [3] e [4]). Helder 21h38min de 1 de julho de 2012 (UTC)[responder]
Seria útil dispormos de páginas equivalentes às seguintes:
Helder 13h02min de 13 de novembro de 2012 (UTC)[responder]

Artigos bons e destacados

Fiz uma seção nessa proposta, já que há algo relacionado com essa discussão. A proposta é acrescentar mais regras em relação a acessibilidade. A proposta foi criada por mim, junto com o Helder.wiki, em minha discussão. Espero que todos comentem sobre esses ajustes.

AB

8.1 – A relação de contraste[1] entre as cores utilizadas no texto e no fundo sobre o qual aparece deve ser superior a 4.5:1. Para medir isso, essa ferramenta será útil (assim como outras similares).
8.2 – É proibido o uso de qualquer código obsoleto[2], cuja função é melhor desempenhada por CSS. Em particular, não devem ser usados os elementos (tags) HTML <font>[3], <center>[3] e <big>[4], nem os atributos color="..."[3], bgcolor="..."[3], size="..."[3], align="..."[4] e width="..."[4]. A relação completa de elementos e atributos depreciados está disponível no site do W3C.

8.2.1 – Pode ser aberta exceção caso verifique-se que não é possível obter um resultado equivalente com códigos considerados válidos.

8.3 – É recomendável que seja utilizada a classe CSS "wikitable" para a formatação das tabelas.

AD

9 - O artigo deve ser rígido quando o assunto é acessibilidade e validade de elementos (tags) e atributos HTML:
9.1 – A relação de contraste[1] entre as cores utilizadas no texto e no fundo sobre o qual aparece deve ser superior a 7:1. Para medir isso, essa ferramenta será útil.
9.2 – É proibido o uso de qualquer código obsoleto[2], cuja função é melhor desempenhada por CSS. Em particular, não devem ser usados os elementos (tags) HTML <font>[3], <center>[3] e <big>[4], nem os atributos color="..."[3], bgcolor="..."[3], size="..."[3], align="..."[4] e width="..."[4]. A relação completa de elementos e atributos depreciados está disponível no site do W3C.

9.2.1 – Pode ser aberta exceção caso verifique-se que não é possível obter um resultado equivalente com códigos considerados válidos.

9.3 – É recomendável que seja utilizada a classe CSS "wikitable" para a formatação das tabelas.

Notas

  1. a b Ver definição, no glossário da WCAG 2.0
  2. a b Entende-se por obsoleto qualquer código que seja considerado inválido tanto em relação à especificação do HTML 4.01 quanto do HTML5, ou que era válido em HTML 4.01 mas deixou de ser em HTML5. Códigos que não eram aceitos em HTML 4.01 mas voltaram a ser em HTML 5 (como <s>, por exemplo) não serão considerados obsoletos.
  3. a b c d e f g h i j Inválido desde a especificação do HTML4.01 em 1999.
  4. a b c d e f Era aceito em HTML 4.01, mas possui equivalente em CSS e deixou de ser válido em HTML 5.

O que acham? PedRmsg 13h03min de 22 de julho de 2012 (UTC)[responder]

  Concordo, pois os bons artigos devem servir de exemplo para quem deseja melhorar outros artigos do projeto. E fugir dessas recomendações certamente piora qualquer texto. Helder 13h31min de 22 de julho de 2012 (UTC)[responder]
  • Podia permitir q os ABs usassem as tags ainda aceitas pelo HTML 4. Ou melhor o AB tb tirar isso e ser mais completo, :facilitando a vida de quem for avaliar / arrumar o artigo?
  • Não tem exceção para o AD?
Rjclaudio msg 15h45min de 22 de julho de 2012 (UTC)[responder]
A omissão da exceção no AD foi por esquecimento. Já corrigi. Helder 16h13min de 22 de julho de 2012 (UTC)[responder]
Mas a proposta não está proibindo o uso de tags aceitas em HTML 4, ou está? Helder 16h18min de 22 de julho de 2012 (UTC)[responder]
"Era aceito em HTML 4.01, mas possui equivalente em CSS e deixou de ser válido em HTML 5.". É HTML 4.01, esqueci do .01 mas vc entendeu né? Pra AB não pode usar o 'big', q era aceito no HTML 4.01. Mantém essa restrição ou permite só para AB? Rjclaudio msg 16h57min de 22 de julho de 2012 (UTC)[responder]
Ah tá, acho que eu deveria ter enfatizado o "possui equivalente em CSS". O ponto é que em geral se há duas formas de fazer algo, uma com CSS e outra com tags que são ou se tornarão obsoletas, a versão em CSS deve ser preferida (e costuma ser a mais eficiente/otimizável). Foi nesse sentido que optei por incluir exceções à proposta original do PedR. Se é possível em CSS, essa forma deveria ser preferida a não ser que haja complicações (exemplo 1 / exemplo 2 ). Helder 19h05min de 22 de julho de 2012 (UTC)[responder]
  Discordo. Cada vez mais olhamos apenas a forma e não o conteúdo de artigos destacados. E agora para destacar um artigo temos que estar de olho nas últimas inovações de códigos wiki... Parece-me muito burocrático e tende a afugentar quem se preocupa com o conteúdo. E poderia dar margem a alguém querer revalidar centenas de artigos que não usam os códigos mais recentes. Braswiki (discussão) 15h56min de 22 de julho de 2012 (UTC)[responder]
Sugere olharmos apenas o conteúdo e não olhar a forma? Se Artigo Destacado é exemplo, ele não deve ser exemplo apenas de conteúdo, mas também de forma. Temos q incentivar os usuários a não ignorarem o conteúdo.
Há usuários com conhecimento técnico que imagino estarão disponíveis e farão com prazer a revisão desses pontos e os ajustes nos artigos candidatos caso alguém peça. Então quem for destacar um artigo pode continuar se preocupando com o conteúdo e 'terceirizar' a forma para outras pessoas. Se for o caso podíamos até criar um WikiProjeto Acessibilidade + HTML para centralizar lá a discussão e os pedidos de revisão.
Tb já tem pessoas ajustando os ADs antigos, e sempre q um novo critério é aprovado há um prazo até ser permitido fazer uma revalidação, q é o prazo dado aos interessados fazerem os ajustes sem se preocupar com a pressão do tempo da revalidação.
Rjclaudio msg 16h04min de 22 de julho de 2012 (UTC)[responder]
A tarefa de fazer artigos em que não há problemas de contraste não tem nada de técnico: é só não fugir dos padrões já estabelecidos. As folhas de estilo que vêm com o MediaWiki já garantem que o formato padrão é acessível (com cores, tamanhos, espaçamentos, etc... tão adequados quanto possível). Se alguém não sabe avaliar se os desvios que pretende fazer do padrão são acessíveis, o sensato é não fazer desvios, da mesma forma que quem não sabe avaliar o impacto do AWB não o utiliza, e quem não sabe configurar predefinições não sai quebrando as que encontra pelo caminho.
As informações que são relevantes ao leitor não podem ser transmitidas apenas por meio de cores, então se não souber usar as cores adequadamente, e tiver que manter o estilo padrão, o leitor não sairá perdendo nenhuma informação importante. Se o único motivo para mudar as cores é "deixar mais bonito", será preciso que várias pessoas concordem que aquilo é bonito (pois o que é bonito para um pode não ser para outro), e se nenhuma delas sabe fazer isso, podem usar um guia para a escolha das cores, ou pedir ajuda - mas não tornar os artigos inacessíveis!
Um análogo do en:Wikipedia:WikiProject Accessibility viria a calhar. Helder 21h28min de 22 de julho de 2012 (UTC)[responder]
Há também que ser levado em conta que essas questões não são nenhuma inovação no código wiki, pois já são recomendações existentes para páginas web desde ANTES da criação da Wikipédia.
Além disso, para poder "olhar" o conteúdo, é preciso que ter acesso a ele, o que não é possível para todos se não se garante a acessibilidade do mesmo. Ou só quem não tem problema algum pode ter acesso ao melhor da Wikipédia?Helder 16h13min de 22 de julho de 2012 (UTC)[responder]
As especificações são muito técnicas, vão desanimar quem quiser destacar um artigo. Não acho que para ser destacado tenha que ter um último código wiki, que tem que ser acompanhado em site fora da wiki ou que, já que é tão complexo, a pessoa que quiser propor a destaque vai precisar sempre da ajuda de um expert. E essa regra técnica da especificação do contraste, que exige também uma ferramenta, é mais um exemplo das mil regras que criamos e tornamos isso aqui cada vez mais inacessível para leigos que querem contribuir. Braswiki (discussão) 17h03min de 22 de julho de 2012 (UTC)[responder]
Braswiki, com a ferramenta, não será preciso ter um grande conhecimento em contraste, apenas ver e medir, se é 4,5 ou 7. Um artigo não precisa ter um "ultra código wiki", apenas não ter códigos obsoletos, por motivos óbvios (e está cheio de artigos com esses códigos). Outra coisa é que não será necessário a ajuda, temos páginas e ferramentas que serão linkadas nas AD? e AB?. Qualquer coisa, devemos pedir a alguém com conhecimento para isso (não é vergonhoso e nem muito trabalhoso). Além disso, a Wikipédia não é para os escritores, mas sim para os leitores. Não adianta ser bem escrito e bem referenciado se eles não conseguirem ler certas partes do texto. PedRmsg 18h05min de 22 de julho de 2012 (UTC)[responder]
[conflito] Agora que chamou a atenção para isso, concordo que a inclusão dos itens como foram propostos tornaria os critérios muito técnicos. No entanto, considero necessário (de alguma forma) atingir dois objetivos:
  1. Explicitar que a acessibilidade é primordial em qualquer artigo, principalmente se for servir de exemplo para a construção de outros
  2. Ter uma forma objetiva de dizer o que é e o que não é problemático, para evitar divergências na hora de decidir o que é melhor para os artigos em termos de acessibilidade
Para o primeiro item, seria talvez fosse suficiente mencionar a acessibilidade nos próprios critérios, mesmo que brevemente, em vez de deixar isso escondido apenas no manual do estilo, no qual até recentemente havia apenas um parágrafo vago que nem sequer possuuia um link para a página de recomendações relativas à acessibilidade. Não é de se espantar que esses problemas tenham se proliferado para tantos artigos. Por sinal, em sua maioria o problema está justamente nas tabelas, para as quais os critérios para destacar artigos permitem exceções em relação ao "cuidado no uso" de cores. Nesse sentido, parece que para destacar um artigo bom é permitido piorá-lo, pois os critérios dos artigos bons não permitem tais exceções... Helder 18h36min de 22 de julho de 2012 (UTC)[responder]

As regras de AB e AD dizem q deve estar de acordo com todas as regras da wiki, incluindo o Livro de Estilo. O Livro de Estilo diz q deve ter acessibilidade (as cores) e deve evitar códigos obsoletos (inválidos no HTML 4.01, mas permite o q era permitido no 4.01). Então mesmo sem escrever com todas as letras nos critérios de AD/AB já se pode votar com base nisso, e se poderá revalidar com base nisso (após algum tempo, claro). Essa proposta é só para a diferença entre AB e AD, caso contrário vai valer o q está no Livro de Estilo e os critérios para os dois serão iguais. Rjclaudio msg 17h15min de 22 de julho de 2012 (UTC)[responder]

Se já está nas regras, não precisam constar de novo, apenas para desestimular quem tenta um destaque. Braswiki (discussão) 17h29min de 22 de julho de 2012 (UTC)[responder]
A proposta irá definir o quanto de contraste deve ter cada um. O artigo bom irá ter o contraste mínimo e o artigo destacado o melhor contraste. Assim fica melhor. Só não entendi uma coisa: se tiver no livro de estilo, não prejudica ninguém. Se tiver nas AB? e nas AD?, irá desestimular os escritores? Não era a regra do contraste que desestimulava isso?   PedRmsg 18h05min de 22 de julho de 2012 (UTC)[responder]
Tudo o que complica, desanima. Se estiver expresso como uma das regras específicas que o candidato vai ler para tentar destacar, desanimará mais ainda do que estando em regras genéricas. Braswiki (discussão) 18h14min de 22 de julho de 2012 (UTC)[responder]
Mas a regra é a mesma. A diferença está no nível do contraste, que é só olhar na página indicada. PedRmsg 18h20min de 22 de julho de 2012 (UTC)[responder]
[conflito] Se já está nas regras o que está escrito acima é a interpretação correta das mesmas? Isto é, as regras são claras o suficiente para que não seja possível um dizer "isso é acessível!" e outro dizer "não, não é!"? Não parecem ser, pois ainda há quem considera que é mais apropriado usar esta combinação de cores e também esta do que as cores usuais em artigos enciclopédicos, bem como fazer com que links para outros artigos e texto comum tornem-se indistinguíveis uns dos outros. Helder 18h36min de 22 de julho de 2012 (UTC)[responder]
  •   Discordo da proposta na generalidade, pelo menos na forma demasiado exigente como é colocada.   Concordo que haja mais exigência com certos detalhes técnicos e principalmente de estilo, principalmente nos AB e AD.

Vamos ser realistas e práticos: ainda hoje há a preocupação de qualquer site produzido com um pouco mais de recursos ser compatível com os inomináveis browsers antigos da Microsoft, pelo que aposto que daqui a 10 anos havemos de ter browsers compatíveis com as tags tornadas obsoletas pelo HTML 5. Por outro lado, até alguém com alguma familiaridade com HTML como eu não sabe de cor como se fazem certas coisas que foram inexplicavelmente complicadas pelo fim de certas tags: o <center> é um deles, outros são as tags extintas das tables. E falando em tables, veja-se há quanto tempo dura a campanha para que deixem de ser usadas e substituídas por divs e veja-se a quantidade de sites que as usam...

Estou à vontade para falar, pois sou dos que não terão dificuldades de maior em respeitar estas regras e, repito, acho que devem ser incentivadas, mas basta ver como ninguém liga à links em quintuplicado, "sobre-linkagem" de datas, o uso de formatos numéricos errados ou as trapalhadas relativamente comuns no uso das predefes de citação (versão arquivada no parâmetro URL, raridade no uso de Harv, etc.), para esta proposta soar como pouco consciente da realidade.

Que me perdoem a franqueza, mas num projeto onde as predefs são a miséria que se vê, onde nem sequer uma Citar decente existe, a documentação em geral e das predefs é pior ainda, inclusivamente em predefs fundamentais, onde "toda a gente" faz alterações de predefs sem as documentar, esta proposta chega a raiar o absurdo. Seria muito bom que não fosse assim...

Como o Braswiki disse, e muito bem, o enfase deve ser posto no conteúdo e não nos detalhes técnicos. E, ao contrário do que o RJ diz, não há usuários com conhecimento técnico que estarão disponíveis para rever. Muitos artigos não são sequer lidos devidamente, o conteúdo raramente é revisto... --Stegop (discussão) 18h07min de 22 de julho de 2012 (UTC)[responder]

Nesse primeiro momento podiam ser critérios mais leves, aceitando o contraste 4.5:1 e o html 4.01, q é o mínimo aceitável, deixando os critérios mais exigentes para o futuro.
A maioria do HTML depreciado vai poder ser arrumado com um script, q vai ficando melhor a cada caso não arrumado q for acrescentado as regras. As exceções serão poucas. Então será só passar o awb (ou um javascript, se fizerem) que a maior parte dos casos estará resolvida, sem problema para ninguém.
O trabalho maior ali seria verificar o contraste das cores, já q não dá para verificar automaticamente se é válido (ainda não fizeram o js/awb/py para isso), e estando errado não tem como arrumar automaticamente.
Rjclaudio msg 18h23min de 22 de julho de 2012 (UTC)[responder]
Quanto a mim, o uso de CSS em vez de center e align (este em tables) complica de sobremaneira a codificação e inclusivamente é contraditório desaconselhar-se o uso de HTML diretamente quando há opção wiki, por, entre outras razões, ser supostamente mais simples, e ao mesmo tempo obrigar a usar sintaxe HTML mais complicada. Incluiria ainda o big e o width, mas como me parece que estes raramente devem ser usados sem ser em predefs, não vejo mal em "proibi-los".
Em relação ao contraste,   Concordo com a proposta e com a indicação da ferramenta. Diga-se de passagem que o bom senso devia bastar (e no caso dos AB e EAD's geralmente bastará), mas para dirimir conflitos é bom que exista algo mais concreto. --Stegop (discussão) 20h00min de 22 de julho de 2012 (UTC)[responder]
Em que sentido o CSS complica a codificação? Os atributos obsoletos não têm como ser movidos para as folhas de estilo do site, então acabam tendo que ser repetidos em todo campo/linha/tabela/artigo em que estivesse presente (e imagine como seria o código de uma tabela para obter o mesmo resultado que se obtem apenas com class="wikitable").
Também acho que o bom senso deveria bastar, mas nem sempre ele é o bastante. Helder 21h28min de 22 de julho de 2012 (UTC)[responder]
É muito mais legível, compacto e simples e está menos sujeito a erros escrever | align=right do que | style="text-align:right;". Para centrar, por exemplo tabelas, é tudo menos intuitivo, além de que, salvo erro, o método com da div com "float:auto" (será? nem sei de cor como se faz...) não funciona com alguns browers.
Apesar de que num projeto voluntário faz pouco sentido sugerir "façam isto em vez daquilo", provavelmente seria mais eficaz, nomeadamente para dar o exemplo, virar a atenção para, por exemplo, predefs. Eu próprio faço o mea culpa, ou seja, sinto que devia ganhar alento para fazer mais nesse campo (daí ultimamente ironizar acerca da proteção a nível de sysops de algumas predefs :-), mas convenhamos que quem anda mais ligado às questões técnicas ganharia muito mais autoridade moral se tentasse que os aspetos mais técnicos fossem mais trabalhados. E admitindo que uma das motivações para a proposta é que seja diminuída a quantidade de código HTML obsoleto para os browsers, meia dúzia de alterações em algumas predefs e a execução de um par de bots, com as scripts-maravilha que alguns gurus conseguem fazer por aqui serão mais eficazes do que 20 anos de AB's e AD's. --Stegop (discussão) 21h59min de 22 de julho de 2012 (UTC)[responder]
A centralização de tabelas é com margin: 0 auto; (e a do texto é com text-align:center;). Mas, sinceramente, o alinhamento das tabelas é o menor dos problemas que quem depende desses navegadores tem Helder 23h04min de 22 de julho de 2012 (UTC)[responder]
Pelo Livro de estilo / Acessibilidade, depreciamos o uso de |align=center , sendo preferível o |style=... só q sendo mais complicado, vale a pena incentivar a troca (como eu estive fazendo pelo awb)? Para a acessibilidade isso é mesmo necessário? O mediawiki não faria a mudança/atualização de tags ele mesmo? Rjclaudio msg 00h15min de 23 de julho de 2012 (UTC)[responder]

─────────────── Acho que vale a pena dizer aqui o que eu disse para o PedR: o problema com os align="left" não é bem de acessibilidade, mas de validade do código, pois o atributo align foi depreciado em 1999 (antes do surgimento da Wikipédia!) quando passou-se a usar HTML apenas para dar significado (semântica) às páginas e deixar que o CSS cuidasse da aparência/formatação.

Apesar de não ser raro que coincida de haver problemas em diferentes aspectos (acessibilidade, uso apropriado das tags semânticas em vez de códigos HTML obsoletos [por não terem semântica nenhuma], usabilidade, etc..) em um mesmo artigo, é importante notar que são coisas diferentes, pois às vezes aparece só um dos problemas (como foi o caso ali). Helder 12h41min de 23 de julho de 2012 (UTC)[responder]

Sim, eu sei, mas chamo td de acessibilidade para simplificar.
Mesmo o align seja obsoleto, ele é mais simples de usar e o código fica mais clean. O mediawiki não 'atualiza' o código obsoleto pelo atual?
O benefício de trocar align por style compensa os problemas com código mais complexo / longo / espantar novatos?
Rjclaudio msg 13h51min de 23 de julho de 2012 (UTC)[responder]
Atualmente o MediaWiki não faz qualquer atualização nas Wikipédias. Mas uma vez que seja Agora que foi ativado $wgHtml5 (que já está já estava em uso no mediawiki.org a bastante tempo) ele passará passou a fazer algumas correções (no HTML, mas não no código wiki, que continuará com os códigos obsoletos). Compare este exemplo no mediawiki.org com o seu resultado aqui na Wikipédia. Aliás, isso mostra que podemos usar margin: auto, pois navegadores que tem problemas com isso já tem problemas em qualquer wiki que ativa HTML5. No entanto a conversão automática não é 100% (vide bugzilla:40329), então a forma mais confiável é corrigir efetivamente o código wiki.
Se a formatação já estiver definida dentro dos styles fica mais fácil a migração dos estilos em linha para as folhas de estilo do site nos casos de padronização (como quando a classe "wikitable" foi criada).
Nem sempre a troca torna o código mais longo, pois as vezes usam tanto o style quanto os atributos "apresentacionais". Além disso, nem sempre há motivo para fugir do alinhamento padrão (que foi definido na classe "wikitable" justamente para não ter que ser definido toda hora). E considero mais confuso permitir a coexistência de dois métodos distintos (um obsoleto e outro não) do que permitir apenas um: uma vez que se aprende a forma correta, é esta que se proliferará e se tornará habitual.
Em relação aos novatos: eles terão que lidar cada vez menos com o código wiki diretamente, já que o desenvolvimento do mw:VisualEditor continua a todo vapor. Além disso, essa é uma ferramenta feita com o que há de mais atual, e acredito que as chances dela falhar em páginas com códigos obsoletos sejam maiores do que nas que não tem esse tipo de problema. Helder 14h43min de 23 de julho de 2012 (UTC)[responder]
  Concordo e   Apoio todas as propostas! Abrações! Mar França (discussão) 04h01min de 25 de julho de 2012 (UTC)[responder]

No que diz respeito a sintaxe e a semântica das páginas, acrescentei um link para a ferramenta de validação do HTML5 da W3C à lista de ferramentas usadas durante a avaliação dos destaques, para facilitar a correção desse tipo de problema. Na wiki em inglês já existe uma página (en:Help:Markup validation) explicando como corrigir alguns dos mais comuns, e também informa erros que só podem ser resolvidos pelos desenvolvedores do MediaWiki (e que portanto podemos ignorar). Seria bom ter uma versão em o português. Helder 15h57min de 6 de novembro de 2012 (UTC)[responder]

A título de exemplo, GRES Portela possui cerca de 900 erros, enquanto que um artigo destacado como Charles Messier possui menos de 20. Helder 15h57min de 6 de novembro de 2012 (UTC)[responder]

Consensos

Para finalizar esta discussão, mesmo sendo contra, alterei o manual do Projeto Carnaval, retirando as cores. Levando-se em conta o WP:Consenso#Princípio da cedência, removi as cores, mas mantive no título, conforme o Fabiano havia proposto originalmente. Parece-me um meio-termo razoável, levando-se em conta a opinião da maioria, e creio que pode ser aceito pela minoria. Podemos considerar mesmo consenso aqui? BelanidiaMsg 19h18min de 2 de agosto de 2012 (UTC)[responder]

Por mim sim! Abraços! Mar França (discussão) 03h43min de 5 de agosto de 2012 (UTC)[responder]