Add strong and emphasis roles

[joanmarie]

---

Preview | Diff

[joanmarie]

Links for review:

• https://raw.githack.com/w3c/aria/issue-905/index.html#emphasis
• https://raw.githack.com/w3c/aria/issue-905/index.html#strong

[mcking65]

While the definition says this is one or more characters, the role description does not include any information about context for appropriate use and constraints on use if there are any. For instance, can you wrap main in a div with role emphasis? What are the HTML restrictions? Can you wrap a link in emphasis or must you put the <em> inside the link text? I haven't looked up the content model for <em>. If an <em> cannot contain interactive content, or even a heading, for instance, the perhaps the emphasis role should have children presentational true. I think this aspect of appropriate useage must be addressed before merging. We might be able to better address this, or do so mor succinctly, when we hhave an abstract phrase-like role.

[mcking65]

github is messing with me ... I can't seem to find my last review comment so adding it again. appologize if it is a dupe:

Like the emphasis role, the strong role also needs information describing whether there are any constraints on descendant content.

[joanmarie]

@mcking65: Regarding this:

Like the emphasis role, the strong role also needs information describing whether there are any constraints on descendant content.

I think that makes good sense. But I am not an author, so I'll leave it to the group to decide and then update this PR accordingly.

[css-meeting-bot]

The ARIA Working Group just discussed https://github.com/w3c/aria/pull/953.

The full IRC log of that discussion

<jamesn> TOPIC: https://github.com//pull/953
<MarkMcCarthy> jamesn: PR 953 is for strong and em, joanie?
<MarkMcCarthy> joanie: matt did a full review earlier today, he did some wordsmithing. i already pushed the smithing changes, but he raised a good comment
<joanie> While the definition says this is one or more characters, the role description does not include any information about context for appropriate use and constraints on use if there are any. For instance, can you wrap main in a div with role emphasis? What are the HTML restrictions? Can you wrap a link in emphasis or must you put the <em> inside the link text? I haven't looked up the content model for <em>. If
<joanie> an <em> cannot contain interactive content, or even a heading, for instance, the perhaps the emphasis role should have children presentational true. I think this aspect of appropriate useage must be addressed before merging. We might be able to better address this, or do so mor succinctly, when we hhave an abstract phrase-like role.
<MarkMcCarthy> joanie: mck's comment is above
<MarkMcCarthy> joanie: mck has lots of good questions! but i don't have answers for all of them. based on all this, don't think we're ready to merge
<MarkMcCarthy> ... waiting for others to assist
<MarkMcCarthy> jamesn: the only restrictions we have on this in aria spec is things like children presentational, no other restrictions really
<MarkMcCarthy> jamesn: sometimes in prose
<pkra> they can be nested.
<MarkMcCarthy> jamesn: are there any hierarchy restrictions?
<MarkMcCarthy> joanie: i don't think so, thought we rely on AP to put in specifics
<pkra> q+
<MarkMcCarthy> ack pkra
<MarkMcCarthy> pkra: didn't we have a discussion about nests? the fact they can be nested in html seems like we shouldn't put children presentational
<MarkMcCarthy> Scott_O: there could be a use case for mimicing HTML
<MarkMcCarthy> carmacleod: sounds like children presentational can't work too well
<MarkMcCarthy> jamesn: why wouldn't it be valid to have an entire paragraph emphasized?
<MarkMcCarthy> Scott_O: depends on how close we are to mimicing what HTML allows
<MarkMcCarthy> Scott_O: you could wrap an entire paragraph in em, but follow the proper structure
<MarkMcCarthy> jamesn: i don't really mind whatever we choose, it'll probably work
<MarkMcCarthy> joanie: in the spirit of consensus, could people give this some thought, comment and/or discuss with matt on the PR issue?
<joanie> https://github.com//pull/953
<jamesn> GitHub: https://github.com//pull/953
<MarkMcCarthy> joanie: those with opinions could discuss in the issue. as a screen reader dev, i just need to know what I'm getting
<MarkMcCarthy> Scott_O: i'll get to that asap

[carmacleod]

HTML strong and em are allowed to contain phrasing content, which includes anchor, button, input, select, etc.
So strong and emphasis roles shouldn't have children presentational true.

[carmacleod]

@mcking65

Like the emphasis role, the strong role also needs information describing whether there are any constraints on descendant content.

They are not supposed to contain block-level content, which includes sectioning content, headings, div, paragraph, etc. (so for example, an entirely emphasized paragraph would need to have the em as a child of the p and not the other way around).

However, other than "Required Context Role" or "Required Owned Elements" (which I don't think apply here?) and related prose, are there other places in the ARIA spec where we discuss constraints on descendant content? i.e. Maybe this type of information belongs in the APG?

[scottaohara]

@carmacleod beat me to pushing this comment, i had to leave it alone for awhile to attend to some client work. So apologies for repeating / expanding on some same ideas Carolyn.

strong and em each allow for phrasing content as descendants. So there are restrictions in HTML to the allowed contents of these elements, or what they can be descendants of, but not to the point to indicate descendants of these roles should be presentational.

Regarding appropriate use and constraints, using Matt's example of role=emphasis wrapping a main, in HTML an <em> cannot wrap a <main>. Therefore the emphasis role should also not be allowed to wrap a <main> or role=main. It should only be allowed to be a parent to other roles which would map to HTML Phrasing Content elements / text.

With that said, how should this be outlined in ARIA? Appropriate use and constraints seems to be mentioned in regards to roles that have required owned elements, or a required context role.
But take role=button, for example. HTML <button> allows phrasing content as child elements, and also note that other interactive elements are not allowed. The ARIA specification does not presently indicate such expectations or restrictions.

To outline these considerations for strong and emphasis in ARIA, I'd imagine we'd need to do the same for other roles lacking this sort of information as well?

This could get quite cumbersome if individual roles were outlined whether in the prose or as part of the characteristics table. To mitigate some of this, roles could be categorized as they are in HTML, and then indicate the allowed roles via their categorization (e.g. phrasing content).

OR, a simpler solution to this could be to mention the role should match the HTML element's existing definitions / allowances, and to refer to the related concepts (which already link to the HTML definition)?

Because I do think it's worth mentioning, or at the very least alluding to, these sorts of appropriate uses and constraints.

[mcking65]

@carmacleod commented:

However, other than "Required Context Role" or "Required Owned Elements" (which I don't think apply here?)

Correct, they do not apply because, as defined today, they are not restrictive. Required owned elements definition does not say that other types of elements are not allowed. This, btw, has been a point of author confusion.

@carmacleod continues:

and related prose, are there other places in the ARIA spec where we discuss constraints on descendant content?

Just prose and then children presentational. While children presentational true doesn't say you cannot include child elements of any specific type, it wipes out all child semantics. When it comes to the accessibility tree then, children presentational true is equivalent to a restriction.

@carmacleod asks:

i.e. Maybe this type of information belongs in the APG?

APG is not normative, and this is an important validation issue. I'm pretty certain ARIA should not allow ARIA declarations that conflict with HTML. I think role parity needs to also mean parity of allowed usage.

@scottaohara commented:

With that said, how should this be outlined in ARIA? Appropriate use and constraints seems to be mentioned in regards to roles that have required owned elements, or a required context role.

The definition of required owned elements does not prohibit other type of elements in a context. Perhaps it should though.

@scottaohara continues:

But take role=button, for example. HTML allows phrasing content as child elements, and also note that other interactive elements are not allowed.

While ARIA does not restrict what children a button can have, it does restrict what accessibility semantics will be exposed because children presentational is true. From an accessibility perspective, this is almost equivalent because the accessibility tree is built as if the button contains only text nodes, which is even more restrictive than HTML.

That said, if you create a button with a focusable child, focus will go inside the button. ARIA probably should explicitly prohibit interactive descendants of button. So, I agree that there is a gap here.

@scottaohara continues:

Or, a simpler solution to this could be to mention the role should match the HTML element's existing definitions / allowances, and to refer to the related concepts (which already link to the HTML definition)?

Unfortunately, that would create a normative dependency on HTML, which we do not want.

We might need to:

1. Add language to the definition of required owned elements so it becomes a restrictive characteristic.
2. Add another role characteristic that is equivalent to the HTML content model concept.
3. Examine whether or current categorization of roles could be utilized for enumerating allowed content.

[scottaohara]

Thanks for the detailed reply @mcking65

Largely agree with the points you raised, and per your closing summary:

1. Per modifying the required owned elements definition, seems to me it might be more straight forward to add a new "restricted owned elements" definition. But I agree with you that something should happen here. It just needs to be easy for people to identify what roles are required vs not allowed.

2. Agree.

3. Re: current role categories, I've re-reviewed these and I don't think they'd be suitable. As a quick example, emphasis and strong would allow for button or img as allowed child elements. However, many of the other Widget and Document roles would not be allowed.

Circling back to this PR, should these new ideas be blockers for merging the new roles as they are now? I think with the updates you requested, and @joanmarie implemented, emphasis and strong are no more or less clear about appropriate use and constraints than many other roles presently are in the spec.

I bring this up because if this information is a blocker here, then it likely stands to be a blocker for other new roles that are to be added as well.