2010-12-02 14 views
10

En el espíritu de mejora progresiva, me gustaría hacer algunas pruebas de capacidades de ARIA para implementar mejoras adicionales si son compatibles con el navegador. No estoy buscando detectar lectores de pantalla. Estoy buscando garantizar que los usuarios de lectores de pantalla obtengan la experiencia óptima con las herramientas que están usando. Por ejemplo, si el atributo aria-live no es compatible, puede que no sea una buena idea implementar endless scrolling.WAI-ARIA: Javascript Capability Testing?

Soy consciente de que hay una preocupación adicional de que los navegadores pueden admitir estos atributos, pero es posible que el lector de pantalla no. Como los lectores de pantalla se ejecutan de forma transparente en los navegadores, estoy de acuerdo con que se ignore ese borde.

Nunca he escuchado que alguien haga algo como esto. ¿Es tan fácil como probar propiedades DOM adicionales dotadas por navegadores? ¿Trabaja uno de los otros capability testing techniques de Mark Pilgrim aquí?

Gracias!

+2

Para asegurarte de que entiendo, ¿quieres JavaScript que te dirá si los atributos 'aria- *' tienen algún efecto en el navegador actual? Por lo tanto, si los navegadores compatibles (combinando navegadores y complementos de accesibilidad) se aseguran constantemente de que 'aria-selected' tenga un valor de' true', 'false' o' undefined' como lo requiere http://www.w3.org/ WAI/PF/aria/states_and_properties # aria-selected luego el JavaScript 'var div = document.createElement ('DIV'); div.setProperty ('aria-selected', 'bogus'); if (div.getProperty ('aria-selected')! = 'falso') {alerta ('aria supported'); } '¿funcionaría? –

+1

¡Correcto! Sin embargo, en muchos navegadores puede establecer valores de atributo arbitrarios en elementos DOM.En el ejemplo que proporcionó, (subbing get/setProperty para get/setAttribute), obtiene la alerta en todos los navegadores que probé, incluidos FF1 y Safari 2 (ninguno de los cuales tiene ningún tipo de compatibilidad con ARIA). Estoy buscando algo que logre ese tipo de resultado, sin embargo. –

Respuesta

1

No estoy buscando para detectar los lectores de pantalla

Lo siento, pero eso es exactamente lo que está buscando hacer. No es posible detectar lectores de pantalla a menos que se expongan a secuencias de comandos de contenido de alguna manera, y hay muchos lectores de pantalla diferentes, por lo que no debería intentarlo. En todo caso, es posible que pueda obtener algún truco trabajando en navegadores compatibles con CSS aural para detectar lectores de pantalla, pero definitivamente no podrá detectar si una determinada característica ARIA es compatible o no.

si el atributo aria-vivo no es compatible

No hay navegadores realidad "apoyan" ARIA algo más que proporcionar acceso de propiedad de elementos en el DOM; solo los lectores de pantalla/software de lectura asistida son compatibles con ARIA, ya que en realidad usa los atributos de ARIA para ayudar al usuario a interactuar con un sitio web.

+1

Y siguiendo los hallazgos del reciente artículo de A List Apart [ARIA and Progressive Enhancement] (http://www.alistapart.com/articles/aria-and-progressive-enhancement/) (¿posiblemente la provocación para esta pregunta?) los lectores de pantalla varían bastante significativamente. Entonces, el olfateo del lector de pantalla será la única forma de hacerlo. –

3

La primera respuesta contiene información incorrecta. Algunos navegadores son compatibles con WAI-ARIA y otros no. Los navegadores envían eventos a los lectores de pantalla a través de la API de accesibilidad del sistema operativo. Si usa IE 7, por ejemplo, no puede tratar con WAI-ARIA donde IE 8 puede. Mire this graphic

Dicho esto, no puede hacer pruebas para determinar qué etiquetas son compatibles. En general, el soporte limitado de WAI-ARIA comenzó en FF2 e IE8. Mire las notas de la versión del navegador para determinar qué soporte de WAI-ARIA tiene.

Aquí es a link that details testing WAI-ARIA