Fix Bug: .visuallyhidden on macOS VO

[scottaohara]

This PR solves issue 1985: macOS - VoiceOver / Chrome announcing visually hidden text out of order

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

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[joe-watkins]

@scottaohara arg! I'm able to replicate the reading order bug with a line-height defined on the body. I was excited to put the new visually hidden CSS into action on a project and it still didn't help with reading order.

This makes a bit of sense as to why my initial 'fix' helped as it kept the text inline. It seems like if the text falls outside of some little box the browser is making for the type it affects reading order.

I'm continuing testing on this today. Check out this pen -- if you move the line-height below 1.3 it works. What the?

https://codepen.io/joe-watkins/pen/GvMyVR

[scottaohara]

well this is incredibly frustrating.

i'll spend some time hammering on this as well

also, it's not working for me w/the line-height below 1.3?

[scottaohara]

OK, @joe-watkins

Here's the markup I've been using (based on your markup, with extra text appearing after the VH-text)

<a href="/some-cool-page" target="_blank">
  I am a link with visually hidden text<span class="visuallyhidden2">, 
opens in a new window</span> more content to come after v.h.text
</a>

I've been able to modify the ruleset in the following ways to correct the reading order:

1. remove the height property. Doing this will result in the correct reading order, but creates a "bump" in the focus indicator, as displayed in the following screen shot:
   

.visuallyhidden-no-height {
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    overflow: hidden;
    width: 1px;
    position: absolute;
    white-space: nowrap;
}

2. Alternatively, the height can be left in tact, and instead the position: absolute; can be removed, and a display: inline-block; can be added. This could work in situations where content ends with a block of visually hidden text, but in the example I made, where the vh-text appears in the middle of a sentence/link, there's a subtle gap of where the vh-text lives, caused by the removal of position: absolute;

.visuallyhidden-no-absolute {
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    overflow: hidden;
    width: 1px;
    height: 1px;
    // position: absolute;
     display: inline-block;
    white-space: nowrap;
}

3. Going back to the first option, if a larger height value is set (i got it to work with 5%, but I'd submit better safe than sorry, so at minimum 20%). and the parent of the visuallyhidden text has a position: relative; set, then the bump in the focus indicator won't appear.

.visuallyhidden-with-height {
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    overflow: hidden;
    width: 1px;
    height: 20%;
    top: 0;
    position: absolute;
    white-space: nowrap;
}

Additionally, I found no issues with reading order when the original visually hidden text class was used with non-interactive text (e.g. paragraphs, lists and a heading, as in the above screen shot)

So those are the 'fixes' I've identified for now....personally I'm partial to number 3, but think number 1 would require the least amount of effort.

Thanks for continuing to test this, Joe.

[joe-watkins]

With the current CSS I also noticed that in Safari the focus ring appears a bit out-of-whack.. you can 'see' the visually hidden text in a way.

Oddly, I've had some success by adding display: flex; - continued visual weirdness with focus ring, only it moves to the bottom.

Adding top: 50%; actually worked a bit as well but created a giant focus box in VO/Safari.

@scottaohara I'm partial to #3 as well but feel like defining a percentage to anything may be brittle in certain scenarios.. who knows.

I'm more partial to my original recommendation to setting the positioning to relative, which will allow for text to be anywhere in the content, and display of inline block. I can't get this to break!

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    display: inline-block; /* new */
    height: 1px;
    margin: 0;
    overflow: hidden;
    padding: 0;
    position: relative; /* relative instead of absolute */
    width: 1px;
    white-space: nowrap; /* 1 */
}

Code demo:
https://codepen.io/joe-watkins/pen/zdEWRv

[scottaohara]

@joe-watkins the original demo also has a break in an underline if you include additional text after the visuallyhidden text :(

subtle, but it'll drive all those 'pixel perfect' perfectionists crazy ;)

shrug....maybe it's not that big of a deal for the break to be there? i'm more interested in the text reading correctly than i am with the link underline staying fully intact.

i guess another question to ask, is this actually a VO bug?

[joe-watkins]

@scottaohara Ha! Adding the old negative margin fixes the visual glitch on the underline. Leaving us with:

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    display: inline-block; /* new */
    height: 1px;
    margin: -1px; /* back to life */
    overflow: hidden;
    padding: 0;
    position: relative; /* relative instead of absolute */
    width: 1px;
    white-space: nowrap; /* 1 */
}

I've been testing this pen with good results. I don't have an IE7/6 VM but holds up in 8/9 visually and JAWS/NVDA/VO doing well with modern browsers.

https://codepen.io/joe-watkins/pen/rzGrWX

Insert Family Guy CSS meme here :)

[scottaohara]

nice @joe-watkins. not going to lie, i feel pretty silly right now since we're mostly back to your original suggestion. sorry to send us in a circle :(

I just tested your codepen link and saw that position: absolute; was still in there. instead of adding relative, i just took the property away, and didn't seem to have any adverse affects. is it needed for JAWS/NVDA IE? I only have voice over presently so i can't test those right now.

[joe-watkins]

@scottaohara Ha good catch.. copy/paste craziness got me there. You are correct,.. removing the position things still hold up. I believe the absolute positioning was for clip support in older browsers.

No worries with driving in circles -- that's all web development is :) This leaves us with:

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    clip-path: inset(50%);
    display: inline-block;
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    width: 1px;
    white-space: nowrap; /* 1 */
}

I'll plop this into a couple projects and see if I can break something.

[scottaohara]

nice work @joe-watkins :)

[joe-watkins]

@scottaohara tnx! you too! Looks like this new CSS also works with .visuallyhidden.focusable:active,.visuallyhidden.focusable:focus {} which is good.

I'll take our findings back to the main issue to get more thoughts ;)

[tomasz1986]

There is no point in using clip: rect(0 0 0 0) without position: absolute.

[joe-watkins]

@tomasz1986 tnx! I wondered about that. I guess in super old browsers visually things may break w/out any targeting.

[tomasz1986]

It is not really about super old browsers. clip was supposed to be replaced by clip-path but support for it is still very spotty/experimental at best.

http://caniuse.com/css-clip-path

On the other hand, clip works in everything starting from IE 4.