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