Open Bug 1324569 Opened 8 years ago Updated 1 year ago

SVG content not heard in screen readers.

Categories

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

defect

Tracking

()

People

(Reporter: stommepoes, Unassigned)

References

(Blocks 1 open bug, )

Details

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.
Flags: needinfo?(surkov.alexander)
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?
Blocks: namea11y
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
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?
Flags: needinfo?(surkov.alexander)
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).
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.
Severity: normal → S3

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.

You need to log in before you can comment on or make changes to this bug.