Showing results for 
Search instead for 
Did you mean: 

User specific CSS selection to utilize the Dyslexie font

3 7 968

I just came from a workshop on "Language and Accessibility" (as a follow-upp to a seminar that we had a month ago on the topic - the slides from the seminar are available (in Swedish) from ). One of the issues that came up is providing users with dyslexia with material presented in the Dyslexie font ( Dyslexie Font: The dyslexia font which eases the reading  ). Has anyone looked at being able to set a particular CSS file to be used for the user's Canvas UI based upon a user's profile? I imagine this to be an extension of the fact that the user can choose their UI language (for example, as commonly used here English or Swedish, based upon their user settings (as stored in the user's 'locale' attribute' in the format described in RFC 5646)). One approach would be to encode this desire for a special font in a subtag for the language and another would be to actually add a custom CSS attribute to the user object. Has anyone done anything like this?

Having an attribute that specifies a custom CSS file would probably be cleaner but would require a new field in the object. An interesting side benefit of the having both the ability to specify a custom CSS and font would be that one could have multiple language pages (ala Using tabs for content in three languages: Chip sandbox ) where the user's choice of language would the automatically the selected visible alternative.

Note that in the above when referring to a "custom CSS file" I am thinking in terms of choosing one from a set of files for the site, as opposed to having each user able to upload their own CSS file. 

Tags (1)

Interesting idea,

Here's a couple of initial thoughts to perhaps get the ball rolling.

The example in the Chip sandbox will stop working at some point as the jQuery UI that provides the tabs is going bye-bye:‌. It's not anytime soon according to the discussion and the fix is for us to add jQuery UI through the custom JavaScript.

That's not the issue you bring up, it just made me think of it. In the Chip sandbox, that page didn't use locale to determine what text to write, it actually had the foreign languages in the page itself. I18n support through the locale isn't the way to go here, either, as dyslexia isn't a recognized locale and so you would run into problems retasking a well-defined item for another purpose.

What you might be able to do is the custom data that can be written for each user. You could save a value that would indicate the person needs something different. Then, upon every page load, you check for the existence of that variable as part of the global custom JavaScript. If it is found, then you act appropriately to load the CSS that changes the font to the appropriate one. You might need to be careful when picking your fonts to make sure that there is support for all of the characters that you need. It might be something that is only applied to user content, while Canvas menus remain the same, or you might change it for the entire page.

The next step is making it easy for people to make that change. It could be a checkbox that you add to the user's settings page that they check if they want to use the Dyslexie font.

Planning should go into this so that you minimize the number of calls for custom data. That is, don't use one just for dyslexia, but think of how it can be used for other things you might need.


Thanks for your very helpful reply!


You may also look into installing Dyslexie Font or OpenDyslexic Font on your users machines. They can then use something like the Google Chrome Force Font Extension to change the fonts on every page they visit.


Once again thanks, James for your very insightful response.

Based upon your comments, I have dug a little deeper and found the following:

Unlike systems such as Hyperwave (or its predecessor Hyper-G) Canvas does not have the concept of an ordered list of languages that the user would like to work with in terms of both the language used by the UI and the language(s) used for content. As I see it the locale used in Canvas is only concerned with the language used for the UI (or more specifically to select which table is used in conjunction with I18n to selected a string to be used in the UI). I agree that adding the support for an alternative font, such as Dyslexie, via the locale mechanism is a bad idea.

There are two different approaches to features with respect to modifying what the user sees:

1. The feature option "High contrast UI" basically replaces the style sheet with an alternative style sheet, for example in KTH's case:

<link rel="stylesheet" media="all" href="" />

is replaced by:

<link rel="stylesheet" media="all" href="" />

Along with replacement of the various Javascript files:

<link rel="stylesheet" media="all" href="" />


<link rel="stylesheet" media="all" href="" />

2. The feature option "Underline links" adds "Underline-All-Links__enabled" to the class of the body. For example (for my course 1751):

<body class="padless-content with-left-side course-menu-expanded with-right-side home primary-nav-transitions context-course_1751">

is replaced by:

<body class="padless-content with-left-side course-menu-expanded with-right-side home Underline-All-Links__enabled primary-nav-transitions context-course_1751">

The first approach seems to be more appropriate for helping user's by providing an alternative font as this selects a specific CSS to be used for the whole HTML page. Moreover, I generally thinking of CSS as the appropriate means to select which fonts, font sizes, etc. are to be used for rendering the elements of the page. This seems a more suitable way to specify that the Dyslexie font should be used for a given user's web pages.

In contrast, the second approach seems more appropriate as the means to affect which language (of a multilanguage page) is made visible to the user. Thus an extension of the enclosing class would seem to be the way to determine by javascript which part of the page's should be used when rendering the page.

However, as you also pointed out the enhanced tab mechanism that I am currently using to support content in multiple languages  on a single page is implicitly dependent upon the jQuery UI being included in the javascript that is currently being loaded for each page and that this functionality will be removed (at some point in the future).  The fix for this is either (1) use a different method to deal with content in multiple languages  or (2) add the jQueryUI code to an institutional file of javascript that is loaded with each page.

[As a aside, I should note that the current way that we add prism.js to pages to render code examples on pages is also based upon the existence of jquery. Moreover, this functionality is selected based upon the subaccount and not on the identity of the user or even specific to a particular course.]

I also found that the jQuery UI CSS is introduce via  <link rel="stylesheet" media="all" href="" />

This can be seen by saving .css file as .css.gz and gunzip the file.

I also found that the current font loading is happening via <script src="" async="async">

This javascript file ends with

new FontFaceObserver('LatoWeb').load().then(function () {
}, console.log.bind(console, 'Failed to load Lato font'));

[Background information about this can be found at GitHub - bramstein/fontfaceobserver: Web font loading. Simple, small and efficient.  ]

Following up on Promise should resolve when font installed locally · Issue #55 · bramstein/fontfaceobserver · GitHub  - it would seem that a very simple solution would be to have users who want to have a specific font simply install a local copy of the font of their choice - but name it to have the same name as the font that they want to replace. Then the browser will use the local "copy"  and never load the font from a remote source! Interestingly this would of have no impact on any of the rest of Canvas and would not require changes to the .css, .js, ... files - but would affect any use of the LatoWeb font by the user's browser. However, one might want to change the CSS to allow loading of the local font, as described at How To Host Google Fonts Locally - The PHP Hero  .

Lato became the primary font as described in Canvas Production Release Notes (2016-12-10) .


Jeremy, thanks for these pointers - I like both approaches. I have made a local page with examples of each of them for our local teachers and will propagate this information to others who can benefit from it. Moreover, this was also timely as I have been trying to encourage the use of serif fonts in out local web pages - Force Font provides an easy way to show the benefits of this.


Here are some comments -- given your in-depth response you may already know them.

Canvas has said jQuery will still be supported and available. That's subject to change, I guess, but it would break a lot more scripts than removing jQuery UI would. So the loading of the prism.js shouldn't be affected (too much). For the jQuery UI, you could take a similar approach, but Canvas has suggested you roll your own widgets of just the features you need. That helps cut down on the size, but it's still big. As a test case, I removed all the Effects group and the minimized jQuery UI file went from 248k down to 224k. I need to do more research about the approach I'm going to take.

The links you provided to the CSS are likely to change. Not only because they're specific to a release and so updating will change them, but because Canvas is moving to Webpack. Webpack allows you to package all of the different types of files (js, css, svg, png, and about anything else) you use into one system that can download it in chunks. I've started reading a book on it, but I'm not very far and this isn't my area of expertise so it's taking a while. That means that those files that are now identifiable will end up looking like this:


It makes it much harder to figure out what is loading what. But I think Canvas is making the point that you should be loading your own things rather than relying on theirs.

I'm not sure if you're saying you would like to retask the existing features high contrast and underline all links or just showing them as examples of ways to accomplish things. I would urge not changing the existing ones because some people need high contrast but won't want Dyslexie.

For the multi-language issue, one approach would be to use custom JavaScript. The lang attribute is supported on all HTML elements in Canvas, so you could write JavaScript that would go through a page, look for all of the elements that have a lang attribute specified and compare the language to the locale. If it finds a match, it displays that one and hides the others. If there is no match, then all three are presented in some manner. This would obviously take a lot more thought than I'm giving it right now to allow for different blocks of content (section A is in English and Swedish, but section B is in English, French, and Spanish, and the locale="es" or Spanish). There would have to be the notion of a default and some way to delineate the sections to know where the choices applied.  I think the easiest way is probably going to be to find a way to replicate the behavior of tabs using jQuery UI or another smaller library.

I'm still not sure about whether Dyslexie has the character support you need to replace Lato for the primary font inside Canvas. I don't have Dyslexie, but I had OpenDyslexic installed and it Lato has support for many more characters. But I really don't know how big of an issue this might even be.


Once again, thanks James for a wonderful response. I've looked at the Lato Regular font and it has 3022 glyphs (while LatoLatin has 466 glyphs), while OpenDyslexic has only 748. As you correctly identify there could be problems when using OpenDyslexic on pages that make use of glyphs outside of those that are supported. I expect that this means that at some time I have to extend my program that gets all of the pages of a course to process all of them to see what set of characters are actually used and then generate a warning when there are characters that are not supported in OpenDyslexic (or another specified target font ).

I think that for the present I will continue to use the tab mechanism for multilanguage content, keeping in the back of my mind that this will have to change later. 

Thanks for the heads up regarding Webpack. This seems to make sense in the context of an application such as Canvas. I also understand the interest in decoupling what Canvas has for the user's interface, but I'm still struggling to understand what the implications are at the course level (rather than the site or subaccount level) or for an individual user. (Personally, I like the fact that turning on the high contrast option disables local branding. Although my local administrators might be unhappy with this Smiley Wink .)

Bringing this discussion to an end, the conclusions seem to be:

  • keep using tabs for multilanguage support,
  • use a browser extension to provide the user with an alternative font for viewing pages (i.e., a solution that is completely outside of Canvas),
  • think about making a tool to check for pages that use characters outside of a subset supported by the set of target fonts (which implies a side effort to determine what this font or these fonts should be), and
  • do some more thinking about at what level a user or course should be able to specify alternative CSS, Javascript, or more generally Webpacks.
About the Author
I've been the professor for Computer Communications at KTH Royal Institute of Technology in Stockholm, Sweden since 1994.