Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Baseline for a11y-related user settings #18
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:
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:
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:
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?
Yep, like Microsoft's "Learning Tools" / "Immersive Reading"
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)
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
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.).
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?
@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:
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/
Follow-up on the
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
The best bet would be applying a global background at the
Possible issues are images’ dimensions, lack of knowledge where
Other issues: scrollable frames/containers, recalc/reflow/repaint on line-height change.
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)
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 Yeah thanks, that was on my roadmap and I was waiting for confirmation.
It should be one extra line of CSS for
@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.).
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.
@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.
For instance, here's a study : Good Fonts for Dyslexia (Barcelona university) - 2013
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.
So quick question.
From “Good Fonts for Dyslexia” (link), it looks like providing users with a monospace font would make sense:
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.
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.
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
There’s no concept of
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. :-/
That being said, in the actual
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.).
The most reasonable implementation to me at first sight:
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.
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
Stylistically, we can use
Problem: several EPUB reading systems (including Readium(1), iBooks iOS/OSX, Edge) seem to interfere with URL anchor / fragment identifier, thereby breaking CSS
So, going back to the question at hand: should ReadiumCSS allow apps to opt into aggressive style overrides (
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