test(loading): add a11y tests

[dakahn]

reference #4611

Adds some base line checks for various required aria attributes on our Loading component. As well as AAT with Axe and DAP

I'll probably bundle a few components together moving forward but wanted a quick check on my style and approach here before I do too much more work. 👍

[netlify]

Deploy preview for the-carbon-components ready!

Built with commit b8e27b0

https://deploy-preview-4621--the-carbon-components.netlify.com

[netlify]

Deploy preview for carbon-elements ready!

Built with commit b8e27b0

https://deploy-preview-4621--carbon-elements.netlify.com

[netlify]

Deploy preview for carbon-components-react ready!

Built with commit b8e27b0

https://deploy-preview-4621--carbon-components-react.netlify.com

[joshblack]

Quick question, do these overlap with the tests in:

carbon/packages/react/src/components/Loading/Loading-test.js

Lines 82 to 102 in ee3d1a1

	it('should be an assertive live region when active', () => {
	const wrapper = mount(<Loading active={false} />);
	const getLiveRegion = () => wrapper.find('[aria-live]');
	expect(getLiveRegion().prop('aria-atomic')).toBe('true');
	expect(getLiveRegion().prop('aria-live')).toBe('off');
	expect(getLiveRegion().prop('aria-labelledby')).toBeDefined();
	wrapper.setProps({ active: true });
	expect(getLiveRegion().prop('aria-live')).toBe('assertive');
	wrapper.setProps({ active: false });
	expect(getLiveRegion().prop('aria-live')).toBe('off');
	});
	it('should have an associated label for the live region', () => {
	const wrapper = mount(<Loading />);
	const node = wrapper.find('[aria-live][aria-labelledby]');
	const id = node.prop('aria-labelledby');
	expect(wrapper.find(`#${id}`)).toBeDefined();
	});

[dakahn]

@joshblack For sure! I didn't catch that. Maybe let's move those into the new -accessibility block?

[joshblack]

@dakahn would it help if we did a dedicated AVT group with different levels? e.g. a block for AVT, a nested block under that for AVT1, 2, 3, etc. Or does it make sense all together as a functional test?

Thinking about it more, here's what might live in each section:

• AVT1
  • aXe or potentially DAP runs
• AVT2
  • Using functional e2e tests with pressTab and pressEnter or pressSpace to verify reachability and operability
  • Zoom, not sure how to address this
• AVT3
  • Assert relevant ARIA exists that must exist, checking for labels, etc

[dakahn]

@joshblack do we want to do Axe now with an eye toward DAP later -- that was a question I had while working.

As for your suggestion. I like the concept, but the three levels of AVT are kinda IBM-only acronym, ya know? Maybe AAT, Keyboard, and Screenreader?

[joshblack]

@dakahn aXe sounds great now, one thought was that the AVT1 test would be essentially an end-to-end test and we would run aXe on each meaningful stage.

Definitely down to swap out names, what would be preferred? Do we need to sub-divide into the categories like perceivable, operable, understandable, and robust? Or just keep it at AAT, Keyboard, Screen reader?

[dakahn]

Even P.O.U.R is esoteric enough to maybe confuse. I like the three broad categories. How would we handle -- like in this case -- not having any specific keyboard accessibility tests?

[elizabethsjudd]

@dakahn we have been using POUR and are actually swapping it out to the three step approach (because we are internal to IBM only we use AVT 1 -3 but I understand how for open source that might be more confusing). The issue we ran in to with POUR was that is was sometimes confusing to known what category a test/failure fell in to where the 1 - 3 was much more obvious and ultimately more clear to the reader as well.

[joshblack]

Thanks so much for the insight @elizabethsjudd! Really appreciate it 🙏 Definitely not going down that path then haha.

@dakahn I think we're fine with omitting sections if it doesn't make sense. In this case, is the rational that we don't need keyboard because of its status being a live region? If using this in a context of a page, would we expect any keyboard behavior to be happening/not happening? Like if it's pull page loading, would we want nothing focusable, focus lock, etc.

[dakahn]

Right, the expected behavior is that loading is not focusable, but still announces to screen readers

[joshblack]

Would we want to run both on under toHaveNoViolations? Or would that get too weird?

[dakahn]

Keeping them distinct makes sense to me -- breadcrumb for debugging might be a little more clear, but I'm not committed to the idea if combining them is best.

[joshblack]

Does this work if we put it in the toHaveNoDAPViolationsmatcher instead of our setup file?

[dakahn]

I would have thought this was part of Jest's setup -- at least that's what the Jest docs implied. That's where I'd look for it at least 🦐