Looking at https://www.w3.org/TR/html50/text-level-semantics.html#the-em-element, it says:

The em element also isn't intended to convey importance; for that purpose, the strong element is more appropriate.

And in https://www.w3.org/TR/html50/text-level-semantics.html#the-strong-element:

The strong element represents strong importance, seriousness, or urgency for its contents.

So on the one hand, they have different meanings; on the other hand, both are "pay attention to this bit more than the other bits" elements. So I personally am leaning towards a single role rather than two.

Somewhat related, I think, to which way we go is the fact that the HTML spec includes this example:

Anger mixed with emphasizing the cuteness could lead to markup such as:
<p><em>Cats are <em>cute</em> animals!</em></p>

in other words, em seems at least in part connected with the spoken presentation. I think that may go beyond the scope of ARIA. Also, APA has a task force related to pronunciation. So perhaps the way to achieve parity for that aspect of em is not through us, but by a combination of using our new pay-attention-to-this-bit role and the to-be-created pronunciation support expected out of APA.

The spec also has:

The level of stress that a particular piece of content has is given by its number of ancestor em elements.

Do we need a level attribute?

in other words, em seems at least in part connected with the spoken presentation.

I think so. The spec has

The em element represents stress emphasis of its contents.

and "stress emphesis" connects with https://en.wikipedia.org/wiki/Stress_(linguistics)#Prosodic_stress.

And the strong element can also be nested to indicate a higher level of strong.

Something else I just noticed regarding the elements in question: Each states that you can use nesting to convey level, e.g.:

The relative level of importance of a piece of content is given by its number of ancestor strong elements; each strong element increases the importance of its contents.

I do NOT think we want to see something like:

<div role="pay-attention-to-this-bit">
   <div role="pay-attention-to-this-bit">
      <div role="pay-attention-to-this-bit">Bla bla bla!</div>
  </div>
</div>

But if we want true parity with that aspect of strong and em, do we want to consider making aria-level be a supported property of our new role? (Yes, I do feel silly for suggesting that possibility, but I don't know what else to do regarding the nested-element "feature" of the elements in question -- other than ignore them.)

The spec also has:

The level of stress that a particular piece of content has is given by its number of ancestor em elements.

Do we need a level attribute?

Github didn't show me your comments until I posed mine in which I say the same thing. Sorry!

aria-level makes sense here. not silly at all. 😄

Follow-up questions:

1. Which is more important: aria-level value of 1 or aria-level value of 100? Are we consistent with heading levels and item levels (in which the biggest, top-level stuff has the smallest number)? Or is an importance level more like a fire alarm (a five-alarm fire being a much bigger cause for concern than a two-alarm fire)?
2. If the author does indeed use nesting (e.g. because the whole sentence is important, but a phrase within it is super important), are user agents expected to calculate the value of aria-level, or are authors expected to specify it?
3. What is the default/fallback value for aria-level?

The answer to 2) seems to depend on what HTML(-AAM) wants.

The answer to 2) seems to depend on what HTML(-AAM) wants.

@stevefaulkner: You have an opinion on this? EDIT: And the rest of the aspects related to aria-level and exposure to ATs. BTW, if strong is for importance and NOT just for bold, then a) is the way to expose it really as a text attribute? and b) should there be a specific way to expose nested strong?/

I am not in favor of "aria-level". I think aria-level is more relvant to something quantifiable concept with a structure, like the value of 3 from 1 to 5. The level of emphais for specific content by content creators seems to be more qualitative and subjective matters, not easily quantifiable.

https://www.w3.org/TR/wai-aria-1.1/#aria-level

1. WYSISWYG editros like CKEditor and TinyMCE will filter out nested STRONG and EM elements, also content management system like Drupal.
2. People can already nest any new strong or emphasis role, for example

<div role="strong"><div role="strong">important</div></div>

so we do not need aria-level

I agree that we do not need aria-level on these roles, because as @jongund points out, they can just be nested. Also, since some editors and cms' filter nested em and strong elements, we probably don't even need to note that it is possible. If AT ever decide to use the information, then guidance can be added to the APG.

Thoughts on whether or not we need two roles or just one pay-attention-to-me role?

If there is only one role would it apply to the following four elements?

• strong
• b
• em
• i

Probably two.

Consider their visual presentations: bold (strong) draws the eye and attention and encourages the reader to pay attention to its contents on first look without regard to the surrounding context; italics (em) are specifically designed not to draw the eye, but to give the marked text some distinguished role in context.

Conversely, a screenreader might well want to read em differently to the surrounding text (e.g., with heavier stress emphasis), but it's not obvious that strong ought to be read differently, or in the same way as em.

I can imagine jump-to-strong being (theoretically) useful but I can't imagine the same for jump-to-em, so I suspect they should be different roles.

If there is only one role would it apply to the following four elements?

• strong
• b
• em
• i

EDIT for clarification: In answer to the original question, if there were one role it would be just for em and strong. The statement below is what would happen if there were two.

One would be for strong and one would be for em. Based on the HTML spec(s), b and i seem to be limited to purely typographical characteristics, thus they are going to be assigned the to-be-created generic role. (The specific typographical characteristics would fall under the heading of candidate attributes during the 1.3 cycle.)

Seems like one role would suffice, unless there is clear authoring advice on where a "strong" role should be used instead of a "emphasis" role, which I think would be hard to get anyone to follow anyway.

my opinion is one role and we potentially in the future(in 1.3) add an attribute to distinguish them. I'm confident at the moment adding a single role is enough.

The thing I'm mulling over is the note from the HTML spec that @joanmarie referenced before:

The em element also isn't intended to convey importance; for that purpose, the strong element is more appropriate.

Using one role but then later adding an attribute to indicate what type of importance/emphasis is meant seems like it could just be settled out of the gate with two roles.

If only starting with a single role, what would the role default to prior to an attribute created to re-distinguish them? strong, or em?

Consider:

<p>
  <span role="new-role">Note:</span> 
  I would <span role="new-role">really</span> like to understand this a bit more.
</p>

With HTML I would have marked that up as:

<p>
  <strong>Note:</strong>
  I would <em>really</em> like to understand this a bit more.
</p>

The way I'd want those to be announced or exposed aren't the same. E.g. For strong I'd expect the screen reader to possibly change volume in which "note" is announced. But for the emphasis, possibly the pitch.

If we go with one role, and a future attribute, authors could go back and revise to:

<p>
  <span role="new-role" aria-emphasis="important">Note:</span> 
  I would <span role="new-role"  aria-emphasis="something">really</span> 
  like to understand this a bit more.
</p>

Again, if we just go with the two roles, it's less the author would have to do:

<p>
  <span role="strong">Note:</span> 
  I would <span role="emphasis">really</span> like to understand this a bit more.
</p>

Thoughts? and thanks :)

I'm afraid I was persuaded more by @scottaohara's argument than the others. 😁 And we need something to review and move forward. So my initial pull request (#953) has two roles.

Roles landed. 0f47d77

A question about the ARIA "strong" role: how good is it supported by browsers and screen readers?
We need to make an HTML element more important, in particular for screen readers.
Using HTML strong/em element is unfortunately not an option.
Is it advisable to use ARIA "strong", and will it be future-proof?
I find this in the editor's draft here: https://w3c.github.io/aria/#strong

@yxieCap

I have tested this with screen reader NVDA and JAWS. By default they behave in such a way that font formatting is not output. However, both screen readers have a mode where font attributes like bold are output.

• JAWS changes the voice for bold words (INS+ALT+S: Proofreading).
• NVDA says "bold" and "bold end" at the beginning and end of the bold word (Settings: Document formatting).

Interestingly, role=strong, <strong> or <b> do not matter (i.e. are always ignored). The only thing that matters is the bold font style (per CSS).

I.e. <strong> oder role=strong is not recognized as bold if it is not bold styled. <span> is recognized as bold if it is bold styled.

Conclusion: <strong> or role=strong should be used if it is semantically correct. Maybe it will be supported in the future or by other screen readers. However, it is not currently supported on Windows by the relevant screen readers JAWS and NVDA. Therefore, <strong> or role=strong should be combined with bold font style and blind users should be advised to enable bold detection if the highlighting is relevant.
Alternatively, highlighting should be omitted and the information conveyed in text form (a warning, e.g., with "Caution: ...")