Re: EPUB tables in reading solutions

Hello,

if authors do not prevent access to some content with CSS by intention or
accidentally, if a part of the table (graphic, word, see below) is not
accessible, this can be considered a serious bug of the used viewers/user-
agent/reading system, not of the book.

It is in general not the task of authors to care about viewer bugs, gaps and
other problems with the presentation of specific books.
You will never be able to test all available viewers, therefore it is only
meaningful to provide accessible content itself, independently for all
programs.

See the (X)HTML recommendation(s) for details about accessible tables.

Note, that similar problems may occur with large graphics (for example SVGs
with width and height in units like em, ex, cm, mm etc) as well.
An accessibility problem can already occur with long words
(for example German can use compounds (Komposita) of almost arbitrary length -
and unicode has the soft hyphens to indicate breaking words across lines, this
might solve already minor problems with tables containing some longer words).
For browsers (user-agents for (X)HTML etc) and related libraries such problems
were typically already solved in the past millennium.
If this still occurs in current viewers specific for EPUB, this indicates
probably, that the developers did shot themselves in the foot with a nasty
user-agent stylesheet.

Options to help viewers to provide better access in EPUB3:
On the one hand you can indicate in the metadata of the OPF-file
something like this:
  <meta property="rendition:flow">scrolled-doc</meta>
  <meta property="rendition:spread">none</meta>

On the other hand you can inform the audience in the preface of the book about
problems with some known or unknown specific viewers, if they ignore such
rendition hints to switch on scrolling and to switch off multi-column display.
If a specific viewer does not provide at least manual switches, there are
several extensions for browsers doing this as powerful alternatives.
One can recommend some of them for parts of the audience facing unsolvable
problems with other viewers.
(But it is not nice to write: 'Best viewed with viewer X', because typically
there are much more without the related bug).

Another option can be to try to override the user-agent stylesheet with CSS of
high priority in the author stylesheet.
Ensure that viewers with less CSS capabilities do not run in problems with
this, because in several viewers the audience gets no interface to switch off
author stylesheets or to switch to an alternative author stylesheet, this
audience is pinned to the default author stylesheet.
The problem here: the problematic viewers typically have different user-agent
stylesheets, therefore it is difficult, to catch them all, even more, if you do
not know all viewers with the related bug.
Some EPUB-viewers do not take into account the proper cascade of user-agent,
author and user stylesheets, this is a major bug of them as well.
Due to this it might be necessary to use something like:
html, :root:not(body) {    }
body, :root:not(body) > body:not(html)  {    }
etc
or worse to be specific enough.
Obviously, such CSS priority battles do not solve the general problem of bugs
in viewers, therefore not something, one can recommend for wider usage.
But it might help to identify the source of the bug in viewers.
If this helps, the problem is typically related to a nasty user-agent
stylesheet, that needs to be fixed.

In theory of course you can teach the authors as well how to apply user
stylesheets with the relevant rendering information to be accessible.
To provide an option to apply user stylesheets is required by the CSS
recommendation for CSS capable viewers as well.
In practice of course several viewers have a bug and ignore this requirement
or they hide the option properly in the program.

Finally, if you know bugs or accessibility problems of specific viewers, write
a bug report to the developers of these viewers.
There is not much more, authors can do for the audience to solve such
problems.

Have fun ;o)

Received on Thursday, 29 August 2019 15:19:53 UTC