Baseline for a11y-related user settings

[JayPanoz]

We started discussing this during the latest engineering call. I’m opening this specific issue so that we can gather outside feedback from the community, especially as @DanielWeck and @Laudrain are dealing with accessibility on a regular basis and can probably point out specific issues and shortfalls. And of course @llemeurfr can forward this issue to a11y experts in contact with EDRLab.

It’s also worth noting that we will probably get more feedback once the Readium Desktop app is available (with an installer), so this should be considered something we’ll have to iterate over. Hence this baseline, which is what we’ll ship in the beta.

So, our current baseline for user settings is:

• night/sepia modes + custom background-color and color
• text-align + hyphens
• font-size + line-height
• typefaces: dys + humanist in bold
• letter and word-spacing
• removing italics (which could be automatic when switching to the two specific typefaces?)

This is a mere draft, really. For instance, Daniel already pointed out that color-blindness will have to be managed (and unfortunately, there is no media query to deal with the OS global user settings, which exist in MacOS/iOS for instance).

And there’s obviously a lot more to deal with, which is the purpose of the OS a11y module. Only Microsoft high-contrast-mode is currently addressed.

We’ll have to make decisions about reading modes there: if the user sets the monochrome option, how are we supposed to deal with sepia and colors? If the user sets an inverted high-contrast mode, what happens with night mode? I know this question might sound kind of dumb at first sight, but there can be multiple users for the same computers, using the same account, etc.

What I can say when it comes to typefaces is that, from research, the more varied typefaces available, the better. There is no silver bullet there, some people don’t like Open Dyslexic for instance, and prefer Verdana or other sans-serif typefaces.

I know Microsoft has commissioned accessible versions of two typefaces (Fluent Sitka and Calibri) but it is a package users have to install, we can’t embed them in apps. Their EULA clearly state that:

b. No Distribution Rights. This agreement does not grant you a license to distribute nor sublicense all or part of the software to any third party.

For the record, there is also an alternative to Open Dyslexic, Accessible-dfa, and it apparently supports more glyphs, but we have to gather feedback to see whether it’s a solid alternative or not

As for OS settings, I can anticipate some Media Queries (see level 5) but others are not clearly defined yet and discussions are still held in the W3C WG repo.

I can see two extra settings at first sight:

• unfloat elements
• remove drop caps

Anything else?

[JayPanoz]

Feedback from Luc Maumet: an advanced feature would be alternating consonants’ and vowels’ colors (dys).

Since you can’t target lines and characters in CSS, this is JS territory. So I guess such features would be able as an optional plugin? (and we should make sure it doesn’t require too much effort to override our reading modes’ and user settings’ colors).

Am I right?

[danielweck]

Yep, like Microsoft's "Learning Tools" / "Immersive Reading" https://www.onenote.com/learningtools

https://support.office.com/en-us/article/Learning-Tools-in-Word-a857949f-c91e-4c97-977c-a4efcaf9b3c1?ui=en-US&rs=en-US&ad=US

[JayPanoz]

On a related note, Home office Depot has released a11y posters a while back.

It might be used as a super quick introduction to implementers and designers who are not very familiar with those issues. I’ll let @danielweck confirm if it is indeed the case.

[Lucmaumet]

I compared the features in seven readers designed for dyslexic persons. The results of this comparisons shouldn't be seen as recommandations but just observations of the state of the market.

Create and personnalise a profile : 4/7 (present in 4 of the 7 readers) Space between words : 7 /7 Space between letters : 6/7 Typeface choice : 6/7 Typeface size : 7/7 Dyslexia typeface : 5/7 Space between text lines : 7/7 Highlight consonants and vowels with different colors : 2/7 Syllabic cutting (ability to highlight syllabs) : 4/7 Words with alternated colors (blue / red / blue / red...) 4/7 Text lines with alternated colors 2/7 Highlight a specific sound in the text 3/7 Highlight a specif letter 2/7 Export the text keeping the choosen layout 5/7 TTS 4/7 Highlight upercase letter : 2/7 Highlight punctuation : 2/7

[JayPanoz]

Thanks @Lucmaumet, terrific job listing those features. 👍

Work with Daniel and other implementers clearly overlaps there, and there are features which are likely to be implemented as plugins. I’ll therefore take the liberty to sort them so that we can define which ones can be achieved in CSS and which ones require extra work in another language.

Notes in italics.

Features in Readium CSS Scope

• Create and personnalise a profile (cf. planned themes)
• Space between words
• Space between letters
• Typeface choice
• Typeface size
• Dyslexia typeface (we still have to find a consensus about which one(s) we’ll recommend)
• Space between text lines

Features outscoping Readium CSS

TL;DR: A lot of features overlap there, but CSS is mainly for styling (colors, highlights, etc.), it can’t be used to target text contents directly, you need hooks (extra markup, classes, attributes, etc.).

• Highlight consonants and vowels with different colors
• Syllabic cutting (ability to highlight syllabs)
• Words with alternated colors (blue / red / blue / red...)
• Text lines with alternated colors
• Highlight a specific sound in the text
• Highlight a specific letter
• Export the text keeping the chosen layout
• TTS (eKitabu is working on that if I’m not mistaken)
• Highlight uppercase letter
• Highlight punctuation

I guess it would be useful to have this list in the Readium Dev Google Group since some features are already being discussed (TTS for instance). @Lucmaumet Do you have access to this group or should I post it myself?

[Lucmaumet]

No, i don't have access to Readium Dev Google Group. Please post it yourself. And please, find a way to express that it's a work in progress (not recommandations, as previously said).

[JayPanoz]

@Lucmaumet will do thanks! (cc @llemeurfr for adding you to the google group so that you can receive mails, etc.)

[SeldomScene]

@JiminyPan @Lucmaumet Great info. Thanks for the job. We plan to implement your work into our ISIcrunch workflow.

[laudrain]

@JayPanoz I think that "Text lines with alternated colors" is possible with CSS. I already did some research about that some years ago with a dyslexic intern. Found today that link : https://codepen.io/green-plastic/pen/thkDg

[gregoriopellegrino]

I think that in this a11y css is important to force outline for focused elements: http://www.outlinenone.com/

[JayPanoz]

@laudrain Yeah thanks, forgot about that but with good reason.

I’ve actually been using this as a poor man’s baseline grid and it has a lot of drawbacks/issues that makes me feel uncomfortable using it:

1. rendering engines’ rounding can play quite badly with such linear gradients, with quite a visible offset at some point in the document;
2. if the paragraph is fragmented in columns, the background is completely off in the second column;
3. there is a lot of styles which can impact the background: margins, paddings, vertical-align, floats, flex, etc. You can sanitize some styles but if you must unset all, we’ll probably have to deal with side effects;
4. unfortunately linear gradients ain’t cheap: we’re asking the rendering engine to draw an image, albeit a simple one, and it kinda killed Firefox’ performance not so long ago. It’s a little bit like opacity and box-shadow, you know it might create an additional performance hit in extreme situations (file with a lot of opacity, box-shadow or HD images, in which case the doc will need an awful lot of memory);
5. more generally, the lack of control over contents (markup, styles, etc.) makes it not very reliable on our side in pure CSS.

We must still discuss alternatives so take that as a simple list of drawbacks/issues. I’m not saying we won’t end up trying to use this.

[Edit] One alternative being something like this: http://zencode.in/lining.js/

[JayPanoz]

@gregoriopellegrino Ah thanks, good one.

[JayPanoz]

Follow-up on the linear-gradient message, to clarify the issues and possible solutions.

Rounding and fragmentation

In order to get around fragmentation issues, you’ll need to have the height of the document as a multiple of the line-height. In the iOS test app, the height is currently managed at the Swift (app) level, and padding | margin would create issues with the vh unit. So it’s a non-starter.

The best bet would be applying a global background at the :root level and enforcing vertical rhythm = all heights (including computed ones from font-size * line-height), margins, paddings, etc. as a multiple of the line-height so that it can work in columns.

Possible issues are images’ dimensions, lack of knowledge where padding should be set, etc.

Due to the lack of Rhythmic Sizing implementations, it implies a lot of JavaScript at first sight.

Other issues: scrollable frames/containers, recalc/reflow/repaint on line-height change.

Impacting styles

It is true that we normalize some styles here and there on user settings, and we’ll have to normalize a lot more for a11y, but this would possibly require a global sanitization — and there go some CSS hacks people have been using so that some features actually work in some Reading Systems. We’d better do research about those hacks (I can think of a hack for Readium 1 for instance)

Perf

I’m unable to tell how much memory and CPU a linear-gradient for the whole doc will consume, and don’t know if it would be a little bit better than multiple gradients either as it is undocumented (and I’m not sure it works the same as normal images).

But sanitization and recalc/reflow/repaint could create a huge performance black hole. On the other hand, you’d have to traverse and alter the DOM with JS so it’s one of those complex issues for which reliability will be a key factor.

[garconvacher]

Superscripts and subscripts are difficult to read for some users. Font size and vertical offset from the baseline need some tweaks.

[JayPanoz]

@garconvacher Yeah thanks, that was on my roadmap and I was waiting for confirmation.

It should be one extra line of CSS for sup and sub, but I must also investigate span there, and of course there is now the Open Type Features (font-variant-numeric: ordinal + font-variant-position) to normalize as well… which will be a lot of fun since it could be applied at the body level.

@SeldomScene Do not hesitate if you have any question or encounter issues (I know we have some but could not necessarily fix them given their apparent complexity, cf. sepia’s blend-mode).

I’d really be interested to hear about your implementation feedback, as it will help with a lot of other issues (fallbacks, themes if you do that, performance, etc.).

[JayPanoz]

Just for future reference: EasyReading typeface.

It’s not an open source/free typeface (and the mobile app licence is 490€ per style) but Microsoft has ordered an audit to check whether it really helps with dyslexia or not, and might acquire a license depending on the result (sorry, source link in French).

Best case scenario it that it would be packaged as a system font and we could then use it “for free” on the Windows platform.

[MarionBerthaut]

@llemeurfr, here is the result of our research.

There is evidence that the presentation of the text has a significant effect on a text’s accessibility for people with dyslexia. Sans serif, monospaced and roman font styles significantly improved the reading performance over serif, proportional and italic fonts. However, there are no proof that one specific typeface among others would have a superior impact on reading performance.

For instance, here's a study : Good Fonts for Dyslexia (Barcelona university) - 2013 http://www.luzrello.com/DysWebxia_files/assets2013.pdf They use eye-tracking to measure the effect of font type on reading speed. They have good results with Helvetica, Courier, Arial, or Verdana. Opendys have good results with specific children, but not with others. We are going to publish a italian book, with Easyreading typeface, for chrismas. I will give you our own results.

My opinion is that a reading system must allow several typefaces, in order to let the user choose (to improve his autonomy). But not too many choices (overload risk). Idealy, you can select in the settings the 2 or 3 typefaces, that are proposed in the menu.

Nota : A simple manipulation of letter spacing is much more relevant. It substantially improves text reading performance, even without any training. Up to 20% speed and two times less mistakes. Extra-large letter spacing improves reading in dyslexia - Johannes Ziegler http://www.pnas.org/content/109/28/11455 "Extra-large letter spacing helps reading, because dyslexics are abnormally affected by crowding, a perceptual phenomenon with detrimental effects on letter recognition that is modulated by the spacing between letters."

[JayPanoz]

Thanks @MarionBerthaut! I guess this can probably serve as a review of https://github.com/readium/readium-css/issues/4#issuecomment-346045056 😅

[JayPanoz]

So quick question.

From “Good Fonts for Dyslexia” (link), it looks like providing users with a monospace font would make sense:

The two fonts that lead to shorter fixation durations than other fonts were Courier and Helvetica. Hence the use of these fonts might help people with dyslexia to read faster. This is consistent with the recommendation to use Courier and to use sans serif fonts in the case of Helvetica. Also, Helvetica was the second most significantly preferred font by our participants after Verdana.

And in such a case, what would be the impact of using a duospace font instead of a monospace font?

To sum things up, a duospace font gives 50% more space to the letters m, M, w and W. So every character is single-fixed-width except those 4.

[JayPanoz]

We would get the following results:

I must admit that even in non-a11y context, it would probably feel good as the 150%-width characters make it a lot more natural than a pure monospace font.

[JayPanoz]

So I’ve added that to the alpha branch since we have the luxury to do such a thing.

The assumption is that it will be far easier to test, review and validate it – it’s an easy implem, and consequently an easy removal, should it not prove very useful.

[danielweck]

Thanks Jiminy! I upgraded r2-navigator-js with the latest ReadiumCSS dist from the alpha branch, and I added support for the "Duospace" font in r2-testapp-js.

I find the text very legible, I like it :)

[JayPanoz]

Great thanks, I just wanted to tell you I added it. 👍

And thanks for the feedback as well.

[JayPanoz]

So I’ve finally made a pen to showcase the pure CSS solution for lines with alternated background-colors: https://codepen.io/JayPanoz/pen/vRPbjd

As you can see, there can be a shift in the context of CSS multicol when the paragraph is fragmented, and the background-color is then completely off. See second column in the following screenshot.

That would work for scroll (you can change to --col variable to 1 if you want to test it), although you can end up with the same background color at the end of one paragraph and the beginning of another.

There’s no concept of nth-line(odd|even) right now in CSS so it’s definitely tricky.

[danielweck]

Cool experiment, would make a nice optional ReadiumCSS feature (plugin?) to improve legibility for some users (maybe not pink and blue though ;)

[JayPanoz]

Yeah, I must really think about the best way to deal with that, should we go the pure CSS way. I can recall dropping that in favor of a reading rule (video demo) for a small side project called eBookDys, which has been stalling for a very long time but seems used by a few teachers.

The challenge there, is that it can reasonably be used only in scroll due to the fragmentation issues. :-/

[JayPanoz]

To-do for the beta release:

• forcing an outline for focused elements;
• unfloat elements (e.g. images, asides, etc.);
• remove drop caps (I could not find a CSS solution working consistently for the alpha though…);
• removing or obscuring images (???)

[danielweck]

forcing an outline for focused elements

Note that r2-navigator-js (Electron/NodeJS) implemented this functionality from the start (as a useful experiment, not as a definite clean API), in order to visualize keyboard navigation inside EPUB HTML documents (as you know, tab and arrow keys -based interaction is important on desktop).

https://github.com/edrlab/r2-navigator-js/blob/c8cee8b5a47e3def7033f711d793ca1452d178f9/src/electron/renderer/webview/styles.ts#L8-L18

In r2-testapp-js, the experiment's aim was to offer consistent reading-system styling between the application chrome and the rendered content (e.g. UI buttons use the same focus outline), much like how screen readers highlight the point of regard. This also extended to "dark / night mode", text selection styles, etc. (see the CSS definitions linked above)

That being said, in the actual readium-desktop app the UI is built differently, and there is no public API in the navigator (yet) to allow an app to "push" its UI styles into those injected in the EPUB content (or vice-versa, for example the app could use ReadiumCSS's dark styles in its own UI).

Note that I'm not even sure this is a valuable feature, I am just describing original experiment I was toying with :)

At any rate, it will be great when ReadiumCSS exposes an on/off switch for focus outlines, and also enables customisation (border colour, thickness, offset, etc.).

[JayPanoz]

The most reasonable implementation to me at first sight:

• create an --USER__a11yFocus flag (custom prop), since we already have a --USER__a11yNormalize;
• outline’s customization can be handled in day, sepia and night mode modules, like ::selection.

But then it’s about UX i.e. is this an explicit = user can turn it on/off, or implicit = automatically enabled depending on some conditions?

Also, we’re (finally) entering FXL territory for this one. So maybe it would be a better idea to make focus its own module and then re-customize it in the sepia and night modes only.

[JayPanoz]

+ we might want to handle :target and maybe :active too in this case?

wdyt @danielweck? I know you mentioned :target a few times during R2 calls.

[danielweck]

Yes, as a matter of fact I was running tests this week, as part of a DAISY activity where we are in the process of defining good practice recommendations for content creators (aka production guidelines), specifically in the context of extended descriptions (typically, for images ... but this can apply to complex information structures like tables too).

Semantically we can leverage existing / upcoming techniques (including fallback mechanisms for non-supporting user agents / reading systems) such as aria:details and aria:describedby, alongside HTML5 <details><summary>, or <aside epub:type="footnote">, etc.

Stylistically, we can use :active and :hover for link interactions, :active to "highlight" link destinations (i.e. to emphasize the point of regard of navigation targets), typically with CSS outline styles rather than border (as the latter usually messes-up the border-box model of arbitrary EPUB HTML documents).

Problem: several EPUB reading systems (including Readium(1), iBooks iOS/OSX, Edge) seem to interfere with URL anchor / fragment identifier, thereby breaking CSS :target pseudo-class. This is something I have been keen to get right in Readium2, where the navigation logic (link activation) is also "hijacked" by some kind of reading system logic, especially in Electron as we listen to <a> DOM click event, as well as higher-level / platform-specific navigation events via a WebView API (which allows us to capture the annoying window.location programmatic redirects that InDesign uses, among other things).

So, going back to the question at hand: should ReadiumCSS allow apps to opt into aggressive style overrides (!important) for common user interactions such as :focus, :target, :active, :hover, etc.?

Well, given that ReadiumCSS can already force (over authored styling) "colour themes" and various other visual formatting rules, it seems logical to allow reading systems to ensure consistent styling for the aforementioned interactions too, some possibly customizable via user preferences, for example the thickness of the :focus outline, or whether or not to enable :target emphasis at all (for people who have difficulty to find the point of regard when following hyperlinks).

[JayPanoz]

This issue has been cut into more specific pieces (see above). Please comment in the new issues if possible, or create new ones if we missed something.