testing-library / dom-testing-library

🐙 Simple and complete DOM testing utilities that encourage good testing practices.
https://testing-library.com/dom
MIT License
3.27k stars 467 forks source link

ByRole doesn't find SVG's graphics-document role #1295

Open Lukas-Kullmann opened 8 months ago

Lukas-Kullmann commented 8 months ago

Basically, it's still this Bug: #1131 The upstream issue was closed more than 1.5 years ago, yet the bug still persists. Is there a possibility that this can be fixed?

jlp-craigmorten commented 8 months ago

Agreed, testing in the latest v10 alpha channel for @testing-library/dom it looks like support for implict graphics roles per https://www.w3.org/TR/svg-aam-1.0/#mapping_role_table is not currently supported and the following chain of issues and updates didn't resolve it:

The changes to aria-query added the existence of such roles but did not associate the svg HTML element with the implicit role of graphics-document per the OP so there is outstanding work needed in aria-query to support this implicit role.


Relevant specifications:

HTML element Implicit ARIA semantics (explicitly assigning these in markup is NOT RECOMMENDED)
SVG role=graphics-document as defined by SVG AAM

It's worth noting that specifications such as SVG-AAM are still W3C Working Draft so are far from stable - e.g. the first Web Platform Tests to cover the GRAPHICS-ARIA and SVG-AAM specifications were only added last year (2023) in May and November respectively, and are fairly sparse due to lots of specification issues not yet decided/resolved (see https://github.com/web-platform-tests/wpt/blob/master/svg-aam/role/roles.html).

There currently isn't a Web Platform Test to cover the implicit role of graphics-document for <svg>. I've raised https://github.com/web-platform-tests/wpt/issues/45440 to address this.


As an aside, explicit roles appear to work fine - see example test cases taken loosely from https://github.com/web-platform-tests/wpt/tree/master/graphics-aam using @testing-library/dom@v10.0.0-alpha.2:

import { screen } from "@testing-library/react";

describe("explicit graphics roles support", () => {
  afterEach(() => {
    document.body.innerHTML = "";
  });

  test("should support an explicit `graphics-document` on a `svg` and an explicit `graphics-symbol` role on a `g` element", () => {
    document.body.innerHTML = `
    <svg xmlns="http://www.w3.org/2000/svg" role="graphics-document">
      <g id="test" role="graphics-symbol" aria-label="lightbulb">
        <circle r="10" />
      </g>
    </svg>`;

    expect(screen.getByRole("graphics-document")).toBeInTheDocument();
    expect(
      screen.getByRole("graphics-symbol", { name: "lightbulb" })
    ).toBeInTheDocument();
  });

  test("should support an explicit `graphics-document` on a `svg` and an explicit `graphics-object` role on a `g` element", () => {
    document.body.innerHTML = `
    <svg xmlns="http://www.w3.org/2000/svg" role="graphics-document">
      <g id="test" role="graphics-object" aria-label="door">
        <rect fill="darkKhaki" stroke="#632" width="50" height="90" />
        <circle fill="gray" stroke="#444" stroke-width="0.7" cx="10" cy="50" r="4" />
      </g>
    </svg>`;

    expect(screen.getByRole("graphics-document")).toBeInTheDocument();
    expect(
      screen.getByRole("graphics-object", { name: "door" })
    ).toBeInTheDocument();
  });

  test("should support an explicit `graphics-document` on a `svg` and an explicit `graphics-symbol` role on a `g` element", () => {
    document.body.innerHTML = `
    <svg xmlns="http://www.w3.org/2000/svg" role="graphics-document">
      <g id="test" role="graphics-symbol" aria-label="lightbulb">
        <circle r="10" />
      </g>
    </svg>`;

    expect(screen.getByRole("graphics-document")).toBeInTheDocument();
    expect(
      screen.getByRole("graphics-symbol", { name: "lightbulb" })
    ).toBeInTheDocument();
  });
});
Lukas-Kullmann commented 7 months ago

Thank you for your comment, @jlp-craigmorten !

I also noticed that testing library seems to not take the <title> tag into account when it's used with a <g> element:

I think this test should work:

  test("should support an implicit `graphics-document` on a `svg` and an explicit `graphics-symbol` role on a `g` element + using `title` tags for lables", () => {
    document.body.innerHTML = `
    <svg xmlns="http://www.w3.org/2000/svg">
      <title>room layout</title>
      <g id="test" role="graphics-symbol">
        <title>lightbulb</title>
        <circle r="10" />
      </g>
    </svg>`;

    // ✅ this works
    expect(screen.getByRole("graphics-document", { name: "room layout" })).toBeInTheDocument();

    // ⚠️ this doesn't
    expect(
      screen.getByRole("graphics-symbol", { name: "lightbulb" })
    ).toBeInTheDocument();
  });

However, this seems not to work for me in @testing-library/dom v9.3.4

Note that it works if you specify aria-labelledby explicitly:

  test("should support an implicit `graphics-document` on a `svg` and an explicit `graphics-symbol` role on a `g` element + using `title` tags for lables", () => {
    document.body.innerHTML = `
    <svg xmlns="http://www.w3.org/2000/svg">
      <title>room layout</title>
      <g id="test" role="graphics-symbol" aria-labelledby="lightbulb-id">
        <title id="lightbulb-id">lightbulb</title>
        <circle r="10" />
      </g>
    </svg>`;

    expect(screen.getByRole("graphics-document", { name: "room layout" })).toBeInTheDocument();
    expect(
      screen.getByRole("graphics-symbol", { name: "lightbulb" })
    ).toBeInTheDocument();
  });

I don't know if this is related or not, but it feels like it is.

jlp-craigmorten commented 7 months ago

When it comes to accname extensions with the likes of <title> I doubt it has been implemented in very many places, certainly not the likes of https://github.com/eps1lon/dom-accessibility-api which drives the accname algorithm aspects of Testing Library.

For example, tests in WPT for browsers were only added 5 months ago to the SVG-AAM test suite, see https://github.com/web-platform-tests/wpt/blob/master/svg-aam/name/comp_host_language_label.html.

Would recommend raising an issue against dom-accessibility-api to consider adding support for SVG accname algorithm extensions.