Software CMS accesible
Mi empresa necesita incorporar software de CMS en su sitio web público. Queremos un software que produzca marcado semántico para maximizar la accesibilidad. ¿Alguien puede sugerir alguna?
En este momento, no necesitamos limitar la plataforma tecnológica; podría ser PHP, Ruby o ASP.NET, por ejemplo.
La accesibilidad es solo uno de los criterios que estudiaremos cuando elijamos el CMS.
Como se mencionó anteriormente, hay diferentes aspectos de accesibilidad cuando se discute un CMS:
- La presentación/tema/capa de piel
- El sistema que genera datos/código en la capa de presentación
- El contenido en sí
(Además, la accesibilidad de las herramientas de entrada de contenido también puede ser una consideración)
Cada uno de los aspectos enumerados anteriormente se puede construir para alentar o desalentar la accesibilidad. Si bien aplaudo su esfuerzo por considerar la accesibilidad tan temprano en el proceso, en realidad recomendaría identificar algunas herramientas que cumplan con todos sus requisitos funcionales y luego evaluar su accesibilidad.
Para obtener mejores recomendaciones, algunos detalles sobre sus requisitos pueden ser útiles. Por ejemplo, para las necesidades básicas de CMS WordPress incluso podría ser una buena opción y tiene un buen historial de accesibilidad: http://codex.wordpress.org/Accessibility
Me gustaría intervenir y señalar que Drupal ha puesto un montón de trabajo para hacer que su producto sea accesible desde el primer momento. Es posible que desee consultar su declaración de accesibilidad ; y tienen un muy activo grupo de discusión de accesibilidad de Drupal , que también puede ser de interés.
Dicho esto, me gustaría agregar que independientemente de qué CMS use, la accesibilidad es más cultural que técnica. No importa si su CMS comienza accesible si no se mantiene así. Cualquier persona que toque código para la web debe recibir capacitación sobre lo que significa accesibilidad, qué funciona y qué no. No es necesario que se conviertan en expertos, pero si no atiende el lado de capacitación de la ecuación, es muy probable que termine con contenido mal codificado que rompa la accesibilidad porque el escritor simplemente nunca se detuvo a considerar qué tan bien funciona para personas que no pueden ver, oir, o que están paralizadas, etc.
Hice una revisión de accesibilidad de un sitio para una gran biblioteca una vez, en la que me encontré con este 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>
-->
Esta es una de las cosas más tristes que he visto en el mundo de la codificación. En algún momento, el sitio tenía un codificador que sabía cómo funcionaban los lectores de pantalla. El "navegador oculto" se puso allí para proporcionar un método conveniente para que los usuarios de lectores de pantalla regresen su cursor a la parte superior de la sección. Pero la institución no logró internalizar la práctica de la accesibilidad, y después de que ese codificador experto se fue, su sucesor desactivó esta característica de accesibilidad, no por malicia, sino por perplejidad. "RH" ciertamente nunca había usado un lector de pantalla, si es que habían escuchado hablar de tal cosa, y el código realmente no tiene sentido a menos que te des cuenta de que se supone que es leer en voz alta .
Entonces, aplaudo sus esfuerzos para elegir un CMS accesible. Pero por favor, no imagines que el trabajo se detiene allí. Si descuidas el lado humano de la ecuación, tu buen trabajo decaerá lenta pero seguramente con el tiempo.
Tengo buena experiencia con Drupal, un CMS de código abierto escrito en PHP. Si está interesado, puede echar un vistazo a su Declaración de accesibilidad . El desarrollo de Drupal es bastante activo.
La razón por la que la mayoría de los CMS producen sitios web con horribles HTML y CSS y semántica y accesibilidad es que la mayoría de los CMS no son muy buenos en la gestión de contenido, y luego intentan compensar eso siendo 'gestión de diseño'.
El mejor CMS no tendrá absolutamente ninguna plantilla automatizada. La plantilla debe dejarse a los desarrolladores y diseñadores web competentes.
Si el CMS resalta 'diseño de página fácil' o 'plantillas robustas', asuma que tomará el control total de nuestro resultado y lo absorberá.
GraffitiCMS hace que su marcado sea semánticamente correcto como lo desee. Todo depende de la calidad de su código de tema. El contenido en sí mismo es semánticamente correcto si utiliza su editor WYSIWYG para generar el contenido.
Te puedo proporcionar varios ejemplos de sitios geniales que usan Graffiti si estás interesado.
Umbraco es un CMS de código abierto. Su producto de formas, Contour, sigue las pautas WCAG.
Una cosa a tener en cuenta es que las WCAG son solo pautas y, al igual que las especificaciones HTML, la interpretación de cada producto puede ser diferente ya que no hay reglas en blanco y negro en la especificación. Obtendrá sitios "accesibles", pero al final, depende de usted y de sus usuarios determinar qué es suficiente.
Umbraco: http://umbraco.org/
Normalmente, la parte del cms que produce el marcado semántico es el tema o la máscara del cms. puedes usar casi cualquier cms siempre que obtengas un tema de alta calidad que tenga lo que estás buscando.
SharePoint 2007 es en realidad bastante compatible con W3C WCAG (Pautas de accesibilidad al contenido web).
En mi investigación, descubrí que un sitio web MOSS 2007) satisfará 15 de los 16 requisitos de Prioridad 1 de WCAG y la gran mayoría de los requisitos de Prioridad 2 y Prioridad 3.
Aquí está la Lista de verificación WCAG: Lista de verificación completa
Aquí hay una lista de funciones de accesibilidad en MOSS 2007: Funciones de accesibilidad
Por supuesto, mucho también depende de cómo cree su máscara y de cómo los usuarios ingresen su contenido, como señaló Scott M.