Seria muito legal saber que todos os blocos que replicam a funcionalidade do editor clássico estão acessíveis em Gutenberg.

A coisa certa a fazer aqui é obter uma auditoria de acessibilidade independente. O WordPress tem uma política declarada de atender às diretrizes de acessibilidade no núcleo e também tem a responsabilidade de seus usuários atenderem a essas diretrizes. Apenas uma auditoria de acessibilidade completa pode mostrar se esse é o caso ou não. A equipe de acessibilidade sinalizou vários problemas, alguns dos quais foram resolvidos, outros não. No mínimo, isso deve ser tratado.

WordPress é uma interface entre o editor, um banco de dados e o visitante. Como exatamente o editor escolhe inserir ou manipular a interface depende desse usuário. O trabalho do WordPress é tornar a interface acessível para qualquer modalidade de entrada escolhida pelo usuário. Isso não é novo nem controverso: é a base sobre a qual a web está.

Eu concordo com @ mor10. Considerando o quanto a Automattic e a equipe principal estão investindo no projeto, e ainda estão vendo problemas, o único caminho verdadeiro e válido é ter uma auditoria independente e objetiva.

O WordPress tem uma política declarada de atender às diretrizes de acessibilidade no núcleo

Sim, exatamente. Eu gostaria da confiança dos líderes do projeto w.org maior - como @afercia e @rianrietveld - no trabalho aqui.

Em suma, acredito que Gutenberg _CAN_ seja acessível, mas estou preocupado que não possa ser entregue em seu estado atual com base nos 117 itens abertos no projeto .

Esperando que isso aconteça!

Eu apoiaria totalmente uma auditoria de acessibilidade externa e independente.

Como você mencionou, existem alguns problemas de percepção que eu acho que estão relacionados à falta de material e informações sobre o teste do usuário e, especificamente, o re-teste conforme o desenvolvimento progredia. Em vez de perseguir os resultados do usuário, parece que estamos perseguindo bugs e regressões.

Agradeço sua honestidade aqui e concordo que uma auditoria externa / independente seria valiosa. Porém, temo que isso esteja abordando retroativamente a acessibilidade de um ponto de vista técnico (ou seja, marcando as caixas para WCAG 2.x / AA) em vez de procurar fornecer uma experiência _melhor_ para aqueles que podem não estar usando um mouse e teclado. Somente para acessibilidade, a pesquisa qualitativa e quantitativa da experiência de Gutenberg sem dados relativos à experiência atual (ou, melhor ainda, outros produtos semelhantes) podem não contar uma história justa.

Eu acho que a transparência em torno dessas informações iria durar muito com o apoio da comunidade e facilitaria muito o atrito, tanto do ponto de vista da acessibilidade quanto do lançamento mais amplo de Gutenberg.

Não estou surpreso de ouvir que outros são a favor de uma auditoria externa, o que seria ótimo. 👍 Posso dizer que adoraria isso também e estarei procurando maneiras de facilitar isso na próxima semana.

Existem agências / empresas especializadas em acessibilidade envolvidas com o WordPress que seriam capazes de priorizar seu tempo para executar uma auditoria de acessibilidade do projeto (provavelmente a partir do 4.0, que é um grande lançamento)? Acho que seria útil estabelecer uma noção básica de como Gutenberg se compara ao Editor Clássico.

Tenho certeza de que haverá problemas (como mencionado acima, temos mais de 100 problemas de acessibilidade), mas estou tentando obter uma visão macro da acessibilidade em Gutenberg. Deve ser apontado que temos mais de 100 problemas rotulados como "bugs", mas isso é graças a nós, considerando nenhum bug muito pequeno. Tentamos registrar tudo, mas lembre-se de que isso significa 100 problemas de acessibilidade, não 100 bloqueios de acessibilidade. Os bloqueadores de acessibilidade (a partir de agora) estão contidos no Merge Milestone do qual este problema faz parte.

Obrigado a todos aqueles que contribuíram para apoiar uma auditoria. Vou fornecer uma lista de fluxos que queremos testar e garantir o trabalho para os usuários como um MVP - quando eu fizer isso, irei postá-los aqui, mas ainda não os formulei totalmente.

Uma auditoria externa é uma ótima ideia. Eu ficaria feliz em contribuir financeiramente para a contratação de uma empresa qualificada para realizar esta auditoria.

Eu também contribuiria financeiramente, especialmente para algo dessa magnitude e importância.

Eu também estaria disposto a liderar o caminho para ajudar a arrecadar dinheiro com a comunidade.

Eu gosto desta ideia. Para empresas que exigem conformidade com WCAG em seu software, uma auditoria pode ajudar muito a suprimir preocupações. Gerar um VPAT a partir de uma auditoria também pode ajudar na aceitação em organizações que o exigem como parte de seu processo de contrato. Consulte Criando acessibilidade em contratos de fornecedores de tecnologia para obter informações relacionadas.

Também apoio uma auditoria de acessibilidade externa e independente. Vou verificar os excelentes recursos a11y do meu trabalho diário e ver o que eles recomendam. :)

Isso é muito gentil! Mas não estamos procurando contribuições financeiras da comunidade. Vou entrar em contato com alguns auditores de acessibilidade e ver se eles podem fazer algumas auditorias em Gutenberg.

Vou ver que tipo de custos e cronogramas estão envolvidos, mas se conseguirmos algo com um preço razoável com um cronograma que funcione por 5.0, devo conseguir o Automattic para cobrir os custos. 😊

Eu estava um pouco inseguro quanto ao apoio financeiro que poderia fornecer da Automattic quando postei um comentário anterior e não estava certo sobre as expectativas da comunidade: desculpe por isso! Atualizei o comentário e esclareci o que não estava procurando. Agora vou tratar de organizar auditorias, provavelmente levarei alguns dias, pelo menos, para encontrar as aspas! Vou relatar quando eu souber mais 😊

Sei que este pode não ser o lugar para afirmar isso, mas minha empresa faz auditorias de acessibilidade. Então, deixe-me saber se você quiser saber mais. Embora não seja tão ativo recentemente, estive envolvido com o WordPress por um tempo e contribuí com ideias de acessibilidade para Gutenberg, bem como para outras partes do WP. Se não sou independente o suficiente, trabalho com um parceiro de confiança que nunca usou o WordPress.

@tofumatt Acho que uma solicitação de propostas seria uma boa maneira de afirmar exatamente o que uma auditoria está procurando e dar aos provedores de serviço a oportunidade de fornecer um esboço geral de como eles deveriam proceder. Existe um precedente para esse tipo de processo na Automattic?

Olá, sou o coordenador de acessibilidade de TI da NC State University. Usamos WordPress para os sites de nossos campus e, como instituição estadual, somos obrigados a seguir a Seção 508 da Lei de Reabilitação de 1973. Por causa disso, nossas ferramentas de autoria, como o WordPress, devem ser acessíveis para pessoas com deficiência.

Temos uma grande variedade de usuários do WordPress, incluindo alunos, professores e funcionários que usam blogs WordPress e editam sites WordPress em nome de seus departamentos de suas organizações. Tudo isso para dizer que o WordPress deve ser acessível para esses indivíduos.

Como instituição de ensino superior, queremos nos manter atualizados com novos programas e tecnologias. Seria prejudicial para nós não sermos capazes de progredir e usar Gutenberg ou fazer uma situação de "separar por igual" onde as pessoas com deficiência são limitadas a usar o editor clássico enquanto as pessoas sem deficiência podem usar Gutenberg.

Isso é tão incrível de ouvir 👍

Eu concordo totalmente! Claro, eu quero definir a expectativa clara de que pode haver problemas de acessibilidade que descobrimos (ou possivelmente sabemos) que não somos capazes de corrigir antes do lançamento do WordPress 5.0.

Existem muitos sites, por vários motivos, que vão querer / precisar usar o plugin do Editor Clássico por um período limitado de tempo enquanto o Gutenberg - ou plug-ins externos - são aprimorados. Provavelmente haverá usuários que encontrarão problemas de acessibilidade - junto com uma série de outros problemas - que precisarão do plugin Classic por algumas semanas / meses enquanto melhoramos nosso software.

Eu quero que o futuro do Editor do WordPress seja incrível e acessível para todos. Minhas desculpas antecipadamente para os usuários que falharam no início, por qualquer motivo. Mas saiba que trabalharemos para tornar o Gutenberg e o WordPress incríveis para eles também, mesmo que isso não aconteça imediatamente . ❤️

Em relação à auditoria

Olá a todos! Eu ainda sou um pouco novo para ser um líder de lançamento e venho de quase uma década trabalhando no projeto @mozilla , onde também trabalhamos abertamente, com erros e tudo. Serei o mais transparente possível sobre o que está acontecendo, inclusive tentando fornecer atualizações oportunas (por isso não tenho certeza de poder pagar por auditorias de acessibilidade até verificar com algumas pessoas).

O tipo de auditoria que estou procurando fazer pode não ser nada muito legal / específico de conformidade, já que primeiro estou procurando obter uma noção macro da usabilidade do WordPress por usuários com necessidades de acessibilidade. Se isso incluir coisas de compliance: incrível.

Neste momento, estou em contato com alguns membros da comunidade de acessibilidade do @WordPress e funcionários qualificados da @automattic que me forneceram algumas pessoas para entrar em contato sobre uma auditoria de acessibilidade. No momento, eu quero que seja imparcial (um pouco fora da comunidade WordPress é ótimo para evitar preconceitos / conhecimento passado / etc.), De alto nível, acionável e feito um pouco rápido. Eu sei que estou pedindo muito 😆

Eu tenho algumas pessoas em mente agora eEstarei chegando a eles Contactei várias empresas especializadas em auditorias de acessibilidade. Vou postar atualizações aqui, mas não saberei mais até a próxima semana. Por enquanto, há:

1. não há necessidade de oferecer suporte financeiro (mas OMG, muito obrigado a quem
2. não há necessidade de oferecer seus serviços (acho que queremos alguém fora do ecossistema WordPress, mas se você quiser ajudar com testes regulares de bugs / acessibilidade , faça-o! )
3. muito ❤️ de mim 🙂

Tenha um ótimo final de semana, vou manter todos informados! 😄

Se estiver procurando por mais fornecedores para a auditoria, recomendo o WebAIM da Utah State University, que geralmente é considerado um dos principais recursos a11y da web nos Estados Unidos. Não sou afiliado a eles de outra forma que não seja pela leitura de sua incrível documentação a11y na web, mas eu vi que eles oferecem auditorias.

Embora o WordPress em si seja de código aberto e ainda tenha muito trabalho voluntário, ele também atingiu o "grande momento", e não pode mais se dar ao luxo de cair na muleta "Mas somos apenas código aberto". Eu acho que uma auditoria completa de acessibilidade e o compromisso de melhorar onde WP está faltando (não apenas Gutenberg) seria uma grande fonte de avanço quando se trata de adoção de WP. Além disso, é claro, democratizar a publicação e tudo mais.

Existem muitos sites, por vários motivos, que vão querer / precisar usar o plugin do Editor Clássico por um período limitado de tempo enquanto o Gutenberg - ou plug-ins externos - são aprimorados. Provavelmente haverá usuários que encontrarão problemas de acessibilidade - junto com uma série de outros problemas - que precisarão do plugin Classic por algumas semanas / meses enquanto melhoramos nosso software.

Este sentimento é simplesmente inaceitável para mim e espero que muitos outros que internalizaram os valores do WordPress ...

Minhas desculpas antecipadamente para os usuários que falharam no início, por qualquer motivo. Mas saiba que trabalharemos para tornar o Gutenberg e o WordPress incríveis para eles também, mesmo que isso não aconteça imediatamente. ❤️

Qual é a vantagem de passar por uma experiência que não atende aos padrões de tudo o mais no Core? Os prazos não são arbitrários, mas isso não significa que você deve economizar. Pelo menos não de acordo com os valores do WordPress como eu os entendo. Esses valores são provavelmente distintos de tudo o que a Mozilla tinha, como um recém-chegado à comunidade, encorajo você a analisá-los.

Em geral, o sentimento de que trabalhar principalmente será suficiente cria riscos desnecessários para a comunidade, e deve-se perguntar quem se beneficia com isso. Qual é a vantagem do projeto Gutenberg ou do WordPress? Não é como se precisássemos de ajuda para identificar problemas.

Uma vez que a Automattic aparentemente patrocinará e conceberá parâmetros para esta auditoria, existe o potencial aparecimento de viés e que eles estão avaliando seu próprio trabalho. Proponho que a grande comunidade prossiga com o crowdfunding para contratar um especialista em acessibilidade para um relatório paralelo da perspectiva dos usuários reais. Talvez a Automattic possa fazer uma auditoria técnica ou qualquer outra coisa, mas a sugestão de que a acessibilidade de Gutenberg “não é tão ruim” foi veementemente discordada por verdadeiros especialistas neste campo (a saber, Sina Braham da WordCamp Publishers). Talvez precisemos de algo mais próximo de um teste de Mikey, onde fazemos com que os usuários cegos naveguem pelo aplicativo e digam se o usariam novamente.

É isso que venho mandando para empresas que tenho procurado para esse trabalho, aliás. Pode ajudar outras pessoas envolvidas na acessibilidade, não tenho certeza. No mínimo estou postando aqui para transparência 🙂

Requisitos

Uma série de testes de acessibilidade a serem feitos usando o editor Gutenberg em um site WordPress usando WP-Admin. Esses testes devem incluir, no mínimo, os seguintes fluxos de teste:

Fluxo de Publicação Principal

• Crie uma nova postagem
• Adicione conteúdo comum (parágrafo, imagem, lista, HTML e conteúdo de tabela; consulte “Usando Blocos” abaixo)
• Publique uma postagem imediatamente e a postagem seja feita conforme o esperado
• Programe uma postagem para o futuro usando o seletor de data
• Atribuir categorias e tags para postar
• Atribuir uma imagem em destaque a uma postagem
• Experimente outras configurações no nível do documento, se houver tempo

Usando Blocos

Estes são os vinte blocos mais usados ​​no WordPress.com e devem ser testados para encontrar quaisquer problemas de acessibilidade que ainda não tenham sido incluídos em nossa lista de problemas de acessibilidade :

1. parágrafo
2. imagem
3. título
4. Lista
5. galeria
6. citar
7. incorporar / youtube
8. html
9. separador
10. Mais
11. imagem de capa
12. Código curto
13. botão
14. mesa
15. espaçador
16. Embutir
17. quadra
18. embed / twitter
19. colunas
20. código

Esses blocos devem ser testados com tecnologias assistivas para garantir que não haja bloqueadores para seu uso e que suas configurações de nível de bloco sejam acessíveis.

Editor Clássico

Devemos verificar que, em comparação com o Editor Clássico, não existem regressões notáveis ​​no que diz respeito à acessibilidade. A criação de uma postagem com o mesmo tipo de conteúdo que se pode criar em um contexto Barebones Classic Editor deve ser possível com Gutenberg. Gutenberg ter zero regressões na experiência de edição em comparação com o Editor Clássico é meu objetivo final ao dizer que podemos recomendá-lo como a experiência de edição padrão para usuários de tecnologias assistivas.

Tecnologias assistivas a serem consideradas

Por causa da linha de tempo limitada disponível e da priorização da capacidade de ação sobre a meticulosidade extrema, eu preferiria que as duas ou três principais combinações de navegador + leitor de tela fossem usadas para teste . Usar mais se o tempo permitir é absolutamente acessível, mas eu preferiria começar com as combinações mais usadas. Do meu entendimento, isto é:

• JAWS com Internet Explorer / Edge (Windows)
• NVDA com Firefox (Windows)
• VoiceOver com Safari (MacOS)
• ZoomText

A tecnologia de assistência móvel não é uma prioridade para esta auditoria. Os testes do VoiceOver no MacOS devem incluir algum cruzamento com os usuários do iOS VoiceOver. Presumivelmente, o uso de aplicativos móveis é mais um foco do que o uso de sites.

Publicar relatório e problemas em aberto

Nossa expectativa é que qualquer relatório de acessibilidade gerado seja postado abertamente para a comunidade WordPress e não exija que eu (ou qualquer outro automatico) seja o porteiro. Os problemas devem ser postados com um contexto útil no GitHub, com foco na causa do problema e reprodutibilidade. Soluções ou abordagens para correções podem ser publicadas se houver tempo no escopo ou se o problema for especialmente complexo.

@davisshaver Olá, e concordo totalmente com você. Uma auditoria completa e imparcial é crítica para garantir que o nível máximo de a11y seja cumprido.

Não é apenas importante garantir que o editor esteja acessível, mas também que haja uma base para garantir que as modificações no editor também possam ser facilmente acessíveis. Obviamente, não podemos impor o que as pessoas fazem por conta própria, mas podemos pelo menos fornecer uma base acessível para as pessoas implementarem.

@tofumatt Também

@tofumatt Obrigado pela atualização. Tenho algumas perguntas de acompanhamento:

1) O plano para a auditoria ser concluído antes do lançamento do 5.0?
2) Se a auditoria retornar problemas, qual é o plano para resolvê-los? O lançamento do 5.0 será adiado até que sejam resolvidos?
3) Existem planos sendo feitos para como o projeto irá testar a acessibilidade daqui para frente?

@tofumatt Se você quiser alguns testes por usuários com uma variedade de deficiências / deficiências, fiz alguns trabalhos com uma empresa chamada Hassell Inclusion, e eles podem organizar esse tipo de teste. Eles são completamente removidos da comunidade WordPress. A empresa é dirigida por Jonathan Hassell, que costumava ser o responsável pela acessibilidade na BBC.

@tofumatt Também estou muito preocupado com a acessibilidade do WordPress e ansioso para ajudá-lo a ter sucesso. Posso fazer com que nossa organização execute uma auditoria de acessibilidade em conformidade com WCAG-EM completa em qualquer nível padrão de sua preferência, incluindo testes técnicos e funcionais, e doar qualquer parte do trabalho que você precisar para caber em seu orçamento.

Eu acho que devemos olhar para ATAG e WCAG AA, e talvez WCAG 2.1 em vez de 2.0. Também podemos fornecer recomendações e coaching para ajudá-lo a escolher a melhor e mais sustentável forma de fechar as lacunas descobertas.

Estamos convenientemente distantes de sua comunidade de desenvolvimento, mas conhecemos bem o WordPress há muitos anos. Eu possuo todas as certificações IAAP e conduzi dezenas dessas auditorias na plataforma WordPress, ao longo de muitos anos, tanto para o setor privado quanto para o público. Verifique nossa boa-fé em davidberman.com/about para decidir como podemos ajudar da melhor forma.

Usando Blocos

Não tenho certeza se a equipe que vai fazer a auditoria deve ser instruída ou ter conhecimento do que é um "bloqueio", pelo menos não inicialmente. Eles devem estar na mesma condição inicial dos usuários que vão usar o Gutenberg pela primeira vez, sem instruções especiais. Numa segunda fase, quando for técnico, provavelmente já saberão o que é um bloco 🙂

Fluxo de Publicação Principal

A equipe de acessibilidade concorda que o principal problema de acessibilidade em Gutenberg é a experiência geral do usuário. Eu sugiro expandir esta parte: ela não deve ser limitada ao fluxo _publihsing_, em vez disso, deve incluir mais tarefas, normalmente aquelas que exigem navegar pela IU e saltar pelas seções principais (barra superior, área de edição, barra lateral , publicar painel). Isso está mais relacionado ao design geral de Gutenberg, ao invés de detalhes técnicos de implementação nos vários componentes. Na verdade, acessibilidade _é_ design.

Eu gostaria de propor algumas tarefas:

• construir um poste com um grande número de blocos, digamos 20 no mínimo
• edite um dos parágrafos no meio da postagem
• mude o tamanho e a cor da fonte e edite novamente o conteúdo
• adicione novos blocos usando os insersores
• insira um link
• insira uma menção
• alterar tipo de bloco
• mude algo nas configurações da barra superior e volte para o bloco que foi editado
• pule para a barra lateral, mude para as configurações de Documento / Bloco e volte para o bloco que foi editado
• editar o link permanente da postagem
• faça um bloco reutilizável
• adicionar e editar um bloco reutilizável existente

Tecnologias assistivas a serem consideradas

@tofumatt Estou um pouco surpreso por você estar mencionando apenas tecnologias assistivas e, especificamente, apenas leitores de tela. As avaliações de acessibilidade não podem ser limitadas apenas ao teste do leitor de tela. Acessibilidade é um tema muito mais amplo e não se limita a deficiências ou deficiências. Trata-se de tornar a web acessível a todos.

Mesmo se quisermos limitar a acessibilidade a deficiências e deficiências, eles são muitos para contar. Apenas para citar alguns: usuários de software de reconhecimento de fala, deficiências motoras, baixa visão, deficiências cognitivas, distúrbios convulsivos, dispositivos de entrada alternativos, distúrbio de déficit de atenção e hiperatividade, dislexia, perda de memória de curto prazo, etc., etc. E as coisas que podem Não pode ser classificado como "deficiência" real, por exemplo, deficiências temporárias, deficiências ambientais, envelhecimento?

A condição humana é bastante instável, e eu sugiro que você considere _Todos estamos aptos apenas temporariamente_.

Eu gostaria de propor algumas tarefas:

Essa lista de tarefas estendida parece boa e realista sobre o que os usuários precisam fazer.

Como os padrões de acessibilidade para o estado

Todo código novo ou atualizado lançado no WordPress deve estar em conformidade com as diretrizes WCAG 2.0 no nível AA.

Portanto, a auditoria deve levar isso em consideração. Coisas específicas:

1) Todas as funcionalidades devem funcionar como esperado quando o navegador está com zoom de 200% (observe que isso pode acionar o CSS móvel) 1.4.4
2) Todas as funcionalidades devem funcionar como esperado usando apenas um teclado 2.1

É importante lembrarmos que o que procuramos aqui é que tudo possa ser utilizado por todos os usuários. Pode não ser uma ótima experiência para alguns usuários, é disso que trata a versão 1, mas os padrões que temos são para garantir que ela seja totalmente utilizável. Todo software vem com bugs e o importante é que sabemos sobre os bugs e fazemos as escolhas entre corrigi-los e não corrigi-los.

Obrigado @tofumatt por liderar a realizar esta auditoria. Estou ansioso para ver isso acontecer e que Gutenberg seja utilizável por todos.

Foi útil, ao examinar uma auditoria / série de testes de acessibilidade, compilar uma lista de funcionalidades "centrais" do Editor Clássico que não deveriam regredir no novo editor:

1. Criação / edição de texto de parágrafo
2. Criação / edição do texto do título
3. Criação / edição de texto pré-formatado
4. Criação / edição de lista com marcadores
5. Criação / edição de lista numerada
6. Criação / edição de um orçamento ("Blockquote")
7. Alinhamento de texto para paragraghs e cabeçalhos
8. Adicionar, editar e remover links de texto em parágrafos, títulos e itens de lista
9. Recuo / redução de listas / itens de lista
10. Negrito / itálico / tachado de texto em parágrafos, cabeçalhos e itens de lista
11. Adicionando uma linha horizontal / espaçador ao conteúdo
12. Desfazer refazer
13. Inserção do comentário "Leia mais" do WordPress (Bloco Leia mais em Gutenberg)
14. Conversão de conteúdo de parágrafo em conteúdo de lista
15. Conversão de conteúdo de lista em conteúdo de parágrafo

Acho que é isso, é o que venho enviando.

Minha lista de tecnologias acessíveis era mínima, concorda. Parte disso é sobre o escopo, mas parte porque era uma lista incompleta que eu esperava adicionar com o tempo. Eu adicionei o ZoomText a essa lista e vou solicitar que seja usado para testes também.

Acabei de revisar a lista de tarefas de

Respondendo a algumas perguntas

@bamadesigner :

O plano, agora, é começar a auditoria o mais rápido possível e ter o máximo de informações disponíveis antes da versão 5.0 para resolver quaisquer problemas encontrados e adicionar contexto à versão em relação à sua acessibilidade. Em termos de atrasar o lançamento: depende do problema, do tempo para corrigi-lo e do seu impacto. Minha opinião é que atrasar o lançamento é improvável, mas devemos cruzar essa ponte quando chegarmos a isso; Eu não quero especular.

Em termos de planos para testes de acessibilidade daqui para frente: essa é uma questão maior e não está relacionada ao lançamento ou a esse problema, então não vou entrar no assunto aqui. Por enquanto, sou um líder de lançamento do 5.0 e vou me concentrar nisso; de novo: não quero especular. Mas é algo que fico feliz em olhar depois de recuperarmos o fôlego com o WordPress 5.0 😄

@LukePettway

Se você tem experiência em testes de acessibilidade, seria ótimo testar o Gutenberg ou fazer a triagem de problemas de acessibilidade existentes para que possamos saber o que ainda é um problema e o que precisa ser enfocado. Trabalhar em qualquer problema no marco Mesclar: Acessibilidade também seria ótimo.

@tofumatt Obrigado por suas respostas, mas são decepcionantes.

Gutenberg / 5.0 não deve ser lançado até que a auditoria seja concluída e quaisquer problemas encontrados sejam resolvidos. Esperançosamente, a auditoria volta e diz que há apenas alguns problemas, mas a decisão deve ser que o lançamento do 5.0 depende dessa descoberta e do tempo necessário para resolver.

Não estou a par do que está acontecendo neste prazo de novembro, mas a acessibilidade é muito importante. Se você lançar antes de garantir que essas bases sejam cobertas, você está estabelecendo um precedente perigoso para toda a comunidade, e para a web em geral, que a acessibilidade não é a prioridade número 1 e pode esperar mais tarde.

O WordPress 5.0 não está pronto até que esteja acessível. Nenhum outro prazo é mais importante. Sem mencionar o fato de que viola os padrões básicos de acessibilidade.

O WordPress 5.0 não está pronto até que esteja acessível.

@bamadesigner fala a verdade.

O objetivo declarado do WordPress é "democratizar a publicação". Isso, literalmente, significa tornar a publicação disponível para todos. A acessibilidade é fundamental para esta promessa.

Espero que não seja um equívoco dizer que um objetivo e uma promessa não são a mesma coisa e não devem ser tratados como tal. 😄

Como mencionado antes, agradeço totalmente qualquer contribuição externa sobre questões de acessibilidade, especialmente aquelas encontradas no marco Mesclar: Acessibilidade (
https://github.com/WordPress/gutenberg/milestone/43).

Se for determinado que haverá problemas de acessibilidade no lançamento, fico à vontade para revisitar a sugestão de @rianrietveld no Trac para alertar os usuários sobre a tecnologia assistiva dos problemas específicos com Gutenberg e sugerir que usem o Editor Clássico se Gutenberg os apresentar problemas de usabilidade. Gostaria de destacar problemas específicos conhecidos e quem eles afetariam.

Não tenho certeza se seria minha decisão em qualquer caso, mas mesmo se fosse: não vejo como uma boa decisão atrasar o lançamento do 5.0 por questões de acessibilidade quando o Editor Clássico existe como um substituto . O objetivo / principal característica do 5.0 é Gutenberg, a nova experiência de edição. Eu preferiria liberá-lo para os usuários que o acharão utilizável (o que deve incluir muitos, mas não todos os usuários de tecnologias assistivas) e aceitar que nem todos podem usar o Gutenberg no primeiro dia. Essa já é a realidade para muitos usuários de plug-ins incompatíveis. Ninguém está forçando ninguém a usar o Gutenberg quando o 5.0 for lançado 🙂

O Editor Clássico existe, mas não faz parte do WordPress , e é um item crucial a ser reconhecido. Requerer um plug-in para adaptar o sistema de gerenciamento de conteúdo para ser utilizável é uma solução muito questionável. Certamente é o que venho sugerindo às pessoas; mas há muitas situações que não são bem cobertas por essa situação. E o mais importante: isso significa que apenas as pessoas que têm a capacidade de instalar plug-ins podem opinar sobre se o site continuará ou não tão acessível como agora. Para o cenário em que alguém simplesmente atualiza o site, e depois os autores que precisam usar o login do site e não podem mais publicar conteúdo, isso é inadequado. O editor clássico não deve ser uma opção tudo ou nada que depende da generosidade de um administrador do site para garantir que as pessoas com deficiência possam continuar a publicar. Esta é a razão pela qual ter o editor clássico não sendo uma opção disponível no núcleo do WordPress é um problema de acessibilidade.

Muito bom ponto

Eu preferiria liberá-lo para os usuários que o acharão utilizável (o que deve incluir muitos, mas não todos os usuários de tecnologias assistivas) e aceitar que nem todos podem usar o Gutenberg no primeiro dia.

Este é um comentário incrivelmente moderado, e esta posição é um projeto pobre na melhor das hipóteses e ativamente capacitado na pior. Eu realmente espero que essa não seja a solução.

@tofumatt Agradeço que você esteja tentando fazer a coisa certa e equilibrar muitas preocupações, mas acho isso incrivelmente preocupante:

Não tenho certeza se seria minha decisão em qualquer caso, mas mesmo se fosse: não vejo como uma boa decisão atrasar o lançamento do 5.0 por questões de acessibilidade quando o Editor Clássico existe como um substituto. O objetivo / principal característica do 5.0 é Gutenberg, a nova experiência de edição. Eu preferiria liberá-lo para os usuários que o acharão utilizável (o que deve incluir muitos, mas não todos os usuários de tecnologias assistivas) e aceitar que nem todos podem usar o Gutenberg no primeiro dia.

Você está dizendo a uma população já marginalizada de usuários que poderá tornar o WordPress utilizável para eles ... eventualmente. Você vê como isso é alienante, certo?

Mas talvez o conjunto de perguntas mais importante seja este:

• De quem é a decisão de decidir se o novo editor está oficialmente pronto para ser incorporado ao núcleo?
• Que fatores eles estão considerando para tomar essa decisão?
• O que nós, como comunidade, precisamos fazer para tornar a acessibilidade central para esse processo de tomada de decisão?

@tofumatt para esclarecer: a equipe de acessibilidade não pediu para atrasar o lançamento. O único pedido oficial foi adicionar um aviso para usuários com necessidades de acessibilidade, informá-los que ainda existem problemas a serem resolvidos, convidá-los a experimentar o Gutenberg, mas recomendar o Editor Clássico. A proposta estava em https://core.trac.wordpress.org/ticket/44671 que foi encerrada 🙁

Eu preferiria liberá-lo para os usuários que o acharão utilizável (o que deve incluir muitos, mas não todos os usuários de tecnologias assistivas) e aceitar que nem todos podem usar o Gutenberg no primeiro dia.

Legal, incrível, grande habilidade aqui. Como disse @briandeconinck , você está alienando um grupo inteiro de usuários só porque eles não podem usar um teclado e mouse (ou monitor) de maneira adequada. Nossa universidade colocou muito trabalho e esforço para tornar nossa experiência WordPress acessível e ainda estamos trabalhando nisso até hoje. Ter uma parte tão grande e importante do núcleo do WordPress potencialmente lançado e ser de outra forma é extremamente decepcionante.

@afercia Oh, eu sei disso! Certamente não quis dizer que a posição da Equipe de Acessibilidade era atrasar a liberação; algumas pessoas nos comentários aqui estavam perguntando sobre isso é tudo. Eu realmente sinto muito se eu falei mal e coloquei isso na equipe. ❤️

Esse problema foi resolvido (em parte porque é sobre a chamada de "teste" que está desaparecendo, talvez tenha havido algum problema de comunicação sobre sua intenção), mas como mencionado aqui: Estou bem com a implementação de seu conceito de alertar os usuários de assistência tecnologias se Gutenberg não vai funcionar para eles.

Concordo com outros neste tópico que buscam uma acessibilidade aprimorada antes do 5.0. Eu também acrescentaria que o lançamento do 5.0 será interpretado como uma luz verde pelo resto do ecossistema WP de que Gutenberg está pronto para uso no mundo real. Nesse ponto, veremos um influxo de plug-ins e temas que estendem Gutenberg e contam com os padrões que ele apresenta como um projeto para seu próprio desenvolvimento.

Como um desenvolvedor no ecossistema WP por vários anos, eu constantemente olho para o núcleo do WordPress para garantir que a acessibilidade, estilos e comportamento em meus próprios plug-ins se alinhem com os do núcleo. Se o 5.0 for lançado antes que os problemas de acessibilidade sejam resolvidos, a comunidade do WordPress estará olhando para um plano inacessível como modelo para seu próprio desenvolvimento. Vamos nos certificar de que o blueprint atenda aos padrões que definimos para tudo o que veio antes.

@tofumatt Você está sugerindo que colocar um aviso dizendo que as tecnologias assistivas não funcionam com o Gutenberg é uma solução razoável, dado que o Core Editor se tornará um plugin que deve ser instalado juntamente com o fato de que o usuário pode ou não ter a habilidade / conhecimento para instalar esse plugin? Espero não estar entendendo isso, você pode esclarecer, por favor?

Como sempre, obrigado pelo seu tempo!

O plugin do Editor Clássico foi construído como uma rampa de saída temporária para aqueles que não estão prontos para mudar para Gutenberg. É tênue, na melhor das hipóteses, e rapidamente se tornará um problema para os desenvolvedores que terão de fornecer soluções para dois editores diferentes. O plugin do Editor Clássico não pode ser nem mesmo uma rampa temporária para pessoas com necessidades de acessibilidade porque ele literalmente oferece uma experiência inferior com base na deficiência. O requisito mínimo para o administrador do WordPress é WCAG 2.0 AA. Qualquer outra coisa, incluindo um plugin para degradar a experiência, vai contra nossas próprias políticas. Estou assumindo uma linha dura porque temos regras. Não enviamos códigos que não atendam aos nossos próprios padrões de conding. A acessibilidade não deve ser diferente.

Como muitos outros aqui, agradeço os esforços da comunidade e as pessoas que dedicam seu tempo e esforço em Gutenberg para torná-lo acessível - pronto para o 5.0. Simplesmente, Gutenberg não está pronto porque não está totalmente acessível. Fim da história.

Até que Gutenberg esteja acessível, ele não deve ser incorporado ao núcleo. A noção de liberar Gutenberg no núcleo para "aqueles que _podem_ usá-lo" não é apenas míope, mas terrivelmente excludente - eu iria mais longe e diria que isso cria (e normaliza) uma experiência _seperada, mas igual_ para usuários do WordPress. É um precedente terrível e extremamente arrogante.

Espero que a comunidade prevaleça e convença a equipe principal a suspender o lançamento do 5.0 até que esteja totalmente acessível. Para tanto, uma auditoria independente é uma boa ideia e deve ser realizada.

Esta edição foi registrada para divulgar meu trabalho na auditoria de acessibilidade, para comunicar que gostaria que acontecesse e para rastrear o compartilhamento dessa auditoria em uma postagem do blog. Não é um ponto de discussão sobre o que deve ser considerado um bloqueador de lançamento do WordPress 5.0. Anotei as opiniões das pessoas sobre o assunto e as retransmitirei para

1. Não tenho veto sobre o frete 5.0, mas mesmo se tivesse:
2. Ainda não estou convencido de que existem problemas de acessibilidade suficientes que impedem um lançamento

Se o segundo ponto mudar, transmitirei essa informação. Pretendo ser um defensor, mas não defino os prazos e também não tenho dados sólidos sobre acessibilidade. Esse é o objetivo da auditoria: para que possamos falar de um lugar de dados concretos. 🙂

Obrigado por todas as contribuições, mas como esta discussão saiu do assunto de seu escopo pretendido, estou bloqueando a conversa deste problema por enquanto. Vou deixá-lo aberto e postar atualizações sobre a auditoria.

Houve uma discussão extra sobre esse problema no Slack: https://wordpress.slack.com/archives/C02RP4X03/p1539300688000100

Acho que valeu a pena abordar aqui para que todos que acompanharam o assunto até agora possam se atualizar sobre o que está acontecendo. @ mor10 também destacou que

Acho que grande parte da confusão no tíquete fechado decorre da falta de clareza sobre o que acontece se / quando uma auditoria não pode ser concluída a tempo para o cronograma de lançamento ou uma auditoria volta sinalizando problemas substanciais que precisam ser corrigidos. Com base em seus comentários, não está claro se você pensa:

• a) todos os problemas serão corrigidos dentro do cronograma atual
• b) quaisquer problemas que não possam ser corrigidos dentro do prazo serão empurrados para 5.0.1
• c) se questões substanciais forem levantadas, o cronograma será alterado.

O que você disse até agora _parece_ indicar apenas a ou b são opções, mas como eu disse, não está claro. A ideia de a acessibilidade ser punida para cumprir um prazo de lançamento é o que preocupa as pessoas há mais de um ano, e essas preocupações não foram amenizadas.

• @ mor10 no Slack (https://wordpress.slack.com/archives/C02RP4X03/p1539303342000100)

Com base nos problemas atuais do Milestone, meu objetivo é consertar todos os problemas, mas não acho que todos constituam bloqueadores de liberação. Eu saberei como fazer a triagem mais perto da marcação final, então não posso acrescentar muito a isso agora. Por enquanto, acho que são uma lista realista de questões que são mais importantes antes do 5.0

Os problemas que não podem ser corrigidos devem ser movidos para a próxima versão do WordPress / Gutenberg, sim.

Não acho que haja nada lá atualmente que justifique atrasar o lançamento.

Este problema foi bloqueado porque meu objetivo ao criá-lo era:

1. para compartilhar meu trabalho comissionando uma auditoria
2. para compartilhar meu trabalho criando uma postagem no blog sobre Make / Acessibilidade em torno dessa postagem

Agradeço a contribuição sobre como a auditoria pode ser conduzida e também para ouvir sobre as questões em torno da minha recomendação de "backup" do Editor Clássico se Acessibilidade acabar sendo um problema sério em Gutenberg. É importante notar agora que não há nenhum relatório a apontar que avalie Gutenberg e recomende contra ele por motivos de acessibilidade. Eu não vi isso, e ninguém está ligado a um aqui. O sentimento aqui é em torno de falhas especulativas. Esse tipo de linguagem é desmotivante para os desenvolvedores de Gutenberg que trabalham duro e veem a falta de boas intenções presumidas.

A função de Líder de Liberação de Acessibilidade é nova e desejada, entregue a mim na semana passada . Ao mesmo tempo, uma data de lançamento de 19 de novembro de 2018 foi finalizada . Meu primeiro instinto ao receber o papel de líder de lançamento foi tentar gastar o dinheiro da Automattic para criar uma auditoria como um sinal de nosso compromisso com a acessibilidade e para criar um senso concreto dos problemas reais que Gutenberg enfrenta em termos de trabalho com tecnologia assistiva. Estou trabalhando em um cronograma restrito e compartilhando as informações que posso e conforme apropriado, com a ressalva de que não quero avaliar publicamente as empresas com as quais estou discutindo (considero isso não profissional) e tenho que classificar as lado de compras das coisas com a Automattic (esse aspecto desta auditoria não pode ser público, até onde eu sei).

Não sou a palavra final em um lançamento. Copiei @m para este problema; ele é o líder de lançamento e faz a chamada para atrasar o lançamento com base em problemas de acessibilidade. Pessoalmente, não seria minha recomendação atrasar o lançamento com base nos problemas atuais conhecidos, mesmo dentro do marco.

Sim, existe um problema maior de design acessível em geral, mas as equipes de desenvolvimento e design consideram essas questões. Estou preocupado, mais ainda, com as coisas que reconhecemos e testamos menos porque somos em grande parte uma equipe de usuários bastante capacitados.

Algumas pessoas no Slack me expressaram sua observação de que o problema parecia estar solicitando feedback e uma discussão mais ampla. Essa não era minha intenção ao apresentar este problema, mas simplesmente manter tudo em aberto; como o GitHub é principalmente onde trabalhamos neste projeto, achei que seria o melhor lugar para fazê-lo. Eu bloqueei o problema porque a discussão, embora possivelmente válida para o projeto como um todo, estava distraindo para:

1. o problema em questão (e auditoria e uma postagem no blog com os resultados)
2. a equipe como um todo que é notificada por comentários de problemas

Os comentários do problema devem ser acionáveis, discretos e, com sorte, fornecer novas informações. Achei que os comentários aqui não atendiam a esses critérios, então queria restringir a discussão ao assunto em questão.

Registrei esse problema no marco porque gostaria que isso acontecesse no WordPress 5.0. Se isso não for possível, o triste resultado é que terá de ser movido. Estou tentando o meu melhor para trabalhar com um cronograma restrito e recursos limitados. Não para "patches bem-vindos" a todos, mas se acessibilidade for importante para você, eu agradeceria muito se você direcionasse sua atenção para nossa lista de problemas de acessibilidade em aberto , especialmente aqueles na Milestone: lista de acessibilidade .

Eu gostaria de manter este problema aberto porque desejo acompanhar meu progresso com a auditoria. Se houver outras discussões que você gostaria de ter relacionadas à acessibilidade, o botão "Novo problema" estará sempre lá. Percebi que enquanto escrevia este comentário, um novo problema já estava arquivado (# 10537): isso é legal 😄

Obrigado a todos e tenham uma ótima sexta-feira. ❤️

@tofumatt Você pode atualizar as informações sobre a auditoria?

A primeira coisa primeiro: falei com várias empresas na semana passada sobre a realização de uma auditoria e recebi propostas delas.

Direi que recebi propostas bastante detalhadas de:

• Nível de acesso
• Deque Systems

E respostas menos detalhadas, mas ainda ótimas de:

• The Paciello Group
• Heydon Pickering

Todos pareciam saber suas coisas. Não vou compartilhar os detalhes das propostas porque não acho que seja apropriado, mas tenho notícias infelizes sobre a auditoria. 😢

Pelo menos por enquanto, a Automattic decidiu renunciar à realização de uma auditoria de acessibilidade em Gutenberg. As principais razões são:

1. uma auditoria não será acionável devido ao nosso cronograma de lançamento, porque ...
2. a auditoria não afetará o tempo de lançamento, então ...
3. seria mais prudente explorar uma auditoria em um cronograma menos apressado no futuro

Tenho esperança de explorar uma auditoria no futuro, mas, infelizmente, isso não acontecerá antes da proposta de mesclagem e, portanto, estou encerrando este problema porque não vai resolver. Eu ainda gostaria de escrever um blog sobre o estado da acessibilidade de Gutenberg, tanto o bom quanto o ruim. Estamos fazendo algumas melhorias na navegação do teclado, contraste de cores, comportamento do foco e selecionadores de data / cor apenas esta semana.

Desculpe a todos por ter esperanças e depois falhar com a comunidade neste caso. 😞

Apenas uma nota rápida para dizer que adoraria ver isso continuar, mesmo que aconteça depois do 5.0.
Existe um motivo para não deixá-lo aberto e atribuí-lo a um marco diferente ou futuro?

Com certeza estivemos em uma montanha-russa emocional ultimamente, não é? 🎢

Em primeiro lugar, obrigado a todos pelo trabalho que realizam. 💖 Sei que às vezes não é fácil ser um defensor da acessibilidade, pode parecer uma batalha constante. Saiba que você está causando um impacto: do pessoal (aprendi muito sobre acessibilidade com as pessoas que compõem a equipe de acessibilidade do WordPress) ao fundamental (o design centrado no ser humano é uma faceta essencial das práticas de design moderno )

Gosto muito da ideia de uma auditoria profissional, embora não me lembre de nunca termos feito uma dessas no WordPress, certamente não é uma condição para um lançamento. Adoraria ver algo assim acontecer em algum momento. O WordPress sempre tentou obter o máximo em acessibilidade, aderindo a padrões e semânticas comuns, com a diferença coberta pelos principais esforços de todos os voluntários da equipe de Acessibilidade fazendo testes e preenchendo relatórios de bugs acionáveis. A mudança de Gutenberg para ser um aplicativo inteiramente baseado em JavaScript tornou mais difícil a aplicação desses padrões, mas podemos trabalhar juntos para estabelecer novos padrões, uma nova linha de base.

Sabemos que Gutenberg ainda precisa de mais polimento - o que estamos fazendo! - e, como tudo, terá problemas que continuaremos a repetir nos próximos meses e anos. Com base em muitas conversas, parece que os problemas mais críticos já foram arquivados, muitos deles foram corrigidos e continuaremos corrigindo-os conforme surgirem.

Há um monte de problemas que ainda não foram

Já mencionei isso antes, mas vale a pena repetir: WordPress 5.0 não é a linha de chegada, é a pistola de partida. Muitos de nós neste tópico temos trabalhado juntos no WordPress por anos antes de Gutenberg começar, e espero que estejamos trabalhando juntos no WordPress nos próximos anos. Vimos muitos novos recursos chegarem ao WordPress ao longo dos anos, e nenhum deles permaneceu o mesmo de quando foram lançados pela primeira vez. Enfrentamos desafios que muitos outros projetos considerariam intransponíveis, mas os fizemos funcionar.

A missão do WordPress continua a ser democratizar a publicação. Acessibilidade é fazer as coisas funcionarem para pessoas que historicamente foram incrivelmente marginalizadas. Estes não são apenas complementares, a missão do WordPress inerentemente requer que seja acessível.

O que lançamos no WordPress 5.0 não é definido em pedra, vamos continuar a consertar, retrabalhar, aprender com ele e torná-lo melhor. Gutenberg é a base sobre a qual podemos construir a próxima geração da web, e o potencial para melhorar a acessibilidade de toda a web também está presente. Cada componente, cada bloco, cada interface deve ser totalmente acessível, e cada plugin e tema deve ser capaz de tirar vantagem disso. A geração Gutenberg deve fornecer uma experiência acessível _por padrão_. Além disso, o verificador de contraste de cores e os avisos de hierarquia de títulos são bons exemplos de como Gutenberg pode tornar a criação de conteúdo acessível o comportamento padrão também.

Eu desbloqueei e reabri este problema e o fiz para o futuro, mas podemos facilmente movê-lo para um marco mais próximo em um ponto posterior. Tenho um pedido especial para que todos tentemos nos manter no assunto e nos concentrar em uma conversa produtiva. Eu adoraria ver-nos pegar o que foi iniciado aqui e descobrir uma estrutura para uma auditoria de acessibilidade de qualidade, algo que pode se expandir para cobrir o escopo da fase 2 de Gutenberg e além. Podemos não estar lá ainda, mas estaremos. ❤️

Relacionado # 10537.

WordPress 5.0 não é a linha de chegada, é a pistola de partida.

Em última análise, porém, aquela pistola de partida parece funcionar apenas para aqueles sem habilidades diferentes. Uma pistola de partida funciona na prática, porque o som é alto o suficiente para criar um rastro no ar que os surdos podem sentir e porque faz um clarão / fumaça que eles podem ver; faz um som para os cegos ouvirem. Uma pistola de partida é acessível a todos; Gutenberg não parece ser.

Ao se recusar a sequer considerar pausar o lançamento de Gutenberg até que uma auditoria anual tenha sido realizada, você está efetivamente dizendo a qualquer um que _fisicamente_ não pode usar Gutenberg que eles não importam para a comunidade WordPress. Isso vai contra os padrões da comunidade WordPress, é irresponsável e, francamente, é embaraçoso e perigoso para um produto que é tão onipresente ter esse tipo de atitude em relação a tantas outras comunidades.

Eu criei o rótulo "Necessita de feedback sobre acessibilidade" para problemas que exigem que alguém com conhecimento de acessibilidade entre em contato, mas como não há nada que possa ser acionado neste problema, estou removendo o rótulo 😄

Ninguém está dizendo nada disso, @cgrymala. Como mencionei, uma auditoria de acessibilidade profissional _nunca_ foi um requisito para que qualquer recurso fosse mesclado no histórico do WordPress. Eu certamente gostaria de ver uma auditoria acontecer, mas escrever que a falta de auditoria é "irresponsável ... embaraçoso e perigoso" é o tipo de hipérbole que atrapalha o diálogo construtivo.

Vou reiterar meu pedido de meu comentário anterior, por favor, permaneça no tópico e concentre-se em uma conversa produtiva .

Mais especificamente, a falta de auditoria não nos impede de corrigir os problemas. Se a acessibilidade é importante para você, se você (ou alguém que conhece) usa tecnologia assistiva, agora é um excelente momento para testar e relatar bugs.

@pento , não percebi que ninguém argumentou que uma auditoria era precedente? Isso parece um argumento espantalho e, com base nessa discussão, o precedente simplesmente não foi a gênese da ideia de auditoria.

A auditoria foi sugerida por @tofumatt porque há boas razões para acreditar que Gutenberg não é tão acessível como deveria de acordo com os próprios padrões do WordPress. Sem uma auditoria independente, ou mesmo apenas uma auditoria _A_, por que você espera que a comunidade de repente acredite que Gutenberg é acessível? A falta de auditoria não é irresponsável e perigosa, mas esse estilo de tomada de decisão e gestão ditatorial sim.

Dados os obstáculos da autenticação, não acho que trazer isso para o núcleo fornece benefícios para o WP além do que a comunidade obtém do plug-in. Não acredito que em seu estado atual o benefício supere o custo, e devemos errar pelo lado da simplicidade.

Isso é o que @m disse durante o debate da API WP. É mais um exemplo das hipocrisias que evidenciam esse ciclo de reciclagem, a começar pelo fato de que os "prazos não são arbitrários" a empresa se recusou a fixar uma data de lançamento para o 5.0, até que encontrou um que gostou e não houve espaço para debate . Amo Gutenberg e uso-o todos os dias. Ele oferece um grande valor como plug-in e, de acordo com a heurística do próprio Matt, devemos errar pela simplicidade até que esteja realmente pronto.

A acessibilidade é importante para muitas pessoas neste tópico, que ofereceram tempo, suporte e dinheiro para nos ajudar a navegar neste impasse. É hipócrita da sua parte sugerir que, se realmente nos importássemos, estaríamos corrigindo os problemas.

Em relação aos motivos apresentados para o cancelamento da auditoria:

uma auditoria não será acionável devido ao nosso cronograma de lançamento, porque ...
a auditoria não afetará o tempo de lançamento, então ...
seria mais prudente explorar uma auditoria em um cronograma menos apressado no futuro

Mesmo que a ideia de uma auditoria de terceiros esteja morta, implícita na ideia de https://github.com/WordPress/gutenberg/issues/10537 estaria a auditoria de Gutenberg para meios de acessibilidade. O fato de a Automattic estar disposta a liberar Gutenberg para o Core sem padrões autoimpostos de acessibilidade é extremamente problemático . Em última análise, fico desanimado por ser lembrado de que, no final do dia, os interesses da Automattic parecem ser promovidos acima dos da comunidade quando se trata do desenvolvimento e lançamento de Gutenberg.

Este tópico é sobre:

1. conduzindo uma auditoria
2. arquivamento de problemas com base na auditoria
3. postando seus resultados como um relatório para o blog Make / Accessibility

Reconhecemos a utilidade de uma auditoria e que as pessoas gostariam que fosse realizada. Por favor, mantenha comentários relacionados ao processo de:

1. conduzindo a auditoria
2. escopo da auditoria
3. resultados da auditoria

Estou escondendo comentários fora do tópico que estão reformulando o que foi dito e destacando a importância de uma auditoria. Eu gostaria de ver um conduzido. Estamos todos de acordo nisso. Por favor, mantenha os comentários sobre o tópico produtivo e certifique-se de que eles estão fornecendo novas informações / adicionando ao problema em questão.

@davisshaver Lembre-se da etiqueta do

As contribuições para o projeto de código aberto WordPress são para o benefício da comunidade WordPress como um todo, não de empresas ou indivíduos específicos. Todas as ações realizadas como um colaborador devem ser feitas tendo em mente os melhores interesses da comunidade.

O projeto de código aberto WordPress é uma comunidade gerida por voluntários. Mesmo nos casos em que os contribuidores são patrocinados por empresas, esse tempo é doado para o benefício de toda a comunidade de código aberto.

Enquanto @pento , @tofumatt , @m e outros são doados pela Automattic, eles estão trabalhando para melhorar o projeto. A Automattic não é quem está decidindo quando Gutenberg será lançado.

A auditoria pode e continuará conforme observado por @pento :

agora é um excelente momento para testar e relatar bugs.

Tudo o que pode ser feito para ajudar a contribuir para esse processo de teste e relatório é benéfico. Existem vários problemas mais antigos que podem ser usados ​​em testes para verificar se ainda são um problema que não requer nenhuma tecnologia de assistência especializada para teste. Isso seria de grande ajuda e é em parte o que uma auditoria independente teria fornecido.

Eu não sabia que ser líder de lançamento do WordPress.org envolvia Matt deixando sua responsabilidade fiduciária para a Automattic. Embora você possa argumentar que o conflito é mínimo, ou que Matt trabalha ativamente para mitigá-lo, a etiqueta do WordPress que você citou é uma recomendação e não uma descrição do mundo ... Em última análise, o conflito existe.

Tenho certeza de que muitas pessoas estão espreitando esse tópico no momento e direi se você está interessado e quer ajudar, mas não usou tecnologia assistiva antes (leitores de tela) participe da discussão em https: // make .wordpress.org / chat / no canal de acessibilidade. Sinta-se à vontade para entrar em contato com um mestre até mesmo. Você pode se surpreender com o quão fácil é configurar o NVDA / Voice Over / JAWS para que você possa começar a testar as coisas.

Além disso, existem muitas ferramentas disponíveis para testar os requisitos WCAG:
Machado de cromo:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

Verificador de contraste para WCAG: https://chrome.google.com/webstore/detail/wcag-contrast-checker/plnahcmalebffmaghcpcmpaciebdhgdf?hl=en

Ferramentas A11y do Chrome: https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en

Existem 113 problemas em aberto com o rótulo de acessibilidade que estão abertos no momento:
https://github.com/WordPress/gutenberg/labels/Accessibility

Quer concordemos ou não com as decisões atuais que estão sendo tomadas, acho que todos podemos concordar que ainda há muito trabalho que todos podemos participar para ajudar a resolver. Mesmo na ausência de uma auditoria oficial, a comunidade ainda tem o poder de ajudar a oferecer uma experiência mais acessível.

Esta edição foi registrada para divulgar meu trabalho na auditoria de acessibilidade, para comunicar que gostaria que acontecesse e para rastrear o compartilhamento dessa auditoria em uma postagem do blog. Não é um ponto de discussão sobre o que deve ser considerado um bloqueador de lançamento do WordPress 5.0. Anotei as opiniões das pessoas sobre o assunto e as retransmitirei para

1. I don't have have veto over 5.0 shipping, but even if I did:

2. I'm still not convinced there are sufficient Accessibility issues that prevent a release

Se o segundo ponto mudar, transmitirei essa informação. Pretendo ser um defensor, mas não defino os prazos e também não tenho dados sólidos sobre acessibilidade. Esse é o objetivo da auditoria: para que possamos falar de um lugar de dados concretos. 🙂

Obrigado por todas as contribuições, mas como esta discussão saiu do assunto de seu escopo pretendido, estou bloqueando a conversa deste problema por enquanto. Vou deixá-lo aberto e postar atualizações sobre a auditoria.

Literalmente, todas as pessoas com deficiência que testaram o Gutenberg, recentemente e no início, sinalizaram problemas de bloqueio que explicam por que ele não está acessível. E o teste do usuário é tão importante para a acessibilidade quanto a conformidade com o nível AA do WCAG 2.0. Provavelmente deveria dizer WCAG 2.1 AA neste ponto, mas WCAG 2.0 ainda deixa você muito mais perto de onde você precisa estar. Dizer que você não tem dados é, na melhor das hipóteses, impreciso.

A falta de uma auditoria neste caso é irresponsável porque, para começar, ao contrário do WordPress no passado, foi escolhida uma estrutura que não vem com componentes acessíveis prontos para uso e, ao contrário do WordPress anterior, você está modificando fortemente o documento modelo de objeto com Gutenberg, bem como remover coisas da árvore de acessibilidade e, no caso de navegadores, o DOM e a árvore de acessibilidade são literalmente como a tecnologia assistiva recupera informações para interpretar. Mesmo se você deixar a tecnologia assistiva fora disso, como Gutenberg está atualmente, a carga cognitiva é enorme. O plugin do editor clássico é um substituto completamente inaceitável. Para começar, é todo o site. Portanto, se um site usa o Gutenberg e eu preciso entrar e fazer algo com o conteúdo, não posso fazer isso por usuário e não consigo instalar o plugin do editor clássico, fazer meu trabalho e depois desinstalar e esperar que tudo se comporte como deveria, uma vez que a reversão para Gutenberg ocorra. E sim, eu testei isso. O fato de a acessibilidade estar sendo deixada em segundo plano, mais uma vez, é literalmente como o WordPress entrou na confusão em que estava em 2011/2012, quando a equipe de acessibilidade saiu do papel. E o projeto está literalmente cometendo exatamente o mesmo erro de novo, e nos pedindo para confiar que ele acabará acertando novamente. Sinto muito, mas quantas vezes as pessoas com deficiência têm que ser mandadas para a parte de trás do ônibus para um bem maior? Quantas vezes teremos que ficar satisfeitos com um monte de palavras bonitas sobre acessibilidade, sobre como prometemos que faremos melhor na próxima vez, apenas para descobrir quando se trata de elementos de metal que acessibilidade realmente não é um prioridade?

Pelo menos por enquanto, a Automattic decidiu renunciar à realização de uma auditoria de acessibilidade em Gutenberg. As principais razões são:

1. uma auditoria não será acionável devido ao nosso cronograma de lançamento, porque ...
2. a auditoria não afetará o tempo de lançamento, então ...
3. seria mais prudente explorar uma auditoria em um cronograma menos apressado no futuro

@tofumatt @pento Você pode esclarecer se o cronograma mencionado aqui se refere a uma data de lançamento de 19 de novembro de 2018 ou 22 de janeiro de 2019, conforme mencionado no Escopo e Cronograma Propostos para WordPress 5.0 ?

A data de 22 de janeiro de 2019 permitiria mais de três meses entre hoje e o lançamento do 5.0 para concluir uma auditoria e agir. Os motivos acima sugerem que não podemos concluir uma auditoria e melhorar significativamente a acessibilidade em três meses. Se for verdade, esse é mais um motivo para iniciar o processo agora e responder à auditoria corrigindo o máximo de problemas possível antes dos lançamentos 5.0.

A ideia de que a linha do tempo se tornará menos apressada após o 5.0 (quando está nas mãos de usuários do mundo real que mais precisam dela) não faz sentido algum.

Os sites que estavam em conformidade com o nível AA do WCAG 2.0, mas com novos conteúdos editados com Gutenberg, não estarão em conformidade quando o 5.0 for lançado, o que desencadeia um pesadelo jurídico.

Obrigado a todos que comentaram aqui até agora e mantiveram a discussão no tópico. Eu realmente agradeço: com tanta coisa acontecendo em torno do WordPress 5.0, realmente me ajuda a ser capaz de reservar o tempo que esse problema merece. 🙂

@amandarush : Você mencionou várias preocupações, vou tentar responder a todas, mas por favor me avise se eu perder alguma coisa.

Literalmente, todas as pessoas com deficiência que testaram o Gutenberg, recentemente e no início, sinalizaram problemas de bloqueio que explicam por que ele não está acessível.

Sou muito grato a todos que sinalizaram esses problemas. Achei que tínhamos feito um trabalho razoável ao abordar esses problemas à medida que surgiam, mas claramente há mais trabalho a fazer. Quando @tofumatt se refere a "não ter dados", acredito que ele está olhando da perspectiva de que corrigimos muitos problemas de acessibilidade, não temos uma ideia completa do estado atual das coisas, então queremos obter uma imagem mais clara da gravidade dos problemas restantes.

A falta de uma auditoria neste caso é irresponsável porque, para começar, ao contrário do WordPress no passado, foi escolhido um framework que não vem com componentes acessíveis prontos para uso

Você está se referindo a React aqui? Meu entendimento é que os aplicativos desenvolvidos com React são igualmente acessíveis a qualquer outra biblioteca que atualiza dinamicamente o DOM. Desde que façamos o uso adequado dos atributos aria-* (bem como garantindo a focalização previsível do teclado), ele deve ser utilizável com tecnologia assistiva. Isso não é correto?

O plugin do editor clássico é um substituto completamente inaceitável. Para começar, é todo o site. Portanto, se um site usa o Gutenberg e eu preciso entrar e fazer algo com o conteúdo, não posso fazer isso por usuário e não consigo instalar o plugin do editor clássico, fazer meu trabalho e depois desinstalar e esperar que tudo se comporte como deveria, uma vez que a reversão para Gutenberg ocorra.

Obrigado por trazer este caso de uso, é um bom exemplo de onde o plugin do Editor Clássico falha atualmente. Certamente podemos adicionar uma opção por usuário.

E o projeto está literalmente cometendo exatamente o mesmo erro de novo, e nos pedindo para confiar que ele acabará acertando novamente. Sinto muito, mas quantas vezes as pessoas com deficiência têm que ser mandadas para a parte de trás do ônibus para um bem maior? Quantas vezes teremos que ficar satisfeitos com um monte de palavras bonitas sobre acessibilidade, sobre como prometemos que faremos melhor na próxima vez, apenas para descobrir quando se trata de elementos de metal que acessibilidade realmente não é um prioridade?

Eu sinto Muito. Apesar das melhores intenções de todos na equipe de Gutenberg, não fizemos o suficiente. Posso dizer honestamente que a acessibilidade _tem_ sempre foi uma prioridade, mas não foi uma prioridade _alta o suficiente_ e fizemos um trabalho ruim de comunicação onde a acessibilidade foi melhorada. Mencionei algumas dessas melhorias em meu comentário anterior, mas essas melhorias não trazem nenhum benefício se não atingirmos a experiência acessível básica.

Claro, um pedido de desculpas não adianta sem ações para corrigi-lo, então aqui está o que estou propondo. No momento, a intenção é priorizar e corrigir o máximo possível de problemas de acessibilidade. Já consertamos centenas e há consertos em andamento para alguns dos problemas em aberto. Estaremos testando, é claro, mas precisamos da experiência de pessoas que usam tecnologia assistiva para descobrir bugs. Qualquer teste e relatório de bug para os quais você possa reservar um tempo será muito apreciado.

Embora eu acredite que possamos colocar o editor de blocos em um estado em que tenha uma UX aceitável para usuários de tecnologia assistiva quando o 5.0 for lançado, reconheço que existe a possibilidade de não podermos. Além da configuração por usuário que você sugeriu, de que outra forma podemos garantir que o plugin do Editor Clássico seja uma opção razoável para as pessoas usarem até que estejam satisfeitas com o estado do editor de blocos?

Eu ainda gostaria de ver uma auditoria de acessibilidade independente acontecer, mas sem o cronograma apressado do lançamento 5.0. É aí que esse problema pode ser usado para criar a estrutura para uma auditoria abrangente. Como os problemas são descobertos, eles podem ser corrigidos nas versões 5.0.x, certamente não há necessidade de esperar pela 5.1.

@kevinwhoffman : O cronograma se refere à data de lançamento em 19 de novembro (ou 27 de novembro, no máximo). Adiar a data de lançamento para 22 de janeiro não nos daria muito tempo extra: entre WCUS (e a preparação necessária para isso), a necessidade de organizar um lançamento WordPress 4.9.9, então pessoal estar de férias no Natal e Ano Novo, podemos ganhar mais duas semanas inteiras de trabalho adiando a data de lançamento em dois meses. Três meses extras parecem uma quantia generosa, mas nos dariam muito poucos resultados reais, e ainda precisaríamos de uma auditoria rápida, portanto, poderíamos estar trabalhando para resolver isso em novembro.

@rcemory : Embora seu comentário seja um pouco fora do assunto, é importante notar que esta discussão está relacionada à própria interface do editor de blocos, não ao conteúdo que ele produz para exibir no front end do seu site. Tal como acontece com o WordPress agora, o conteúdo produzido no editor de blocos está acessível. Em muitos casos, é mais acessível do que antes, como o editor de bloco faz um trabalho melhor ao adicionar aria-* rótulos apropriados, ele avisa quando você está usando combinações de cores que não são compatíveis com WCAG, ou quando você está colocando elementos de título na ordem errada.

O plugin do editor clássico é um substituto completamente inaceitável. Para começar, é todo o site. Portanto, se um site usa o Gutenberg e eu preciso entrar e fazer algo com o conteúdo, não posso fazer isso por usuário e não consigo instalar o plugin do editor clássico, fazer meu trabalho e depois desinstalar e esperar que tudo se comporte como deveria, uma vez que a reversão para Gutenberg ocorra.

Obrigado por trazer este caso de uso, é um bom exemplo de onde o plugin do Editor Clássico falha atualmente. Certamente podemos adicionar uma opção por usuário.

Isso seria ótimo, mas é uma preocupação que foi levantada há mais de um ano e não foi abordada até agora. Uma vez que no estado atual das coisas, uma vez que uma postagem vai para GB, ela não pode ser revertida para "normal" e depois de volta para GB novamente, mantendo todas as informações relevantes.
Portanto, o plano de ter uma opção baseada no usuário simplesmente não é realista, pois significa que os editores que optarem por não aderir ao GB terão dificuldade em editar o conteúdo criado por autores que usam o GB.

Os comentários de @amandarush são poderosos e

Desde que estive envolvido na Equipe de Acessibilidade, ocorreram 4 (eu acho) grandes atualizações de funcionalidade na área de administração: Construtor de menu personalizado, Gerenciador de mídia, Personalizador e agora Gutenberg.

Como originalmente concebidos e construídos, todos esses componentes eram praticamente (ou totalmente) inacessíveis para usuários de leitores de tela e usuários de teclado com visão. Na minha opinião, isso se deve ao fato de a acessibilidade não ser pensada de forma alguma nas fases de design gráfico e UX. Depois que a Equipe de Acessibilidade gritou, melhorias de acessibilidade foram feitas em todos os 4, mas o design subjacente e UX permanecem basicamente os mesmos.

Portanto, compartilho sua visão de que o WordPress continua cometendo o mesmo erro indefinidamente. E, infelizmente, compartilho seu ceticismo quando ouvimos "A acessibilidade é muito importante para nós". É muito frustrante, e uma das razões pelas quais raramente contribuo mais para o WP.

Parece improvável agora que as preocupações com acessibilidade parem o impulso para lançar o WP5.0 em novembro, o que é claro, é uma grande decepção depois que a lista de 'bloqueadores' de acessibilidade foi elaborada pela primeira vez na primavera deste ano. E o desejo freqüentemente citado de WP para democratizar a web, e a promessa de não lançar nenhuma funcionalidade que não seja compatível com WCAG2.0.

Mas acho que uma revisão independente de acessibilidade - envolvendo não apenas testes para WCAG2.1, mas também testes de usuário adequados - seria uma coisa sensata a se fazer agora. Pelo menos dessa forma, todos nós saberíamos onde estamos, e o foco apropriado pode ser dado para priorizar e corrigir os defeitos / problemas de acessibilidade em versões futuras.

Em resposta a isso de @pento

Você está se referindo a React aqui? Meu entendimento é que os aplicativos desenvolvidos com React são igualmente acessíveis a qualquer outra biblioteca que atualiza dinamicamente o DOM. Desde que façamos uso apropriado dos atributos aria- * (bem como garantindo a focalização previsível do teclado), ele deve ser utilizável com tecnologia assistiva. Isso não é correto?

Sim, é verdade, mas os desenvolvedores precisam entender como tornar seus componentes acessíveis em design, semântica, operação, gerenciamento de foco e com o uso correto do ARIA. Infelizmente, isso raramente acontece na minha experiência.

Se / como o Automattic segue o caminho de uma auditoria, pode valer a pena não apenas identificar fluxos críticos / jornadas do usuário, mas também widgets comuns para revisar. Se esses widgets puderem ser identificados e auditados sozinhos, eles também podem formar a base de uma biblioteca de padrões acessível. Isso pode ajudar a mitigar os riscos de acessibilidade à medida que mais recursos são criados usando esses padrões.

pode valer a pena não apenas identificar fluxos críticos / jornadas do usuário, mas também widgets comuns para revisar. Se esses widgets puderem ser identificados e auditados sozinhos, eles também podem formar a base de uma biblioteca de padrões acessível. Isso pode ajudar a mitigar os riscos de acessibilidade à medida que mais recursos são criados usando esses padrões.

@aardrian Esse é um ponto de partida interessante que pode já existir e que será necessário para a auditoria que podemos usar agora para agir: Eu não vi jornadas de usuário para Gutenberg, e esse é provavelmente o ponto de partida mais óbvio para começando a definir o escopo dessa auditoria.

@karmatosed @jwold - Você sabe se os ditos fluxos / jornadas para usar Gutenberg já existem? Talvez uma lista de "widgets" ou "padrões", conforme descrito aqui?

Eu acho que embora este tópico geral tenha muita emoção (e eu concordo que Gutenberg deve ser usado por todos e enviado quando estiver pronto) - eu adoraria encontrar um terreno comum e os próximos passos. Eu adoraria mudar os lugares de conversa para identificar onde estamos prontos para a ação.

Esse fluxo de usuário também nos daria uma lista de tarefas de locais para auditoria, para desenvolvedores, testadores e caçadores de bugs começarem a se dividir e procurar coisas para relatar.

@postphotos , acho que @afercia descreveu um bom conjunto de fluxos acima em https://github.com/WordPress/gutenberg/issues/10318#issuecomment -428957684.

@aardrian Concordo, é um ótimo lugar para começar! 👍 Obrigado por lembrar isso.

Minha pergunta continua de pé - eu adoraria saber, além desse fluxo crítico inicial, se há trabalho adicional que já foi colocado nas jornadas do usuário no que se refere aos recursos, pois ajudará a validar o trabalho que estamos fazendo aqui. Pode haver outros itens que nós (este grupo) podemos querer adicionar à lista inicial de @afercia , ou sequência após uma auditoria inicial. 😄

Por exemplo, não chamamos o recurso de Estrutura de Conteúdo, desfazemos / refazemos, etc. ou visualizamos uma postagem, e essas tarefas que podemos concordar são importantes e úteis para os usuários poderem usar - as coisas que concordamos fazem Gutenberg incrivelmente útil e deve ser acessível. Seria ótimo encontrar consenso ativamente, se possível.

Um benefício adicional de fazer uma auditoria é a contribuição de volta ao projeto React maior. O React tem seus próprios problemas de acessibilidade, e uma auditoria de Gutenberg pode muito bem identificar problemas e soluções que se relacionam e podem ajudar no núcleo do React.

Bem, esta é uma notícia empolgante: https://make.wordpress.org/core/2018/10/18/regarding-accessibility-in-gutenberg/

Atalhos de teclado para navegação de região e bloco, comandos de barra, barra de ferramentas focalizável e melhorias na barra lateral de marcos e funções ARIA aprimorados, testes automatizados de ponta a ponta e muito mais.

ICYMI: A organização WPCampus está organizando uma auditoria de acessibilidade de Gutenberg.

Concluímos nossa RFP e agora estamos selecionando um fornecedor.

No entanto, como a maioria de vocês provavelmente sabe, uma auditoria de acessibilidade profissional é uma grande despesa para uma pequena organização sem fins lucrativos como a WPCampus.

Estamos pedindo sua ajuda para financiar a auditoria para garantir que essa pesquisa vital seja concluída.

Você pode ler mais sobre a iniciativa e fazer doações em nosso site: https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

Oi Rachel,

Vejo que você está nos pedindo para fazer uma doação para a auditoria.
Gostaria de saber se você pensou em minha postagem neste tópico que escrevi
alguns meses atrás, oferecendo-se para doar auditoria de acessibilidade, pois esta
resolveria totalmente qualquer lacuna restante no financiamento?
Temos a confiança de alguns dos principais governos e empresas Fortune 500 do mundo
com esses projetos!

Aqui está o que postei em 11 de outubro de 2018:

============================

@tofumatt https://github.com/tofumatt Também estou muito preocupado com
Acessibilidade WordPress e ansiosos para ajudá-lo a ter sucesso. Eu posso ter nosso
organização realizar uma auditoria de acessibilidade em conformidade com WCAG-EM completa para
qualquer nível padrão que você preferir, incluindo técnico e funcional
teste, * e doe qualquer parte do trabalho que você precisa * para ajustar o seu
despesas.

Eu acho que devemos olhar para ATAG e WCAG AA, e talvez
WCAG 2.1 em vez de 2.0. Também podemos fornecer recomendações e
coaching para ajudá-lo a escolher a melhor e mais sustentável forma de fechar qualquer
lacunas descobertas.

Estamos convenientemente distantes de sua comunidade de desenvolvimento, mas sabemos
WordPress bem por muitos anos. Eu possuo todas as certificações IAAP e conduzi
dezenas dessas auditorias na plataforma WordPress, ao longo de muitos anos, para ambos
setor privado e público. Por favor, verifique nossa boa fé em

davidberman.com/sobre para decidir como podemos melhor ajudar.

Pensamentos?

• David

Na quarta-feira, 28 de novembro de 2018 às 10:10, Rachel Cherry [email protected]
escrevi:

ICYMI: A organização WPCampus está organizando uma auditoria de acessibilidade de
Gutenberg.

Terminamos nosso RFP
https://wpcampus.org/2018/10/gutenberg-a11y-audit-rfp/ e agora
selecionando um fornecedor.

No entanto, como a maioria de vocês provavelmente sabe, um profissional
a auditoria de acessibilidade é uma grande despesa para uma pequena organização sem fins lucrativos como a WPCampus.

Estamos pedindo sua ajuda para financiar a auditoria e garantir este
a pesquisa está concluída.

Você pode ler mais sobre a iniciativa e fazer doações em nosso site:
https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/WordPress/gutenberg/issues/10318#issuecomment-442480511 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABz4pIgVSgZmWJRL2n3Uy-i8Ov7NXnj1ks5uzqdcgaJpZM4XG_WQ
.

-
David Berman, RGD, FGDC, CPWA
David Berman Communications | [email protected] | @davidberman
+ 1-613-728-6777 https://dialpad.com/launch?phone=%2B1-613-728-6777 | 340
Avenida Selby, Ottawa K2A 3X6

Conselheiro de alto nível, Nações Unidas | Especialista convidado, W3C | Ico-D
Cadeira de Sustentabilidade | Cadeira Carleton U. Access Network

Próximo: Toronto | New Orleans | Montreal | Buenos Aires | Tampa | Tel Aviv
Curso de acessibilidade: junte-se a nós online www.davidberman.com/next

Esta mensagem pode conter informações proprietárias. Não autorizado
divulgação / cópia / distribuição de conteúdo proibida.

@tofumatt , vi isso no blog pessoal de Matt Mullenweg em 29 de novembro:

Finalmente, a Automattic financiará um estudo de acessibilidade do WordPress, Gutenberg e uma avaliação das melhores práticas em toda a web, para garantir que o WordPress seja totalmente acessível e definir novos padrões para a web em geral.

Como você é um representante da Automattic, agora que a auditoria Automattic está de volta, você pode nos dizer se ela será separada da auditoria WPCampus ou a Automattic financiará a auditoria WPCampus?

Por um lado, eu odeio ver o WPCampus ter que financiar isso em conjunto. Por outro lado, gosto da ideia de duas auditorias de duas empresas para comparar e contrastar.

Matt respondeu à minha pergunta em seu blog:

Acho que não há problema em ter dois também, vou conversar com Rachel sobre como está indo o financiamento.

Para aqueles que estão acompanhando, se comprometeram a financiar totalmente todas as necessidades do projeto de Rachel no Campus WP e na fase de seleção do fornecedor para o patrocinado pela Automattic. O objetivo do último é ver também quais são as melhores práticas de acessibilidade para outras interfaces de estilo de editor de bloco na web moderna.

@m Obrigado pela atualização. É muito encorajador ver isso acontecendo e eu realmente mal posso esperar para ver aonde isso vai levar. Eu adoraria que o WordPress um dia fosse o exemplo de como a acessibilidade deve ser tratada.

@m

Para aqueles que estão acompanhando, se comprometeram a financiar totalmente todas as necessidades do projeto de Rachel no WP Campus

Isso é ótimo e valioso. Existe alguma razão para você não financiá-lo no total, hoje? Parece estranho pedir às pessoas que continuem doando quando sabem que será totalmente financiado de qualquer maneira.

@aardrian Isso não está de acordo com o que estamos fazendo. Queremos que este seja um projeto comunitário e que permita às pessoas e organizações a oportunidade de participar e mostrar apoio, se puderem.

No final de 2018, o WPCampus lançou um pedido de propostas para conduzir uma auditoria de acessibilidade do editor de blocos do WordPress, também conhecido como Gutenberg. No início de 2019, anunciamos nossa escolha da Tenon, LLC para conduzir a auditoria, a um custo de $ 31.200.

Hoje, estamos animados para lançar o relatório de Tenon sobre a acessibilidade do novo editor.

Veja mais em https://wpcampus.org/2019/05/gutenberg-audit-results/

Acho que conclui esta edição 🎉🎉🎉🎉🎉

Todos os problemas relatados são rastreados neste projeto:
https://github.com/WordPress/gutenberg/projects/25

Todos os problemas relatados são rastreados neste projeto

Não totalmente correto. O relatório WPCampus / Tenon inclui considerações adicionais importantes que não são abordadas na lista de problemas no GitHub. Mais especificamente, o Resumo Executivo e o Relatório de Usabilidade mostram (com dados) que existem questões de acessibilidade estrutural mais amplas em Gutenberg que não podem ser tratadas em questões pequenas e acionáveis ​​do GitHub e requerem soluções em um nível superior.

Isso é para deixar claro que, mesmo que todos os problemas relatados sejam resolvidos, ainda haverá problemas importantes de acessibilidade a serem resolvidos. Normalmente, eles estão relacionados ao design geral do editor.

Para referência, estou anexando aqui dois dos documentos publicados em https://wpcampus.org/2019/05/gutenberg-audit-results/

Documento de resumo que descreve o teste de usabilidade de Tenon
Gutenberg_UX_Report.pdf

Sumário executivo
Gutenberg_Executive_Summary.pdf

Sugiro abrir um novo problema, ou mesmo projeto, para lidar com os problemas de usabilidade descobertos no relatório.