Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Lukas-Kullmann opened this issue Mar 28, 2024 · 3 comments
Open

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

Lukas-Kullmann opened this issue Mar 28, 2024 · 3 comments

Comments

@Lukas-Kullmann
Copy link
Contributor

  • @testing-library/dom 9.3.4 version:
  • Testing Framework and version: N/A
  • DOM Environment: 20.0.3

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
Copy link
Contributor

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 web-platform-tests/wpt#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/[email protected]:

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
Copy link
Contributor Author

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
Copy link
Contributor

jlp-craigmorten commented Apr 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants