- 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.
- 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
Ah right.
In that case I'd recommend these tools
https://wave.webaim.org
https://www.deque.com/axe
I'd recommend this one, it gives a really good break down of the issues end users might have
https://whocanuse.com/?b=ffdddd&c=567000&f=24&s=
It's set to display: block and block element don't respond to text align. Remove that and it should work.
Depends a bit on how you're defining responsive.
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...
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")
Try this...
Following from the code sample I have above you can style the checked label like this
#n1:checked ~ div [for="n1"],
#n2:checked ~ div [for="n2"],
.etc{
background-image:url();
}
Breaking that code down it can be read like this...
#n1:checked the n1 label is checked,
~ div that input is a general sibling of a <div>,
[for="n1"] inside that div is a label for n1 (could use a class or id here instead of the for attribute selector).
For disabling the labels, you could use pointer-events: none, however support for that isn't great.
Another option is to add a span next to each label, use the same class name so they look the same. Then show/hide the label/span depending on if you want it clickable.
<label for="n1" class="foo">1</label><span class="foo">1</span>
<label for="n2" class="foo">2</label><span class="foo">2</span>