Software CMS acessível
Minha empresa precisa incorporar algum software CMS em seu site público. Queremos um software que produz marcação semântica para maximizar a acessibilidade. Alguém pode sugerir alguma?
No momento, não precisamos limitar a plataforma de tecnologia - poderia ser PHP, Ruby ou ASP.NET, por exemplo.
A acessibilidade é apenas um dos critérios que examinaremos quando escolhermos o CMS.
Como mencionado acima, existem diferentes aspectos de acessibilidade ao discutir um CMS:
- A camada de apresentação/tema/capa
- O sistema que envia dados/código para a camada de apresentação
- O próprio conteúdo
(além disso, a acessibilidade das ferramentas de entrada de conteúdo também pode ser uma consideração)
Cada um dos aspectos listados acima pode ser construído para incentivar ou desencorajar a acessibilidade. Embora aplaude seu esforço para considerar a acessibilidade tão cedo no processo, eu recomendaria identificar algumas ferramentas que atendam a todos os seus requisitos funcionais e depois avaliá-las quanto à acessibilidade.
Para obter algumas recomendações melhores, alguns detalhes sobre seus requisitos podem ser úteis. Por exemplo, para necessidades básicas de CMS WordPress pode até ser um bom ajuste e ter um bom histórico em relação à acessibilidade: http://codex.wordpress.org/Accessibility
Eu gostaria de comentar e apontar que Drupal dedicou muito trabalho para tornar seu produto acessível imediatamente. Você pode consultar as declaração de acessibilidade ; e eles têm um muito ativo grupo de discussão sobre acessibilidade Drupal , que também pode ser interessante.
Dito isso, gostaria de acrescentar que, independentemente do CMS que você usa, a acessibilidade é mais cultural do que técnica. Não importa se o seu CMS inicia acessível se não permanecer assim. Qualquer pessoa que toque no código da Web precisa ser treinada sobre o que significa acessibilidade, o que funciona e o que não. Eles não precisam necessariamente se tornar especialistas, mas se você não atender ao lado do treinamento da equação, é muito provável que acabe com um conteúdo mal codificado que quebra a acessibilidade porque o escritor simplesmente nunca parou para considerar o quão bem funciona para pessoas que não podem ver, ouvir ou que estão paralisadas, e assim por diante.
Fiz uma revisão de acessibilidade de um site para uma grande biblioteca uma vez, na qual me deparei com esse trecho de código:
<!--don't know why "hiddenNav" is here - rh 3/21/08
<div class="hiddenNav">
<a href="#navigation_w">
<img src="/exhibitions/web/woodstein/images/spcr.gif" border="0" alt="Go to the Top" />
</a>
</div>
-->
Essa é uma das coisas mais tristes que eu já vi no mundo da codificação. Em algum momento, o site tinha um codificador que sabia como os leitores de tela funcionavam. A "navegação oculta" foi colocada lá para fornecer um método conveniente para os usuários de leitores de tela retornarem o cursor para o topo da seção. Mas a instituição falhou em internalizar a prática da acessibilidade e, após a saída do codificador experiente, o sucessor desativou esse recurso de acessibilidade - não por maldade, mas por perplexidade. O "RH" certamente nunca usou um leitor de tela, se é que eles ouviram falar disso, e o código realmente não faz sentido, a menos que você perceba que ele deveria ser lido em voz alta .
Então, aplaudo seus esforços para escolher um CMS acessível. Mas por favor, por favor, não imagine que o trabalho pare por aí. Se você negligenciar o lado humano da equação, seu bom trabalho decairá lenta mas seguramente com o tempo.
Tenho uma boa experiência com o Drupal, um CMS de código aberto escrito em PHP. Se você estiver interessado, pode dar uma olhada no Declaração de Acessibilidade . O desenvolvimento de Drupal é bastante ativo.
A razão pela qual a maioria dos CMS produz sites com HTML, CSS, semântica e acessibilidade horríveis é que a maioria dos CMSs não é muito boa em gerenciamento de conteúdo e tenta compensar isso sendo 'gerenciamento de design'.
O melhor CMS não terá absolutamente nenhum modelo automatizado. O modelo deve ser deixado para os desenvolvedores e designers da web competentes.
Se o CMS destacar 'layout de página fácil' ou 'modelos robustos', suponha que ele assumirá o controle total de nossa saída e será uma merda.
GraffitiCMS torna sua marcação tão semanticamente correta quanto você deseja. Tudo depende da qualidade do seu código de tema. O conteúdo em si é semanticamente correto se você usar o editor WYSIWYG para gerar o conteúdo.
Posso fornecer vários exemplos de ótimos sites usando o Graffiti, se você estiver interessado.
Umbraco é um CMS de código aberto. O produto de formulários, Contour, segue as diretrizes da WCAG.
É importante notar que as WCAG são apenas diretrizes e, como as especificações HTML, a interpretação de cada produto pode ser diferente, pois não existem regras em preto e branco nas especificações. Você obterá sites "acessíveis", mas no final das contas, cabe a você e seus usuários determinar o que é suficiente.
Umbraco: http://umbraco.org/
Normalmente, a parte do cms que produz a marcação semântica é o tema ou a capa do cms. você pode usar quase todos os cms, desde que obtenha um tema de alta qualidade com o que procura.
O SharePoint 2007 é praticamente compatível com o W3C WCAG (Diretrizes de acessibilidade de conteúdo da Web).
Em minha pesquisa, descobri que um site de MOSS 2007 2007 atenderá a 15 dos 16 requisitos da Prioridade 1 das WCAG) e a grande maioria dos requisitos da Prioridade 2 e Prioridade 3.
Aqui está a lista de verificação das WCAG: Lista de verificação completa
Aqui está uma lista dos recursos de acessibilidade em MOSS 2007: Recursos de acessibilidade
É claro que também depende muito de como você cria sua capa e de como os usuários inserem seu conteúdo, como apontou Scott M.