macOS - VoiceOver / Chrome announcing visually hidden text out of order

[joe-watkins]

I'm submitting a ...

• bug report
• feature request
• other (Please do not submit support requests here (below))

Steps to reproduce

1. Visit https://codepen.io/joe-watkins/pen/OjpqxL with Safari or Chrome and VoiceOver activated.
2. Tab to each link and listen to how they are announced.

Expected Results

The visually hidden text using HTML5 boilerplate's .visuallyhidden {} will be announced in the order that it is within the markup.

Actual Results

The order of the text is not announced does not match the markup order. Visually hidden text is announced before visible text copy.

Potential fix

After some testing, I've found that using position: relative; and display: inline-block; appears to solve this. e.g.

.visuallyhidden {
	border: 0;
	clip: rect(0 0 0 0);
	clip-path: inset(50%);
	width: 1px;
	height: 1px;
	margin: -1px;
	overflow: hidden;
	padding: 0;
	position: relative; // different - for reading order in macOS VO
	display: inline-block; // new - for reading order in macOS VO
}

SR Tested (works in)

• Win Edge,IE11,FF,Chrome JAWS 18/17
• Win IE11,FF,Chrome NVDA
• macOS Seirra Safari,Chrome,FF VoiceOver

Browsers tested (works - hides text in)

• Win Edge, IE11, IE10, IE9, IE8, FF 53, Chrome 60
• macOS Seirra Safari 10.2, Chrome 60, FF 54

Video screencast of experience

I'd love to get some thoughts on this and I'd be happy to create a PR if everyone is into it :)

[scottaohara]

Doing some additional testing on this and I've identified that it's the negative margin that is specifically to blame for the incorrect reading order.

If you either delete the negative margin or set the margin to zero, the correct reading order is reinstated with no additional change to the rule set needed.

Awesome find @joe-watkins

[roblarsen]

🥇 bug report @joe-watkins

Thanks for bringing this to our attention.

Changes to this class will require a ton of testing (which you've already started 👍) to make sure there are no regressions in other situations. I'd also really like to understand the underlying issue.

[joe-watkins]

@scottaohara Aww interesting -- I'm sure that negative margin is there for a reason... can anyone remember?

@roblarsen tnx! :) Glad to help. Reading order is being affected by visual presentation some how. 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.

But, I'm wondering if it may be advantageous to have less absolutely positioned elements in the DOM? That a perf thing?

It feels silly to attack an Apple bug from this angle but we know how bug submissions and updates go with that camp.

[roblarsen]

@joe-watkins it's an OLD commit relating to issue #194, where there is a LOT of discussion of the original code. I'll dive in a bit later to check it out myself, but there's got to be some reasoning in there.

[scottaohara]

I assumed the negative margin was for legacy browsers (since the linked commit/issue reference ie7), as I have yet to find a situation where it's been useful/needed at all in ie9+ projects.

doing a quick check in ie7/8/9, i'm still trying to find exactly what that margin did... possibly a fall back to negate a stray pixel if the visuallyhidden content had a background color?

[joe-watkins]

@scottaohara Yes, after poking around a bit it looks like it is to combat single pixel appearing.

I wonder if this dark art would be considered:

.visuallyhidden {
  ...
  margin: -1px/9; /* ie8 and below */
  ...
}

[scottaohara]

while i am a fan of the occasional practicing of dark arts, @joe-watkins, the README states it supports ie9+

I haven't seen the pixel in ie9 plus, have you with your testing?

[joe-watkins]

@scottaohara Nor have I seen any issues in IE9... even by giving it a huge width/height and background color. clip is doing the magic with the visibility.

Removal of the negative margin sounds like the fix.

Thoughts?

[roblarsen]

We don't need to worry about old IE anymore, so if we can clean this up with the removal of the negative margin, then that's great. I'd love to see a PR for this. One last bug fix before I ship 6.0.

[roblarsen]

Closed via #1986

[joe-watkins]

Noticed issue persists when a line-height is defined. Continued testing needed.

h5bp/html5-boilerplate#1986 (comment)

[scottaohara]

my comment outlining additional options to rectify the bug

[roblarsen]

BUMMER.

The good news is, removing old IE code is still a valid thing to do these days.

[joe-watkins]

Hey all, so after some fiddling around with the help of @scottaohara in h5bp/html5-boilerplate#1986 we have landed on a solution a bit more like what I originally was thinking with a twist..bringing back the negative margin which helps with visually oddities with focus ring, removing the absolute positioning, and introducing display: inline-block; and things appear to be working well.

I've introduced this snippet into existing projects and things hold up well in all browser/at combinations I can test (mentioned in original post). Reading order in Safari/Chrome/VoiceOver is correct.

It would be great if some others could run this through the ringer:

.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 */
}

[joe-watkins]

As pointed out by @tomasz1986 in h5bp/html5-boilerplate#1986 (comment) the absolute positioning was structural for the clip for old browsers. Recommending removal of that.

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

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

With a green light I could submit a PR for this :)

[roblarsen]

What testing has been done? Is there any missing coverage? I'd like to put together a laundry list of what we've tested in.

[joe-watkins]

Hi @roblarsen below you will find the browsers/AT I've tested the latest CSS with and all is well.

SR/AT Tested (works as expected in)

Win IE11,IE10,FF,Chrome with JAWS 18/17
Win IE11 w/Dragon Naturally Speaking
Win IE11,IE10,FF,Chrome NVDA
macOS Seirra Safari,Chrome,FF VoiceOver
iOS 10 VoiceOver / Safari
Android 7 TalkBack / Chrome

Browsers tested (works - visually hides text in)

Win Edge, IE11, IE10, IE9, IE8, IE6, FF 53, Chrome 60
macOS Seirra Safari 10.2, Chrome 60, FF 54
iOS 10 VO / Safari

[roblarsen]

Thanks @joe-watkins, that's perfect. Let's PR this.

[roblarsen]

closed via #1989

[svinkle]

Bad news: without position: absolute the .visuallyhidden element adds space to the container.

Demo: https://codepen.io/svinkle/pen/LjQJbZ

/cc @joe-watkins @scottaohara @roblarsen

[scottaohara]

(╯°□°）╯︵ ┻━┻

back to work then!

[svinkle]

I mean, you could apply a work-around to the extra space by specifying a container width and height but that's not realistic. 😕

[joe-watkins]

@svinkle Ahh nuts! Looks like a code/whitespace thing: https://codepen.io/joe-watkins/pen/yovRzJ (hmmmff!)

[roblarsen]

This issue is like a see-saw.

[svinkle]

@joe-watkins Interesting…

@roblarsen I might suggest a roll-back on the latest merge until this is sorted. Having extra, visual space is worse than the read order bug, imo.

[joe-watkins]

@scottaohara @roblarsen @constancecchen Ha! This issue rules. I've not considered translation services and aria-labels nor reader mode w/visually hidden text. Love it!

@scottaohara I think we could make an argument for filing bugs with browsers on NOT using display: none for those classes that they think are used for hiding content from screen readers. SR w/Reader mode may be edge case - but accessibility is all about reach!

Firefox styles for reader mode (aboutReader.css):

.moz-reader-content .visually-hidden, .moz-reader-content .visuallyhidden, .moz-reader-content .hidden, .moz-reader-content .invisible, .moz-reader-content .sr-only {
  display: none;
}

Bug created w/FF about maybe respecting visually hidden approaches in Reader

One could probably author a suite of fragile hacks for reader modes that leverage descending selectors.

.visuallyhidden VO reading order fix??

Well here goes another stab at the reading order for Safari/VO. This so far, seems to be working. No extra/funky space in focus outline and reads in order. Changed height definition to em and tweaked margins to .25em -25em. I'll continue to pound at this.. can others take it for a spin?

CodePen using em-based height and em-based margins

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1em; /* new - was 1px */
    margin: .25em -.25em; /* new - was -1px */
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
    white-space: nowrap; /* 1 */
}

[scottaohara]

oh yeah @joe-watkins, i completely agree. filing bugs is by far the way to go.

and per your new CSS setup, I added loads of content to the visually hidden span, and it announced in the appropriate order...so that's a plus and far better than the hack I posted :)

[svinkle]

@joe-watkins Can we change to rem units instead of em in order to size from the root and not the parent container? I haven't tested but seems like a safer route to me.

[joe-watkins]

@svinkle rem could work too. 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.

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1rem; /* new - was 1px */
    margin: .25rem -.25rem; /* new - was -1px */
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
    white-space: nowrap; /* 1 */
}

[afercia]

Having faced this issue in various projects, I'd tend to think the root cause is that Safari + VoiceOver tend to read content "by line", or based on what they consider lines of text. For some reason, CSS positioning comes into play when they decide what a "line of text" is.

I've personally used the same CSS fix in some cases, with good results. Giving the visually hidden element the same approximate height of the line of text it's placed onto certainly helps. In a way, the previous text and the visually hidden text will be considered "on the same line".

However, this fix won't cover all the cases. For example, buttons or other elements containing text might have a height that depends on other CSS properties (explicitly set height, padding, whatever). n my experience, in these cases (see for example the screenshot below) using the 1em/rem fix wouldn't help so much:

It would be very interesting if anyone could test the scenario above, when they have a chance 🙂

[joe-watkins]

@afercia In my experience/testing, the reading order isn't affected when <button> is used in Safari/VO.. now links that look like buttons are a different story :)

So I've created another demo with an assortment of link/buttons that rely on different heights and such. I noticed the little visual offset creep back in w/Safari's focus ring and tweaked the margin to 0 and that helped. I'm not able to get it to break with these examples.. is there another scenario you are referencing? Can you create a demo of it? tnx!

updated w/zero margin

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1rem; /* new - was 1px */
    margin: 0; /* new - was -1px */
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
    white-space: nowrap; /* 1 */
}

[joe-watkins]

In Safari, with the current CSS there is funkiness with the focus ring. It falls out of bounds a bit.

With the new/fix using height: 1rem; & margin: .25rem -.25rem reading order is fixed and the funkiness moves to the bottom of an inline link.

By using height: 1rem; & margin: 0 the focus funkiness is fixed and reading order is fixed in Safari/VO.

But here's the deal, it can be different depending on stuff like resets, Normalize, Bootstrap. The focus funkiness position can be different if using those and I've noticed the height: 1rem; & margin: .25rem -.25rem work best there.

So with margin being a bit squishy what should we set that to? 0 and let authors tweak it? Or base it off popular things like Normalize and set it to .25rem -.25rem?

[afercia]

@joe-watkins well anything that alters the height of a line of text (meaning the line-height) will probably make it fail. For example, see https://codepen.io/afercia/full/YvzPyB/

[mgifford]

Can someone look through the list of all open WebKit accessibility bugs:
https://bugs.webkit.org/buglist.cgi?list_id=625399&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Accessibility&product=WebKit

To see if it is described there or not. If not, please add an issue with:
http://webkit.org/new-ax-bug

Thanks.

[roblarsen]

Also, does someone want to get 100 open source friendship points and document this issue?

[afercia]

This seems related: https://bugs.webkit.org/show_bug.cgi?id=173914
(although it mentions containers with aria-label or aria-labelledby)

[joe-watkins]

@afercia Thanks for putting that demo together.. yes that line height weakness is one that sure makes it fail. I think I've found an approach for that which appears to be holding up... of course I think I've said that 10 times in this thread :) ha! I love a good challenge though.

height: auto; to the rescue.

Initial testing of a clone of your CodePen seems to be doing well. Take a peek.

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: auto; /* new - was 1px */
    margin: 0; /* new - was -1px */
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
    white-space: nowrap; /* 1 */
}

[afercia]

@joe-watkins interesting. Based on a quick initial testing seems to work :) Was curious to understand why height: auto gives the span a full height, which isn't the normal behavior we're used to. Learned something new:

8.3. The height of absolute or fixed positioned, non-replaced elements
https://www.w3.org/TR/css-position-3/#abs-non-replaced-height

If all three of top, height, and bottom are auto: First set any auto values for margin-top and margin-bottom to 0, then set top to the static position, and finally apply rule number three below.

3 ... then the height is based on the Auto heights for block formatting context roots, and solve for bottom.

8.5. Auto heights for block formatting context roots
https://www.w3.org/TR/css-position-3/#root-height

If it only has inline-level children, the height is the distance between the top of the topmost line box and the bottom of the bottommost line box.

Aside: unrelated, but was thinking that any method that uses absolute positioning won't work when the container is a flex container. Absolutely-positioned flex children behave in a different way and VoiceOver will read out the hidden text first. 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)

[joe-watkins]

@afercia Ha nice finds and makes sense -- especially 8.3 as I was fiddling around with transforms at one point and adding backgrounds to the element and was surprised to see it span the height of the box. Thanks for surfacing those!

Yes, I've been thinking about flex and grid and wonder if we should be attacking from the parent since we can't drive up the tree with CSS really. One could almost write a visually hidden framework - ha!

I've battled the Flex parent issue with position: relative; on the parent, added .has-flex-parent to the .visuallyhidden element and used right: 0; on the hidden element and VO appears to reads in order. Not ideal, but in this case works. Definitely a case-by-case thing with newer CSS technologies.

View the CodePen demo battling a Flex parent

In related good news, I've learned that in flex/grid scenarios, visually hidden elements that are grandchildren of Flex parents and Grid parents announce in order w/VO+Safari when using the my latest chunk of .visuallyhidden CSS.

Flexbox demo with grandchildren
CSS Grid demo with grandchildren

[NickColley]

Hey everyone,

I've been doing some investigation into this since we ran into the same issue on the GOV.UK Design System.

I have written up the results of an audit I've done here: https://gist.github.com/nickcolley/19b80ed24d0364cfd3afd3b1b49c4014

Conclusion

We should update the govuk-visually-hidden class to remove the negative margin which will fix the ordering issue in VoiceOver for OSX.

We should recommend using aria-label or aria-labelledby where it makes sense to.

Visually hidden CSS can result in text not being read out when touching on iOS, this is regrettable but does not cause a hard barrier as users can explore the surrounding content to understand context.

The funkiness with the outline ring which seems to a blocker here is only seen in OSX Safari when you are using the user-agent outline styles.

Since we set an outline style this is not an issue for us. I think we could make the assumption that most people will style their outlines instead of using the default.

So we could update the class here to have the improved announcement for screen readers with the rendering issue and add some guidance that explains the need to style your own outlines (which is good practice regardless).

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: 0;
  padding: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  -webkit-clip-path: inset(50%);
          clip-path: inset(50%);
  border: 0;
  white-space: nowrap;
}

Hope this is helpful, thanks for your help!

Nick

[afercia]

We're facing an issue with flex items, where:

• a button has display: inline-flex
• the screen reader text within the button is placed differently across browsers
• specifically, Chrome places the screen reader text before the content and this doesn't seem correct to me: in absence of left/right/top/bottom values, an absolutely positioned element should stay in its original position

For more details: WordPress/gutenberg#13221 (comment). In the past, there have been several inconsistencies across browsers regarding absolutely positioned flex items. I'd greatly appreciate feedback from all the experts here 🙂 can this issue be considered a Chrome bug?

[xiongemi]

I got this similar issue on my current team project.
We changed the styles to be

border: 0;
  height: 0;
  width: 0;
  margin: 0;
  padding: 0;
  font-size: 0;
  overflow: hidden;
  white-space: nowrap;
  position: relative;
  float: left;

It seems to work for styling for latest chrome, safari, firefox, IE edge. However, not sure how backwards compatable is that.

[joe-watkins]

Related bug:
https://bugs.webkit.org/show_bug.cgi?id=182881

[bagewadi-akram]

...