1324569 - SVG content not heard in screen readers.

Status: REOPENED

(Core :: Disability Access APIs, defect, P3)

Description

[stomme poes]

Using this test page: http://www.stommepoes.nl/work/firefox_svg.html
where I have inline SVGs, both inline with text and inside buttons. Some have only a title tag inside them with content; others have the additional accessibility hack of aria-labelledby on the SVG itself pointing to the title element and an explicit img role.

I expect in at least the last case to get the SVG content read out in various screen readers. I am not certain if the tree produced by Firefox is correct within the spec or is lacking something.

NVDA (2016/latest) on Firefox 50/Win 7/64-bit reads the SVG content, both inline and in buttons. However JAWS 16 does not (it does on IE11 and latest Chrome). Orca 3.18 on Ubuntu 14/trusty 32-bit also does not read the content.

Joanmarie confirmed that Orca 3.22.x DOES read out the SVG content.

I used Surkov's DOM Inspector on Linux and the SeaMonkey version on Windows to see if I could find the buttons getting an accessible name from their SVG content. The SVGs with titles did show them having a name and the ones with the explicit img role had the correct role, however I'm unsure if what I'm seeing in the Dom Inspector is what I should be seeing.

This is possibly actually a JAWS bug though I don't know what the problem is with older Orca.

Comment 1

[Marco Zehe (:MarcoZ)]

Alex, a quick test from my end shows that the first two buttons do indeed *not* get an accessible name from their SVG children. The third button and the rest are OK. Any idea why? Are we ignoring graphic/diagram accessibles as children for button acc name retrieval for some reason?

Comment 2

[stomme poes]

Third button should be the aria-label one, added as an example of what I expected to hear with the first two (or, at least button #2).

Comment 3

[alexander :surkov (:asurkov)]

If I understand right that these examples are examined:

<button type="button">
        <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
          <title>Remove</title>
          <use xlink:href="#remove"></use>
        </svg>
      </button>

<button type="button">
        <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" role="img" aria-labelledby="title2">
          <title id="title2">Warning</title>
          <use xlink:href="#warning"></use>
        </svg>
      </button>

and the buttons should pick up name from the subtree. What are accessible trees for these?

Comment 4

[stomme poes]

Is there a better way to post the tree besides screenshots? I have a screenshot of the SeaMonkey version of the DOM Inspector: http://www.stommepoes.nl/work/acc_tree.png
The second red area is the button with Remove SVG. The fourth red area is the button with Warning SVG. The last one which is outlined and focussed on is the button with aria-label, so should be ignored. Is this screenshot showing correctly the tree?

So the two buttons with SVGs, the SVGs have Names and Roles however the pushbuttons they are inside of have no Names (the button with aria-label is the only one with a Name).

Comment 5

[Dennis]

The second case in the code above (https://bugzilla.mozilla.org/show_bug.cgi?id=1324569#c3)seems to work now with Firefox and NVDA (see https://weboverhauls.github.io/demos/svg/). It is the ARIA version. The first case still does not work.

Comment 6

[Andy]

I just stumbled upon this due to a stack overflow question.

Apparently, the <title> contents are correctly used as the element’s name in Firefox’ accessibility tree, but it is not read by NVDA 2023.1.
According to https://github.com/nvaccess/nvda/issues/13863 this is related to Firefox’ choice of default role for SVG.

In my case it works:

• Not for a simple SVG
• Logically neither as the accessible name for an input or button

Using aria-labelledby does not change the situation, only <svg aria-label="… does.

Changing the SVG’s role to role=img seemed to help in one case, but not another, weird.

Comment 7

[Nathan LaPré]

I've done some work on accessible naming in Gecko, and, after retesting these cases in latest Nightly, Firefox passes the test cases here. I'm not 100% sure, but I suspect it was due to my work for Bug 1865582.

Comment 8

[James Teh [:Jamie]]

(In reply to Nathan LaPré from comment #7)

I've done some work on accessible naming in Gecko, and, after retesting these cases in latest Nightly, Firefox passes the test cases here.

How did you test these? For me, the first test case isn't read by NVDA at all, though the version within the button now is.

Comment 9

[Nathan LaPré]

Ugh, sorry - I missed that the first example isn't read out. I just tested the button examples in Comment 1 and 3. NVDA does read out the first SVG test case on the Comment 1 test page if you object navigate to it, but it's not included in the readout of the entire paragraph. NVDA does read it out as part of the paragraph in Chrome.

So, I'm reopening this with the caveat that this is now the only failing test case:

<p>1. The way SVGs could work but so far not everywhere: 
  <svg focusable="false">
    <title>Remove</title>
    <use xlink:href="#remove"></use>
  </svg> (you should hear "remove" according to spec).
</p>