I'm using System.Net.Mail to send an email message and want to make sure it appears properly from anything from a text-only cellphone to a rich client on Mac, Suse Linux/Evolution, or Windows.
I gather there are a few points to consider when sending a message with such a broad reach. Here is my list so far:
Plain text header: For text only clients, preface the entire message with plain text that says "to view this message click this link". This text should be readable even if the message hits the spam folder.
Layout: For the html portion of the message, should I use CSS or HTML Tables?
Doctype: What is the proper doctype to use XHTML, HTML5?
Images: What is the best image format to use? .. should I take any special considerations when embedding it? I'd prefer for the existence of an image to not give the message an "attachment" icon
MIME types: Is there any special MIME type I should use for the plain text or html part... or should I just preface the HTML with my text, and then hide that text with CSS style?
I'm sure there are more things to consider, or ways to rethink the above. What other items should I keep in mind when generating such an email that needs to understood by many devices?
This guide to css support is invaluable. In general, write your html like it's the year 2000. You'll be using a lot of tables for layout. CSS support is decent, but you have to use inline styles. That's because gmail strips styles in the header and no mail client links to external style sheets. The referenced guide does a great job of explaining all the guidelines.
As far as html and text, the best practice is to send them both. You do this by adding an alternate text view. See this article for an example. There are many such tutorials if you google "send html and text with .NET" or something similar.
This might sound trite, but if you want your email to display properly on any system, why not just send a plain-text email?
Is there some compelling feature of rich HTML that you really need?
Me, when a web site presents the option to choose text over HTML for their communications, I always choose plain text. It requires less bandwidth, is easier to read, doesn't have any obnoxious images, requires less processing power, etc etc.
If you only use the lowest common denominator, you will have the broadest device support.
That said, using multipart/alternative with a text/html part should work just fine on any reasonable device. The things not supporting HTML will display the text and the other devices will display the HTML. Use only a simple set of HTML - don't go overboard with fancy CSS features.
Related
Got a site with powerpoint presentations that the client wants embedded, the embedding is being done via google docs embed. I have been doing some accessibility testing, albeit not particularly in-depth but even with OS X screen reader it is not having any luck reading the slides. (I am aware slides are probably terrible for accessibility anyway). I can get the text content of the slides stripped out via the Google API, but I don't know if thats the best thing, to include it on the page below/above the iframe embed with one of the CSS tricks for hiding it from normal view?
I am aware of iframe title and aria-label but those seem to imply they are only to describe the contents of the iframe, which I am doing, but I need somewhere that can contain more text.
Has anyone got any good tips for the best way to deal with such things? Thanks!!
Embedding rich 3rd-party content in web pages poses many challenges.
When we put something like this in a web page, we typically think we're adding a bit of "content", but it often amounts to embedding a complex application; and the user interface, semantics, and presentation are outside of our control. In your case it's a presentation slide deck, but it could also be a Flash/Silverlight/Java applet, a slippy map, interactive SVG infographic, a 3D-panorama, virtual tour, zoomable image, chemical molecule viewer, or who-knows-what. (Note: I'm not familiar with the Google docs embed/API specifically, so most parts of my answer will address these rich content cases in general.)
Even if the embedded rich 3rd-party content/application is accessible today, there's no guarantee it will remain so after the 3rd-party system gets an update.
So what can you do? The safest thing might be to assume it's inaccessible, and consider the best way to provide an accessible alternative. The Web Content Accessibility Guidelines (WCAG) calls this a "conforming alternate version", and it sounds like you're already thinking along these lines.
An important caveat to all of this, is that the use of "conforming alternate versions" isn't considered ideal by many accessibility specialists. It's greatly preferred to make your main content accessible as you can.
Some relevant parts of WCAG:
Understanding conformance, especially the section about "Understanding Conforming Alternate Versions".
Technique G190: Providing a link adjacent to or associated with a non-conforming object that links to a conforming alternate version.
F19: Failure of Conformance Requirement 1 due to not providing a method for the user to find the alternative conforming version of a non-conforming Web page.
It's worth mentioning the 3rd-party content in your website's accessibility statement. Statement of Partial Conformance - Third Party Content offers guidance about that.
The crucial thing about conforming alternate versions, is that it's no use at all if the user isn't made aware of it, or isn't able to reach it.
Implementation-wise, there are a variety of approaches you might take. In many ways, providing an alternative for embedded rich content is similar to providing a long description of a complex image, or a transcript of a video. Have a look at these WAI tutorials for some ideas.
Web Accessibility Tutorials: Complex Images
Making Audio and Video Media Accessible: Where to Put Transcripts
I can get the text content of the slides stripped out via the Google API
It sounds like you're trying to automate the process. That's fine, but it might not give satisfactory results. Some things you should consider:
Is the text content alone going to be enough? Presentations often have images too. Did the author provide text alternatives for these images, and are they present in the text extracted via the API? If the author hasn't provided text alternatives for images in the slide deck, the text you get from the API won't be telling the whole story.
Not all text in slides carries the same weight. Some slides serve to introduce sections, some slides have headings. Does the text obtained from the API convey these relationships?
Lists are very commonly found in presentation. Does the text obtained from the API preserve this structure?
Slides sometimes contain links. Are these included in the text obtained from the API, so the links are available to everybody using the alternative version?
Slides sometimes contain tables and charts. How will the information in these be conveyed in your alterative version? Is the information included in the text obtained from the API?
Sometimes, presentation decks also contain rich 3rd-party embedded content themselves! A slide containing a video, or an animated GIF are examples of this. If so, you can find yourself with a much more complex challenge.
... and many other meaningful info and relationships. Quotations, code samples, etc.
If any of the above points give cause for concern, you will need to consider managing your alternative version manually.
The "conforming alternative version" has to conform to WCAG; if you just offer a choice of two non-conforming version, that doesn't satisfy WCAG.
include it on the page below/above the iframe embed with one of the CSS tricks for hiding it from normal view?
No, I wouldn't recommend that. I assume you're refering to visually-hidden text, using CSS utility classes such as .visually-hidden or .sr-only. It sounds like you're only thinking about screen reader users.
You need to offer the alternative version available to everybody, not just one group of users who you think will need it.
Many groups of users may experience difficulty using the rich 3rd-party embedded content. This includes people using the keyboard only, screen readers, magnifiers, speech control, switch access, or other tools. The conforming alternative version can be navigated like a normal web page though.
The 3rd-party content likely has a different visual style, and it may not be adaptable in the same way as the page it is embedded in. That can frustrate people who make use of browser zooming, text resizing, font preferences, reader mode, Windows high-contrast themes, viewport resizing, and other user-applied presentation changes. The conforming alternate version should be as adaptable as the rest of your site.
Rather than hiding the alternative version in a visually-hidden container, here are some other ways to present it. The first two are the simplest and most reliable.
Put it on the same page, just after the original content, visible to everybody.
Put it in a collapsible disclosure element just after the embedded content. A <details> element is an easy way to achieve this. This is useful if the alternative version is quite long.
Put it elsewhere on the same page, and tell users where to find it. An internal link can help here.
Put it on a separate page, with a link next to the embedded content. I'm less keen on this approach. Only use it if you can commit to maintaining both pages.
Provide a way for users to switch between the two versions. For example some buttons, or a tabbed UI. However, you must also ensure that the switching mechanism is accessible. That might mean a full-blown ARIA tabs implementation.
I am aware of iframe title and aria-label but those seem to imply they are only to describe the contents of the iframe
Giving the iFrame a useful name is important. It's also a useful mechanism to inform screen reader users that an alternative version is available. The WAI Complex Images tutorial linked above has some similar approaches. Example: <iframe title="Google Slides Presentation of FOO BAR BAZ. Link to text version follows this frame.">. This only helps screen reader users though; you still need to make the availability of the alternative version clear to everyone.
How committed are you to using Google Docs for displaying these slides?
Any accessibility enhancements that you'll be able to implement on Google Slides won't be very good.
One way around this whole thing is to offer PDF versions of the slides that have been fully-remediated for accessibility instead of using Google Slides. That would potentially be a single solution that could be accessible to all visitors. Going this route means that you wouldn't have multiple copies of the same slides to update, which could lead to a split in content if one gets updated and the other is forgotten.
If you're really set on having the slides embedded in the page, then you could offer both formats by applying aria-hidden to the embedded iframe and then hiding the PDF links from sighted users using CSS clip, or by positioning content off-screen.
I already read lots of threads about this and they all say that gmail doesnt support the style tag so I have to use the inline styling to resolve the problem. The problem is that I've look at the source code on most of the emails that I've received on gmail and most of them use the css style tag, which contradicts what other says.
So question is, why the emails with css that I've send via php mail is not showing correctly on gmail. It does show ok on Yahoo and Hotmail though
Its a bit hard to provide a detailed answer to a question that doesn't provide specifics so I'll make some general comments...
Cross web-browser designing is a piece of cake compared to designing HTML emails for different e-mail clients. There are far more email clients than web-browsers and far more variation in their support of HTML and CSS rendering. There are no "standards" per-se.
You need to keep everything simple and play to the lowest common element. It's not just a matter of the style tag being implemented or not, different client may or may not support different styles. You need to experiment with what works and what doesn't on as many clients as possible.
Some more reading for you if you haven't read these already:
http://css-tricks.com/using-css-in-html-emails-the-real-story/
http://coding.smashingmagazine.com/2012/03/13/techniques-overcome-poor-css-support-email/
Many people design with their CSS in the style tag and then use a tool to inline it prior to sending, making it compatible with for Gmail. Depending on the tool, it may not remove the original css, effectively doubling up. Another reason could be that those css declarations are intended for non-Gmail clients. A common example is media queries, which don't work inline, making them incompatible with Gmail.
Here is a related blog post I've written that also includes a few links to some popular CSS inlining tools
Im making a normal RSS feed for my website. I need to include simple html formatting in the description eg paragraphs, line breaks, lists, etc. To do this I need to wrap the description content as CDATA.
The issue with this is that when I validate my feed the content of the CDATA is ignored. So although the feed validates, I dont actually know if everything is ok or not.
How can I find out what markup will likely be read ok by the various RSS readers?
Can I use whatever markup I would happily put in a website? How about inline styles? Or is more like designing html emails? Thanks
RSS files are XML Formatted plain text, I think that's the only standard you can rely upon.
I think most Syndicators look like they're handling HTML in RSS as they simply download the linked article when you choose the header.
If you're looking to embed rich content, then you may well be better investigating Atom instead of RSS.
Have a look at this S/O question: Which is better for encoding HTML for RSS?
Suppose you're developing a web site and blind users will be a significant chunk of your target market. If the web site includes document editing functionality, what would be appropriate WYSIWYM tools? Are languages like Markdown, Textile and Wiki Formatting really accessible or are they inconvenient to blind users?
I'm a blind programmer and while I haven't used most of the languages you mention I've found that any markdown language is fairly easy to use if you have the desire to learn it. I've had no problem using either HTML or several markup languages for wiki's. Part of it will depend on how invested the users are in your site. If it's a site that will be visited infrequently or for short periods of time, it's much less likely that a user will take the time to learn the required markup whether they are blind or not. Unfortunately, I have not found an accessible JavaScript WYSIWYG editor but I find it easier to manually enter the markup so haven't looked very hard.
the first question is: how important is semantic structure? could you get away with plain text. You could do simple parsing like treating blank lines as paragraph markers, treating a series of lines which begin with * as a bulleted list, identify URLs and make them into links, etc.
As a blind developer myself, I have no problem in understanding languages like Markdown. But if it's a syntax I'm unfamiliar with, I'll only learn it if I expect to use the site very often, or care deeply about the content.
Two final thoughts come to mind: while I certainly experience some accessibility challenges using TinyMCE, you could develop something much simpler - provide less than 10 formatting options, like inserting hyperlinks, making lists, centering text, setting the style (such as heading) etc.
And lastly, when I talk to non-technical blind people, they often just write their content in Word and paste into a wiki or blog post. This sounded strange when I first heard it, but it does make sense. So an ideal solution would accept pasted in content.
In closing - it depends how important this is, and how much effort you want to expend. Maybe a Markdown editor with a live preview (like on this site), buttons for inserting simple formatting like URLs, and the ability to paste in rich text would tick all boxes :-)
On a web page, the most accessible embedded text editor for blind users is one that uses standard HTML, such as a <textarea> element, with a corresponding <label> element:
<label for="editor">Enter your text here using wiki markup:</label>
<textarea id="editor"></textarea>
If a WYSIWYM tool is built using standard accessible HTML, then blind users can easily enter text into it, with full confidence that they're entering text in the right place. Then the question becomes: Which is the better markup language? They all require memorization, but some may be more intuitive than others. One way to find out which is best would be to do some usability testing with a wide variety of target users. Also be sure to providing easy, accessible access to syntax help.
Picture yourself working in pure text 80x4 display (just open a console and resize appropriately), then use vi/emacs/ed and you'll soon realize what markup will get in the way.
Try to do as much work as possible to understand plain text, else use light markup like POD, finally things like AsciiDoc are very powerful but needs training.
I don't know about WYSIWYG/WYSIWYM tools, but I do know that complying with W3C standards (especially their HTML5 en CSS3 drafts) while writing your own editor code will help a lot.
In CSS you can specify speed and intonation of speech. In HTML you can specify alternative text (alt attribute in many elements) that screen readers are compatible with. Be sure to know when to use the abbr and the acronym elements. Use the former when you want the screen reader to read the meaning of an abbreviation and the latter when the acronym should be read as a word (e.g. ASAP, NATO and OS).
For the editor itself, I recommend creating a WYSIWYG editor that uses divs and spans. Screen readers will understand easily the structure of a document. For the current line, use a text box; for every other line that's not being edited, convert the contents immediately to valid HTML.
If you find a good tool, be sure to post it here. I'm looking for one too. :-)
I have a mail in Outlook which is having an Html layout and has defined some Styles in style tag. When I open Outlook in IE and open the mail, it works fine and show me the correct layout. But, when I have used same in Firefox, the style part doesn't work. When I view source, I could not see Style tags.
Style tags are notoriously badly supported by Outlook and other HTML E-Mail clients.
The convention is to use inline CSS for Rich E-Mail.
Check out this great overview: Style in E-Mail
mail readers have far greater diversity than browsers and support of HTML ranges from none to limited CSS. While a few of the newest mail readers might support CSS, its almost always safest to stay with very conservative (old) markup. HTML for emails going to the overall web should be written in HTML3.2 with limited use of CSS1.
Design your HTML with the following guidelines:
Use HTML3.2 DOCTYPE for all email going to non-restricted internet domains
If your audience is restricted to AOL, you can safely use HTML4.01 transitional or experiment with XHTML1.0
Validate the HTML and keep it very clean. After you validate, shred the validation with the following hacks.
Use CSS1 and extremely limited CSS2. If NN4.7 can parse it, it's probably safe. Otherwise: TEST.
Another great resource that I always use is Campaign Monitor's Articles and Tips section. Their Guide to CSS support in email clients is just fantastic! There's loads of info on how to get started, etc...
Hope this helps!