Definitely a case-by-case thing with newer CSS technologies.

Very odd. It sure would be less heavy handed to look at the margin declaration per scottaohara s finds rather than changing position and adding display.

Ill dive in a bit later to check it out myself, but theres got to be some reasoning in there.

By removing the negative margin, and setting it to margin: 0;, the issue is resolved.

But, this is the only thing Ive come up with that negates the reordering while also taking your comments about internationalization into account.

Now it can be translated and since theres no breaks in the text, it will be read as intended.

Re-show it with CSS undoing the attributes default display none.

This is done specifically for no CSS situations (e.g.

Read more Read more about.

Safari seems to target sr-only content and simply doesnt carry it over into their reader mode version of the document at all.

Ive not considered translation services and aria-labels nor reader mode wvisually hidden text.

Love it.

SR wReader mode may be edge case - but accessibility is all about reach.

Changed height definition to em and tweaked margins to.25em -25em.

Ill continue to pound at this.

I was leaning em for wider browser support but I just tried IE6 and everything looks great.

Updated to rem. Need to test some rwd typography size changes on root to make sure Safari VO behaves.

Giving the visually hidden element the same approximate height of the line of text its placed onto certainly helps.

In a way, the previous text and the visually hidden text will be considered on the same line.

For example, buttons or other elements containing text might have a height that depends on other CSS properties (explicitly set height, padding, whatever).

I noticed the little visual offset creep back in wSafaris focus ring and tweaked the margin to 0 and that helped.

The focus funkiness position can be different if using those and Ive noticed the height: 1rem; margin:.25rem -.25rem work best there.

I think Ive found an approach for that which appears to be holding up.

Based on a quick initial testing seems to work:) Was curious to understand why height: auto gives the span a full height, which isnt the normal behavior were used to.

The only way to fix that I can think of would be not using absolute positioning at all, for example using clip-path (alas not supported in Microsoft Edge).

Css Hack For Mac Chrome Only