Brief Summary
This video introduces a new accessibility rule in Cypress that identifies potential accessibility issues in custom components by comparing HTML and page interactions during tests. It highlights scenarios where elements, despite appearing visually correct and being clickable in tests, lack the appropriate semantic structure for accessibility, such as using <div> or <span> elements styled as buttons instead of actual <button> elements. The rule helps catch issues that static analysis tools like Axe Core might miss, ensuring a more accessible user experience.
- The new accessibility rule in Cypress identifies potential issues in custom components.
- It compares HTML and page interactions during tests to find elements lacking proper semantic structure.
- The rule catches issues that static analysis tools like Axe Core might miss.
The video introduces a new accessibility rule in Cypress, designed to supplement Axe Core rule sets. This rule helps identify accessibility problems in custom components that might not be apparent through static analysis. It focuses on comparing the HTML structure and page interactions during tests to reveal potential issues.
A Cypress test recorded to the cloud is examined to demonstrate the rule in action. The test involves finding and clicking elements using various methods, including testing library find by role and IDs. Although the test itself doesn't include explicit accessibility checks, the new rule identifies several suspicious elements that are clicked but lack proper accessibility semantics.
The first example involves a button element with an icon but no text, which Axe Core flags as an incomplete button pattern. This is because the HTML indicates it should behave as a button, but it's missing essential attributes. This type of issue is detectable through static code analysis.
The second example highlights an SVG element inside a <div> with a class of "button." Unlike the previous example, Axe Core doesn't flag this because the <div> is treated as generic content without specific expectations for interactive behavior. Visually, it appears identical to a button, but semantically, it lacks the necessary accessibility attributes.
The third example involves a <span> element with the role of "button." While it partially fulfills the button contract and might be located using testing libraries find by role command, it still fails Cypress's accessibility check. This indicates that it's not fully compliant with accessibility standards and requires manual review to determine if it should be replaced with a standard <button> element.
The video concludes with an invitation to try out the new accessibility rule with a one-week trial. Interested users can fill out a form to gain access and see how the rule works with their own Cypress tests and applications.
Summarize any YouTube video in seconds
Get summaries like this one for any video, in your language, with the free Summ app.
Transcript
Full transcript of “Find Accessibility Issues in Custom Components using Cypress Accessibility”. Click a timestamp to open the video at that moment. Need another video? Use the YouTube transcript generator.
0:00 Hey folks, let's take a look at this new accessibility rule in Cypress Accessibility. This runs in addition to the Axe Core rule sets and it helps you find custom components and things like that that might have accessibility problems that are not considered issues in a static analysis scan, but can be revealed by comparing the HTML and the page with the interactions that take place in your tests. So, we have a Cypress test here that was recorded to the cloud. We'll take a look at what the test did. It finds elements in various ways. We use testing library find by ro. We just use the ID sometimes and we're able to see these elements in the page and click them and verify some side effects. So this test is just using the buttons. There's no accessibility check in the test itself. However, this rule has a bunch of findings to check out
0:46 because three of these elements are suspicious in that you're clicking on them in the test but they don't have the appropriate semantics for accessibility. To explain this, let's look at this example first. This is a button element. We're going to open up the dev tools and print out this button. We can debug it here. This is a standard AX core finding. This is where the button is created. It has an icon inside, but there's no text. And so, because of that association, Axe core can say we have an incomplete button pattern. Essentially, we have something that we know is supposed to behave a certain way because of the HTML, but it's not doing everything it's supposed to do. And that's kind of a code static analysis check that lets us find this button with axe core. The next one here is not showing up in the axe core check. So I'm
1:32 going to print this one out as well. So here this is flagging the SVG element um that gets clicked here where the icon is clicked. And we can go over to the elements panel and say okay well it's inside of a div. Is the div accessible? It's not even a button element. It's just a div with a class of button. And so visually these two things are identical. But as far as axe core is concerned, this one is a button that's supposed to have a name and everything. And this one here is just content. It's just a div. It doesn't get assigned any particular expectations for interactive behavior. Similar story on this next button down in the page. This is going to turn out to be a span. An interesting twist here though is this has the role of button. So it's partially fulfilling the button contract. And in our test that we looked
2:18 at, this is located with testing libraries find by roll command. So you might rightly think that this is like, you know, an accessible part of the page, but there's just more to what a button is supposed to have. Uh, and so it has an element. This is not passing Cypress's check. This is something that deserves a manual review to figure out if you should just switch to the standard button element, which is passing everything. If you're interested in how this would work for you, we have a oneweek trial available. sort of no questions asked, no obligation, no demo call. Uh just fill out this form and you'll be able to get access to the trial and then we'll set you up and you'll see how this works with your own Cypress tests and the way that they interact with your application.
