The exact nature of the role(s) will be influenced by the input we receive from stakeholders responding to the HTML element/role-parity triage. Thus adding the "blocked" label for now.

Dupe of #525

I think #525 may prove to be a subset of this issue, but ok.

Actually, I'm re-opening because #525 may prove to be a subset of this issue.

We're taking a different approach to triaging and tackling these roles, and I'm reserving the right to open new broader issues such as this one. I, of course, don't want to immediately close out old issues which have discussion. So there may be duplicate issues. I promise to clean things up in the end. Hope that's ok. 😄

Conclusion from the Working Group face-to-face today is that we're going to create two generic roles: inline and block. They will be fleshed out and a pull request will be created.

First attempt at fleshing out block/inline roles is in PR #805 in branch issue699-block-inline.
Feel free to edit directly in branch as needed.

Reminders for later:

1. Update "Class diagram of the relationships described in the role data model"
2. Open PRs for HTML and other specs for new generic mappings

@joanmarie I'm sorry I did not see the decision from May until @carmacleod's PR went in, but I think this is a serious mistake. It's unfortunate that the original issue #525 was closed in favor of this one, because more of the discussion (and my defense of a single "generic" role) happened there.

My main objection is that this conflates an ARIA role with a style (display: inline vs display:block). Separation of content (usually markup) from presentation (usually CSS) is widely understood to be a good thing for the Web, so I'm at a loss to understand why the working group wants to two new entirely style-based roles.

My best guess is that it's caused by a misunderstanding of how these are represented by user agent implementations. Screen readers treat block and inline elements differently, and I know members of the WG don't want to lose this functionality, but I don't believe that's at risk. WebKit and Blink (maybe other user agents too) expose differences in these generic elements because they are styled differently, not because the element is tied to a block or inline role. Therefore a single generic role would work for both, and user agents can still expose any presentational relevance (block, inline, bold, italic, underline, etc) without adding presentational roles to the ARIA role hierarchy.

Adding some other implementors in case they know of an implementation reason we would need style-based roles. @aleventhal @asurkov @minorninth @alice @hober @dwsinger

The best suggestions I saw in Issue #525 were these two:

• @devarshipan's suggestion to make the "structure" role non-abstract and use it.
• @asurkov's recommendation that if this is really necessary, it should be an attribute, not a role.

I'd prefer either of those to adding style-based ARIA roles.

I'll admit that it did feel weird to try coming up with words for inline and block roles. :)
Adding @mcking65 and @jnurthen to the discussion.

@cookiecrook, I know we had a role vs attribute discussion at the meeting in Toronto in May, and I do not clearly recall the reasons we landed on role. You can see in the minutes for May 1 that I raised the possibility of an attribute. I honestly believe there was a good reason for going with role instead of attribute. I do not recall going in with a strong opinion on that point. I didn't leave with one, but I remember the decision as rational, not arbetrary. So, we may need to do some more brain-digging on that point so we can at least document it, and, per your request, revisit it.

However, One point where we are not connecting is on the "presentation" vs "semantics" issue. I think it would beneficial if we could sort that out.

If I understand correctly, You do not support having two roles, but you could support a property that distinguishes between elements that should be treated as blocks and elements that should be treated as inline. And, this is because roles should not be used to represent style. In issue 525, you wrote:

We don't need separate role mappings for inline-vs-block generics. The rendering engines can remap the generics based on display if necessary.

and, in this issue you wrote:

My main objection is that this conflates an ARIA role with a style (display: inline vs display:block). Separation of content (usually markup) from presentation (usually CSS) is widely understood to be a good thing for the Web

I would 100% agree if the types of presentation did not have semantic significance. However, the types of presentation we are talking about completely change meaning and understandability. That is why browsers occasionally, and frequently differently, remap based on style in an attempt to correctly represent the meaning the author is conveying. Unfortunately, that remapping based on style goes wrong as or more often than it goes right. So, it is imperative that we give authors a way to explicitly declare the semantics that is independent from styling.

On Windows, span has historically had the strongest semantics because, regardless of styling, all versions of Chrome, Firefox, and IE render span in exactly the same way when read by any version of either NVDA or JAWS.

<p>The following 3 spans are read as the single word, "cat", with any version of either JAWS and NVDA using any version of Chrome, Firefox, or IE:</p>
<span>c</span><span>a</span><span">t</span>
<p>The following 3 block style spans are read as a single word, "cat", with any version of either JAWS and NVDA using any version of Chrome, Firefox, or IE:</p>
<span style="display:block">c</span><span style="display:block">a</span><span style="display:block">t</span>

The default treatment of div as a block element has been just as essential to understandability. A stunning amount of content on the internet would be become unintelligible by screen reader users if the representation of spans and divs were to change.

In other words, there are accessibility semantics associated with inline and block styling. While you have pointed out that this is historically the consequence of an implementation detail in browsers, that does not remove the fact that authors have both intentionally and unintentionally relied upon those implementation details for their semantic consequences. From my perspective, turning those side effects of implementation into explicit first-order effects is one of the primary objectives of this issue. The fact that we have not had explicit ways to declare block and inline semantics independent of style has created real problems in some browsers.

That said, if the rest of the group is open to reconsidering the role verses attribute decision, this would become a mute point if the decision were to change. While I would be more comfortable if we had consensus on both the rationale behind the specification and the actual specification, mostly because that rationale effects pedagogy, I grant that consensus on rationale is a nice-to-have.

semantics: read blocks separately; read inlines run together

Matt's comments seem to confirm this decision was made based on the current interaction of Windows-based browser+screen readers combinations. As mentioned in #525, its the opposite behavior of the Mac browser+screen readers combinations. That and my other objections seem to confirm this is worthy of revisiting.

@cookiecrook My opinion is that we should let browsers determine if an element should be inline/block using their internal rules but we should provide an ability in ARIA for a developer to override the browser and state that an element really should be either inline or block. Do you agree with this?

Conceptually, I sort of agree, but definitely not as a role, and definitely not as the values 'inline and block... Those two come with CSS display baggage. What happens when we need an inline-block behavior? Or a block flow, or a flex run-in? Check out all the display values on MDN and I hope you'll agree it should not use these terms.

I think it's reasonable for the WG to consider a feature that indicates whether element breaks are considered meaningful. Is the purpose of this limited to whether or no screen reader speech is continuous, or is there another benefit to other types of Assistive Tech?

definitely not as the values 'inline and block... Those two come with CSS display baggage.

I am a strong supporter of having two generic roles which reflect the normal inline vs block semantics of HTML elements, and the presumed whitespace/line-breaks that come with them. However, I agree with @cookiecrook that using the CSS terms is problematic, because the CSS can be overridden, and has hybrid layout options like inline-block.

I'd suggest looking instead to the HTML terminology.

The "inline-by-default" HTML elements are called "phrasing content", so maybe the "span" role could be phrase ? Although span as a role name works, too (and would be more recognized by authors), if people don't think it's confusing to have other phrasing elements map to role=span with extra formatting exposed.

For the "block" role, there isn't a clear term in HTML. But when you look at the list of elements that are default block-layout in HTML, the only non-deprecated ones that don't have a more specific role are address, div, and p.

If p is going to map to a specific new paragraph role (as I believe it should), maybe the new block-level role can be called division? That makes it clear that the impact of this role is to divide otherwise continuous phrasing flow of content, without being quite as strong as a group. But quite frankly, I'm also happy with group being the default role for div and address when they need to be included in the accessibility tree.

So to summarize, we have either separate roles:

1. role="block" and role="inline" (which have CSS display baggage)
2. role="div/division" and role="span"
3. role="structure" (make concrete) ... and role="span"?
4. role="group" (like structure but supports aria-expanded and -activedescendant) ... and role="span"?

Or single role with attribute (property):

5. role="generic" and aria-block/aria-inline="true/false" or aria-display="inline/block"
6. role="structure" (make concrete) and aria-x property as in point 5.

Did I miss any?

Some other possible words that could be used for role or property names:

• discrete, distinct, discontinuous, individual
• connected, combined, continuous, phrase, part, piece, entity, portion, fragment
• aria-render="separately/together"

TBH, I'm a little unclear on why we seem to be leaning towards "two roles" rather than "one role and a property"? Might be slightly more "future proof" to use a property, i.e. easier to add a new property value than a new role?

@carmacleod wrote:

TBH, I'm a little unclear on why we seem to be leaning towards "two roles" rather than "one role and a property"? Might be slightly more "future proof" to use a property, i.e. easier to add a new property value than a new role?

👍 Since the goal seems to be overriding AT element separation behavior (useful on any element or role), it shouldn't be a role.

Did I miss any [options to resolve this feature]?

There are lots of options, but enough members of the WG are convinced this shouldn't be a role, I move to 1) open a new issue for the element separation behavior (which would likely end up as an attribute), and 2) reopen the original issue #525 to address the need for a generic role.

Seems like there is some agreement that there are two semantics that have been accidentally or unintentionally imposed by span and div: a block-like semantic that is similar but not identical to paragraph, and an inline semantic that is similar to a string.

Even though there are some differences among browsers that effect whether or not these semantics are perceived by screen reader users, the vast majority of the time, the appropriate semantic is conveyed. This good luck has been supported by a variety of circumstances, including the popularity of particular browsers and screen readers as well as customary usage patterns for div and span.

BTW, @cookiecrook, VoiceOver in Chrome does not work the same as VoiceOver in Safari when reading div and span elements. In Chrome, VoiceOver actually works more like Narrator. VoiceOver in Safari is an outlier. That said, even if you ignore the uniqueness of Safari, most of the time, the appropriate semantic is rendered.

Proposal for minimum requirements to address with new ARIA attributes

Here are the requirements I think we need to address:

1. New role or attribute mappings should not change how existing content is experienced, specifically:
   1. For div, We need an ARIA expression of default block semantics that browsers are allowed to override during rendering based on visual styling.
   2. For span, We need an ARIA expression of default inline semantics that browsers are allowed to override during rendering based on visual styling.
2. Authors need a way to override default behavior and explicitly declare a block-like or inline-like semantic that is not changed based on visual styling during rendering.
3. No inherritance: These semantics apply to child text nodes but not to descendant elements or text nodes contained by descendant elements.

The no inherritance requirement is particularly important. I strongly disagree with the idea that one advantage of a property is that it can be applied to existing roles. I think that is a very dangerous idea that would not just massively complicate the spec and its implementation but eventually lead to unintended side effects. For example, this semantic should not apply to descendants of a group that contains a set of widgets.

The semantics currently expressed by today's treatments of div and span are limited to text nodes and whether or how browsers should combine them in the accessibility tree. Currently, screen readers already have their own methods for how they present elements with any other accessibility semantic. For instance, no matter what screen reader or browser you use, a span containing a set of buttons is presented in the same way as a div containing the same set of buttons. The solution this issue should not attempt to change that.

Another thing to keep in mind is that the resolution to this issue could have consequences for the name calculation and how strings are concatenated. This is especially true for elements that are named from content where that content consists of one or more generic containers that contain text. If the effects of the role or properties we develop for this issue were inherrited by descendants, we'll have yet one more complexity to consider during recursive collection of text for naming.

Another requirement to consider

Consider:

<h1><span>foo</span><span>bar</span></h1>
<a href="..."><div>foo</div><div>bar</div></a>

In circumstances like the above, CSS is used to separate "foo" and "bar" in ways that could lead to either "foo" and "bar" getting lumped together as a single word or separated into two separate elements while the most accessible result would be to have them read as a string of two words "foo bar". However, getting them to be space delimited is actually challenging. It means adding a 3rd element to contain the space or adding space to one of the existing elements. Often, neither of those options is practical.

I think we could solve this issue in a way that gives authors the ability to fix problems like this, which have become extremely common.

Proposal for solution

blob (role)

Generic, nameless grouping container that can be used to specify how child text nodes are presented to assistive technologies.

Superclass: structure
No subclasses.

aria-text separation (property)

Indicates the type of separation, if any, that is required between the text nodes contained in the blog and its sibling elements.

If a blob contains one or more text strings, and if any contained strings are at the start or end of the blob, the value of the aria-textseparation property specifies how those text strings will be separated from text strings contained by sibling elements.

Allowed values:

• none: Text in this blob is not separated from neighboring text; it will be concatenated with any previous and subsequent text without any delimination.
• textnode: Text in this blob is treated as an independent text node that is semantically separate from sibling elements.
• space: When concatenated with text from neighboring elements, the text in this blob will be separated from text in sibling elements on either side by a single space.
• leadingspace: When concatenated with text from neighboring elements, the text in this blob will be separated from text in the previous element by a single space.
• trailingspace: When concatenated with text from neighboring elements, the text in this blob will be separated from text in the subsequent element by a single space.
• inline: Same as none except that user agents may override the text separation during rendering based on the style computed for the element. (This value is for use by user agents; authors SHOULD NOT use it.)
• block: Same as textnode except that user agents may override the text separation during rendering based on the style computed for the element. (This value is for use by user agents; authors SHOULD NOT use it.)

Mappings for div and span

• span maps to role="blob" with aria-textseparation="inline"
• div maps to role="blob" with aria-textseparation="block"

Possible Future Enhancement

We could add a property aria-textseparator that allows the author to specify a string to be used as a text separator. We could add 3 more tokens for aria-textseparation: string, leadingstring, and trailingstring. Thus, it would be possible to add punctuation in situations where the visual presentation connotes something that is not accurately represented by only a space character. Then you could have:

<div><span aria-textseparation="trailingspace">Price:</span><span>$4</span><span aria-textseparation="leadingstring" aria-textseparator=".">99</span></div>
<!-- Rendered to a screen reader as a single text node with value "Price: $4.99". -->

@mcking65, I like where you're headed, with a few mods:

Role: I'm not sure about the role name "blob"… Why do you prefer this over the previously proposed "generic" name?

Attribute: How about aria-whitespace? values could be space, line-break, paragraph-break, none, and inherit.

I like the direction, also. This (by either set of names) would solve a long-standing problem.

Although, if AT would look for aria-label on a div, that would solve it, too. :)
But they don't - I just tried it with the following:

	<p>Styled spans with aria-label on parent div:</p>
	<div aria-label="Price: $4.99">
		<span>Price:</span>
		<span style="padding-left: 4px;">$4</span>
		<span style="vertical-align: super; font-size: 70%;">99</span>
	</div>

NVDA and JAWS both say "$499" instead of "$4.99" (a significant difference in price that is only apparent visually).

Blob is a very cool name, but maybe it's a bit too "computer jargony"? Maybe generic would be more universally understood?

Regarding attribute, aria-whitespace is easier to understand, but aria-textseparation is more powerful.

@cookiecrook You asked:

Is the purpose of this limited to whether or no screen reader speech is continuous, or is there another benefit to other types of Assistive Tech?

I would guess that voice commands like "Go to cat" or "Select cat" in Matt's "cat example" would benefit.

I tested a version of the cat example on Windows with 2 screen readers in 3 browsers:

• Chrome 68, FF ESR 52, IE 11
• JAWS 2018 1808.10, NVDA 2018.1.1

The visual rendering is: divs: c, a, t, inline divs: dog, spans: cow, and block spans: p, i, g.
Rendered speech generally follows the visual rendering, but the exceptions are wildly inconsistent:

• inline divs: dog, are read as d, o, g, by JAWS in IE
• spans: cow, are read as c, o, w, by NVDA in IE
• block spans: p, i, g, are read as pig in JAWS in Chrome/IE, and by NVDA in Chrome/FF

Given that inconsistency, it's obvious that authors need a way to help AT interpret these things.

Commenting on this proposed definition.

A nameless container element that can confer accessibility properties to its descendants without exposing itself to assistive technologies.

Aside from the hilarity of phrasing it "exposing itself", this doesn't appear to be correct. Generic containers like <span> are exposed to the API so that assistive technologies can gather certain properties such as layout and bounds. This allows VoiceOver to enlarge the cursor for low vision users, Switch Control to simulate mouse or drag events, etc. These elements are conveyed to the APIs… the distinction is that the role is irrelevant, or generic. Naming it does not cause the user to infer some specific interaction model as it would with a button, landmark, or form field.

@cookiecrook commented

Aside from the hilarity of phrasing it "exposing itself",

Funny ... But, let's keep in mind that, hopefully, all readers are aware that the spec is not a transcript of a legislative hearing about nominees for judicial positions.

@cookiecrook commented:

this doesn't appear to be correct. Generic containers like are exposed to the API so that assistive technologies can gather certain properties such as layout and bounds. This allows VoiceOver to enlarge the cursor for low vision users, Switch Control to simulate mouse or drag events, etc. These elements are conveyed to the APIs… the distinction is that the role is irrelevant, or generic.

Thank you for the assistive tech dev use cases. Those, combined with the case of the generic being focusable, are sound reason for having the role rather than mapping to none.

Would the following wording be more acceptable?

A nameless container element that is not exposed to users of assistive technologies but can confer accessibility properties to its descendants.

@cookiecrook commented:

Naming it does not cause the user to infer some specific interaction model as it would with a button, landmark, or form field.

Nameless is meant to say that the generic element cannot be named, i.e., labeled. So, two critical aspects of the definition are:

1. Unlike other elements, e.g., headings or buttons, AT users will never be aware of the role of the element. Generics are always part of some other element that has a role.
2. Generics are unlabelable.

This implies a need for a requirement on assistive technologies. That seems necessary if we can't express the requirement at the API level.

two random examples we were talking about in f2f:

• https://codepen.io/schne324/pen/NmVeEW
• https://codepen.io/schne324/pen/eoabwW

Quickly testing @schne324's examples with JAWS/NVDA in Chrome/FF.

Example 1

• NVDA in Chrome: says "quickbrownfox" as one word (I wasn't sure, because the words almost sound distinct, so I changed the code a bit to use the letters in "char" "acter", and it is definitely being spoken as "character")
• JAWS in Chrome/FF: all one word (same as NVDA)

Example 2

• NVDA in Chrome: says separate letters F o o B a r
• JAWS in Chrome/FF: separate letters (same as NVDA)