Font size in pixels

[laudrain]

Please provide the following details if possible or relevant:

• [] the version of Ace impacted by the issue (as returned by the ace -v command).
• [] the version of Node used to run Ace (as returned by the node -v command).
• [] your operating system and version.
• [] if the issue is a bug when running Ace: the error message as produced in the log file (you can enable debug logging with the --verbose option).
• [] if the issue is about the HTML report: the browser(s) and version(s) you used.
• [] if possible, let us know if you can share a sample input file to help us reproduce the issue.

Do Ace reports font sizing in pixels ? This has an impact on displayTransformability and then to accessibility.

[clapierre]

That would be good to flag that, thanks for bringing this up and also maybe the inspection of !important on a font size in CSS.

[danielweck]

Hello, I am trying to understand the feature request.

When analysing a rendered DOM, it is indeed possible to obtain the "font size" of any HTML element, as reported by the "computed style" API. For example, this is a typical result for the body element:

window.getComputedStyle(window.document.body)["font-size"] => 16px

However, elements further deep into the DOM can override this "base" font size, so can this information really be meaningful / useful, especially in relation to accessibilityFeature and displayTransformability?

Thank you for clarifying :)

[laudrain]

@danielweck I'd say that any font size expressed in pixels in the source CSS brings an issue on transformability, be it on body or any other element. If the font size after computation is a value in pixels, I think it is ok. But if the source size in the EPUB CSS is in pixels, there is no more transformability.

[danielweck]

I see, thank you for clarifying. So the problem to solve is:

• parse static authored styles (i.e. linked stylesheets as well as DOM-inline styling)
• parse dynamic styles (i.e. injected via authored scripts, either as proper head stylesheets, or as inline style attributes)
• discover font-size rules with pixel values (what about other CSS properties, see comment below)
• report all occurrences in the accessibility evaluation
• match with presence / absence of displayTransformability with adequate suffix (see comment below)

Notes: if I am not mistaken, CSS properties other than font-size should also be analysed? For example, specifying box sizes, margins, etc. can also introduce visual scaling inconsistencies, potentially hindering content responsiveness. Thus the displayTransformability suffix / appendix, I suppose (such as /line-height): https://www.w3.org/wiki/WebSchemas/Accessibility#Features_for_transformation

Thank you for helping to bring clarity on this feature.

[laudrain]

To summarise, any CSS property with an absolute source value that would prevent transformability is an issue.

From the displayTransformability list of properties:

• /font-size
• /font-family
• /line-height
• /word-spacing
• /color
• /background-color only /font-size, /line-height, /word-spacing may have pixels values. In that case, reading systems may not transform the rendering as the user wishes. There is something to report by Ace here.

Obviously, /font-family, /color, /background-color will not accept pixels values. And I believe existing RS still allow these properties to be changed by the users. IMO nothing to report by Ace here.

[nekennedy]

Many years ago there was an incident where a book was distributed with all the font-sizes in pixels, and most of the major reading systems did not resize the font when the user changed their settings. There were quite a few mainstream articles about it (like this one from the BBC). While it was 8 years ago, I'm not sure if all the reading systems have updated to account for this.

Unsure if ACE should be reporting these, but I don't think we can assume that RS deal with pixel font-sizes in an accessible way.