Report emphasis (`<em>`) and strong importance (`<strong>`) in browsers

[Qchristensen]

Steps to reproduce:

Reported by Ivan via email.

1. Open a page with text with emphasis. On the NVDA Download page at https://www.nvaccess.org/download/, the text "Please note: NVDA is only available for PCs running Microsoft Windows 8.1 and later." uses <strong> and the text "NV Access does not recommend or support running these older versions on newer Operating systems." uses <em>
2. On NVDA's document formatting settings (NVDA+control+d) ensure "emphasis" is checked.
3. Read the above mentioned text.

Actual behavior:

NVDA reads the text without noting any emphasis. If font attributes are enabled in NVDA document formatting settings, then the <strong> text is reported as bold and <em> text as italic.

Expected behavior:

Text using <strong> should be reported as "Strong" and text using <em> should be reported as "Emphasised".

This comment on a previous issue seems to indicate that this behaviour used to work.

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

NVDA version:

NVDA 2024.4 Beta 4 installed

Windows version:

Windows 11 (64-bit) Version: 23H2, Build: 22631.4169

Name and version of other software in use when reproducing the issue:

Firefox version: 130.0.1

Chrome Version: 129.0.6668.59

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Have you tried any other versions of NVDA? If so, please report their behaviors.

I tried NVDA 2018.4.1 (released a few months after that linked comment) but with the current browser versions, and the text was read identically to how it is read with NVDA 2024.4 beta 4.

If NVDA add-ons are disabled, is your problem still occurring?

No add-ons.

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

[CyrilleB79]

It's worth noting that in MSHTML <em> and <strong> are reported twice, once if "Attributes" is checked and once if Emphasis is checked in Document formatting settings.

MSHTML was used with Internet Explorer, but it is still used in ui.browseableMessage. So you can test in Python console:

import ui;ui.browseableMessage('<p>This is an example for<strong>strongified</strong>or<em>emphasized</em>text</p>', isHtml=True)

Moreover <strong> is reported as "bold" because it has been argued in the past than "strong" would not be understood by many users.

[Adriani90]

I agree reporting "strong" is not common. When communicating with sighted people, the word "bold" or "emphasized" is rather used for text that stands out.

[ivnc]

I think that despite bold is visually correct for labelling this kind of text, we should still distinguish between actual bold (b tag) and emphasis (strong or em), both when reporting it and also in the document formatting options, as it is currently. The problem is that the emphasis option seems not to work, and that prevents users from A. Being able to enable b and strong/em reporting separately, and B. Identifying whether a text is marked as bold only for visual purposes or as strong/em because it is actually highlighted in the page, something between a simple bold and a heading.

[seanbudd]

This can't be fixed due to issues on the browser side. An issue needs to be opened on the chromium and firefox bug trackers. In the meantime, we should remove this option from NVDA.

[CyrilleB79]

The option is working in MSHTML, which is used for browseable messages, and maybe in other components.

Maybe it does not hurt to keep the option?

[seanbudd]

I don't think MSHTML usage really justifies the feature, it creates confusion for users. I do think removing it would be an API breaking change.

[ivnc]

@seanbudd, could you provide more details on what should we request when opening a potential issue in the browsers' bugtrackers? At least in Firefox, the accessibility tree is correctly exposing the strong and emphasis roles for text marked with the strong and em tags, so can't figure out what the issue in the browsers' side could be that prevent this from being fixed. Anyway I would be happy to file issues with the browsers if needed :).