Something like the hidden attribute but still mapped to the accessibility API

[jonathantneal]

I want to semantically express when an element is not yet, or is no longer, directly relevant to the page’s visual presentation or layout. This means that, although the element has no perceivable visual impact on the page, its implicit native role semantics are still mapped to the accessibility API.

I see no way to currently express this with pure web standards, and I think all developers would benefit from such a feature.

A situations where an author would reach for a way to “visually hide” a thing is when visual information and visual cues need to be conveyed to non-visual users:

<p class="text-danger">
  <span class="sr-only">Danger: </span>
  This action is not reversible
</p>

— From Bootstrap: Accessibility

Another situation would be to visually obscure “Skip to content” links until they receive focus.

<a class="sr-only sr-only-focusable" href="#content">Skip to main content</a>

— From Bootstrap: Accessibility

There is a [hidden] attribute to indicate when an element “is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user.” However, this attribute is insufficient because it unmaps native role semantics from the accessibility API.

Presently, the most common strategy used by authors to obscure elements from appearing or contributing to layout involves class names mapped to CSS declarations that accomplish the presentational effect without unmapping the element from the accessibility API.

I’m not sure if what I’m asking for is best solved by an HTML spec, an ARIA spec, or a CSS spec. However, what I’m asking for seems most similar to [hidden], and so I am starting here.

[Yay295]

This sounds like a good place to use aria-hidden=false, except it's explicitly not a supported argument. https://www.w3.org/WAI/PF/aria/states_and_properties#aria-hidden

[jimmyfrasche]

I've been trying to track all the threads for adding similar to CSS recently. As far as I can tell, the most recent discussion, with links to some previous discussions, is w3c/css-a11y#13

Whatever the solution, something like this is certainly something missing from the platform.

[annevk]

This does seem like a semantic of sorts that's best conveyed in markup.

cc @whatwg/a11y

[patrickhlauke]

in essence, something like the opposite of inert https://github.com/WICG/inert/blob/master/README.md - a standardised way to visually hide but keep accessible certain content (and assuming that this also intends to keep things focusable and interactive, and that the author would then make sure that at least when there are interactive elements, they are made visible again once focused - e.g. by a sighted keyboard user - as otherwise this would create accessibility black holes where focus just disappears into the void and users are focused/can interact with something that is simply not displayed)

(with some context that this goes around the lengthy to-ing and fro-ing we had on twitter yesterday https://twitter.com/jon_neal/status/1128260090019106820)

[alice]

I have a few disconnected thoughts:

• In general, I agree with the guidance given in the excellent WebAIM "Invisible Content" article:

  In most cases, if content (particularly content that provides functionality or interactivity) is important enough to provide to screen reader users, it should probably be made available to all users. Cases where verbose cues or instructions are provided only for screen reader users are most likely a reflection of poor design and accessibility.

  Any solution should keep this in mind. (The article does go on to explain that there are valid cases for using these techniques, of course.)

• Obviously, skip links should only be non-visible while they are unfocused, as the OP notes, and thus do need to be available for page focus for non-AT users.

• Relatedly, this makes me question the goal of "not contributing to layout". Would this be better stated as "not affecting the layout of other elements"?

• For non-interactive content, virtual AccessibleNodes may eventually provide a solution. However, as currently conceived they are not Elements or even Nodes, and can't be added via markup.

• For interactive content which is never intended to be visually presented, we need to be mindful that we are not tacitly encouraging assistive technology detection.

[LJWatson]

I'm not convinced by the use cases (so far).

The need to provide information only for screen reader users is much less common than people think. The information is almost always useful to more people than is first thought.

That aside, the first use case could be met like this:

<p role="note" aria-roledescription="Warning: " class="text-danger">
  This action is not reversible
</p>

The skip link use case seems to be a visual use case, not an accessibility API use case? Whether it is visible or not is irrelevant to most screen reader users, and whether it's exposed to the acc API is irrelevant to its visual state, so I'm not sure what this use case is trying for.

[patrickhlauke]

discussing this a bit more with @IanPouncey he made an excellent point that the "this element should be visually hidden, but remain accessible" aspect is probably more a presentational, rather than purely semantic, issue - so perhaps something more suited to a very declarative CSS way of saying it. the problem, as i see it, with the various sr-only approaches is that we've had to jump through so many weird hoops to achieve the hiding without triggering odd browser/AT heuristics, or inconsistencies, or side effects.

of course, getting a nice clean CSS way to say "this should be visually hidden, not affect layout (so not visibility:hidden or opacity:0 or similar), but remain accessible / exposed in the DOM and accessibility tree / focusable" still won't solve @jonathantneal's other desire to have some non-classname based CSS selector to hang this off of. i suspect this is part of the issue...there's two things at work here: a desire to actually do the visual but accessible hiding consistently and without hacks, but also a desire to then be able to very generically target it with some CSS selector. but i don't think spec'ing a new attribute just for the latter is the best solution, particularly when this indeed does skirt the line between being semantic and being just a style/layout/presentational issue.

[scottaohara]

Agree with many of the points above. Especially Alice's mention of:

Relatedly, this makes me question the goal of "not contributing to layout". ...

There are already many ways to visually hide content with CSS, whether that be opacity: 0, color: transparent (useful if you need a message to appear in Windows High Contrast Mode), or a combination of properties that can hide and/or remove the content from being visually rendered.

However, depending on the type of content that needs to be hidden, and how accessible it should remain to different input types, should dictate to an author the method they employ to visually hide said content.

I worry that a proposal to make an element accessible but not contribute to the document's layout would just perpetuate usability issues with current visually hidden techniques. For instance, the mentioned .sr-only ruleset that essentially hides content as an invisible 1px, absolute position square (e.g. not contributing to layout), which can have selector conditionals to reveal itself again on focus.

This ruleset works well in the context of a device with a keyboard and standard focus and blur events, but can pose problematic on devices where one may not be able to "focus" (e.g. VoiceOver's focus indicator does not initially fire a focus event, so content remains visually hidden). Additionally, attempting to find such content (being a 1px invisible square n' all) can also pose problems if someone is exploring by touch on their device, rather than sequentially swiping through content with the aid of a screen reader. Issues like this are prevalent when people attempt to visually hide a form control, and replace it with a faux control. Low vision users who may be using a screen reader for assistance may attempt to touch or drag their finger to find the element that is visually represented, but encounter difficulty because the true control is only discoverable if they swipe through the interface.

The alternative to all of this is a solution where an element (and any children) are visually hidden but are not removed from contributing to the document's layout... but then we're just talking about opacity: 0.

I have many more thoughts on this topic, but I think it's important to note @LJWatson's response as well as @alice's quoting of the WebAIM article. Visually hidden content is more often a solution for developers to solve a design or UX issue, than it is an actual benefit to end users. Comparing this ask to the hidden attribute overlooks the fact that hidden provides the same experience to everyone. Making something like this a standard purposefully creates a divide in end user experiences. I find that to be problematic.

[travisleithead]

CC @atanassov & @melanierichards

[herrernst]

@LJWatson

I'm not convinced by the use cases (so far).

The need to provide information only for screen reader users is much less common than people think. The information is almost always useful to more people than is first thought.

I understand that it would be better never to hide content visually, but it's just not the reality. Even you wrote an article for the accessibility blog on gov.uk, where the class .visuallyhidden, which hides content except for screen readers, is used 22 times:

Also gov.uk itself, a site with probably high a11y ambitions, uses a similar class a lot (with all its associated code smell and risk of future breakage):

Thanks for the tip about aria-roledescription, but I have not found much real world usage and also no information about browser/SR support.

Could all these use cases e.g. on gov.uk really be solved without some kind of .visuallyhidden workaround? If yes, this would need massive education even for CSS framework authors (Boostrap, Tailwind, etc.) and a11y experts (who often propose .visuallyhidden as best choice for invisible content, even for simpler cases where e.g. aria-label could be used). If not, a "native"/standardized solution would be much appreciated.

Thanks.

[patrickhlauke]

and as @herrernst posted those screenshots without appropriate alternative text (which did make me chuckle in this discussion...)

first one is a <span class="visuallyhidden">Posted on</span> preceding the date for the blog post on the gov.uk blog.

the second one is an <h2 ... class="govuk-visually-hidden">Services and information</h2> heading on the gov.uk homepage

[herrernst]

@patrickhlauke Sorry, I noticed my mistake and wanted to correct it, thank you for doing it 😅

[patrickhlauke]

fwiw, as i had forgotten about this discussion for a while...i think i still have the same view here as back last year #4623 (comment)

[LJWatson]

@herrernst

I understand that it would be better never to hide content visually, but it's just not the reality.>

I think perhaps you misread my comment. I said the "need is much less common than people think", not that it's never warranted. The quote from WebAIM in the comment from @sundress is a good description of the situation:

In most cases, if content (particularly content that provides functionality or interactivity) is important enough to provide to screen reader users, it
should probably be made available to all users. Cases where verbose cues or instructions are provided only for screen reader users are most likely a reflection
of poor design and accessibility.>

But note that it says "most cases" not "all cases.

Even you wrote an article for the accessibility blog
on gov.uk, where the class .visuallyhidden, which hides content except for screen readers, is used 22 times>

I'm not sure how this is relevant. I write a lot of things in places where accessibility is either out of my control, could be done differently, or both - including this issue we're commenting on.

Could all these use cases e.g. on gov.uk really be solved without some kind of .visuallyhidden workaround?>

I don't know because I haven't looked at all of them, but arguably many of the uses on that blog post are unnecessary.

I don't think that phrases like "Posted by" and "Posted on" need to be explicitly indicated. The pattern of identifying the author and date of a post based on the proximity of that information to the heading and/or article tagline is well enough understood to make it unnecessary. See the Guardian and Wired for a couple of examples. If there is a need to indicate that information then doing it in ways that make it part of the design is entirely possible. See the New York Times for an example.

The "Sharing and comments" heading could be replaced by <section aria-label="Sharing and comments">...</section, which would fulfill the same navigational and informational purposes as the hidden heading. There really isn't a need for either this or the heading though, since the visible headings that follow it ("Share this page" and "7 comments") do the job more than adequately.

Including words like "Comment" and "Replies" just add verbal noise to the page. The fact they're comments is clear from the context provided by the preceding heading, and the relationship between comments and replies is provided through the nested lists.

To flip your question around, what are the cases on Gov.UK or elsewhere you think can't be solved through other means?

[herrernst]

Dear @LJWatson, thanks for your explanation, and sorry if I have sounded rude. Labeling sections (when necessary) makes sense.
Another example (not on gov.uk) I've stumbled upon lately is replacing/"augmenting" text which seems self-explanatory for sighted users but maybe needs more information for users with AT, like this info about pagination:

<div>
  <span class="sr-only">Subpage 1 of 3</span>
  <span aria-hidden="true">1/3</span>
</div>

Is there any alternative except a kind of visually-hidden class? Thanks for your patience.