Theming options

[jackbsteinberg]

Themes are a common pattern with toasts, and the intention is to build some themes into the std-toast. A non-exhaustive list of current ideas for themes:

• Default (Info)
• Success
• Warning
• Error

Is there strong feeling that this doesn't cover it? Do people feel a distinction between Default and Info? Additionally, while these will be built to be styled, is there strong opinion that there should be a way to add new themes beyond existing support for styling?

[domenic]

My take is that we should have themes for semantically distinct categories of toast, which might affect the behavior. (For example, for accessibility technology, it's possible we may want warning and error to be more interruptive than default or success.) There should be some default styling for each theme, but the main point of a theme is to communicate categories and intent, not to create styling.

So, specifically toward the last question, I don't think allowing user-supplied themes is important, since we already intend to support user-supplied styles. If there are more interesting semantic categories of toasts, then we should standardize them as a common vocabulary everyone should use, and not have per-application themes.

[andrewwatterson]

Is "theme" the right name for this? I agree that the categories you're describing are more semantic/behavioral, whereas I more often see "theme" used for visual styling.

type? role? intent? content?

[kumarharsh]

Agree - theme is a bad name, and will clash with CSS styles the user supplies. And also, no other HTML element supports anything like theme in the first place.

Are there really different usecases for there to be an actual need for the attribute? How would an alert toast differ from a success toast semantically? As I see it, there would always be some text content, zero or more actions, and a close button.

[andrewwatterson]

As @domenic points out, error toasts could have different a11y behavior, or linger on the screen for longer, or respond differently to preferences around muting (compared to info toasts).

We'll also want some way to style different types of toasts differently, which could either be done by selecting this attribute, or via a developer-added class name (which would allow developers to use as many or as few toast types as they wanted).

So I think it comes down to whether a) there's a pretty standard set of types and b) whether we can actually articulate how the behaviors would be different beyond "maybe they have different behaviors!"

Then we'll be able to more easily see if we need types, and how many distinct ones there are.

[domenic]

The starting point for a) is https://github.com/jackbsteinberg/std-toast/tree/master/study-group, FWIW. But yeah, b) is the key point that determines whether this is worthwhile. See also #25 which is the most concrete step in the direction of b).

[aardrian]

I think #25 also addresses a) above. ARIA has defined the standard set of types. For new patterns that emerge / have emerged since, then they will need to have their accessibility properties defined before they can be implemented anyway. Which means the accessibility work to define them would be concurrent and should include the WAI team.

IOW, two concurrent paths:

1. match the types already defined via ARIA (for which there is no native HTML counterpart);
2. start to spec new types and loop in the WAI team.

[jackbsteinberg]

I agree with the sentiment that the name theme doesn’t quite capture the essence of the feature; that different toasts should be treated differently, in more than just a cosmetic manner. This ties into some of the accessibility concerns raised in #25 and #29, and I think we can do better.

I think type is a good option, capturing the idea that it’s not just theming that’s changing but behavior as well. This also avoids confusion with WAI-ARIA roles that naming it role would bring. I have a PR out to change this (#40), I’ll merge it into the explainer in a few days if there are no objections or other suggestions.

With respect to accessibility roles, I think alert and status will be the most useful roles. The exact set of types is still TBD, but based on those used in external libraries it might look something like this:

• warning
• error
• info
• success

Assertive types such as error and warning could use role=”alert”, and polite types such as info and success could use role=”status”. Other solutions could involve creating new ARIA roles for types like warning and error (if there’s an important distinction between them), or scoping down to just the two types alert and status.

[aardrian]

@jackbsteinberg

Assertive types such as error and warning could use role=”alert”, and polite types such as info and success could use role=”status”. Other solutions could involve creating new ARIA roles for types like warning and error (if there’s an important distinction between them), or scoping down to just the two types alert and status.

I suspect (at this point) there would be no need to mint new ARIA roles.

But I am curious why you group "errors" and "warnings" into mapping to the alert role (with a default aria-live value of assertive) and "info" and "status" into the status role (with a default aria-live value of polite).

Not all errors nor warnings warrant the SR interrupting the user and not all status updates should wait for the user to finish a task. If the only difference you see is visual, then IMO that is not enough.

How about leaning on the existing roles, which are already documented and have suggested practices. So perhaps:

• type="alert"
• type="status"

Then you can borrow existing text from ARIA and authors do not need to juggle 4 values for type with AT behavior that overlaps in two of them.

[hidde]

As a developer, I agree with @aardrian's point that reusing existing roles would be ideal for authors,. Knowing when to use which type (and which browsers/AT they work in) is quite a burden already as it is. Adding more roles increases complexity for me as an author, I imagine it does too for browser and other parties.

[domenic]

It seems this thread has arrived at essentially two alternatives we should consider:

• Semantic types, based on what the toast represents. As the study group (as well as other design systems such as those mentioned by @gilmoreorless in Is "toast" the best name for this concept? #33 (comment)) shows, the general consensus here seems to center around toasts being used to represent the following types of information:
  • Info (neutral, default)
  • Success
  • Warning
  • Error
• Screenreader types, giving two types (e.g. alert/status or assertive/polite) directly mapping to whether the toast should be interruptive or wait for a pause when used with a screen reader.

Historically, HTML has leaned on semantics for the attributes of its elements. It leaves granular control of screen-reader behavior to the ARIA family of attributes. Instead, HTML plus the accessibility-mappings spec (HTML-AAM) do their best to ensure that when authors use elements and attributes that have accurate semantics, this gives good-by-default experiences for screen reader users.

As a concrete example, HTML has a semantic distinction between ordered lists, unordered lists, and menus (<ol>, <ul>, <menu>), as different types of lists. HTML-AAM maps these to, respectively, the list role, the list role, and no role. This shows how HTML can have more granular semantic distinctions, which map to less-granular ARIA roles. And of course, this can be overridden: if an author really needs their <menu> to have a list role, they can always do <menu role="list">, despite that not being the default mapping.

In #49 I put up an initial draft proposal to flesh out the current README, which uses semantic types, instead of screenreader types. It maps between the two by saying that errors should map to the alert role (assertive), whereas the info, success, and warning types should map to the status role (polite). Like the ol/ul -> list, menu -> no role mapping, this seems like a solid starting point. Authors can always choose to override this, e.g. deemphasizing an error with <std-toast type="error" role="status"> or urgently interrupting the user with a warning by doing <std-toast type="warning" role="alert">.

I'd like to get folks thoughts on two things in particular:

• Do semantic types, instead of screenreader types, make sense for the type="" attribute?
• Does the default mapping proposed in Add initial type="" API draft #49 seem reasonable?

For example, @aardrian argues that not all errors warrant the screen reader interrupting the user, and in his post, @scottaohara suggests toasts should always be role="status" (polite). Perhaps it would be safer to avoid inferring politeness level from semantic type, and require that interrupting the user be done with explicit opt-in (i.e. aria-live="assertive" or role="alert"). We welcome thoughts on this subject.

[scottaohara]

At a high level i quite like the idea of the type attribute being used to indicate level of assertiveness of the component/element it could be used on. As I think the output element could benefit from this as well, since it already defaults to role=status in modern browsers, save for an open bug with Firefox.

As you noted from my post, I do not think that an aria-live=assertive or role=alert are appropriate for a "toast" component, especially due to the fact toasts typically auto-dismiss. If they convey important warnings/alerts, they should not go away until a user has had a chance to understand the message.

But that's not to say the option to change the type wouldn't be desirable for a more generic "message" or "notification" component that could be styled/behave as a pop-up notification, like a toast, or as a static or position-sticky element in the DOM that exists until a user dismisses, like a global alert or warning notification.

[aardrian]

I want to caution over-analyzing HTML-AAM and HTML to justify a particular approach.

Historically, HTML has leaned on semantics for the attributes of its elements. It leaves granular control of screen-reader behavior to the ARIA family of attributes.

That is not strictly true.

• Historically HTML (1993) existed for years before ARIA (2014).
• ARIA is not exclusively for screen readers, SRs just happen to be the AT that supports it most (Braille displays, and some effort for dictation tools is underway).
• ARIA was built to be a bridge until user agents and HTML caught up with one another.

I defer to @scottaohara on HTML-AAM's intent and plans as he is an editor, but I feel its role here is orthogonal to this discussion.

Now, to the larger point, you have identified 4 types (warning, error, info, success). What do you propose these will do beyond visual style? Setting aside ARIA role mappings; do these solely adjust visual layout?

[domenic]

@scottaohara

As you noted from my post, I do not think that an aria-live=assertive or role=alert are appropriate for a "toast" component, especially due to the fact toasts typically auto-dismiss. If they convey important warnings/alerts, they should not go away until a user has had a chance to understand the message.

But that's not to say the option to change the type wouldn't be desirable for a more generic "message" or "notification" component that could be styled/behave as a pop-up notification, like a toast, or as a static or position-sticky element in the DOM that exists until a user dismisses, like a global alert or warning notification.

Toasts don't have to automatically expire; you can set their timeout to Infinity when showing them. So this case is within the scope of the repository, regardless of what the element is ultimately named (which, as you note, is an open issue, #33).

One interpretation of what you're saying is that warning or error toasts should have a default timeout of Infinity. (Existing discussions have already suggested this for toasts with actions.) Does that sound like a good idea? We could update #49 in that direction. Would that impact your assessment of whether the screen reader behavior should change based on semantic type, or do you still think role=status is the only appropriate role for the toast pattern?

@aardrian

Now, to the larger point, you have identified 4 types (warning, error, info, success). What do you propose these will do beyond visual style? Setting aside ARIA role mappings; do these solely adjust visual layout?

Like many distinctions in HTML, these are semantic distinctions. Other existing examples are ol/ul, or non-body-scoped header/footer/section, or samp/kbd. As a refresher, semantically-distinct elements often have different default styling as their only UA/AT impacts. But the main purpose of using semantic elements is not for styling; it's to communicate important distinctions to humans and machines. This purpose remains valuable for the HTML language even if those distinctions do not directly affect AT or UA behavior.

[aardrian]

@domenic

Like many distinctions in HTML, these are semantic distinctions. Other existing examples are ol/ul, or non-body-scoped header/footer/section, or samp/kbd. As a refresher, semantically-distinct elements often have different default styling as their only UA/AT impacts.

You are citing different elements, not attributes on the same element.

To use a closer analogue, If I have <input type="text"> versus <input type="checkbox"> versus <input type="radio"> versus <input type="submit">, those are all the same element where the function is different thanks to the type attribute. Some default visual styles have to come along with that function, of course.

So let me ask a different way — what is functionally different among these 4 types?

But the main purpose of using semantic elements is not for styling; it's to communicate important distinctions to humans and machines. This purpose remains valuable for the HTML language even if those distinctions do not directly affect AT or UA behavior.

I may be missing a related issue, but what are those machine distinctions that do not affect UA nor AT behavior? (I think this question builds on my question above)

[domenic]

You are citing different elements, not attributes on the same element.

I don't think that changes the argument.

So let me ask a different way — what is functionally different among these 4 types?

I think I've answered this question pretty thoroughly: like the examples I gave of preexisting HTML elements, the difference is mainly semantic, not functional.

I may be missing a related issue, but what are those machine distinctions that do not affect UA nor AT behavior? (I think this question builds on my question above)

For example, CMS's, authoring tools, content indexers, conversion tools between HTML and other formats, ... there are many pieces of software that consume HTML content and utilize semantic distinctions.

[aardrian]

@domenic

I think I've answered this question pretty thoroughly: like the examples I gave, the difference is mainly semantic, not functional.

Ok. Above you say "the main point of a theme is to communicate categories and intent, not to create styling." For those four 'semantic' type values (Info, Success, Warning, Error), how do you intend to expose / convey that semantic meaning to users?

For example, CMS's, authoring tools, content indexers, conversion tools between HTML and other formats, ... there are many pieces of software that consume HTML content and utilize semantic distinctions.

Can you outline how you imagine these 4 type values will be consumed by tools? Again, unless there is a document / issue I am missing that I can go read.

[domenic]

For those four 'semantic' type values (Info, Success, Warning, Error), how do you intend to expose / convey that semantic meaning to users?

Similar to non-body-scoped header/footer/section, or samp/kbd, or strong/em, or cite/i, I think users will likely not see much of the semantic distinction here directly. (The exception would be if it changed the ARIA role mapping or timeout behavior, which are still under discussion in this thread, but you've asked that we set aside the former for now.)

The exception would be is if page authors choose to align their stylistic categories with the semantic ones, but that's a styling choice for page authors. (And to some extent for the default stylesheet, e.g. <ol>'s default style sheet chooses to use arabic numerals vs. <ul>'s filled bullet points.)

Can you outline how you imagine these 4 type values will be consumed by tools? Again, unless there is a document / issue I am missing that I can go read.

http://seekbrevity.com/semantic-markup-important-web-design/ is one of the first Google results for "why semantic HTML matters", and it seems pretty reasonable. It details the content indexer and developer-facing aspects of semantic HTML. Of course it also mentions the accessibility benefits, but---as long as we're putting aside ARIA role mappings, at your request---those do not come in to play for the examples in question.

Other results at https://www.google.com/search?q=why+semantic+html+matters seem to touch on similar themes. http://html5doctor.com/lets-talk-about-semantics/ in particular covers one of historical flare-ups of this debate that we're currently recapitulating. (That time about whether article/section is a useful semantic distinction, instead of our current debate about whether error/warning/success/info is a useful semantic distinction.)

Since I don't have a reference for authoring tools off-hand, and it isn't obviously forthcoming in those search results, I'll give the example of how authoring tools today let you choose whether to use <ol> or <ul>, or define <header>s and <footer> templates for content sections (e.g. cards). I'd envision them similarly letting you choose the different type of toast you'd like to wire up to a particular occurrence.

[aardrian]

@domenic

Thank you for humoring me. I am genuinely trying to understand intent. What I am getting from this conversation, and from your links, is:

• that you do not have a direction in mind for how machines may parse the values from type; you mostly want to make it available should they choose to do so.

• authors may lean on these type values for styling across 4 distinct values.

Given that, here are my thoughts:

• Default UA styling will likely be limited (see <output> today) (and should be, again IMO).

• Visual style can be achieved by authors via classes or other selectors..

• Additional machine-consumed information can come from microdata (etc).

• One-off, framework, etc. scenarios for parsing can lean on data- attributes (similar to how Angular uses ng-).

Otherwise, if these four proposed types come into existence and have semantic meaning beyond visual style, that semantic meaning needs to be exposed to users. All users.

Without a clear proposal of how these 4 type values will be exposed to all users, I see two type values that map to existing, documented, tested, understood APIs and which require no additional mapping, cross-mapping, nor documentation (and, again IMO, looping in the WAI team):

• type="alert"
• type="status"

In my head I see HTML that might look like:

<message type="status" class="info" datetime="2019-07-18T11:36:03-04:00" data-framework="{framework-thing}">
   File downloaded.
</message>

I find it helpful to talk in concrete terms sometimes, hence fake code.

[domenic]

I see. It sounds like, going back to my post at #18 (comment), you're advocating for screenreader types, not semantic types. It's good to understand your position.

My general inclination is that we already have mechanisms for screenreader control (role/aria-live), so we do not need a new attribute that duplicates that control. (And then we need to define the interaction thereof, between the two mechanisms of control.) Whereas, I do think there is a benefit in adding semantic meaning to toasts, for the reasons listed in the reading I linked to.

Otherwise, if these four proposed types come into existence and have semantic meaning beyond visual style, that semantic meaning needs to be exposed to users. All users.

I disagree with the idea that HTML should stop adding semantic meaning to its elements unless that meaning is exposed directly to users. I think we would have a very different language if we were concerned only with user-exposed differences, and avoided semantics. And I don't think we should change course on that now.

I can respect if you feel differently. What I am hearing, if you'll allow me to summarize, is that you would like to use the introduction of new elements, like toast, to change the standards for how we design HTML. You would like us to not introduce any new primarily-semantic distinctions, like we have in the past, but instead only introduce user-facing functionality. You believe that for the future, semantic distinctions (such as between ols and uls, or footers and headers, or kbd and samp, or error toasts and success toasts) can be handled by classes, microdata, and data- attributes. Let me know if this is inaccurate in some way.

At this point it may be good to bring in more voices to the conversation.

[aardrian]

@domenic

you're advocating for screenreader types, not semantic types.

I still don't accept this fabricated distinction.

I disagree with the idea that HTML should stop adding semantic meaning to its elements unless that meaning is exposed directly to users

This is not a global HTML conversation, nor did I suggest what you assert.

What I am hearing, if you'll allow me to summarize, is that you would like to use the introduction of new elements, like toast, to change the standards for how we design HTML. You would like us to not introduce any new primarily-semantic distinctions, like we have in the past, but instead only introduce user-facing functionality. You believe that for the future, semantic distinctions (such as between ols and uls, or footers and headers, or kbd and samp) can be handled by classes, microdata, and data- attributes. Let me know if this is inaccurate in some way.

I disagree with your entire assertion. That my points above lead you to this conclusion suggests that I was not clear.

You did not challenge my assertions about your position above, so I take it to mean you have accepted them as-is. Those inform the following…

Let me re-state and explicitly limit the scope to just the proposed element:

• However you choose to expose information to users, it must be available to all users.
• Creating attribute values with no purpose other than styling is not semantic.
• Absent defined goals, map attribute values to existing patterns / behaviors.
• For machine consumption, define the goal / purpose before minting new attributes; until then, lean on existing patterns for machine-readable information.

[domenic]

I see we are still talking past each other. I think it'll be best for me to step away, as we're not making much progress, but let me explicitly refute some things you're saying, since that seems important to you as otherwise you assume I accept them:

However you choose to expose information to users, it must be available to all users.

I don't agree that this is necessary. I think we have a long history of semantic information that is not exposed to users at all (article/section, etc.), or to all users (kbd/samp, ol/ul, etc.).

Creating attribute values with no purpose other than styling is not semantic.

I agree. Nobody is proposing that.

Absent defined goals, map attribute values to existing patterns / behaviors.

I agree that we should map attribute values to existing patterns and behaviors. That is what the semantic types proposal is doing, based on the study group research.

For machine consumption, define the goal / purpose before minting new attributes; until then, lean on existing patterns for machine-readable information.

The goal and purpose behind semantics is generally well-defined. Even if you do not agree, the existing patterns for toasts are well established, as the study group shows.

[LJWatson]

@domenic commented:

I'd like to get folks thoughts on two things in particular:

• Do semantic types, instead of screenreader types, make sense for the type="" attribute?
  ...>

Separating "semantic types" and "screen reader types" suggests a distinction that doesn't really exist.

As an example: The <h1> to <h6> elements were introduced in HTML+ in 1993. From the outset they were defined as having both semantic and visual meaning:

The tags H1, H2, ... H6 are used to represent headers. H1 is the most significant and rendered in a large font*1 (preferably centered). H2 to H6 are progressively less significant and usually rendered flush left in smaller fonts.>

Such elements were distinct from elements like <b> and <i> that, at the time, had no semantic meaning. They were purely intended for visual representation.

In the 1990s browsers and assistive tech parsed HTML documents more or less independently of each other. Browsers represented the headings visually in ways that conveyed their semantic meaning, assistive tech like screen readers represented the headings aurally in ways that conveyed their semantic meaning.

The introduction of platform accessibility API changed the way assistive tech obtained the relevant semantic information, but did not change the semantic information itself. Instead of parsing HTML for themselves, assistive tech could query semantic information directly from the browser using the accessibility API.

The way HTML elements with semantic meaning are mapped to the platform accessibility API is documented in the HTML AAM. Although ARIA makes it possible to override the default semantics of an HTML element in a way that is targeted only at assistive tech, it doesn't alter the fact that assistive tech makes use of the default semantics of HTML elements and always has done.

So the "semantic type" and the "screen reader type" are necessarily one and the same thing.

[scottaohara]

OK. There's quite a bit here to go over / comment on. This will be long. I appreciate your time on this, in advance.

@domenic

Toasts don't have to automatically expire; you can set their timeout to Infinity when showing them. So this case is within the scope of the repository, regardless of what the element is ultimately named

OK, yes agree. If an author can config the component to not automatically dismiss, then that would require a dismiss button to get it out of the way (I also realize this has been discussed) ideally outside of the live region area so that the button's name is not announced as part of the component's message.

e.g. The announcement of an example message should be "Your file was saved" not "Your file was saved dismiss notification".

One interpretation of what you're saying is that warning or error toasts should have a default timeout of Infinity. (Existing discussions have already suggested this for toasts with actions.) Does that sound like a good idea? We could update #49 in that direction.

I think that would be an important feature of this component, disallowing a timeout if the type of message was an error/warning in nature, or if the element contained an interactive element. Otherwise for more benign messages (info/success) an author would be allowed to set a timeout (again as long as the message didn't contain an interactive element). For clarity, I do not consider a close/dismiss button a control that would negate the timeout as that would be a part of the component and not the content added by the author.

An aside: it would be amazing if users could override an author set timeout. For instance via a browser or OS-level setting. I realize a user-level setting like that is more than likely out of scope here, but it'd help alleviate the issue of what's deemed enough time for some people does not equate to all people.

Would that impact your assessment of whether the screen reader behavior should change based on semantic type, or do you still think role=status is the only appropriate role for the toast pattern?

My assessment of a "toast" needing to adhere to role=status behavior is specifically tied to making an accessible component that more often than not behaves as an auto-dismissed pop-up notification which contains a message that reports a benign status (info, success). It would not contain interactive elements (aside from an optional sibling dismissal control to the live region). I focus in on this specific definition because while there are many implementation of "toasts" in the wild, which contain features beyond what I've outlined, the accessible UX of them all can be inconsistent, ranging from problematic to down right awful.

That said, having an opportunity to allow for additional features that would modify the functionality and semantics of the component, to ensure proper accessible usability for all, considerably loosens my more strict outlook of what a "toast" (but again, wouldn't call it that) should be.

So, if the author can set a type to determine the assertiveness and importance of a message, where more important messages would not allow for an auto-dismissal, then that should allow for a change in what the underlying semantics of the message container should be.

Now, specifically on the topic of semantic "types" (info, success, warning, error), while I understand the intent to cow path some long standing CSS class names, if you break down what these messages often consist of you're really just talking about divvying up "status" and "alert" messages.

For instance, imo a "success" message is really just a green colored information message. And both "success" and "info" are really just types of "status" messages. An error is an "alert". A warning could be either a status or alert depending on severity.

This is why I think it makes much more sense to adhere to what you're calling the "screen reader types", though I point to Léonie's response regarding this designation. CSS can and should be used by authors to differentiate any further.

Then with those two types, allowances could be made for the expected customizations, much like how step is allowed on type=number but not on type=text. So circling back, type="alert" would map to role=alert, it'd not allow for an auto-dismiss, it would allow for a dismissal button or open by default. A role=status would allow for an auto-dismiss, unless the component contained an interactive element.

[domenic]

@LJWatson the post you're referring to defines the terms I'm using at the beginning. To reiterate them, "screenreader types" are alert/status or live/polite, whereas "semantic types" are info/success/warning/error.

OK, yes agree. If an author can config the component to not automatically dismiss, then that would require a dismiss button to get it out of the way (I also realize this has been discussed) ideally outside of the live region area so that the button's name is not announced as part of the component's message.

This is great feedback. I've filed this against our implementation (for which the close button has recently landed) as https://bugs.chromium.org/p/chromium/issues/detail?id=985871. We should also look in to updating the explainer to make sure this is clear.

I think that would be an important feature of this component, disallowing a timeout if the type of message was an error/warning in nature, or if the element contained an interactive element. Otherwise for more benign messages (info/success) an author would be allowed to set a timeout (again as long as the message didn't contain an interactive element). For clarity, I do not consider a close/dismiss button a control that would negate the timeout as that would be a part of the component and not the content added by the author.

This makes sense to me. I'll revise #49 so that warnings and errors have a default timeout of Infinity, and a default of showing the close button. Let's discuss further steps in #37, e.g. for action-containing toasts. (There we can also get into discussions about how strongly we try to enforce the defaults.)

An aside: it would be amazing if users could override an author set timeout. For instance via a browser or OS-level setting. I realize a user-level setting like that is more than likely out of scope here, but it'd help alleviate the issue of what's deemed enough time for some people does not equate to all people.

We've been in talks with @alice about this. Basically, today, to achieve WCAG 2.2.1, site authors need to add their own timeout customization UI. For toasts, we could continue this tradition, i.e. site authors need to add their own customization UI for WCAG 2.2.1, and thread down the results of that customization to toast.show() or showToast() calls. That would be most aligned with how users are used to configured these things today, from what I understand.

Alternately, we could attempt to standardize a new mechanism a UA-level setting, e.g. for "ephemeral notification timeouts", or perhaps something more general. This could then apply to toasts, but also be filtered down to page authors (e.g. via navigator.ephemeralNotificationTimeout or similar) for their own controls. This would effectively subsume the site-specific configurations by moving that responsibility into browser (or AT?) configuration.

There are a lot of tradeoffs here, and it's a complex space, so it's hard to say what's best. But this would be a good topic to spin into its own issue.

Now, specifically on the topic of semantic "types" (info, success, warning, error), while I understand the intent to cow path some long standing CSS class names, if you break down what these messages often consist of you're really just talking about divvying up "status" and "alert" messages.

I don't think this is an accurate representation of the semantics of info, success, warning, or error. These are more than just CSS class names; they mean fundamentally different things, in the same way (or arguably more so!) than distinctions like article/section or kbd/samp.

We can make assumptions that infos and successes should be announced politely, but not always. For example, a financial trading app may consider certain pieces of "info", or certain "successes", as imperative to alert the user about as soon as possible, interrupting their current task. And as you point out, it's not clear whether warnings should be interruptive or not. Finally, I've certainly seen a lot of errors in my time that are not very important. (E.g. "Unable to cache images for offline use".)

So I think having separate axes, semantic categorization vs. screenreader politeness, is important. If nothing else, to allow them to vary independently.

The question I'm hoping to get input on, is whether there are meaningful default mappings between the semantic distinctions in question, and the politeness levels announced to screen-readers. I think as a baseline, we should be polite. (A good rule in life in general.) And I think that authors who are aware of the concept of politeness levels, should be able to customize it using the familiar technologies they have today, viz. aria-live="polite|assertive" or role="alert|status". But should we say that by default, errors are assertive? That's what I'm unsure on, and would appreciate input regarding.

[aardrian]

@domenic

We can make assumptions that infos and successes should be announced politely, but not always.
[…]
But should we say that by default, errors are assertive? That's what I'm unsure on, and would appreciate input regarding.

Since the only concern I see here for the four proposed types is how they are exposed to SRs, remove that complexity by mapping the types to the very thing with which you are trying to achieve parity: roles (as type="alert|status", which I proposed above). Then an author chooses the type based on a direct mapping.

Alternately, using confusing types, if an author writes type="sandwich" (which let's say defaults to aria-live="assertive") when the author wants it to be polite, then the author adds aria-live="polite" or role="status".

Informed defaults with the ability to override. Or 1:1 mapping to existing roles.

[LJWatson]

@domenic I think perhaps you misunderstood my comment. Any distinction between "semantic types" and "screen reader types", however you might try to separate them, is meaningless.

You and @scottohara already noted that the information types (warning, error, info, success) have a logical mapping to the accessibility layer (status/alert, assertive/polite).

So your question asking whether your "semantic types" or "screen reader types" made more sense, was in itself non-sensical because they're one and the same thing.

[scottaohara]

@domenic

But should we say that by default, errors are assertive? That's what I'm unsure on, and would appreciate input regarding.

I'd say a hard yes on an "error" mapping to role=alert and being assertive. But, the following adds context to this...

Regarding the semantics of the other types, per your response I think (hope) we're actually more aligned on this than may have originally come across?

We can make assumptions that infos and successes should be announced politely, but not always. For example, a financial trading app may consider certain pieces of "info", or certain "successes", as imperative to alert the user about as soon as possible, interrupting their current task. And as you point out, it's not clear whether warnings should be interruptive or not. Finally, I've certainly seen a lot of errors in my time that are not very important. (E.g. "Unable to cache images for offline use".)

So, your thoughts here make me think more that types should be limited to status / alert (or any other naming that could indicate "passive" vs "assertive") and then use classes to style. As authors could very well then say "I want this success message to be assertive and not dismiss until the user has definitely seen it / interacted with it" or "this message is really of little consequence, but someone up the PM chain REALLY wants this to be a 'warning'." So style it like a warning but give it a status/polite behavior.

If the component were to use all four types that have been outlined above, then seems to me that there'd be a need for mapping these types to roles/behaviors, and then another config to determine an assertion level to potentially override a types default assertion level. But sticking with two and then allowing for author styling would allow for the customization you and I both seem to want.

The other thing to consider here being what you noted should be discussed in issue #37. So I will re-review and comment there at some point in the near future.

[domenic]

So, your thoughts here make me think more that types should be limited to status / alert (or any other naming that could indicate "passive" vs "assertive") and then use classes to style.

It depends on if you thing there's any semantic value in distinguishing between info, errors, warnings, and alerts, beyond just using stylistic classes. I think there is, and that there's a lot of ecosystem evidence to back that up. I think that value is separate from, but additive with, using attributes to control screen reader politeness. That is why I say they should be varied independently.

You seem to be saying that if people want to convey semantic distinctions between info, errors, warnings, and alerts, they should only do so with classes, and not with semantic attributes. I disagree with that; I think those are valuable semantic distinctions, not just styling distinctions.

Perhaps the core point of misalignment is that I see value in semantics apart from how they control screen-readers (or styling). For example I think kbd vs. samp is a useful distinction, or ol vs. ul, or section vs. article. Similarly I think success vs. info is a valuable semantic distinction, even if it does not change screen reader behavior.

If the component were to use all four types that have been outlined above, then seems to me that there'd be a need for mapping these types to roles/behaviors, and then another config to determine an assertion level to potentially override a types default assertion level.

Well, we already have that config, namely aria-live. Adding something that just duplicates it seems like a net negative to me. With semantic types + aria-live to control screen reader behavior, we can express the 2x4 matrix of possibilities (assertive, polite) x (info, success, warning, error), all of which may be useful. With something that duplicates aria-live, we have a 2x2 matrix (assertive type, polite type) x (assertive aria-live, polite aria-live), where 2 of those matrix entries are just self-contradictory. A lot of important semantic information gets lost.

[scottaohara]

You seem to be saying that if people want to convey semantic distinctions between info, errors, warnings, and alerts, they should only do so with classes, and not with semantic attributes.

I'm trying to say that in regards to how a live message can be conveyed it's either going to be "polite" or "assertive" and that the content of the message / intent of the author is what will designate what it needs to be.

Could there be 4 types that map to the two roles (alert/status)? Yes. Warning being the one that I think would be the most debated about which role it fell under.

I think what I've been leaning away from, but haven't made it clear in my responses, is that as you've said aria-live could potentially be used to overwrite the assertiveness of the component if an author chose to do so. I am of the opinion that it'd be better if instead of acknowledging that authors may want to overwrite this component with extra ARIA, that we should instead make a point to try and build this in a way where that would be less necessary.

I hope that helps clarify my position on this particular topic.