Proposal to Investigate the Use of SVG for Creating Accessible Fixed Layout EPUBs

[gregoriopellegrino]

In recent discussions, it has been suggested that utilizing SVG (Scalable Vector Graphics) could be a viable solution for creating fixed layout EPUBs that are accessible. This issue serves as a reminder to conduct a thorough analysis to determine the feasibility of this approach.

Background

SVG is a comprehensive standard that fully supports accessibility features and enables the creation of pixel-perfect graphics. These characteristics make it an attractive option for designing fixed layout EPUBs. However, there are concerns regarding the limited support for SVG in various reading solutions and rendering engines, as well as potential challenges with assistive technologies.

Objectives

The main purpose of this investigation should be to evaluate the practicality and potential benefits of utilizing SVG for accessible fixed layout EPUBs. The following objectives should be considered:

1. Assess the compatibility of popular reading solutions and rendering engines with SVG
2. Investigate the current support for SVG in assistive technologies commonly used for accessing EPUBs
3. Identify any existing limitations or issues related to using SVG for fixed layout EPUBs
4. Evaluate the benefits of SVG in terms of creating pixel-perfect graphics and enhanced accessibility features

[gregoriopellegrino]

I know some friends have ideas and doubts about this investigation: @HadrienGardeur and @larscwallin please comment or join next calls, your opinion is important 😀

[HadrienGardeur]

Looking at comics/manga, I know that the majority of specialized apps end up getting rid of the "container" which would be HTML AND SVG in this case.

For publications where there is no real content in SVG, they simply extract the bitmap out of it. If there is useful content, they rasterize it and generate a bitmap.

There are very good reasons why this is done, for instance Web Readers for comics/manga tend to be built entirely using one or more <canvas> elements, whereas native apps use native APIs dedicated to graphics to handle high resolution bitmaps.

To enhance the accessibility of such publications, we need to look at solutions beyond HTML and SVG in my opinion, otherwise we're cutting ourselves away from the majority of what's produced and read in FXL.