4 ms·

> I'm actually not a kook about it. ;-) I'm glad you were being hypothetical, because you were sounding kooky, but I didn't want to say :) I gotta believe tha

> I'm actually not a kook about it. ;-) I'm glad you were being hypothetical, because you were sounding kooky, but I didn't want to say :) I gotta believe that HTML email doesn't pose an accessibility issue as long as the HTML is simply used for formatting. Any client can easily extract the text. Am I missing something?

jcr 14y ago
damn. I really need to be a lot more careful when hypothetically impersonating kooks --it seems I'm better at it than I thought. ;) Unfortunately, the parts you're still missing are commonly missed. Unless you are disabled or have done work assisting disabled people, it's really tough to grasp all the details involved in "accessibility" coding. The most common oversight is not knowing the significant variance in impairments. For example, vision impairments are not binary. It's not a matter of blind, or not blind. There's actually a fairly vast spectrum of disorders under the "vision impairment" category. Again, hypothetically, all you want to do is add some formatting to your email messages to make them look attractive. If a disabled person is unable to see the foreground text color you used against your chosen background color, then they will be unable to read your message. If it is a commercial message, and they can't read your 'unsubscribe' link, you might be in violation of the CAN-SPAM act. --As mentioned before, it doesn't matter if the accusation is true for it to be an expensive pain. Sure, the example is a bit of an over-simplification since people with various color deficiencies can often still read poorly chose colors due to variance in luminance between the background and foreground. None the less, that you should get the underlying point of the example; you can't anticipate the exact impairment so you are unable to anticipate the impact of your formatting decisions. If it's easy to extract text, then you should do it once, send it along with the HTML version as a separate MIME part. Many clients do this automatically, but I have a hunch you're sending commercial mail through a bulk mail service (MailChimp, ConstantContact, etc.). A lot of the services will automatically generate and include plain text version along with the HTML version, so it's not a real problem for you. Speaking of hunches, I mean no offense, but for some reason I think you might be somewhat unfamiliar with the format of raw email messages, particularly the MIME specifications? It is entirely possible to have a single email contain both a HTML version of the message and a plain text version of the message in the same email. Plain text mail clients are typically configured to just ignore the HTML version, but the vast majority of email clients (including web mail clients) will render the HTML version. May I ask why you have an aversion to also including a plain text version of your messages?
- eevilspock 14y ago
  No aversion at all. I've read that some receiving mail systems do that automatically, and I've seen this in emails I've received. But I'm not sure if the typical email client, or even a web-based one like Gmail, does that for you. For example I care about typography and want to pick a better font. That goes out as HTML. I don't think any of the clients I use send both the plaintext and HTML as multiparts. I'll take a look.
  - jcr 14y ago
    It seems I omitted the well known problem with HTML-only emails. There are commonly used spam filtering rules (specifically, spam assassin, but also Barracuda Networks and probably a lot of others) where sending HTML-only email adds to the (combined weight) probability of the message being marked as spam. In less pedantic terms, HTML-only counts against you. Depending on the weight given to the rule by the mail admin, the weight can be enough to automatically mark the message as spam (hypothetical kook config), but I haven't seen it weighted that high in practice. As for the generation of multi-part MIME messages, this is usually done by the creator of the email (the sending system/client), but there's a caveat... As a former calligrapher, I understand your love of typography. I know some of the very simple and basic design aspects of using typography for for more effective communication, but I haven't ever really studied it. A lot of the artistic effective design stuff goes over my head. If you do use fonts (typefaces) in your HTML emails, it would be wise to include them as attachments (MIME parts) rather than access them from a remote server. The reason is simple; many HTML email rendering engines in MUA and web based email systems actively thwart "web bugs" in HTML emails. A "web bug" is defined as any means of tracking if an email is opened, including all network traffic generated by accessing remote resources (like font files). If you used a font that resides on a server you controlled, you could track if the email was viewed by the recipient through your log files. If an email message contains "web bugs", the receiving system and/or client might create a defanged version of the message and either replace the MIME part of the problematic version, or alternatively, add a new MIME part to the email that is then used for rendering. Though you might think the defanging of "web bugs" is straight out of kook land, it's entirely real and very wide spread. All modern web mail implementations and local email clients at least try to thwart remote tracking when rendering HTML emails. Sadly, off the top of my head I'm unable to recall if a font file binary can be embedded within the html source as textual data (i.e. like base64 encoding of image data, favicons, etc.), but this might work. If not, you'll need to manually add the fonts as attachments if they aren't automatically attached by your email client/service. In both the attachment and embedded data cases, you're now fighting with the variance of HTML rendering support in browsers or email clients, so testing to see if your fonts will render properly will be a whole lot of work across a whole lot of systems/software. Lastly, as you might imagine, giving away free copies of copyrighted fonts can result in substantial legal nightmares. When picking your fonts, you need to be really careful about the license terms of the fonts you use. With a bit of effort, you can get what you want working on the majority of modern systems, and if you include a plain text version and the required fonts, you can also avoid most of the spam traps and similar problems. Good luck with it!

jcr 14y ago

damn. I really need to be a lot more careful when hypothetically impersonating kooks --it seems I'm better at it than I thought. ;) Unfortunately, the parts you're still missing are commonly missed. Unless you are disabled or have done work assisting disabled people, it's really tough to grasp all the details involved in "accessibility" coding. The most common oversight is not knowing the significant variance in impairments. For example, vision impairments are not binary. It's not a matter of blind, or not blind. There's actually a fairly vast spectrum of disorders under the "vision impairment" category. Again, hypothetically, all you want to do is add some formatting to your email messages to make them look attractive. If a disabled person is unable to see the foreground text color you used against your chosen background color, then they will be unable to read your message. If it is a commercial message, and they can't read your 'unsubscribe' link, you might be in violation of the CAN-SPAM act. --As mentioned before, it doesn't matter if the accusation is true for it to be an expensive pain. Sure, the example is a bit of an over-simplification since people with various color deficiencies can often still read poorly chose colors due to variance in luminance between the background and foreground. None the less, that you should get the underlying point of the example; you can't anticipate the exact impairment so you are unable to anticipate the impact of your formatting decisions. If it's easy to extract text, then you should do it once, send it along with the HTML version as a separate MIME part. Many clients do this automatically, but I have a hunch you're sending commercial mail through a bulk mail service (MailChimp, ConstantContact, etc.). A lot of the services will automatically generate and include plain text version along with the HTML version, so it's not a real problem for you. Speaking of hunches, I mean no offense, but for some reason I think you might be somewhat unfamiliar with the format of raw email messages, particularly the MIME specifications? It is entirely possible to have a single email contain both a HTML version of the message and a plain text version of the message in the same email. Plain text mail clients are typically configured to just ignore the HTML version, but the vast majority of email clients (including web mail clients) will render the HTML version. May I ask why you have an aversion to also including a plain text version of your messages?

eevilspock 14y ago
No aversion at all. I've read that some receiving mail systems do that automatically, and I've seen this in emails I've received. But I'm not sure if the typical email client, or even a web-based one like Gmail, does that for you. For example I care about typography and want to pick a better font. That goes out as HTML. I don't think any of the clients I use send both the plaintext and HTML as multiparts. I'll take a look.
- jcr 14y ago
  It seems I omitted the well known problem with HTML-only emails. There are commonly used spam filtering rules (specifically, spam assassin, but also Barracuda Networks and probably a lot of others) where sending HTML-only email adds to the (combined weight) probability of the message being marked as spam. In less pedantic terms, HTML-only counts against you. Depending on the weight given to the rule by the mail admin, the weight can be enough to automatically mark the message as spam (hypothetical kook config), but I haven't seen it weighted that high in practice. As for the generation of multi-part MIME messages, this is usually done by the creator of the email (the sending system/client), but there's a caveat... As a former calligrapher, I understand your love of typography. I know some of the very simple and basic design aspects of using typography for for more effective communication, but I haven't ever really studied it. A lot of the artistic effective design stuff goes over my head. If you do use fonts (typefaces) in your HTML emails, it would be wise to include them as attachments (MIME parts) rather than access them from a remote server. The reason is simple; many HTML email rendering engines in MUA and web based email systems actively thwart "web bugs" in HTML emails. A "web bug" is defined as any means of tracking if an email is opened, including all network traffic generated by accessing remote resources (like font files). If you used a font that resides on a server you controlled, you could track if the email was viewed by the recipient through your log files. If an email message contains "web bugs", the receiving system and/or client might create a defanged version of the message and either replace the MIME part of the problematic version, or alternatively, add a new MIME part to the email that is then used for rendering. Though you might think the defanging of "web bugs" is straight out of kook land, it's entirely real and very wide spread. All modern web mail implementations and local email clients at least try to thwart remote tracking when rendering HTML emails. Sadly, off the top of my head I'm unable to recall if a font file binary can be embedded within the html source as textual data (i.e. like base64 encoding of image data, favicons, etc.), but this might work. If not, you'll need to manually add the fonts as attachments if they aren't automatically attached by your email client/service. In both the attachment and embedded data cases, you're now fighting with the variance of HTML rendering support in browsers or email clients, so testing to see if your fonts will render properly will be a whole lot of work across a whole lot of systems/software. Lastly, as you might imagine, giving away free copies of copyrighted fonts can result in substantial legal nightmares. When picking your fonts, you need to be really careful about the license terms of the fonts you use. With a bit of effort, you can get what you want working on the majority of modern systems, and if you include a plain text version and the required fonts, you can also avoid most of the spam traps and similar problems. Good luck with it!