nvaccess
NVDA no longer reading individual SVG elements.
Steps to reproduce:
- Open https://jsfiddle.net/xw1zgf6t/show (see code at https://jsfiddle.net/xw1zgf6t/)
- Browse using NVDA default settings and down arrow. DEBUG-level log attached.
Actual behavior:
The SVG is read as a single unit. In some larger SVGs, the elements seem to be split into groups, but NVDA still reads the group as a single unit, and there appears to be no way to navigate the individual elements. (The grouping behavior can be observed with e.g. this demo: https://www.highcharts.com/samples/highcharts/accessibility/accessible-line/).
Expected behavior:
Other popular screen readers (e.g. JAWS, VoiceOver) allow users to navigate individual SVG elements with an aria-label and img role. This is helpful in our case for creating accessible SVG charts.
System configuration
NVDA installed/portable/running from source:
Installed from https://www.nvaccess.org/download/.
NVDA version:
2019.2.1
Windows version:
Windows 10 Pro 10.0.17134 Build 17134
Name and version of other software in use when reproducing the issue:
Mozilla Firefox v70.0.1 (64-bit)
Other questions
Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
Older (unknown version) NVDA with older (unknown version) Firefox behaved as other screen readers, announcing the individual SVG elements.
Confirmed still happens with latest NVDA (2020.3) and Firefox (82.0.2). Any updates?
To be clear, I don't speak for NVDA core developers here, since I'm not one. Just dropping in some thoughts.
The elements are already rendered separately. For example, you can navigate between them with g and shift+g and they also show up on separate lines with screen layout disabled.
I guess the problem being reported here is that they are rendered on the same line. These SVG elements are inline and it's intentional that NVDA renders inline elements on the same line when screen layout is enabled, which it is by default. (In contrast, JAWS has screen layout disabled by default.)
I can see how this is not ideal for charts. I don't really have a solution that isn't going to break other kinds of inline graphics, though. I guess a special exception could be made for SVG elements, but special exceptions are ugly and there's no solid justification for this beyond this specific use case.
@jcsteh Thanks for replying.
I would caution against dismissing the use case as minor or theoretical, given today's massive focus on graphics. Our interactive charts see major use in critical applications worldwide, including finance, healthcare, and education - and making these services accessible is of great importance to society in general if we are aiming for equal opportunity.
As a developer I sympathize with the reluctance towards ugly workarounds, but I would argue that considering an exception for SVG graphics should be obvious, to ensure that the technology is not taking a step backwards in usability and accessibility for potentially essential applications.
The state of SVG accessibility has been more robust in later years, and has paved the way for more accessible graphics, but inconsistent behavior between AT and browsers will undoubtedly make this harder - both for vendors and end users.
I would caution against dismissing the use case as minor or theoretical, given today's massive focus on graphics.
To be clear, I wasn't dismissing this as minor or theoretical. My point was that the change being considered here would be relevant only to one web library. We don't have any data to suggest that other SVG use cases would benefit from this change (or indeed that it wouldn't detriment them).
I would argue that considering an exception for SVG graphics should be obvious, to ensure that the technology is not taking a step backwards in usability and accessibility for potentially essential applications.
Only if you take as given that NVDA's current behaviour is always incorrect. See below.
The state of SVG accessibility has been more robust in later years, and has paved the way for more accessible graphics, but inconsistent behavior between AT and browsers will undoubtedly make this harder - both for vendors and end users.
In contrast to JAWS or VoiceOver, NVDA's default behaviour is screen layout; i.e. to render inline elements on the same line. This gives the user a better sense of what is contained on a line, which can be important for context and efficiency; consider a Wikipedia article with lots of inline links or a credit card number entry split into four fields. JAWS has an option to enable this, but it isn't default. I'm not sure about VoiceOver. The behaviour between ATs is thus already "different"; this isn't specific to SVG.
There are arguably cases where this is correct even for SVG. For example, if a list item contains an SVG icon on the same line as the text content, it shouldn't be rendered on a separate line to the text of that item. The SVG special casing you're asking for here would break that.
@jcsteh Thank you for taking the time and clarifying further.
The practice of marking up SVG elements to provide an accessible structured graphic is by no means unique to our library - nor would we want it to be, as it is fantastic technology for presenting such information in an accessible way. The W3C even published the WAI-ARIA Graphics Module in 2018 as an extension to ARIA to allow even clearer semantics when marking up structured SVG for accessibility. The SVG Accessibility Task Force and SVG Accessibility Working Group are forces behind this work. This continued commitment from the W3C should serve as a clear indicator of the intended direction of SVG for accessible web graphics.
Our library is the largest charting library currently taking advantage of the accessibility features available with SVG, but there are also other charting vendors using similar techniques. In addition there are myriads of use cases for structured SVG graphics in infographics, maps, scientific and educational illustrations - often created from scratch or dynamically with libraries such as D3.js.
It sounds to me like there is a need for additional control of the NVDA screen layout behavior in order to always provide the best experience for the end user - given that SVGs often should be treated as separate structures.
Practically speaking, perhaps NVDA could intelligently select between screen layout enabled/disabled based on the contents of the SVG? I imagine an SVG with subelements with accessible names generally should not be considered an inline graphic. If this is not feasible, perhaps the author could provide markup to indicate the desired behavior?
@CyrilleB79 Apologies if I am missing something, but I can not see a link between these issues. Did you add the intended issue number?
The practice of marking up SVG elements to provide an accessible structured graphic is by no means unique to our library - nor would we want it to be, as it is fantastic technology for presenting such information in an accessible way.
Right. The question here is whether presenting individual SVG elements as block elements is always correct for users of screen layout. For charts, sure, it probably is. There are other forms of graphical content, though.
perhaps the author could provide markup to indicate the desired behavior?
That would be the ideal path, but there is no markup in any spec (other than CSS, which impacts visual presentation) that allows an author to specify block vs inline. The thinking is probably that block vs inline is a purely visual thing and has no semantic parallel. I disagree with that assessment.
given that SVGs often should be treated as separate structures.
To be extra clear, NVDA already treats them as separate structures. The question is whether they should be treated as being on the same line. Line separation and structural separation are not the same thing. It's easy to conflate them because JAWS and VoiceOver behave this way by default.
Sorry for the erroneous reference in my previous comment (error with automatic GitHub suggestion list); I have hidden it.
I wanted to write: See also related issue #11716.
@CyrilleB79 Thank you for clarifying. Turning off screen layout mode by default would certainly alleviate our specific issue. From the discussion with @jcsteh I think it is still interesting to consider how NVDA should ideally behave with SVGs in screen layout mode however.
@jcsteh
The question here is whether presenting individual SVG elements as block elements is always correct for users of screen layout.
My postulation is that it would be correct disproportionately more often than not. I have yet to see examples of SVG graphics that are marked up accessibly in a way where an inline presentation would be preferable. I am sure they exist, but I would consider them edge cases. Apologies if I am missing something obvious here.
Of course icons, logos, clip-art and other use of SVG as a generic vector graphics format could be presented inline, as long as they do not contain subtrees with accessible information. But SVG introduces its own concept of groups and elements, and to me it is a stretch to assume that this tree should always be flattened by default. If care has been put into making this tree accessible I would argue that flattening it can safely be assumed to be undesirable.
Add display: block; on the sub svg elements you want to read separately.
@seanbudd here is another use case which speaks for screen layout to be off by default, onsistent with what other screen readers do. @jcsteh another use case is braille users,, who cannot distinguish how long the label of an inline interactive elementt is, if there is plain text in between (e.g. links in a plain text paragraph.
So in fact, I think there are more advantages to have screen layout off by default than vice verrsa. Some people with a bit of sight would argue against this, but they can turn it on on demand if they need it. NVDA is primarily a software for blind, and visually impaired people can also use it for their needs, but in my view, in a conflict situation like this, the default behavior in NVDA should serve blind people in the first place.