Elements that use .visually-hidden and .focusable aren’t read when using VoiceOver in iOS or in Chrome

HTML Boilerplate also has position: static; in it, so is this a new pattern?

.visuallyhidden.focusable:active,
.visuallyhidden.focusable:focus {
clip: auto;
height: auto;
margin: 0;
overflow: visible;
position: static;
width: auto;
}

skip-link.css has the focusable element defined, but it isn't static, but rather position: static. I'm just trying to get some clarification here:
.skip-link.visually-hidden.focusable:focus {
position: absolute !important;
}

Which version of iOS is this?

Needs re-roll.

Re-rolled with 8.2.x-dev

Thanks for the re-roll. I'd argue thought hat this should stay in 8.0 rather than bumping it up to 8.2.

If this is a bug fix, presumably it's still a candidate for an 8.1.x maintenance release

After the patch in #3, the rule for .visually-hidden looks like this:

/**
 * Hide elements visually, but keep them available for screen readers.
 *
 * Used for information required for screen reader users to understand and use
 * the site where visual display is undesirable. Information provided in this
 * manner should be kept concise, to avoid unnecessary burden on the user.
 * "!important" is used to prevent unintentional overrides.
 */
.visually-hidden {
  position: absolute !important;
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

Feedback:

• The position property is declared twice; this needs clean-up.
• The !important keyword is used the first time position is declared, but not the second time. What's the intention - do we keep the important keyword? The (existing) comment says we want the important keyword to avoid accidental overrides.

Updated with the above changes.

We need to have some testing in AT before we can mark this RTBC.

Agreed, it's about specific browser/AT combinations. Do we know if this problem is documented elsewhere, perhaps in HTML5 boilerplate's issue history?

I don't have ready access to a Mac or iOS device. I can test in ChromeVox and NVDA, but that only guards against regressions. We need the Mac + iOS tests to confirm it actually makes things better.

Tagging in case someone can pick it up at the New Orleans sprints.

Failing that I'll go and bother some Mac owners at a local tech meet-up ;-)

I've just tried this with voiceover on both iPhone (safari and chrome) and Mac (chrome) using 8.2.x without applying the patch and the skip links are read on both devices.

Has the problem been independently fixed in Bartek and Stark?

Looking at the patch and knowing the history of this issue, I wouldn't think that there were any changes to Bartik, Classy, Seven Stable or Stark.

But we can check if .visually-hidden or .visually-hidden.focusable:active / .visually-hidden.focusable:focus in core/modules/system/css/components/hidden.module.css is over-ruled in the other Core themes we should be fine.

Unfortunately it seems to be, so yes this will have to be checked on other themes:

$ grep -ir visually-hidden * | grep css
bartik/css/components/header.css: /* @extend .visually-hidden */
bartik/css/components/skip-link.css:.skip-link.visually-hidden.focusable:focus {
seven/css/components/skip-link.css:.skip-link.visually-hidden.focusable:focus {
stable/css/system/components/hidden.module.css:.visually-hidden {
stable/css/system/components/hidden.module.css: * The .focusable class extends the .visually-hidden class to allow
stable/css/system/components/hidden.module.css:.visually-hidden.focusable:active,
stable/css/system/components/hidden.module.css:.visually-hidden.focusable:focus {

I closed mine duplicated issue. COPY MY WORD:

FYI: There's an issue thread for more better accessibility on this CLASS. Probably we should update it together at once.

[macOS - VoiceOver / Chrome announcing visually hidden text out of order]
https://github.com/h5bp/html5-boilerplate/issues/1985

changing issue tag to a more accurate name, got some others with this tag already

The earlier patches fail to apply, so I had a go at updating this, and it's such a rabbit hole!

Since we copied HTML5 Boilerplate's lead I started there, their approach has changed since Drupal copied it I believe, but there's also this issue with their approach resulting in content being updated in the wrong order: https://github.com/h5bp/main.css/issues/12. I'm not sure if their updated approach fixes this specific Voiceover issue or not?

Someone from the GOV.UK development team in the United Kingdom made a big comparison of hiding text methods, but it includes lots of non-CSS approaches so is only partially relevant: https://gist.github.com/nickcolley/19b80ed24d0364cfd3afd3b1b49c4014

Bootstrap have recently released v5 and they have updated their approach here: https://github.com/twbs/bootstrap/blob/main/scss/mixins/_visually-hidden... ………

The list goes on!

I eventually gave up and decided to stick with whatever HTML5 Boilerplate is using, in the spirit of Drupal's original decision.

Attached is a patch that brings the Drupal implementation inline with the latest HTML5 Boilerplate implementation from https://github.com/h5bp/main.css/blob/master/src/_helpers.css#L14-L51.

There is still the issue of themes having their own implementations - this patch just targets core/themes/stable/css/system/components/hidden.module.css.

needs more eyes on it

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

We really should fix this!

This could possibly fall under a few SC, but I'm putting it under https://www.w3.org/WAI/WCAG21/Understanding/name-role-value

I'm not experiencing any problems with Apple VoiceOver. Skip link is being read.

MacBook Pro Sonoma 14.1
Drupal version 11.0-dev

Private windows opened in:
Google Chrome: Version 119.0.6045.199
Firefox: 120.0.1 (for this I used Chris Pederick's Web Developer tools simulator for iOS 12/13, Pro max IOS 114.6)

tried to reproduce it but as comment #29 mentioned and for me also the voice over issue i am not facing it tried on chrome and safari for ios and for desktop too.

This might be outdated, per #29 and #30.

IIRC, I haven't experienced this recently with VO on MacOS, but I will double-check.

I'm not experiencing the problem with VoiceOver on:

• main branch, Microsoft Edge, MacOS 14.8.7. Edge is based on Chromium, as is Chrome.
• 11.4.0-beta1, physical iPhone 16, iOS 26.5

Tested:

• Stark.
• Olivero.
• Claro.
• Default Admin.

Feel free to reopen if new cases are found.