search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.11k stars 637 forks source link

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

Open Qchristensen opened 1 month ago

Qchristensen commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 :).

seanbudd commented 1 month ago

I'm not sure if this information is exposed via the IAccessible buffer in Firefox, it's possible that nothing needs to be done if they are exposed in the accessibility tree, but the tree doesn't always match whats exposed to the screen reader.

@michaelDCurran - are we sure this is still blocked on the browser side. These bugs that seem solved in VoiceOver make me think this work is unblocked: