Charlie Freestone Blog Post - Some Best Practices for Accessible Automation Testing #317

cfreestone-ScottLogic · 2025-05-14T13:19:13Z

Please add a direct link to your post here:

https://cfreestone-scottlogic.github.io/blog/2025/05/14/some-best-practices-for-accessible-automation.html

Have you (please tick each box to show completion):

Added your blog post to a single category?
Added a brief summary for your post? Summaries should be roughly two sentences in length and give potential readers a good idea of the contents of your post.
Checked that the build passes?
Checked your spelling (you can use npm install followed by npx mdspell "**/{FILE_NAME}.md" --en-gb -a -n -x -t if that's your thing)
Ensured that your author profile contains a profile image, and a brief description of yourself? (make it more interesting than just your job title!)
Optimised any images in your post? They should be less than 100KBytes as a general guide.

Posts are reviewed / approved by your Regional Tech Lead.

_data/authors.yml

chriswilty

Overall, plenty of good advice.

I was surprised that an article about testing with "Accessible" in the title only lightly touched on accessibility concerns - using roles to locate elements. I feel this is somewhat misleading, as the rest of the article concerns your thoughts on naming and tagging tests to make them more informative, plus the part which I think is about not worrying too much about specificity, not testing in too much detail the things which are not all that important, none of which is about accessibility.

I would advise changing the title to reflect this.

chriswilty · 2025-05-19T07:06:20Z

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

+categories:
+- Testing
+---
+# Some Best Practices for Accessible Automation Testing


Please remove this one, as your title is provided for you:

Still need this correction.

Sorry I have been busy with client work I shall make this adjustment.

Other way around, need a title in the head section, not in the body of the post:

author: cfreestone
title: Some Best Practices for Accessible Automation Testing
summary: ...

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

chriswilty · 2025-05-19T07:11:30Z

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

+While on my most recent project I had the unique experience of working closely with many testers and test minded individuals. This allowed me to learn some much-needed lessons about how to best implement automation testing with accessibility in mind, a sometimes-overlooked area of test automation.
+
+## Introduction
+What I hope to share with you is how simple it can be to both think about and implement the approach to make sure your tests are accessible. This can be because you have strict reasons on the project to ensure compliance with certain metrics, because this can lead to improved readability of your code and its longevity, or because you want to read some wonderful thoughts from certain Testers perspective.


certain Testers perspective

Not sure what you are trying to say... Do you mean "from a certain tester's perspective", i.e. you? Or did you mean plural "testers"?

I think this introductory paragraph highlights my main question about your article: what does it mean for a test to be accessible, and what do metrics or code readability have to do with that? Are you concerned about making your test code accessible to testers who need to use a screen reader? If so, I think you need to make that clear, and give more examples of how you can achieve that.

Certain testers perspective was meaning myself.

What I wanted to share was skills I learnt which anyone can write in their tests which is in line which accessibility testing. Its not aimed at testers who need a screen reader. Its lessons I have learnt from doing Accessibility testing, which can make your automation tests more accessible.

Certain testers perspective was meaning myself.

Then you want "from a certain tester's perspective" (need apostrophe)

Accessibility testing is about testing that a UI is accessible to all users, whether they are keyboard-only users, have vision or motor impairments, dyslexia, epilepsy, etc. The only part of this article which is about accessibility is locating elements by role. You are not really making your automation tests more accessible, you are making them more readable.

By the way, how did you do Accessibility testing, what tool(s) did you use? That would also make an interesting blog post.

Made the adjustment to add the apostrophes.

The application of these methods was what I picked up while learning about accessibility testing on the project. Readability does allign itself into accessibility. If something is more readable it is inherantly more accessable. The lessons I learnt about accessibility testing I have led to creating tests which are more accessible to others, readability is one of those areas.

By the way, how did you do Accessibility testing, what tool(s) did you use? That would also make an interesting blog post.

I shall keep this in mind for a future blog

Made the adjustment to add the apostrophes.

Ah no, you've added quotation marks around the phrase. I mean this:

from a certain tester's perspective

I still take issue with your use of the word accessible here. You need to be really careful with that word, because accessibility testing (how accessible is your UI) is a totally different ballgame to writing tests in a way that makes them easier for other people to read, modify and maintain - that is not accessibility testing.

Readability or understandability is one very small part of making test code accessible

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

chriswilty · 2025-05-19T07:45:21Z

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

+
+So, when creating Test Names its best practice to instead use the back tick ` as this will then still allow you to use a variable in the test name as seen in this example: 
+
+```test(`should return a 400 when X-CUBE-ASSERT is '${user}'`)```


While the use of backticks when there is no variable to interpolate is somewhat contentious, of far more importance here is that the name of the test contains implementation detail: X-CUBE-ASSERT which is presumably a header. Including implementation detail in a test name is fragile because implementation can change, making the test name confusing or incorrect. Changing an aspect of implementation should not cause us to rename our tests.

Additionally, CUBE is a client and we shouldn't identify, no matter how tenuously, that they are our client.

Ok noted I shall use a different example for this.

Yep that looks a lot better.

You still have an earlier mention of X-CUBE-ASSERT, so change that one also to match.

chriswilty · 2025-05-19T07:54:06Z

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

+
+```test('should return a 400 when X-CUBE-ASSERT is Valid')```
+
+which uses single quotation marks ' as what you are passing into the name is a string. However, it can be difficult when you wish to pass in a variable to that same string, as variables are noted by single quotation marks also. 


To be nitpicky, "as the name is a string" is more accurate.

Also I suggest putting that single-quote in backticks like `'` so it stands out in the text, like this:

single quotation marks ' as

Ah sorry, my suggestion was unclear, i meant this:

as what you are passing into the name is a string
as ~~what you are passing into~~ the name is a string
as the name is a string

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

chriswilty · 2025-05-19T07:56:37Z

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

+
+```test(`a test example to show a test name for a test under ticket RBP-000`, {tag: 'RBP-000'}, async()```
+
+Here you can see that the tag simply just needs to be placed at the end of the test name and is separated with a comma. For good practice this should be the ticket number that the work is being generated from.


Use "simply" or "just", not both.

It's not really as simple as separating with a comma, as you are needing to pass your (single) tag in as an object (hence the curly braces), as the second argument to the function.

Playwright docs state tags must begin with @ char:
https://playwright.dev/docs/test-annotations#tag-tests

In fact, playwright docs show using annotations for marking tests against an issue:
https://playwright.dev/docs/test-annotations#annotate-tests

I have added the @ symbol as that is something which has been missed on the example. I do still think descibing it as simple is correct. Would you prefer it to say something along the lines of "tag object"

The wording just felt odd on first read, as comma separation is just how we separate parameters in javascript, but we know what you mean and the more I read it the more it seems fine! So ignore me.

For good practice this should be the ticket number

Playwright suggestion is to use annotations for ticket number. Tags are used for filtering tests to run, or filtering test results, not for tracking / annotating tests with issue numbers, so I would argue this might not be Good Practice if you are following Playwright's own guides 😉

Added another paragraph to explain this.

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

chriswilty · 2025-06-06T15:23:35Z

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

+
+By the same accessible reasoning it is good practice to not use `.getbyTestID`.This is due to the fact that names of those same ID’s will not be useful to someone with an accessibility issue, as it will sound like Jargon when navigated to.
+
+Sometimes though this may not of been implemented on the project. This requires roles to be assigned correctly on the project you are on, things like test ID's or divs could of been used instead which makes this impossible to implement. When this is the case its always best to have that conversation with the team so that you can explain how useful and helpful having roles can be.


may not have been implemented

could have been used instead

When this is the case it is best to

how useful and helpful HTML roles are.

chriswilty · 2025-06-06T15:26:21Z

_posts/2025-05-14-some-best-practices-for-accessible-automation.md

+
+Here you can see that the tag simply needs to be placed at the end of the test name and is separated with a comma. For good practice this should be the ticket number that the work is being generated from.
+
+If you want to go the extra mile its even better to use annotations for ticket numbers. That way tags can be used excusivly to filter what tests are ran, filtering test results. This is what is documented in the Playwright documenteation. 


it's even better (need apostrophe)

Playwright documentation

cfreestone-ScottLogic added 3 commits May 14, 2025 14:02

Adding a new user

c6a042d

Create blog post

e14ac3e

Update formating

f37e213

kellis-sl reviewed May 15, 2025

View reviewed changes

_data/authors.yml Outdated Show resolved Hide resolved

Update authors yml

d02e6c8

kellis-sl approved these changes May 16, 2025

View reviewed changes

chriswilty requested changes May 19, 2025

View reviewed changes

cfreestone-ScottLogic added 2 commits May 19, 2025 15:07

Add improvents based from comments left on PR by chriswilty

f92db1f

Changes to blog

cbeba45

chriswilty reviewed Jun 6, 2025

View reviewed changes


		So, when creating Test Names its best practice to instead use the back tick ` as this will then still allow you to use a variable in the test name as seen in this example:

		```test(`should return a 400 when X-CUBE-ASSERT is '${user}'`)```


		```test('should return a 400 when X-CUBE-ASSERT is Valid')```

		which uses single quotation marks ' as what you are passing into the name is a string. However, it can be difficult when you wish to pass in a variable to that same string, as variables are noted by single quotation marks also.


		```test(`a test example to show a test name for a test under ticket RBP-000`, {tag: 'RBP-000'}, async()```

		Here you can see that the tag simply just needs to be placed at the end of the test name and is separated with a comma. For good practice this should be the ticket number that the work is being generated from.


		By the same accessible reasoning it is good practice to not use `.getbyTestID`.This is due to the fact that names of those same ID’s will not be useful to someone with an accessibility issue, as it will sound like Jargon when navigated to.

		Sometimes though this may not of been implemented on the project. This requires roles to be assigned correctly on the project you are on, things like test ID's or divs could of been used instead which makes this impossible to implement. When this is the case its always best to have that conversation with the team so that you can explain how useful and helpful having roles can be.


		Here you can see that the tag simply needs to be placed at the end of the test name and is separated with a comma. For good practice this should be the ticket number that the work is being generated from.

		If you want to go the extra mile its even better to use annotations for ticket numbers. That way tags can be used excusivly to filter what tests are ran, filtering test results. This is what is documented in the Playwright documenteation.

Charlie Freestone Blog Post - Some Best Practices for Accessible Automation Testing #317

Are you sure you want to change the base?

Charlie Freestone Blog Post - Some Best Practices for Accessible Automation Testing #317

Uh oh!

Conversation

cfreestone-ScottLogic commented May 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

chriswilty left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

chriswilty May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chriswilty May 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cfreestone-ScottLogic commented May 14, 2025 •

edited

Loading

chriswilty May 19, 2025 •

edited

Loading

chriswilty May 20, 2025 •

edited

Loading