• NoOxml
• Discapacitados
• Generalidades

3 Problemas Generales

Traducción hecha por OpenBox

En la sección 1.2, se presentaron algunas condiciones estándar de accesibilidad para un documento. Estas incluían que un estándar:

• Debe ser fácil de seguir (3.1)
• Debe ser consistente, sin un número grande de excepciones (3.1)
• Usa, en la medida que sea posible, otros estándares abiertos (3.2)
• Armoniza con otros estándares en el dominio ( 3.3 ) y,
• Pone a disposición la semántica de la programación a la tecnología adaptativa. (3.4)

Esta sección explica cómo el estándar OOXML falla en cada uno de estos puntos

3.1 Longitud, opacidad e inconsistencia del estándar de OOXML

Muchos individuos y organizaciones se han quejado acerca de la longitud y opacidad del estándar dentro del contexto de ISO JTC-1. El estándar es de 6.000 páginas de largo. un hecho irónico por sus escasas descripciones de muchos comportamientos (e.g., ver la sección 3.4 abajo) y peor por su pobre organización. Una razón de la longitud excesiva es que el estándar incluye descripciones de muchos módulos que son únicos a él. La mayor parte de estos módulos son las variaciones de la funcionalidad para las cuales los estándares existen ya. Esto plantea problemas de accesibilidad de los que nos ocuparemos en la siguiente subdivisión. Pero la longitud plantea otros problemas de accesibilidad también, porque se hace más susceptible a las inconsistencias internas. De hecho, en el corto plazo desde que fueron introducidos, muchos de éstos han sido encontrados. Estos violan los principios de la sección 1.2 haciendo muy difícil interconectarse con aplicaciones que ponen estas características del documento en ejecución. A pesar de la defensa de Ecma de que estas características son optionales, los vendedores AT no pueden tener el lujo de “saltarse una característica” AT debe ser compatible con todas las características posibles, de modo que se puedan utilizar para crear documentos. Si cualquier persona utiliza o ha utilizado siempre la característica especificada, un individuo con una inhabilidad puede encontrar la característica y AT debe ser capaz de procesarla apropiadamente.

3.2 No hace uso de estándares abiertos aplicables

Un formato de documento electrónico debe poder representar muchos tipos de contenido además del texto, tal como acoplamientos, los campos y los controles de la forma, las ecuaciones, los gráficos (para los dibujos, el clip art, las imágenes, los gráficos, etc.), y otros contenidos multimedia encajados para audio y video (especialmente en el contexto de los documentos de presentación).

Para cada uno de estos tipos contenidos, hay estándares existentes y “mejores prácticas”. De hecho, las preocupados por la accesibilidad estimaron el desarrollo de la mayor parte de estos estándares. Éstos incluyen:

Tabla 1. Estándares accesibles que existen para los varios tipos de contenidos

Sin embargo, en todos estos casos, OOXML sobrepasó estos acercamientos de accesibilidad en favor de los acercamientos inmaduros y funcionalmente redundantes (algunos basados obviamente en los formatos de propietario de Microsoft que nunca antes se han presentado tan abiertamente y para los cuales los detalles son escasos). Esto no sólo viola los principios dispuestos en la sección 1.3, sino también el espíritu de la Guía 11 de las Pautas de Accesibilidad de Web W3C. Como tal, OOXML aumenta la carga de los desarrolladores para AT, los cuales deben ahora descifrar y apoyar maneras alternas de hacer cosas similares; aun sí fuere el caso que cada uno de estas representaciones de contenidos fuesen favorables a los desarrolladores AT, estas todavía tienen que ser revisadas.

Esto parece haber seguido una tendencia general dentro de OOXML, pues la inconformidad con estándares numerosos internacionales ha sido encontradao en la oferta, incluyendo divergencias de o contradicciones con ISO 8601 ( representación de fechas y horas ), ISO 369 ( códigos para la representación de nombres y lenguajes ) ISO 216 ( tamaños de papel ), ISO/IEC 8632 ( Metarchivos de gráficas de computador ), ISO/IEC 10118-3, W3C XML-ENC y otros estándares criptográficos. Mientras que estos tienen menos implicaciones para la accesibilidad que aquellos de la tabla superior, aún violan los principios de la sección 1 forzando a los vendedores de AT a dar mantenimiento a situaciones superiores a los estándares.

Finalmente, OOXML sobrepasa por si mismo el estándar más relevante de su dominio, ISO/IEC 26300, “formato de documento abierto para el estándar de Aplicaciones de Office ”. Esto de por si es lo suficientemente importante como para abordarlo en su propia sección.

3.3 OOXML compite con los formatos de documento abierto (ODF) para le estándar de aplicaciones de Office (ISO/IEC 26300)

Muchos han tratado estos puntos desde varios ángulos. Por ejemplo, un argumento es que el proceso del desarrollo de los estándares de OOXML no siguió el proceso debido o apropiado para los estándares, que habrían podido remitir cualesquiera exigencias del consumidor (véase 3.2) o pudiera ser remitido a los redactores del proyecto de la ISO JTC1 para buscar mejoras o extensiones de búsqueda; en comparación con proponer enteramente un nuevo, estándar competente. Esto habría conducido a la consulta abierta de los grupos tratados a accesibilidad ( ver sección 2 ) Hay también un gran problema de accesibilidad. Como ODF y OOXML llenan el mismo espacio – al menos en términos de aplicaciones y los AT deben soportarlos -, la competencia entre los dos ha ido en contra de las comunidades con discapacidades pues ha incrementado el soporte de múltiples formatos, ha incrementado el surgimiento de diferentes plug-ins y band-aids, que los usuarios con discapacidades requieren para mantener sus sistemas al día de modo que haya interoperabilidad con ambos estándar. Las tecnologías de Asistencia agregan un nivel adicional de complejidad a cualquier interacción del usuario con una aplicación. Al crear un sistema AT las posibles incompatibilidades causadas por cada mejora o modificación están al menos en el doble. El efecto de dos estándares que responden a un propósito similar es más costoso para los desarrolladores AT y los usuarios de los mismo.

3.4 OXML hace referencia a los comportamientos y formatos cerrados de propietario

El estándar OOXML hace numerosas referencias a los comportamientos y formatos de propietario. Pr ejemplo, en ECMA-376 , Parte 4. sección 2.15.3, hay al menos 12 elementos definidos que hacen referencia a comportamientos de aplicaciones específicos de las aplicaciones heredadas sin especificar el qué son esos comportamientos. Estos incluyen:

• shapeLayoutLikeWW8
• autoSpaceLikeWord95
• wpSpaceWidth
• footnoteLayoutLikeWW8
• mwSmallCaps
• suppressTopSpacingWP
• truncateFontHeightsLikeWP6
• useWord2002TableStyleRules
• wpJustification
• uiCompat97To2003
• useWord97LineBreakRules
• lineWrapLikeWord6.

Por ejemplo, en la parte 4, sección 2.15.3.63, un elementos llamado "useWord2002TableStyleRules” es introducido. Y es descrito como:…. “….. este elemento específica que las aplicaciones deben emular el comportamiento de un procesador de texto previo ( Microsoft Word 2002 ) cuando la determinación del formato resultante de estilos de tabla aplicados a tablas dentro de un documento de WordprocessingML.

[Guía Para replicar fielmente este comportamiento, la aplicación debe imitar el comportamiento de esa aplicación, lo cual implica muchos comportamientos posibles y no puede colocar fielmente la narrativa para este estándar abierto de la Office XML. Si las aplicaciones desean emparejar este comportamiento, deben utilizar y duplicar la salida de esas aplicaciones. Se recomienda que las aplicaciones no repliquen intencionalmente este comportamiento debido a los problemas con su salida, y son mantenidos solamente por compatibilidad con los documentos existentes de esta aplicación.]

Éste es el grado de la definición del elemento. Hay muchos problemas de accesibilidad en un “estándar” como este. Por ejemplo, nótese que ese comportamiento referido no es especificado en ninguna otra parte del estándar, ni en ninguna otra documentación. Además, desde esta corta descripción no hay suficientes detalles para los desarrolladores AT para decidir sí este elemento tendrá un impacto en los desarrolladores AT, como los lectores de pantalla ( eso, recordemos, debe tener presente la estructura de la tabla . Y, como se discutió anteriormente, y cmo los desarrolladores de AT debían dar soporte a este elemento, dado que ECMA sentía que esta característica era importante o lo suficientemente extansa para incluirla en el estándar, todavía hay documentos existentes para los cuales esta etiqueta deberá ser marcada para que se haga accesible

Nótese que muchos de estos elementos especifican comportamietos relacionados con la organización espacial del documento, algo que extremadamente importante de entender para los AT, como se discutió en la sección 1.1. Son forzados a reversar la ingeniería de las aplicaciones de software ( muchos de los cuales explícitamente lo prohiben en sus acuerdos de licenciamiento ). Además, no es claro sí ellos pueden legalemente implementar esos comportamientos. La razón de la preocupación es la promesa “abierta” de la especificación de Microsoft que indica: “Clarificar que, las “demandas necesarias de Microsoft” son aquellas demandas de las patentes poseídas por Microsoft o controladas por Microsoft y que son necesarias para poner solamente las porciones en ejecución requeridas en la especificación y que se describen y refieren detalladamente a tal especificación. Las “especificaciones cubiertas” se enumeran abajo

Nótese que las cosas que “son referidas simplemente” por la especificación (como, por ejemplo, los comportamientos referidos a la sección 2.15.3 de la parte 4, probablemente) no estan exentas de demandas del IP de Microsoft. Sí este es en realidad el caso, entonces la mayoría de los vendedores tendrán opciones legales limitadas cuando enfrenten atributos como estos, salvo que las ignoren.

En efecto, esto significaría que los únicos vendedores capaces de correcta y legalmente exhibir los documentos de Microsoft de una manera compatible (sin licenciar) sería Microsoft. Especificando que son “opcionales” simplemente los medios que solamente los vendedores AT que entren en un acuerdo que licencia con el vendedor de la aplicación heredada (Microsoft o Corel) pueden hacer los documentos afectados completamente accesibles. Esto viola obviamente el requisito de base de la sección 1.3.

Finalmente, haciendo estos comportamientos de propietario parte del estándar ( en oposición a aplicaciones con extensiones especificadas para un elemento XML separado, como en la parte 5 de ECMA-376, con más soporte denotando cómo las aplicaciones deben lidiar con las etiquetas que ellos no entienden ), incrementa la necsaria complejidad de los aT para todas las aplicaciones – por ejemplo requiriendo casos especiales de manejo en el software - cuando los elementos solamente aplican a aplicaiones específicas. Estas caracterísiticas lesionana la interoperabilidad en la medida que los documentos que las contienen no serán completamente portátiles, minando uno de los puntos de tener un estándar abierto en primer lugar.

Los problemas son similares con respecto a los formatos propietarios referidos al estándar. Por ejemplo, la referencia de las marcas del estándar a los “Metafiles de Windows” y “realzó los Metafiles”, que son formatos propietarios específicos al sistema operativo de Windows. (Nota que ISO/IEC 8632 para “los Metafiles de los gráficos de computadora” se habría podido utilizar en lugar de otro.) por ejemplo, ECMA-376, parte 4, sección 6.4.3.1 especifica el tipo de “ST_CF (tipo del formato del portapapeles)”, una secuencia que propósito sea especificar el formato de ajuste para el portapapeles. El estándar dice: los siguientes son valores de enumeración posibles