`<callout>` element for callouts/alerts/admonitions about html HOT 35 OPEN

Generally agree that this would be nice, but I'd modify the proposal a bit, as currently the proposed use cases for this single element could actually touch on a few different potential roles / potential elements.

for instance, if done "right" now, a warning/alert could be (for example) a role=region, group, alert, or status depending on the type of content it represents (if it's meant to act as a live region or not could be a factor, or the severity of the information presented could determine the role someone were to use - if they aren't just throwing divs around).

if it's a note/example, like what is used in the WHATWG/W3C specs, then role=note would be appropriate (i've actually wanted a 'note' element for awhile now.)

I know it was referenced as one of the 'wrong' things (and likely is misused in a lot of cases) but a "callout" could potentially even be a correctly used blockquote, if it actually represents a quote from another source.

In my opinion, it would be good to have a distinction here (and thus maybe this could be a proposal for 2 elements), rather than considering all the mentioned use cases a single 'callout'.

For instance, if there was a <note> and a <callout> (or <notification>?), then it could make it clear to someone using AT that the first represents additional information, while the second represents important "callouts" that may even need to be acted upon. Having them all under the same implicit role would make this distinction less clear / would prevent the possibility of AT allowing people to navigate to the different content by the type of content. Or in other words, one element for all the different types of callouts could be useful, but if one needed to be more granular, then they'd still just need to reach for the ARIA roles that are more appropriate - or potentially use the new element 'incorrectly' since a better suited ARIA role existed for the use case.

If <note> was added, the cow path of <div class=note>Note: ...</div> could be paved to use an existing role.
For the other scenarios, whatever role is decided upon as the base (an existing role or potentially a 'new' one), regardless of how AT 'could' work with it, it would be a benefit to be able to consistently expose it - so then AT could do whatever they wanted with it, which they can't now due to the variability of implementations which don't even necessarily have any meaningful ARIA semantics to expose.

And then people use the existing elements, styled as they wish, for the remaining use cases that 'could' be 'callouts'.

from html.

@LeaVerou

Wouldn't <callout type="note"> cover the use cases for <note>?

Yes, potentially. That is if using the type attribute to modify the semantics of the element is a desired pathway forward. My understanding/recollection was that when popup was being proposed as an element, that using type to adjust its semantics to match the kind of popover it was meant to be (per its content/use case) wasn't desired. This seems like it'd be similar. But if I was incorrect in my understanding, or that has changed, then sure... one element with types that could modify the visual style and in some cases the ARIA semantics.

...and that a generic <callout> would not be useful? Are there any useful semantics that could apply to <callout> in general? (so they can apply to custom callouts)

If by 'generic' you mean one type of potential role that could be used to apply to all of these / all of these non-note types... eh? That seems like it'd be a miss if that was the desired route and could overlap with existing elements like article or section then.

I did mention some roles that these sorts of callouts could be marked up as in my previous comment. but the callouts that are more 'important' (warnings, errors/alerts, potentially dynamic info messages) could be exposed as status and alert roles (ideally with a way to indicate if they should be treated as an auto-live region, or not). They could potentially repurpose the region or complementary landmark roles (which are already handled by section and aside)... but I personally think it makes more sense for someone to be very mindful about when they use landmarks... the more landmarks that are added to page, the less useful they end up being...

The 'tips, examples and notes' could all arguably be under the note role. They're not as important the draw attention to as the above mentioned types. They generally would not be desired to be live regions, and also not landmarks.

But, going any further down those rabbit holes probably need to have the original question answered, if it's desired for type to change an element's role and thus its potential usage and the type of content that would be expected within it. If type is fine, then we can work this out. If that is not, then it's probably better to go with different elements, and let people style them how they want (which can be similar to each other if they so choose)

from html.

@LeaVerou i had a much longer response to specifically answer/dig into some of your previous comment, but I think maybe that makes more sense to discuss separately, if you want.

Rather, I will respond by saying that, I do appreciate/want this proposal to progress. If type can be used to allow users to determine the semantics, then great. we can work out what each type could be, though there would likely be overlap in the underlying ARIA semantics, and there would need to be clear author guidance as to what would be appropriate for each callout type.

But I think to hopefully address your question about a generic/custom callout - this is where there is exact overlap with popup I mentioned. If there's no known/defined purpose for such content, but it is important to emphasize, is this not just a section or article element that is styled to look like a callout? Potentially even a div with a heading. If roles are based on the type, and then there's a ? for what a generic/custom version looks like - to me that says it's up to the developer to figure that out and potentially reach for the correct element instead and apply styling to that. I mean, the styles that consistently apply to these elements are largely variations of background colors and maybe a border or icon. Not a big LOE to create using the appropriate element.

from html.

The benefits have to be concrete, not speculative, and cannot depend on as-of-yet unrealized downstream inventions. If your new markup idea requires implementation work beyond browsers it will have to be enormously compelling (and likely it isn't).

from html.

Hello everyone :-). Thanks @LeaVerou for the ping, and starting this discussion.

Regarding calling out the callout to assistive technology, I think it's important to demarcate the bounds of the note, so some sort of role is appropriate. However, a document structuring role (such as note or article) that doesn't create a landmark region would be best. Because the callout is an integral part of the text in which it lives, it shouldn't be a separate landmark region, but having the ability to skip over/between them does sound useful. If a document had many notes, and they used landmark roles, that would put a lot of noise into the landmark structure and navigation, as @scottaohara mentioned. Hopefully this helps to answer @domenic's comment on roles.

I wasn't able to find any current info on how well role=note is supported by AT—and it'll be a little while before I could do any serious testing, but maybe others on this thread have.

I'm wondering if we'd want to do anything to indicate the relative importance of the note—e.g. do we want to distinguish between warnings and notes, for example? I imagine that the ARIA WG has discussed this, when they created the note role—we should check out what was discussed there. Also I think @scottaohara's comment about having potentially two elements expands on this.

I also think we should carefully consider @patrickhlauke's point, that there are a lot of ways notes etc. are used, and we should be able to demonstrate that we're making an improvement in a large number of those use cases, particularly for AT users. Maybe we can do some querying of the HTTP Archive to check on common patterns?

tl;dr of my thoughts for now...

• This feels like a neat addition (somewhat in the spirit of HTML5 elements that provide implicit landmarks). We'll need to enumerate and get consensus on some key use cases, and the accessibility benefits. I also wonder if it's something that has come up in OpenUI's developer surveys as a possible area for improving consistency.

• I like @hidde's idea about affording consistent signposting/rendering of certain constructs across sites—in the APA WG's Adapt TF, we are working on a couple of different projects that do this in other areas (one is about bringing AAC symbols to web content—using the symbols set the user knows, and the other is about making navigation around sites easier, by making it more consistent).

• It seems like we have already talked about notes, tips, warnings, and maybe other things. We should check out ARIA WG's past discussions on this (which I'm sure must've happened, and resulted in role=note).

• My feeling is that we should steer clear of potentially overloading landmark regions, or live regions (it feels like there's a risk of confusing DX there), but we should be willing to explore various options. I've not thought too much about type yet, but maybe that is a way to avoid both overloading existing roles, and adding too many new ones.

HTH!

from html.

I find that imagining how screen readers behave can be counterproductive.

from html.

@domenic @patrickhlauke

I will let the a11y experts comment on the specifics of the semantics (@matatk ? @alice?), my understanding is merely that divs are insufficient and blockquotes are flat out wrong, yet these are what is most frequently used right now.

Authors are much more willing to use HTML elements than ARIA as it also provides DX benefits. The default UA styling is merely further motivation (if done well). It seems very clear from the current state of things that asking authors to hand roll it doesn't work well. It's also entirely possible the underlying AT doesn't provide great primitives for callouts — that’s another reason to have an element: the element can be associated with the current state of the art in and once the underlying technology improves, the element semantics can be upgraded transparently, upgrading the web for AT users in one fell swoop, rather than having to painfully educate authors once more.

from html.

I will let the a11y experts comment on the specifics of the semantics

good to know that I don't count as an a11y expert... ;)

from html.

To make @scottaohara's point a bit more concrete, from my perspective this proposal is blocked on explaining the exact accessibility benefits, in the form of ARIA mappings for each potential state of the element. Especially if (as some have suggested) this involves new roles, or modifying AT behavior in a way that goes beyond roles, then that would be a significant lift which we've rarely succeeded with in the past.

The best ARIA mappings I can see right now are just the same as that which section has, so, if people believe a dedicated element is a good idea here, please suggest something better.

from html.

That sounds like you're reducing accessibility to ARIA mappings? Even if those are non existent, distinctions can be helpful beyond AT, including for personalisation, COGA and reader modes, which can all improve accessibility for specific users (sorry for almost
repeating myself), regardless of whether this would go the separate element or type route.

from html.

A new element would require some parser changes (to make it close p elements).

ARIA has a note role, which might be close enough? https://w3c.github.io/aria/#note

from html.

I think it's a good idea to pave a cowpath like this.

However, can you say more about how the proposed element would be an accessibility improvement? /cc @whatwg/a11y

It sounds like you're suggesting it be a sectioning element. Concretely, do you mean that like a <section>-with-a-name, it would map to the region ARIA role? If so, what accessible name would it have?

from html.

If I am reading a text that contains callouts I may read a sentence or two and decide it does not apply to me and skip down to continue reading the main text. Later, I may realize I should have read it and scan up looking at the callouts for the one I skipped. I imagine the equivalent actions for screen readers would be a key combo to exit the current callout to the main text and some means to navigate by callouts.

from html.

Another accessibility benefit of standardised callouts/alerts/admonitions could be (the potential of) personalisation, for cognitive disabilities, and more useful rendering in reader modes.

from html.

i'll admit i'm not quite sure how a proposed <callout> with default (by the sound of it?) styles for warnings etc (which authors will then likely immediately want to override to match their particular look and feel) and slots would be exposed in a sensible way to assistive tech in a way that's better than a hand-rolled section with an accessible name (and an appropriate role which will depend on the nature of the "callout"). maybe it's the "don't need to even hand-roll it anymore" part that is the point here, but i'm not sure how it would be any better for AT unless screen readers also did lots of work implementing and announcing these callouts in a different and more useful way.

from html.

I will let the a11y experts comment on the specifics of the semantics

good to know that I don't count as an a11y expert... ;)

Settle down Patrick ;) I pinged two specific a11y experts because they are or have been on the TAG, as I wanted to capture that particular perspective in the thread (especially since the proposal came out of a convo with one of them). In case it's not obvious, I was not implying that the parentheses in my comment were an exhaustive list of all a11y experts in the world (they’re not even an exhaustive list of the ones I know personally!).

from html.

@scottaohara Wouldn't <callout type="note"> cover the use cases for <note>? Given that these are usually styled in a very similar way, I think there's some value in grouping them under a single element, but it sounds like type should be part of the MVP, and that a generic <callout> would not be useful? Are there any useful semantics that could apply to <callout> in general? (so they can apply to custom callouts)

from html.

@scottaohara
I think with <popup> the issue was that there were no useful semantics without type, which is why I asked if there are any useful semantics for <callout> that has a custom type.

the more landmarks that are added to page, the less useful they end up being...

Agreed. Is there any way to prioritize landmarks? If not, should there be?

The 'tips, examples and notes' could all arguably be under the note role.

Agreed. Though I still think the distinction could be useful for AT users from a UX perspective: I imagine an AT user may choose to e.g. skip tips or examples in a document but may still want to read notes. A sighted user can easily do that as they're styled differently. So perhaps all three could still be using a note role, but announced differently?

For custom callouts, I was envisioning things that are too purpose/domain-specific to be standardized. E.g. in my book I had callouts called "Future" which described future web standards developments. Is there value in these types of callouts using a separate element? Presumably the benefit of AT users being able to skip that kind of content easily still applies?

from html.

This was opened with assertions conveyed from an IRL conversation, but not everyone in that conversation has weighed in with all the potential scenarios / benefits they discussed. That might be useful.

Seeing this construct in print as a sighted reader is often confusing to me because sometimes it is redundant with the content (a visual flair to repeat a particular statement), sometimes a parenthetical thought, sometimes a de facto footnote, and so on.

IMO, <figure> and <blockquote> can already do the lifting on some / most of these. Some of the other artifacts of print design I cited, also IMO, don't warrant landmarks.

To @hidde's question, if we want to expose these in any meaningful way to SR users then ARIA mappings are where to start. COGA SR users would be included in that. Otherwise, can you identify how you think a new element / type might help other users (that are not strictly visual affordances an author could do or undo on their own)?

from html.

Anne said:

The benefits have to be concrete, not speculative, and cannot depend on as-of-yet unrealized downstream inventions.

ok

Adrian said:

Otherwise, can you identify how you think a new element / type might help other users (that are not strictly visual affordances an author could do or undo on their own)?

Helpfulness that I was thinking of would be in that software/plugins could make visual affordances that could be consistent across websites, rather than different everywhere.

But to @annevk's point that is very much not concrete and would require implementation work beyond browsers (except maybe for browser reader mode use case, that's in a browser).

Maybe a comparable case is WCAG's 1.3.5; some also cited personalisation/COGA as the main reason for including it (see John Foliot's reply in this thread. But that too is (arguably) speculative. If speculative is outside of scope here, please do ignore my comment above.

from html.

@aardrian

This was opened with assertions conveyed from an IRL conversation, but not everyone in that conversation has weighed in with all the potential scenarios / benefits they discussed. That might be useful.

I’ve already pinged @matatk to weigh in, though not sure what his availability is.

Re: concrete benefits (beyond what @hidde mentioned, which I agree with):

1. Even if we do conclude that the ARIA roles are the same as what other elements are mapped to, the fact that the UA knows that this is a callout and not a generic section means it can announce the callout label (e.g. "Note", "Warning" etc) in a way that makes it easier to navigate content (I'll let the a11y experts weigh in on what that would be) without the author having to do the heavy lifting to make that happen.
2. The point about future inventions was not to justify the value proposition of <callout>, but as an additional benefit: that IF said future inventions happen, all <callout>s on the web can be automatically upgraded at once.

from html.