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.