Accessibility issue with SVG
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
People
(Reporter: curt.bellew, Unassigned)
References
(Blocks 1 open bug)
Details
Steps to reproduce:
A simple svg such as this --
<svg width="100%" height="100%">
<g><text dominant-baseline="text-before-edge" y="80" x="607" text-anchor="middle">2</text></g>
<g><text dominant-baseline="middle" x="605" y="116" text-anchor="middle">12.4%</text></g>
</svg>
Actual results:
Screen readers read out the svg as 212.4% instead of separately reading them out as 2 and 12.4% separately. This was tested on Windows using NVDA and JAWS.
This only seems to duplicates in Firefox. The accessibility tree looks normal to me and does not suggest why this is happening.
Expected results:
Each value should be read out separately as the user uses their virtual cursor to navigate the elements
2
Down Arrow
12.4%
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Thanks for the report.
Testing with NVDA using both eSpeak and Windows OneCore voices, NVDA reports "2 12.4%", not 212.4% here. That is, the 2 is separated. However, they do appear on the same line, which isn't ideal in this case.
Screen readers decide whether to render content on separate lines based on whether the element reports as block or inline. Otherwise, something like Some <ins>inserted</ins> text
would be read as three separate lines instead of one. In Firefox, these SVG text elements are treated as inline instead of block for some reason, but in Chrome, they are treated as block.
I guess we'll need to fudge accessibility exposure of the display style in this case.
Updated•3 years ago
|
Description
•