Repository navigation
macOS - VoiceOver / Chrome announcing visually hidden text out of order #12
Description
Activity
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
Reacted by Trevor Pierce, Joey Hoer and 0ri0n🥇 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.
@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
margindeclaration per @scottaohara
's finds rather than changingpositionand addingdisplay.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.
@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.
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?
@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 */ ... }
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?
@scottaohara Nor have I seen any issues in IE9... even by giving it a huge width/height and background color.
clipis doing the magic with the visibility.Removal of the negative margin sounds like the fix.
Thoughts?
Reacted by Scott O'HaraWe 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.
Reacted by Scott O'Hara- added a commit that references this issue
on Aug 12, 2017 Closed via #1986
Noticed issue persists when a
line-heightis defined. Continued testing needed.Reacted by Scott O'Hara66 remaining items
@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-parentto the.visuallyhiddenelement and usedright: 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
.visuallyhiddenCSS.Flexbox demo with grandchildren
CSS Grid demo with grandchildrenReacted by Scott O'Hara- added 2 commits that reference this issue
on Jun 12, 2018 - added a commit that references this issue
on Sep 1, 2018 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
Reacted by Elizabeth Schafer, Rob Larsen, Cee Chen, Sophie Schneider and Ted WhiteheadWe'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?
- a button has
I got this similar issue on my current team project.
We changed the styles to beborder: 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.
Related bug:
https://bugs.webkit.org/show_bug.cgi?id=182881- added a commit that references this issue
on Sep 2, 2020 - added a commit that references this issue
on Oct 13, 2020 ...
Is this still an issue? We are unable to replicate on the latest versions of FF, Chrome and Safari using VoiceOver on MacOS 13.2.1. The original codepen reads out in the correct order as does the markup in our internal testing. We are using the following CSS:
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
white-space: nowrap;Reacted by shch and Dylan James Wagner@singhpaul I hadn't checked in on this is a while, so I'm not sure. I would love to close this issue. It's only been open for 6 years 😂
It's my first day here
Hope to find something goodReacted by Bunnie4242
I'm submitting a ...
Steps to reproduce
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;anddisplay: inline-block;appears to solve this. e.g.SR Tested (works in)
Browsers tested (works - hides text in)
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 :)