Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Noticias de Junio 2010
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
Noticias de Julio 2010
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
4.3.
INCLUSIÓN DE ENLACES
Los usuarios invidentes y con otras discapacidades se ayudan en la navegación de herramientas que les permiten mostrar un listado de todos los enlaces de una página. Por lo tanto, la descripción del enlace debe ser lo suficientemente buena para comprender su utilidad fuera del contexto. Por ejemplo deben evitarse textos para los enlaces como “pinche aquí”, “más”, etc.
Por otro lado, se ha de evitar la apertura de enlaces en nuevas ventanas del navegador dados los problemas que ello puede originar:
El usuario puede desorientarse, al no darse cuenta de lo que ha ocurrido.
La nueva ventana tendrá anulada la funcionalidad del botón "atrás".
Gestión de la Accesibilidad en Gestores de Contenido 17
El rendimiento del sistema puede verse reducido.
Puede confundir al usuario, en caso de que no entienda que la nueva ventana es realmente una ventana del mismo navegador que estaba usando.
El usuario se puede sentir confuso, puesto que los navegadores modernos bloquean en ocasiones la apertura de nuevas ventanas, lo que le puede hacer pensar que el enlace no funciona.
En caso de que dicha apertura resulte completamente necesaria, se ha de informar de la misma. Concretamente, para las Administraciones Públicas, se considera como necesaria o recomendable la apertura de ventana en los siguientes casos:
Enlaces a portales externos.
Enlaces a archivos adjuntos.
En principio, y según los requisitos de accesibilidad de la Norma UNE 139803:2004 es suficiente con avisar por medio del atributo title del enlace.
Pese a que la técnica anterior es suficiente, a continuación se exponen los métodos más aconsejables para avisar de la apertura de enlaces en nueva ventana.
Para los enlaces de texto:
En el texto del propio enlace:
Texto del vínculo (se abre en ventana nueva)
Aportando un elemento gráfico () que indique al usuario visualmente (y a través de su alternativa) la apertura de nueva ventana:
Texto del vínculo
Para los enlaces gráficos:
Como texto del enlace, o bien, aportando un elemento gráfico () que indique al usuario visualmente (y a través de su alternativa) la apertura de nueva ventana.
Aportando la información de apertura en nueva ventana en el contenido de la imagen. Para ello se puede incluir el elemento gráfico de apertura en nueva ventana
Gestión de la Accesibilidad en Gestores de Contenido 18
( ) dentro de la propia imagen, indicando al usuario visualmente y a través de su alternativa la apertura de nueva ventana:
Una solución válida tanto para enlaces textuales como para enlaces gráficos consiste en incluir el texto "Se abre en nueva ventana" en el propio enlace, mostrándolo a modo de tooltip mediante técnicas CSS cuando se fija el foco sobre el enlace.
Los gestores de contenido deben incluir entre las propiedades de enlace un campo que permita indicar información adicional acerca del mismo o su posible apertura en nueva ventana mediante la inclusión de textos como “se abre en ventana nueva”. A nivel de código, el gestor incluirá esta información a través del atributo title del enlace.
Figura 5. Campo de introducción de información adicional en enlaces
Lo óptimo sería que el propio CMS gestione directamente el aviso de apertura de nueva ventana. Por ejemplo, cuando se incluya un enlace que se abre en nueva ventana, el gestor de contenidos podría incluir automáticamente un icono de nueva ventana con su alternativa textual. De este modo se gana consistencia en la navegación, al avisar siempre de la misma forma.
Gestión de la Accesibilidad en Gestores de Contenido 19
4.4.
INCLUSIÓN DE FICHEROS ADJUNTOS
Los ficheros adjuntos incluidos en los contenidos generados deberán disponer de un texto de enlace descriptivo del fichero que se vincula. Este texto descriptivo será normalmente el nombre o contenido principal del fichero adjunto y debe ser comprensible fuera de contexto.
Además de un texto descriptivo del fichero, es recomendable incluir en el título del enlace (atributo title) una indicación sobre el formato del mismo, junto con el texto replicado del enlace (por ejemplo: “Accesibilidad en gestores de contenidos. Fichero PDF”). El gestor de contenidos debe ofrecer un campo a través del cual se pueda indicar la información de formato del fichero adjunto.
Con el fin de diferenciar visualmente los enlaces a ficheros adjuntos, también es recomendable que el gestor disponga de una funcionalidad que permita aplicar a este tipo de enlaces algún estilo CSS o icono representativo del formato del fichero.
4.5.
IDENTIFICACIÓN DE LISTAS
Las listas permiten identificar grupos de elementos que tienen alguna relación entre sí, lo que ayuda a comprender la estructura de las páginas o de los contenidos. Los usuarios invidentes cuentan con herramientas que les permiten navegar por el contenido de las listas de una forma estructurada y más cómoda.
En (X)HTML se distinguen tres tipos de lista:
Lista no ordenada: conjunto de elementos relacionados entre sí para los que no se indica un orden o secuencia determinados. Este tipo de lista se define mediante el elemento
, mientras que sus elementos se definen mediante la etiqueta
.
Lista ordenada: conjunto de elementos relacionados que se muestran siguiendo un orden determinado. Este tipo de lista se define mediante el elemento , mientras que sus elementos se definen mediante la etiqueta
, la misma que se utiliza en las listas no ordenadas.
Lista de definición: conjunto de elementos que están formados por términos y definiciones. La etiqueta
crea la lista de definición y las etiquetas
y
definen respectivamente el término y la descripción de cada elemento de la lista.
El gestor de contenidos ha de ofrecer opciones para marcar cualquier enumeración de elementos como lista, ya sea no ordenada, ordenada o de definición. Es muy habitual que los editores visuales no incluyan una funcionalidad para crear listas de definición, por lo que en ese caso resulta fundamental que el equipo de desarrollo del portal la añada al editor. A nivel de código, la lista generada por el gestor deberá tener una estructura correcta y, en ningún caso, ser simulada mediante elementos que no han sido creados para tal fin (por ejemplo, párrafos iniciados con asterisco, guiones o números).
Gestión de la Accesibilidad en Gestores de Contenido 20
También se debe disponer de una funcionalidad que permita crear listas anidadas, es decir, definir listas completas en los elementos de otras listas, con independencia del tipo de lista del que se trate (por ejemplo una lista ordenada dentro de una lista no ordenada). Con ello se contribuye a aumentar el valor semántico del listado y se facilita la interpretación del mismo a determinados usuarios, por ejemplo, aquellos que hacen uso de lectores de pantalla.
Figura 6. Funcionalidades de marcado de listas ordenadas y no ordenadas
Figura 7. Funcionalidades de sangrado empleadas en el anidamiento de listas
4.6.
INCLUSIÓN DE TABLAS DE DATOS
En (X)HTML, las tablas sirven para mostrar información tabular y no para dotar de presentación a los contenidos, por lo que se debe evitar el uso de tablas para maquetar. Así, las tablas de datos estructuran la información en filas y columnas describiendo una relación entre cada celda de datos con otras celdas en su misma fila y/o columna.
Uno de los requisitos principales de una tabla de datos es que cada celda de encabezado se identifique mediante el elemento TH. Con ello se consigue:
Que los lectores de pantalla puedan asociar las celdas de datos con sus correspondientes encabezados.
Que se indique visualmente los encabezados en navegadores gráficos.
Que el editor final de contenidos pueda diferenciar el estilo con CSS.
Asimismo, en tablas de datos complejas (aquellas con dos o más niveles lógicos de encabezado) se debe realizar una asociación explícita entre las celdas de datos y las celdas de encabezado correspondiente, con el fin de permitir una correcta interpretación de la tabla por los productos de apoyo. Dicha asociación se realiza por medio de los atributos id y headers, de forma que cada celda de datos incluirá en su atributo headers el identificador unívoco id de todos los encabezados relacionados con ésta.
Cuando se crea una tabla con un gestor de contenidos, por defecto no se marcan los encabezados, si bien, éste debe ofrecer al menos herramientas de marcado semiautomático (marcado de determinadas filas y/o columnas de la tabla). Es muy importante que a la hora de identificar encabezados en tablas de datos, el propio gestor de contenidos realice la transformación por medio del marcado adecuado (TH), y no mediante características de presentación (por ejemplo, efectos de fuente y fondo).
Gestión de la Accesibilidad en Gestores de Contenido 21
También sería aconsejable que el gestor de contenidos ofreciera una funcionalidad para asociar celdas de datos y encabezados.
Figura 8. Funcionalidad de marcado de encabezados de tablas de datos
Por otro lado, es importante que el gestor de contenidos incluya entre las propiedades de la tabla unos campos para introducir un título que describa brevemente la naturaleza de la tabla, y/o un resumen de las relaciones entre las celdas de datos de la misma. En (X)HTML el título se proporciona a través del elemento CAPTION, mientras que el resumen se incluye por medio del atributo summary.
Gestión de la Accesibilidad en Gestores de Contenido 22
Figura 9. Campos de introducción de título y resumen de tablas de datos
En ocasiones podría ser necesario definir un ancho específico para la tabla, por lo que sería recomendable disponer de una opción para ello. Gestión de la Accesibilidad en Gestores de Contenido 23
Figura 10. Campo de selección del tipo de unidad para las dimensiones de una tabla
En caso de que se fijen propiedades visuales como el borde, el espacio entre celdas o el espacio interior, el editor visual debería introducirlas por CSS y no mediante atributos de presentación (border, cellspacing, cellpadding).
4.7.
IDENTIFICACIÓN DE CAMBIOS DE IDIOMA
Identificar correctamente los cambios de idioma facilita la comprensión de los contenidos, entre otros, a los usuarios que utilizan lectores de pantalla o programas de síntesis de voz, debido a que éstos detectarán el cambio de idioma y verbalizarán correctamente el contenido.
Si se utilizan varios idiomas en una misma página, se debe asegurar que cualquier cambio de idioma esté indicado. Esta indicación varía en función de la gramática empleada:
Páginas con gramática HTML: atributo lang.
Páginas con gramática XHMTL 1.0 servido como text/html: atributos lang y xml:lang.
Páginas con gramática XHTML 1.0 servido como xml: atributo xml:lang.
Páginas con gramática XHTML 1.1: atributo xml:lang.
Gestión de la Accesibilidad en Gestores de Contenido 24
Los atributos de cambio de idioma se aplican sobre el elemento que contiene el texto en el idioma que cambia y pueden ser aplicados a cualquier elemento (X)HTML. En caso de que el cambio de idioma se encuentre en un fragmento de texto dentro de un párrafo, se puede marcar a través del elemento genérico SPAN.
Ejemplo de código:
En este caso usaremos preferentemente la modulación QPSK (Quadrature Phase Shift Keying) en lugar de 64-QAM (Quadrature Amplitude Modulation).
No será necesario identificar aquellos cambios de idioma derivados de palabras extranjeras que sean empleadas de forma común en la lengua de origen, ni de direcciones o de nombres propios.
Los gestores de contenido han de ofrecer una opción para poder asignar un idioma a un texto previamente seleccionado, para lo cual utilizarán a nivel de código el marcado (X)HTML indicado anteriormente.
Figura 11. Campo de introducción del idioma de un elemento
Gestión de la Accesibilidad en Gestores de Contenido 25
4.8.
IDENTIFICACIÓN DE CITAS
Una cita consiste en una referencia textual de un fragmento o totalidad del discurso de una persona, o el texto de otra fuente.
En (X)HTML existen dos tipos de cita:
Citas cortas o en línea: fragmentos de texto contenidos en párrafos u otros elementos de bloque.
Citas largas o de bloque: Uno o varios párrafos completos.
Figura 12. Funcionalidad de marcado de citas
Los gestores de contenido deben incluir una funcionalidad para marcar tanto citas en línea, como citas en bloque. A nivel de código, el propio gestor de contenidos deberá identificar las citas en línea mediante el elemento Q y las citas en bloque a través del elemento BLOCKQUOTE.
En el caso de las citas en bloque, es necesario que el texto interno del elemento BLOCKQUOTE se encuentre a su vez marcado con elementos de bloque (por ejemplo como párrafo de texto). Además, es muy importante que el gestor no utilice este elemento para crear efectos visuales, tales como sangrías.
Ejemplo de código de cita en línea:
... Lorem ipsum dolor sit amet, consectetur adipisicing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua
Ejemplo de código de cita en bloque:
Lorem ips
um dolor sit amet, consectetur adipisicing elit:
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Otra funcionalidad interesante que podría incluir un gestor de contenidos es la de indicar la fuente de la que se ha extraído la cita. En (X)HTML es posible indicar la URL de la fuente de una cita mediante el atributo cite, así como marcar referencias mediante el elemento CITE.
Gestión de la Accesibilidad en Gestores de Contenido 26
4.9.
USO DE UNIDADES RELATIVAS
Las unidades relativas (em, ex y %) especifican una medida en relación a otra propiedad de medida. Su empleo permite redimensionar el texto, lo que facilita el acceso a la información a usuarios con deficiencias visuales transitorias o permanentes y en general a todos los usuarios, de tal forma que puedan adaptar el tamaño de la fuente a sus preferencias o necesidades.
Por su parte, el uso de unidades absolutas (px, pt, in, pc, cm y mm) en fuentes, tablas o cualquier contenedor impedirá su redimensionado, resultando útiles únicamente cuando las características físicas del medio de salida son conocidas.
En el diseño de un sitio Web, las páginas deben adaptarse y transformarse adecuadamente sea cual sea la resolución usada y tamaño del texto. Para ello, los tamaños de fuente y bloques han de especificarse en unidades relativas en vez de unidades absolutas, pudiéndose utilizar unidades em o %, en función del tipo de maquetación aplicada.
Es muy común en los gestores de contenido la inclusión de funcionalidades de edición para aplicar tamaños de fuente a textos previamente seleccionados. Los textos editados a través de estas funcionalidades deben quedar definidos en unidades relativas, ya que sólo de este modo podrán ser redimensionados por los usuarios según sus necesidades o preferencias.
Figura 13. Funcionalidad de selección de tamaño de fuente para textos
4.10.
EDICIÓN DEL ESTILO O ASPECTO VISUAL DEL DOCUMENTO
Las funcionalidades ofrecidas por los gestores de contenido para cambiar aspectos presentacionales deben generar un código correcto, libre de elementos y atributos desaconsejados y/o de presentación. Las características desaconsejadas (elementos y atributos obsoletos) ponen en riesgo la compatibilidad con cualquier tipo de agente de usuario.
Así, por ejemplo, para enfatizar la información mediante negrita o cursiva se deben utilizar los elementos STRONG o EM, en lugar de los elementos desaconsejados B e I.
Gestión de la Accesibilidad en Gestores de Contenido 27
Del mismo modo, cuando se dota de estilo a un fragmento de texto (efectos comunes como el subrayado o tachado), el CMS siempre debe hacerlo mediante propiedades CSS y no con los elementos HTML desaconsejados (U y STRIKE).
Figura 14. Efectos de presentación a través de elementos desaconsejados
Ejemplo de código incorrecto:
Prueba
Prueba
Otro caso típico dentro de la edición de contenidos es la introducción de saltos de línea con el propósito de crear separaciones visuales en el contenido. Para conseguir tal efecto, el gestor de contenidos no debe generar párrafos vacíos con entidades .
De forma análoga, cuando se utilizan líneas separadoras horizontales para distinguir secciones o dividir visualmente los contenidos de una página, el gestor de contenidos ha de evitar la generación de elementos de presentación (HR).
Figura 15. Separaciones visuales implementadas de forma incorrecta
A fin de respetar los estándares Web, los efectos comunes en la presentación de contenidos en todas las páginas como son entre otros, el tipo de fuente, color del texto, espaciados o tabulaciones, deben ser llevados a cabo por el gestor de contenidos a través de hojas de
Gestión de la Accesibilidad en Gestores de Contenido 28
estilo CSS externas y no mediante estilos en línea (atributo style) o embebidos (elemento STYLE), ya que éstos dificultan el mantenimiento y la limpieza del código.
Ejemplo de código desaconsejado:
Esto es un párrafo que incluye un fragmento de texto con una tipografía diferente
Párrafo de texto centrado
Por lo tanto, sería recomendable eliminar de los editores visuales todas aquellas funcionalidades que generen características (X)HTML desaconsejados y/o de presentación en la aplicación de efectos visuales, o bien, mantenerlas siempre que éstas utilicen correctamente las propiedades CSS correspondientes.
También sería de gran utilidad que los gestores de contenido ofrecieran herramientas para pegar texto desde fuentes externas, de forma que se realice una transformación adecuada tanto a nivel visual como a nivel de código mediante el marcado HTML correspondiente: encabezados, listas, párrafos, etc.
4.11.
MARCADO DE FORMULARIOS
Los formularios resultan esenciales en la experiencia de usuario de un sitio, al permitir interactuar con los servicios Web de empresas, instituciones, organismos públicos, etc., dando acceso a servicios tales como: compras, banca, viajes, elecciones, y otros.
Un formulario se compone de dos tipos de elementos: etiquetas y controles.
Todo control de formulario, a excepción de los botones, debe ser identificado mediante una etiqueta, que debe ser marcada mediante el elemento LABEL.
Por otra parte, para garantizar la correcta interpretación de los formularios, es necesario que se lleve a cabo en ellos una asociación tanto implícita como explícita entre etiquetas y controles.
La asociación implícita se realiza por proximidad, colocando una etiqueta inmediatamente antes o después de cada control en la misma línea, encima del control si la línea es diferente, o envolver el control dentro de la etiqueta.
Gestión de la Accesibilidad en Gestores de Contenido 29
Por otro lado, la asociación explícita se realiza utilizando el elemento LABEL con el atributo for, de forma que el valor del atributo id de cada control coincida con el valor del atributo for de su respectiva etiqueta.
Figura 16. Ejemplo de formulario con asociación implícita y explícita
El hecho de que una etiqueta no esté identificada, implica que no sea posible asociarla a su correspondiente control tanto implícita como explícitamente. Es por ello, que los gestores de contenido deben ofrecer una opción para identificar las etiquetas de formulario, a través del marcado (X)HTML adecuado (elemento LABEL).
También se debe cuidar que los controles generados mediante el gestor dispongan de atributo id, ya que de no ser así, no podrán ser asociados de forma explícita con sus respectivas etiquetas.
Por ejemplo, cuando se crea un control de formulario mediante un gestor de contenidos, entre las propiedades del control, se podría incluir un campo para definir su correspondiente etiqueta, de forma que el gestor de contenidos genere automáticamente la etiqueta a nivel de código y asigne el mismo valor para el atributo id del control (INPUT, TEXTAREA o SELECT) y para el atributo for de la etiqueta (LABEL).
Ejemplo de código:
Por otro lado, cuando en un formulario se utilizan varios controles relacionados entre sí (por ejemplo en un formulario de registro, los campos relativos a la información personal, los datos de contacto, las áreas de interés, etc.), es recomendable agruparlos para facilitar su comprensión. Para ello se utiliza el elemento FIELDSET, el cual debe contener a su vez un elemento LEGEND que proporcionará un título identificativo al grupo completo de controles.
Así, los gestores de contenido deberían incluir una herramienta que permita identificar grupos de controles comunes por su función o significado, y asignarles un título.
4.12.
INCLUSIÓN DE OBJETOS PROGRAMADOS
Un objeto incrustado es un elemento externo que funciona insertado en una página Web a través del elemento OBJECT y que proporciona nuevas características a la misma (efectos decorativos, información, funcionalidades relevantes…).
Cuando se incrusta un objeto se deben tener en cuenta principalmente dos aspectos:
La alternativa al objeto: Todo objeto debe contar con una alternativa que muestre contenido o funcionalidad equivalente, para aquellas situaciones en las que no se disponga de soporte para objetos o éstos se encuentren deshabilitados. La alternativa se introduce en el interior del elemento OBJECT, esto es, entre sus etiquetas de apertura y de cierre, y puede ser un texto o cualquier código (X)HTML+CSS.
La accesibilidad del objeto: Cualquier objeto programado debe ser directamente accesible, ya que puede que el usuario tenga el plugin y los objetos activados, por lo que en este caso no accederá a la alternativa, sino al propio objeto, y por lo tanto debe poder manejarlo. Para que un objeto sea directamente accesible, se deben tener en cuenta principalmente los siguientes aspectos:
o
Permitir una navegación coherente dentro del objeto, y entre el objeto y la página que lo contiene.
o
Permitir su uso con independencia del dispositivo de entrada.
o
Permitir una tabulación adecuada.
o
Contener un etiquetado adecuado de los controles del objeto, botones, enlaces, campos de formulario, etc.
o
No incluir destellos o movimientos que no puedan ser controlados.
Gestión de la Accesibilidad en Gestores de Contenido 31
o
No provocar actualizaciones automáticas periódicas.
o
Poseer niveles de contraste adecuados.
Cuando se introduce un objeto programado a través de un gestor de contenidos, éste debe hacerlo utilizando el elemento OBJECT en lugar del elemento propietario EMBED, el cual no se encuentra recogido en las especificaciones oficiales del W3C.
Ejemplo de código incorrecto:
Otra opción que debería incluir un gestor de contenidos entre las propiedades del objeto programado es la de poder definir una alternativa al mismo (al menos textual).
Por otro lado, se ha de tener en cuenta que cuando la información se presenta con movimiento se puede dificultar la navegación de personas con discapacidades neurológicas y cognitivas. En este aspecto, sería conveniente que los gestores contaran con funcionalidades que permitan al usuario controlar el movimiento de los objetos programados, como por ejemplo, la posibilidad de anular tanto la ejecución automática del objeto al cargar la página, como su repetición.
Gestión de la Accesibilidad en Gestores de Contenido 32
Figura 17. Funcionalidades para el control de movimiento en objetos
4.13.
VALIDACIÓN GRAMATICAL
Resulta importante que el código (X)HTML de las páginas Web utilice una sintaxis válida según la gramática definida. Ello ayudará a que los navegadores funcionen de manera más efectiva y a que las páginas se visualicen correctamente en la mayoría de dispositivos.
Se ha de tener en cuenta que las reglas varían en función de la gramática (HTML o XHTML) y versión (Transitional o Strict) utilizadas. Así, un mismo código puede ser válido para una gramática pero no para otra.
El código de las plantillas (X)HTML utilizadas en los gestores de contenido no debe contener errores de validación gramatical. Del mismo modo, el código de las hojas de estilo CSS asociadas a dichas plantillas también debe ser gramaticalmente válido.
Para facilitar la tarea de análisis del código (X)HTML y CSS de una página Web, el W3C proporciona herramientas online:
Markup Validation Service: http://validator.w3.org/
CSS Validation Service: http://jigsaw.w3.org/css-validator/
Gestión de la Accesibilidad en Gestores de Contenido 33
No obstante, una opción interesante sería la de incluir en el propio gestor de contenidos un validador interno, que permita analizar el código (X)HTML y CSS cada vez que se editen los contenidos de una página Web (inserción, modificación o eliminación de textos, tablas, imágenes, objetos, formularios, etc.).
Gestión de la Accesibilidad en Gestores de Contenido 34
Gestión de la Accesibilidad en Gestores de Contenido 35
5.
PERSPECTIVAS ACTUALES Y FUTURAS
Dada su flexibilidad y facilidad de uso, los gestores de contenido se están erigiendo en una de las herramientas preferidas por los editores finales para la creación y mantenimiento de sitios Web dinámicos.
Pese a ello y como se ha podido comprobar a lo largo de la presente guía, el hecho de utilizar gestores de contenido accesibles no implica que los contenidos generados a través de los mismos sean finalmente accesibles. Dado el carácter permisivo de los gestores de contenido actuales, para poder garantizar la accesibilidad de un sitio Web es necesario que el editor final de contenidos lleve a cabo distintas revisiones manuales, que no puede realizar de forma automática el propio gestor.
Hasta que los editores visuales o los gestores de contenido generen código accesible, será necesario un trabajo del equipo de desarrollo de un portal para modificar el editor y adaptarlo a la creación de contenido accesible.
De cara al futuro, se contempla como posible mejora la incorporación de funcionalidades que permitan crear contenidos atendiendo a su significado y no al formato o apariencia final, aumentando de esta forma la carga semántica.
Por otro lado, la inclusión de revisiones automáticas permitiría que no recayera todo el control de la accesibilidad del sitio Web sobre el editor final, que puede tener escasos o nulos conocimientos en la materia.
No hay comentarios:
Publicar un comentario