You could try @supports (position:absolute){}
Or something like this (may have more support but I'm not sure), set the elements in the HTML but hide them
<div style="position:absolute:display:none"></div>
Then target that with CSS and it'll only display them if the position hasn't been removed. And add more styles you might want there.
[ style="position:absolute:display:none"]{display:block !important;}
Try applying the class to a <div> rather than a <td>.
Yahoo is probably adding something to the table to mess it up table {width: auto !important;} maybe.
The class is on the <p> tag but you're trying to change the <a> color. You could either move the class on to the <a> or change the selector to target the <a>
.links-read a:hover { color: #4471c3 !important; }
Generally the advice is don't use aria, use semantic code instead. Unfortunately that's not always possible, so to fill the gaps we can use aria.
I'd suggest listening to your email with a screen reader (this in itself is a skill and can take a while to get used to) if anything doesn't make sense, first off try and fix it with regular text, if that's not possible you can use some aria.
Think of using the screen reader as a way of proofreading your content. i also think this should be part of everyone's QA process.
The majority of emails shouldn't need anything added, and it's always best to be sparing with it.
From our testing all those units you've listed px, pt, em, % all work across the board.
From an accessibility point of view em or % would be best as they would scale with the user settings where px and pt do not.
The only issue with em and % is they are based on the parent font-size so could cause issue if used with a nested component build system.
In this case rem would be better as that is only relative to the root font-size. Unfortunately rem doesn't work in mso Outlooks but you can define a px fallback quite easily font-size:16px;font-size:1rem.
Hope that helps.
Yeah we've used aria attributes a fair bit. I'd say use them exactly how you would for the web however be aware that they will get stripped out in some email clients so don't rely on them. I believe Yahoo, AOL, GMX, Web.de all remove aria attributes, Outlook.com recently added support which is great.
Also when using things like aria-labelledby and aria-describedby that rely on a matching ID, a lot of email clients will prefix the ID but not the aria so they will no longer match up.
No seen any docs on it but I did a few tests a while ago and it picks up, subject, from, and text in the body and alt text.
But not any aria- attributes, I though aria-label might show up but it didn't.
There are a number of browser plugins available that block pixel tracking, often these are bundled as part of a larger Ad Block plugin. That could be what's causing the issue on the webmail clients.