TypeError: (0 , _prettyFormat.default) is not a function

Question

I recently started to get this problem when running a test:

 Wizard component should have no accessibility violations

    TypeError: (0 , _prettyFormat.format) is not a function

      48 |     const { container } = render(<Wizard />, { wrapper: MockProviders })
      49 |     const result = await axe(container)
    > 50 |     expect(result).toHaveNoViolations()
         |                    ^
      51 | })

I believe I started getting this after a big batch of updates in a monorepo (where this project lives) triggered by a react-scripts upgrade, though I'm not entirely sure about this.

Now while the Wizard component is not really an absurdly massive component (less than 200 lines), it uses like 7 different hooks, 7 times useState alone, and 4 times useEffect. Lots going on. I'm not sure this is even relevant but in any case, now wouldn't be an appropriate time for a refactor.

I'd just like the test to pass because I need to commit other urgent stuff.

Any ideas on what to do in a situation like this? The message TypeError: (0 , _prettyFormat.format) is not a function is not very helpful to me, can't find anything on google... should I ditch this accessibility test? Or how could I try maybe to pinpoint the reason I'm getting this now?

UPDATE

After lots of trials, I've found that it fails because of a custom heading component deep down that renders an h3. It also fails if it renders an h3 directly

It doesn't fail when it renders a h2, but it also fails (with the same error message) when rendering an h4 or h5.

Makes me think of the "Heading levels should only increase by one" rule.

So... axe is the offender; it's not properly displaying an error message and making us spend a huge amount of time on an accessibility issue that honestly, in my opinion, shouldn't matter all that much. Right? Sorry that's just my opinion.

Also... how should we deal with this type of issue when we're working with components? Who knows where a component will be rendered so it knows what semantic heading it should hold?

UPDATE 2

As Graham pointed out, yes, a correct sequence of headers is essential as screen reader users might miss essential content, or it could lead to a poor/confusing user experience. I reconsider my position (was in the heat of the moment)

So in this case I just used the correct heading, as this specific component very likely won't be reused elsewhere.

But otherwise yes, good suggestion, the heading could be passed as prop, or maybe the header text, wrapped by a heading component. Maybe the heading component could have the heading element handled automatically during render time with Context/Provider. If you really need that.

Answer 1

The problem was that the tested component (which has other nested components) when rendered formed an incorrect sequence of headings: an <h1> was rendered and then later on an h3 without an h2 in between.

That's an accessibility violation and results in poor UX and screen reader users potentially missing essential content.

The error message from axe wasn't very helpful, though. I remember having that issue in the past and getting a helpful error message, not sure what happened this time.

UPDATE

Although this really seems to be the reason why I got that error, the accessibility test is still flaky. I've run the test 10 times for each of these scenarios:

• with the right heading element: FLAKY (passed 5 out of 10)
• commenting the heading element: ALWAYS PASS (passed 10)
• with the wrong heading element: ALWAYS FAILS (failed 10)