Accessible Forms and Images in Gatsby

Published: April 18, 2020 | 3 min read

Making apps accessible to all users is something I aim for whenever I do any design or engineering, so this particular 100 Days of Gatsby challenge is near and dear to my heart. I completed these steps during Challenge 1, however, because the site is more expanded, I did a re-audit to make sure nothing broke in the process.

Re-auditing my site:

Once I started re-auditng the site for accessibility, I noticed that the form <labels> were not being recognized as properly with their respective <inputs> anymore, so I made sure that the id attribute was clearly added to each input. The component was relying on using spreaded props before this. The <iframe> embeds were missing the title attribute which provides descriptive information for screen readers, so I added those in.

I also noticed that any of the MDX files that used a default export in the document would fail the accessibility audit, because they would not use the default layout defined in my gatsby-config file. The default layout file I used contained my<SEO> component, which injects a lang attribute into the <html> element to help search engines return language specific results, and a page <title> element in the <head> to describe the purpose of the page. Importing the <SEO> component into those particular files solved the issue.

Once all those accessibility issues were solved, I chose to focus on getting end-to-end testing scaffolded using Cypress, along with some unit testing on one component as a proof of concept.

I decided to tackle setting up Cypress CI GitHub action in my kathleenmcmahon.dev site… later.

Setting up unit and end-to-end testing:

While I was setting up my unit testing config, I had to remember to refer to the config file's code snippet repeatedly when referencing the creating a configuration file for Jest section documentation.

As I went back and started adding support for unit testing with Jest, I learned that I should delete the cypress/integration folder. Otherwise, the test script that called Jest would also look at that integration folder and try to test it. I deleted it, but still, Jest was running tests that lived in the cypress/e2e folder. Odd. I then tried going about it using the steps described in the Gatsby documentation on testing React components, then tried using @testing-library/react and @testing-library/jest-dom instead. Still no luck.

Then... I noticed this sentence in the documentation:

Lastly you need to tell Jest where to find this file. Open your jest.config.js and add this entry to the bottom after setupFiles.

I wondered if order was important in the config, since the link to the using-jest Gatsby example at the bottom of the page showed a different order in the config.

setupFiles in that example was listed after the setupFilesAfterEnv in the example repo config, rather than before. I changed the order in my config file and still ran into issues. After some digging, I discovered that file naming is important.

When adding both Jest and Cypress support into the app, if you named your Cypress test file according to the writing tests for Cypress section and named your file accessibility.test.js rather than accessibility.js, Jest would try to run a test on that file. Once I removed the .test from the file name, all tests ran smoothly.

Another way I could have avoided this issue was to add cypress as one of the items to the exclude/ignore files from Jest coverage statement in the jest.config.js testPathIgnorePatterns array https://codewithhugo.com/jest-exclude-coverage/

Items to tackle later

I’d love to try out testing components that use GraphQL in Storybook, because I really enjoy all the features Storybook provided when I used it for the O'Reilly Design System component testing. Also, I’m planning to look into using Cloudinary to host my images.

That wraps up this challenge. Next on my list, 100 Days of Gatsby — Challenge 9.