Depends a bit on how you're defining responsive.

• Some people might say it's making the email adjust to fit the viewport.
• Some people might say it's making the email adjust to fit the viewport by specifically using @media queries.

Neither is outdated. Neither is "the lazy way out".

It's worth noting that no ESP can or will be able to serve the different versions to the end user depending on if they are using desktop or mobile. Tracking for mobile v's desktop isn't 100% accurate. and just because someone has previously opened on desktop doesn't mean they will never open on mobile.

Also viewport size is more important than the device. You can have a mobile device with a huge screen and a desktop device with a small preview pane both can be adjusted very easily to change the viewport size.

My only guess would be they are talking about having the layout change significantly on smaller viewports rather than just scaling down to fit. But worth clarifying with them to be sure.

Yeah you are right, making everything a link is VERY bad for accessibility and VERY bad for user experience.

Without looking into the full specifics I'll assume that you have a good design with clear CTA's and I'll assume the recipient understands that this is an email and not a banner ad.

Assuming those things then any click that is not on a clear CTA can be categorised as an accidental click. The user was trying to do something else but accidentally triggered a click to the landing page rather than what they were trying to do.

This often leads to the question what were they trying to do...

• double tap to zoom
• tap the scroll
• highlight some text to translate it
• highlight some text to look up the meaning of a word
• highlight some text to copy and paste
• highlight some text to keep place while reading - (I do this one myself)
• highlight some text to run through a text reader I'm sure there are more to add to this list

From a screen reader users point of view all these links will make the content confusing.
The text inside a link should describe the action of the link in a concise way "buy our product" "read more about our product" etc. Having a long paragraph here makes no sense. The screen reader will announce "Link: some text" "Link: some text" "Link: some text" leaving the user wondering what different things those paragraphs and images are linking to.

There is also a shortcut to list all the links on the page that is often used by screen reader users, you can quickly scroll through a list of the links to go to the one you want. If everything is a link then this function is made redundant.

The only possible thing I can think of as a reason in favour from an accessibility point of view is it makes the click area larger. That's fine, you should have a large click area but just make your links bigger, don't break other parts of the accessibility to get this one thing.

Really it depends on how strict you are with your QA. Personally I say yes use them.

I say any <table> that isn't a data table should be a ghost table (wrapped in <!--[if mso]>). This is because some email clients still strip out role attributes, meaning a screen reader will announce the table as in this video https://www.youtube.com/watch?time_continue=13&v=8gAnE1il9QY&feature=emb_logo

Here's an example creating a 600px wide container for your content

<!--[if mso]>
<table width="600" cellspacing="0" cellpadding="0" role="presentation">
  <tr>
    <td>
<![endif]-->
<div style="margin:0 auto; max-width:600px">
  Content
</div>
<!--[if mso]>
    </td>
  </tr>
</table>
<![endif]-->

Hope that helps

There is a write up about this issue in the email bugs repo https://github.com/hteumeuleu/email-bugs/issues/73

Short answer is, the way to avoid this is to not use width attributes (width="600") anywhere in your code, instead use style attributes (style="width:600px")

1:
Yes this is possible but you'll need to change your code structure. You'll need to move all the checkboxes higher up in the code so they come before all the labels.

<input type="checkbox" id="n1">
<input type="checkbox" id="n2">
<input type="checkbox" id="n3">
<input type="checkbox" id="n4">
<input type="checkbox" id="n5">
etc...
<div>
  <label for="n1">1</label>
  <label for="n2">2</label>
  <label for="n3">3</label>
  <label for="n4">4</label>
  <label for="n5">5</label>
  etc...
</div>

Then you can use some CSS to select if any 4 inputs have been checked to hide the labels
input:checked ~ input:checked ~ input:checked ~ input:checked ~ div label{display:none}

2:
Yes, this is also possible wrap a <form method="get" action="https://superemail.com"> around the inputs and add a <button type="submit">Submit</button>. When the user clicks submit it'll pass along the selected numbers. This won't give you the order they were selected in, only the selected numbers. If you want the order as well it's possible but will take a lot more code.

This is pretty standard set up for multi language so strange it's not working. You should always declare a default language so that bit is correct.

Are you using an XHTML doctype? If so you will need xml:lang as well as lang. Although I'd recommend just switching to an HTML5 Doctype if you can.

As well as adding a default lang in the <html> element, it's also good to add an additional one on an element inside the body that wraps all of your content as the <html> element is removed by a number of email clients. Although I'd guess the screen reader test will be done in an environment that doesn't strip any code.

This is the basic set up I'd use

<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
  <div lang="en">
    <p>Some content in english</p>
    <p lang="es">Algún contenido en español</p> <!-- translated by Google translate -->
  </div>
</body>
</html>

Yes is does.
Every character in the file = 1 byte and this include a space.

A new line is actually 2 bytes (something to do with it technically being 2 characters).

So this does add to the overall file size, but as you say, it is much easier to read and write code when it is spaced out nicely.

What a lot of people do is create the code spaced out cleanly like you have it (it's good to save a copy like this too) that then run it through a Minifier that will remove spaces, line breaks and even comments just before sending (also do this before testing as it could affect things). In my experience this can be anything from 10% to 90% saving on file size. https://emailcomb.com is a great tool you can use online for this.

If you find you need to undo the minify and have lost the original version, look for a Beautifier a lot of editing tool have this build in or if not can be added as an extension. This will add new lines and indentation back in and make the code readable again.