Diseño de libros electrónicos

Diseño de libros electrónicos

Lista de verificación

El diseño no es solo lo que parece y se siente, el diseño también es cómo funciona. Los diseñadores de libros y publicaciones electrónicas debemos tener en cuenta varias limitaciones de hardware y software, que van mas allá del CSS. Esta lista de verificación se creó para ayudar a lograr excelentes diseños de libros electrónicos [eBooks].

Esta lista detalla los items de verificación mas importantes a tener en cuenta al momento de diseñar eBooks en formato EPUB accesible.


Semántica

No utilizar disposición fija si no se puede justificar su uso

Debemos pensar en la experiencia de usuario y no en la perfección del pixel. Los libros para chicos, los libros de arte y los comics se benefician de la disposición fija [Fixed-Layout], pero varias aplicaciones y dispositivos para eBooks no conocen realmente como gestionar este tipo de disposición: o realmente no admiten o no proporcionan a los usuarios características importantes como anotaciones, zoom inteligente, etc.

Es indispensable estar informados que muchas de las tiendas de libros electrónicos (Apple Books, Kindle, Kobo, etc.) desalientan oficialmente en sus guías el uso de disposición fija para libros basados principalmente en texto.

Por cierto, la web llegó a la conclusión de que las dimensiones fijas probablemente no fue la mejor idea cuando se trataba de mostrar contenidos en pantalla, entonces promovió e invirtió en un diseño adaptable. Finalmente, los sistemas operativos móviles introdujeron el concepto de diseño automático para brindar capacidad de respuesta a las aplicaciones.

Aplicar estructura

Comencemos con la forma en la que se presentan los contenidos, en un orden lógico de lectura, lo cual es fácil de arruinar en aplicaciones de diseño como InDesign cuando se exporta a disposición fija. Debemos asegurarnos de verificar esto.

Luego, se trata del uso adecuado de las etiquetas HTML5, que superarán cualquier divitis, es decir, el proceso de usar demasiados divs anidados e innecesarios para etiquetar una página.

Finalmente, los roles ARIA ayudan a la tecnología de asistencia y a los usuarios.

Nunca utilizar etiquetas según su estilo predeterminado

Las etiquetas son importantes: marcan los contenidos. Esta es la razón por la que no debe usarse <h3> porque se desea que los encabezados simplemente sean más pequeños, <hr /> porque se desea una regla horizontal (ahora representa un salto temático), o <em> como un sinónimo de cursiva (principalmente es énfasis).

Refinar la estructura semántica utilizando vocabularios ARIA para EPUB

Si bien tomamos prestado el HTML de la web, en primer lugar se destinó a páginas y sitios web. Como consecuencia, no cubre todas las necesidades para los diseñadores de libros.

Afortunadamente, tenemos un vocabulario para mejorar la semántica estructural; solo requiere atributos epub:type para indicar capítulos, introducciones, bibliografías, tabla de contenidos, etc.

Mientras, también podemos agregar roles de publicación digital ARIA, que ya están implementados en algunos navegadores, y las aplicaciones se benefician automáticamente si utilizan visualización web.

Tener especial cuidado con la navegación

Por supuesto que debe proporcionarse a los usuarios una tabla de contenidos, pero podemos hacer mucho más como aprovechar los puntos de referencia [Landmarks], crear listas de ilustraciones, imágenes, tablas, etc.

Recordemos incluir una lista de páginas, especialmente si el libro electrónico se usará en educación y tiene una versión equivalente impresa, porque los lectores digitales también buscan números de página.

Dejar que el texto sea texto

Debido a que no hay nada peor que utilizar texto como imágenes. Penalizaciones adicionales se aplican si el texto se exporta como imágenes debido a licencias de fuentes.

Si necesitamos utilizar texto de estilo libre (texto sobre trazados vectoriales, diseños complejos), entonces SVG será la mejor opción.

Esto se aplica a las tablas también. Claro, siempre han sido problemáticas en el diseño web y los libros electrónicos no son una excepción, pero las tablas como imágenes deben ser un último recurso si las otras opciones son imposibles (por ejemplo, disponer los datos de otra manera).


Tipografía

Confirmar que los sistemas de lectura puedan gestionar los pictogramas [Glyphs]

¿Caracteres griegos, CJK o especiales? Para estos casos, una buena práctica es incrustar fuentes que admitan estos caracteres debido a que no son datos que traigan las fuentes predeterminadas. Kobo incluso aconseja insertar una nota en el comienzo del libro para este caso particular.

Elegir sabiamente el tipo de escala

Los usuarios eligen sus propios ajustes y configuración. No permitamos que los encabezados se conviertan en un lío importante.

Esto tiene que ver con la inclusión: algunos usuarios deben elegir un tamaño de fuente enorme para poder leer.

No forzar la justificación

Otra vez los ajustes del usuario. A estas alturas deberíamos estar convencidos de que el diseño de eBooks no consiste en diseñar contenidos, sino en crear una experiencia de usuario excelente.

Además, es posible que algunas aplicaciones o dispositivos no admitan particiones, lo que significa que su texto justificado se verá de manera desagradable.

Aprovechar las características OpenType

Las tecnologías de representación pueden no ser tan poderosas como el software de DTP, pero las características OpenType se están convirtiendo en una práctica común.

Aquí se incluyen las fracciones, las mayúsculas reales, el estilo antiguo o los números tabulares, etc. Todas estas características pueden mejorar la legibilidad de una manera dramática. Utility OpenType es de gran utilidad para dar el puntapié inicial en este proceso.

Confirmar que la disposición dinámica funciona

El nuevo formato Kindle, KFX, adapta los capitulares y los elementos flotantes según el tamaño de fuente elegido por los usuarios.

Si Amazon piensa que es un problema, también deberíamos nosotros. No sobre-utilicemos capitulares, elementos flotantes, etc. si no podemos asegurar que no interrumpirán la experiencia de lectura en pantallas pequeñas o cuando se elija un tamaño de fuente mayor.


Colores

No olvidar la modalidad “escala de grises”

Los eReaders dedicados a libros electrónicos utilizan tinta electrónica (eInk), lo que significa que los colores se convertirán a 16 tonos de gris. Es una buena práctica comprobar si el eBook, especialmente las imágenes, se muestran bien en escala de grises.

Con suerte, nuestro sistema operativo de escritorio puede ayudarnos a hacerlo. Si utilizamos macOS, por ejemplo, podemos hacer la comprobación desde las preferencias de accesibilidad.

Tratar de evitar los colores de fondo

Ajustes de usuario una vez más. Los sistemas de lectura generalmente eliminarán el color de fondo en modo nocturno, por lo que tal vez no debamos depender de esto.

Negro es blanco, aprovechar la herencia

En modo nocturno, lo oscuro se vuelve claro, por lo que nunca debemos especificar colores desde #000 hasta #666, incluso está indicado en la Guía de Publicación Kindle. Debemos tener en cuenta que Adobe InDesign exporta estos valores para luego eliminarlos o reemplazarlos.

Por lo tanto, si necesitamos negro/blanco, podemos utilizar color:inherit, border-color: currentColor, fill: currentColor, etc. Todos estos se asignarán al color actual de los sistemas de lectura.

Elegir los colores teniendo en cuenta la ceguera al color

Los lectores con discapacidad aman los libros electrónicos, no los defraudemos.

Evitemos combinaciones de rojo/verde y rojo/negro, utilicemos patrones además de los colores en gráficos de datos, tengamos cuidado con el texto en fondos que contienen ruido, comprobemos que los niveles de contraste sean suficientes, etc.

La base de conocimientos DAISY es un recurso invaluable cuando se trata de accesibilidad.


Imágenes

Utilizar elementos figure y figcaption

Estas dos etiquetas están hechas una para la otra y es por esto que algunos sistemas de lectura las tratarán de una manera muy especial. Mientras tanto, no dudemos en agregar page-break-inside:avoid en el CSS. Claro, no funcionará en Kindle, pero todos sabemos que Kindle tiene grandes limitaciones.

Confirmar que las imágenes contengan texto alternativo cuando sea necesario

Las imágenes decorativas y las que contienen leyendas que lo cuentan todo no necesitan un texto alternativo, otras demás imágenes si. Hay un excelente tutorial de accesibilidad para conocer cómo gestionarlos.

Utilizar unidades relativas para diseñar con imágenes

Muchos sistemas de lectura no incluyen estilos predeterminados para las imágenes, lo que significa que es muy probable que ocurra un desborde. Debemos utilizar al menos max-width: 100%.

Como no se puede confiar en los píxeles –InDesign exporta en pixeles de manera predeterminada–, debemos usar % para imágenes horizontales y vh (con un % para compatibilidad) en el caso de imágenes verticales.

Confirmar que la proporción de las imágenes se mantenga con CSS

Utilicemos object-fit:contain desde ahora en más.

Considerar la visualización de las imágenes en modo nocturno

Modo nocturno + PNG con transparencia. Está todo dicho.


Diseño CSS

Evitar generar estilos basados en ID

Debido a que los ajustes de usuario son básicamente una hoja de estilo, los selectores de ID pueden arruinar los ajustes del usuario de una manera espectacular.

Por supuesto, si hay algo crucial que no debe cumplir con las ajustes del usuario, ID puede ser una solución.

Evitar utilizar !important

Leer punto anterior. Además, puede que algo salga mal ya que debemos gestionar la cascada en un CSS en constante desarrollo.

Confirmar que las unidades relativas sean usadas en disposición dinámica

No utilicemos px o pt porque romperán los ajustes del usuario para el tamaño de fuente en una gran cantidad de aplicaciones y dispositivos. Las alturas de línea sin unidad también son una buena idea.

Confirmar lo que no debe fluir con el tamaño tipográfico

Los márgenes horizontales (derechos e izquierdos) y los márgenes de páginas no deberían aumentar con el tamaño de la fuente, ya que cuanto mayor sea el tamaño de la fuente, menor será el contenedor. Utilizar %.

Confirmar que las fuentes de la misma familia sean la misma familia de fuentes

Las fuentes regulares, cursiva, negrita y negrita cursiva deben ser exactamente de la misma familia de fuentes.

Si cada una es una familia de fuentes específica, entonces los ajustes del usuario se arruinarán, la cursiva y la negrita no se reemplazarán en algunos sistemas de lectura y los usuarios no quedarán a gusto.

Evitar utilizar inline-block

Los contenidos serán cortados debido a la paginación. Con inline-block hay una gran responsabilidad (otra cosa que InDesign hace de manera errónea, ya que lo usa para el estilo de las imágenes).

Eliminar el posicionamiento absoluto en disposición dinámica

Se indica en las guías y especificaciones, lo cual tiende a demostrar que esto puede ser un problema crítico a solucionar primero.

Evitar reiterar -webkit-text-size-adjust y text-rendering

El primero rompe la configuración de tamaño de fuente en Apple Books para iOS.

El segundo interrumpe la representación de fuentes en algunos dispositivos Kindle (todo el texto se representa como “signos de interrogación en un recuadro”).


Interactividad

Confirmar que los enlaces sean percibidos como tales

Dar estilo a los enlaces es complejo. Tanto que puede molestar en las “páginas” del libro electrónico (peso visual, manipulación incorrecta al intentar navegar, etc.).

Tal vez podemos atenuarlos para que no interrumpan el proceso de lectura. Tal vez se podríamos tratarlos como notas al pie de página, si hay demasiados en el libro electrónico, etc.

En cualquier caso, debemos asegurarnos que los usuarios puedan percibir los enlaces como tales al explorar la página.

No ocultar notas pop-up al pie

Hace mucho tiempo, en la aplicación Apple Books, el diseño de notas emergentes se introdujo en los diseñadores de libros electrónicos. Y luego descubrimos que podríamos usar <aside> para ocultar o <div> para mostrar la nota al pie en la vista de lectura normal.

Resulta que la nota de pie de página no es accesible para la tecnología de asistencia cuando está oculta, por lo que es mejor mantenerlas visibles en la lectura normal usando <div> o <p>.

No utilizar el patrón ocultar/mostrar (colapsar/expandir contenidos)

Actualmente es incompatible con la paginación, y esto también afecta a la etiqueta <details>.

Desafortunadamente, los sistemas de lectura no actualizará automáticamente la paginación al contraer/expandir contenidos, lo que significa que se desbordarán al final del archivo XHTML. Actualmente no hay una manera segura para forzar un re-cálculo.

Confirmar que las interacciones no sean molestas

Una interacción puede convertirse en un truco inútil. Esto puede ser frustrante porque no agrega valor al libro electrónico, sino que interrumpe la experiencia de lectura.

Desarrollar scripts accesibles

Se trata de cómo se diseñan los scripts. Para esto se deben consultar las pautas de creación ARIA.

Luego, se implementan los atributos ARIA: aria-label, aria-hidden, aria-live, role & al. De esta manera se puede mejorar dramáticamente la usabilidad.


Mejora progresiva

Mejorar, no degradar

Construir sobre una roca sólida es mucho más fácil que eliminar partes de un cohete espacial durante el vuelo. Se debe diseñar para el mínimo común denominador y luego mejorar progresivamente.

Podemos hacer mucho desde que los sistemas de lectura están desarrollados sobre las tecnologías de representación de los navegadores. Depende de nosotros mejorar la experiencia de usuario en función de las características que admiten estas tecnologías.

Adoptar una pequeña estrategia

Es menos probable que los lectores utilicen una pantalla de 24 pulgadas que un teléfono inteligente, un lector electrónico o una tableta. Deberíamos adoptar un enfoque eInk primero para diseñar libros electrónicos.

Además, no olvidemos que algunos usuarios pueden aumentar el tamaño de la fuente a no menos de 36 puntos. En otras palabras, al diseñar primero para pantallas realmente pequeñas, es probable evitar muchos problemas.

Aprovechar las consultas de características (@supports)

@supports es una herramienta poderosa que permite probar la compatibilidad con CSS. Si la propiedad y el valor que prueba son compatibles, se aplicarán los estilos. De lo contrario, serán ignorados, y no bloquea el antiguo RMSDK.

Al aprovechar las consultas de funciones, podemos usar todas las especificaciones CSS modernas y asegurarnos de que no afecten a los sistemas de lectura que no las admiten. Esta es la manera fácil de hacer una mejora progresiva.

Tener cuidado con Media Queries

Las media queries @amzn-* vacías bloquean el antiguo RMSDK.

Algunos sistemas de lectura indican visores dañados (ya sea debido a la implementación de paginación o al uso de columnas CSS para simular un pliego).

Actualmente no existe encanto por las media queries en los libros electrónicos y su uso probablemente debería ser desalentado.

No utilizar Media Queries que apunten a dispositivos

Si realmente no podemos prescindir de las media queries, no las utilicemos para los dispositivos.

Los dispositivos se desarrollan constantemente en diferentes formas, resoluciones de pantalla, dimensiones de visores, etc. Es simplemente imposible mantenerse al día a largo plazo.

Además, lo que podría funcionar en Apple Books para iOS en horizontal ya es contraproducente en muchas otras aplicaciones de iOS. Lo mismo para iPhone, etc.


Seguro de calidad

Probar en la peor aplicación que se tenga a disposición

Es la forma más fácil de asegurarnos que la estructura de un eBook sea a prueba de balas. Lamentablemente, millones de lectores digitales los están utilizando.

Cambiar los ajustes de usuario para corroborar que todo está bien

Debería ser obvio a esta altura.

Eliminar fricción

¿Por qué algunos proveedores abren el libro electrónico en el primer capítulo? Porque los lectores van a leer.

Comencemos desde el inicio del libro hacia el final siempre que sea posible. En cualquier caso, no forcemos que el libro electrónico para que se abra antes de las diez páginas principales que los lectores no quieren leer.

Considerar el tamaño final del EPUB

Las tiendas de eBooks establecen un límite superior, pero ¿significa que debemos publicar un archivo de 650 MB o 2 GB?

Es un problema de experiencia de usuario: es probable que la descarga de un enorme archivo demore al dispositivo del usuario, etc. No olvidemos que muchos de los dispositivos Android que se venden actualmente se entregan con solo 8–16 GB de almacenamiento.

Probar el texto a voz

Es la forma más fácil de asegurarnos que estamos usando ARIA correctamente.

Además, podemos aprender mucho, especialmente sobre cómo el software entiende el marcado, los estilos e interacciones. Recordemos que el software puede ser el único enlace entre el contenido del libro electrónico y los usuarios con diversas limitaciones físicas.

Organizar pruebas de usuario para interacciones experimentales

Las ideas a veces se convierten en realidad. Si no realizamos pruebas de usuario, descubriremos que una única vez puede ser demasiado tarde.

Si estamos tratando de mejorar la experiencia de usuario con interacciones funcionales o funciones adicionales, deberíamos obtener comentarios tan pronto como se construya el prototipo. Así es como funciona el diseño.


Conclusión

Ahora que ya conoces cada punto, recuerda tener a mano esta lista de verificación para los futuros diseños de libros y publicaciones electrónicas con características de accesibilidad. Si hay dudas e inquietudes, comenta al final de este artículo.

Puedes conocer más acerca de como crear EPUB accesibles en el curso Adobe InDesign: Accesibilidad EPUB.

También ofrecemos el servicio de crear libros y publicaciones EPUB accesibles con etiquetas HTML5, CSS3, gráficos SVG, metadatos y validación.

Adaptación y traducción: Mariano Caino. Fotografía: Amanda Jones. Fuente: Blitz Design.

About The Author

Leave a reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *