I am trying to use custom font in my Email template, but it seems webmails like gmail remove style tag in email body. Is there any way to load a custom font in email body? Like file URL or base64 encoded data URI?
Custom fonts using #font-face only have limited support on email (no support for Gmail). https://www.caniemail.com/features/css-at-font-face/
The only way around it is to save it as an image. Having said that, many people do use images extensively for that reason.
If you do use an image for writing make sure you:
Use a font-size large enough to be read on the mobile rendition (which will often reduce it to half size)
Use the 'alt' attribute to write the text out for screen readers, smart watches & other smart devices that use a plain text rendition of your email
Test it on a few different email clients
Do not over-do it. Low quality (and spammy) emails tend to be image-heavy, and you don't want to get that sort of reputation.
Related
We have a project at my work at the moment around ensuring we meet accessibility standards on our website.
Our emails are built using Salesforce Marketing Cloud layouts. Does anyone know how we can see or test how 'accessible' they are?
I can test using ReturnPath to see how they render on various devices and that gives me results for colour blindness, but I'm not sure how to test how well they would or wouldn't work with a screen reader for example
Emails are a tough one from an accessibility perspective. We are still stuck using tables for layout even in 2021!
We can't use WAI-ARIA and CSS is very limited.
As such I have a smaller checklist for emails that covers the important stuff we can control.
The main things I would look at are:
Reading order
Make sure that the email reads left to right and then downwards (assuming the language is a left to right language, otherwise reverse it)
Use headings
Email marketers often just style normal text instead of putting proper headings in. Make sure headings are in fact <h2> to <h6> with a single <h1> explaining the purpose of the email at the start.
Also make sure that the headings do not skip levels (so don't go from <h2> to <h4> for example).
Colour contrast
The exact same rules for websites apply to emails. I would recommend running the colours through the Web Aim colour contrast checker for your text and background around the text, button backgrounds and text etc.
Alt Attributes
Alt attributes on images is the big one you need to check for especially in emails where images might be the only content within a hyperlink. As you can't use aria-label or visually hidden text in an email alt attributes are the only way you can make a link have meaning if it contains an image (plus as email clients block images it means there is meaningful text for everyone else not just screen reader users).
Meaningful Link Text
Along the same lines make sure links do not just say "Read more". Instead make link text meaningful e.g. "Read our article on X Y Z".
Use a descriptive subject line
This one is the only one that is "difficult" as a marketer. You want subject lines to intrigue people to open the email, however for people with cognitive impairments cryptic subject lines can be disturbing / confusing etc.
Getting the balance between "giving the game away" and meaningful subject lines is difficult, if unsure err towards meaningful (it may help your open rate / conversion rate anyway so A / B test it!)
View in Browser
Due to the limitations of email clients the best way to ensure accessibility is to have a custom "view in browser" link in the email (as salesforce etc. are very unlikely to do a good job of the browser versions of their emails).
That way you can use WAI-ARIA, visually hidden text etc. and mark the page up properly, complying with WCAG 2.1 (and very soon WCAG 2.2) requirements.
Obviously I am aware of the amount of work this entails but once you have a template and components built that are accessible it does become much easier.
Testing
Personally I would just test manually, but I am sure somewhere out there an email testing service exists similar to Axe Accessibility Checker.
But given the length of a typical email I would say a manual check will only take 2 minutes once you know what to look for so a service may not be worth it.
You could always copy and paste the email HTML into a file and save it with a .html extension and then open and test it in a browser / accessibility checker. But you might get a load of issues you can't resolve due to the use of tables for layout.
Finally - learning to use a screen reader takes less than an hour, grab NVDA or VoiceOver and test the email yourself, if you can understand it and access all the same information as everyone else then send it!
I'm using font-display: optional to make my fonts optional and just show it to users with fast internet connections. It's not important to have the font there all the times, and the design team doesn't want to have the font swap ocurring.
I was asked if it's possible to track the number of users who were served with the font. The fonts are now self-hosted, we are using Adobe Typekit.
Anyone has any idea how to track it?
Firstly, if you were ok with using javascript, this question may help you: How to get the actual rendered font when it's not defined in CSS?
First you would have to define the function given in the accepted answer:
function css(element, property) {
return window.getComputedStyle(element, null).getPropertyValue(property);
}
And then you could use it like this:
var fontUsed = css([insert element here], 'font-family')
I would then use ajax and php to upload the fontUsed variable to a mySQL database, creating a new row for each user. You can then process the results and see how many users were served with your font.
See the w3schools tutorial on ajax if you need help: https://www.w3schools.com/js/js_ajax_intro.asp
I understand that it is a risk to use SVG and Wordpress disable the use of them. But many website nowadays use SVG because of the performance and resolution. So are all these websites having a huge risk to get hacked?
If I would code the website in plain html, css, php, mysql without a cms, would my website be highly risked to get hacked too?
SVGs are effectively (XML) text that are interpreted and rendered by the browser. The SVG "text" can include scripts (for valid or malicious reasons). SVG has a lot of benefits. I use animated SVG headers that I created myself on my Wordpress sites; file are small and do not rely on JavaScript for animation.
I assume you are ONLY talking about having your OWN SVG images for the header, or in your own posts (and won't be including malicious scripts to attack you or your visitors!). If so, in my fallible opinion, there should be near Zero (can never say never) risk as long as you cater for these possibilities:
you use an SVG file created by someone else that contains malicious code. So create your own, or obtain them from one of the major image sites and check the SVG source text carefully before use.
a visitor/user uploads (innocently or otherwise) a poisoned SVG. Even if it is not displayed on your site the simple act of you viewing (say via Cpanel) the uploaded file in a browser could trigger the malicious payload. So block anyone else from uploading SVGs. Ideally upload your own via FTP and block all uploads via your site's pages.
see also https://wordpress.stackexchange.com/a/247190/128374
I know how to create an HTML email template for Outlook, by copying your HTML file (in Windows) to %AppData%\Microsoft\Stationery. However, if you use the template to send emails Outlook messes around with it first - adding CSS to the head, stripping out things like media queries (from the head), adding its own CSS classes to the HTML etc etc.
Is there a way this can be avoided or minimised?
Thanks,
Toby
Outlook completely rewrites the HTML using the MS Word rendering engine when you send out. Pretty much once Outlook has its claws on your email, it is now a Word doc.
Also, I would recommend saving the code as an HTML file, then using Insert > Document >Insert as Text option when you go to send a new email in Outlook to create your HTML email instead of stationary. This allows much more leniency in HTML/CSS display. (Walkthrough)
Designing for sending from Outlook is extremely tricky and unless you have an experienced HTML/CSS email designer, I would recommend (as much as it pains me to say) that you just create it through Word and saving as HTML file. As long as it is going from Outlook to Outlook, there should be little to no discrepancy in design.
If you are going to send to recipients that do not use Outlook, then you will need another email client to send from or deal with the fact that either these people will get less than optimal email messages or create a super simple design that can display well across all email clients.
I'm currently making a project where I need to print out a receipt on a receipt printer.
At the moment i'm using the CSS mechanism media=screen , media=print to indicate what to print.
Problem is of course the header and footer which can't be removed, as it is client browser specific.
So i'm wondering if anyone has another suggestion on how to do the printing. Preferbly without using too much IO.
Generally speaking, if you need precise control, your best bet is to have a pdf, or other doocument format that is generated from the server, for your printing. (if the machines printing receipts are controlled, and have word, than .doc (html with an output type) is the easiest method. There are a number of third party controls for generating PDF from server-side code as well. Hope this leads you in a usable direction, since you didn't specify if you controlled the client machines in use.
One benefit to PDF is you can use it as a hard archive, as well as being able to email receipts as an attachment.
The header and footer information (Assuming you're talking about the URL showing up at the bottom of a page) is client-side and there is nothing you can do to change that from server side.
If all of your printing is going to be done from inside your company, you could have a group policy created for Internet Explorer printing to remove these company-wide. You could also just have instructions on your page on how to change these setting manually.
Another option is to print with a 3rd party application, such as PDF, or print it directly from the server if that option is available to you.
Do you mean the page header and footer?
If that's the case, wrap the header and footer in IDs and create CSS tags to target them and give them a much simpler styling, or you can use the CSS element display:none to remove them altogether in the print css.
You could load the content you want to print into an iframe, focus on it, and print that. That way you'll have exact control over what appears on the receipt.
It'd take a small bit of javascript, but I've had success doing similiar things when I wrote a custom contract printer.
It's not an ASP solution, but may help:
http://code.google.com/p/jzebra
It's a java plugin that can bypass the header and footer stuff.