A JAWS Screen Reader Users Guide to Creating Jira Tickets
Back in March, when I decided to publish a series of articles to begin documenting how to perform certain basic tasks in Jira using the JAWS screen reader, I had a few different goals in mind. First, as an assistive technology user who almost exclusively relies on keyboard navigation, I thought it was important to contrast this lesser known, and oftentimes more difficult to learn/master keyboard-only approach, with the typical experience of most sighted users, who are usually able to effortlessly point and click their way through complex applications, plus have the luxury of eyesight to compensate for any inaccessible features they might encounter. Second, being that I serve as a member of the Sakai QA team, which regularly utilizes Jira for creating and tracking tickets, I had to be able to learn how to do this myself, so I felt I should come up with easy to follow/understand steps for systematically completing these tasks that I could refer back to as needed. Finally, since I am responsible for helping on-board other blind/low-vision testers for Sakai, I wanted to leave a virtual breadcrumb trail for other screen reader users to be able to follow when it became their time to learn how to use these tools.
Now I should point out that while my primary motivation for creating these Jira user guides is to directly support the ongoing QA/accessibility testing efforts of the open-source Sakai Project, it was never my intention to just stop there. I’m operating under the assumption that there aren’t that many blind/low-vision users out there performing quality assurance work, or testing, or serving in other roles/functions that are part of the software development life cycle, and therefore, even fewer screen reader users who have any sort of practical experience using ticketing systems like Jira. So, for the budding blind/low-vision QA analyst wondering whether it’s possible to use Jira with their screen reader, I wanted these guides to serve as an emphatic ‘yes’ with the hope that providing them with access to these tips can help them to build their own technical skills/add to their body of knowledge.
Like Blindly Driving A Typhoon Class Sub Through A Deep Sea Canyon
As noted above, this article will build upon basic information about the Jira ticketing system that was previously covered in our March 29 blog. If you missed our first blog post, or would like to re-familiarize yourself with Jira, you can click here to view detailed step-by-step descriptions for how a JAWS screen reader user can perform some of the more common tasks in Jira.
For this next installment in our multi-part blog series, we are focusing on how to create Jira tickets.
Before we move on, I thought I would take a moment to describe my process for learning/evaluating this particular feature, as it greatly contributed to my brutally honest assessment of the Jira creation portal which follows.
Like any other situation where I find myself needing to learn a new tool/feature, I decided that the best way to learn how to create a Jira ticket was by doing exactly that.
Master Yoda said it best… “Try not, do” which are words of wisdom that we can all strive to live by.
So, I gently set the boulders that I had been levitating down onto the swampy ground, and logged into Sakai’s instance of Jira to create a ticket for an issue that I had observed during some of my recent testing.
Through much trial and error, and with an occasional assist from my fourteen-year-old who I had looking over my shoulder to clarify what was happening when I got into some sticky situations, I managed to bump and swear my way through the Jira creation modal.
Even though I had succeeded with completing my main objective, I knew that there were likely things that I screwed up along the way, that I would probably need to go back in and fix.
So, that Thursday when I met up with my colleagues Shawn and Gonzalo for our weekly “WAM-A11Y” interactive test session, I proposed using the screenshare feature in Zoom to walk through the entire Jira creation process so they could spot-check my work.
Prior to launching into my demo, I clarified that there were several parts of the Jira creation process that I found to be confusing, because of the clunky way that my JAWS screen reader interacted with different parts of the modal.
For example, I found it was easiest to use tabbed navigation to move through the various fields, however, JAWS wouldn’t always announce which element you were landing on. But if you tried to use your arrow keys to orient yourself to where you were at in the modal, you risked having your cursor unexpectantly jump to some other part of the page, which was super confusing and frustrating.
As a result, after sufficiently familiarizing myself with the lay-out of the Jira creation modal, I used the mental map of the process that I had been building in my mind to define exact step-by-step instructions that could allow a screen reader user like me to compensate for these various blind spots.
In other words, it's possible to use the JAWS screen reader to create tickets in Jira, but only if you follow a certain prescribed way that is able to neutralize those parts of the modal that are still not screen reader compatible.
Joking with Shawn and Gonzalo, I likened my experience navigating the Jira creation modal to that memorable scene in the movie “Hunt for Red October” when Sean Connery’s character Captain Marco Ramius adeptly navigates his Typhoon class Russian submarine through the underwater labyrinth of canyons known as “Red Route One” using only his memory of the rock formations and the internal clock in his head to shout out one precise turn after another.
This might seem a bit abstract without actually being able to demonstrate the behaviors, so maybe at some point I will create a video to accompany the below instructions, so anyone who is interested can actually see (hear) how the JAWS screen reader interacts with the Jira creation modal.
But for now, the step-by-step instructions should suffice, and there should be enough detail there to allow you to get started.
While the following steps reference some Jira features/components/processes unique to the Sakai Project, the general process for creating a Jira ticket should be similar regardless of what version of Jira you are using.
If you are interested in trying out Jira for yourself, below is a link to where you can sign up to access a free trial for Jira Cloud, hosted by Atlassian:
https://www.atlassian.com/software/jira/free
Moreover, for those of you who would like to try and recreate these steps to simulate the Jira experience for a JAWS screen reader user, you can visit the Freedom Scientific web site to download a trial version of JAWS that you can run in 40-minute demo mode.
It should be noted that I was using JAWS 2022 and the Google Chrome web browser when preparing these notes, so different versions of JAWS, or other screen reader/web browser combinations may yield completely different results.
How to Create Tickets in Jira
1--From within any Jira filter, use the tab, shift+tab, and up/down arrow keys to navigate to the “Create” button (last item in the “Primary Navigation Region”) and press enter.
Note: You can also use the JAWS pass-through command Insert+3 followed by “C” to open the Jira creation modal.
2--When the page refreshes, a Jira creation modal will appear on the screen and your cursor will be inserted into the “Summary” text field.
Note: The “Project” and “Issue Type” fields actually proceed the “Summary” field, and these will be pre-populated with the last project you used in Jira and the default/top issue type for that project. If you are always in the “SAK” project, then it should always select that project. But if you use multiple projects, it will be the last project you visited before clicking the create button.
3—The purpose of the “Summary” field is to provide a brief description of the ticket or issue. With your cursor in the editable text field, you can begin to type out the summary of your ticket, or you may find it easier to type this information out in advance (for example, in a MS Word document) so that you can easily cut and paste the information into the provided text field by using the Control+C (copy) or Control+X (cut) and Control+V (paste) keyboard commands.
4--Next, tab to the “Priority” field which will be set to “Major” by default. You can use the up/down arrow keys to change the priority to “Minor,” “Critical,” or “Blocker” by highlighting the option you want and pressing enter.
5--Next, tab to the “Component” field and use the provided text field to enter any components. Keep in mind that tickets can contain multiple components. Typically, you will want to add the specific tool/feature that you were testing on when you observed the issue. For accessibility-related issues, you will also want to add the “Accessibility” component to the ticket (note: as you start to type a term, it will auto-complete so that you don’t have to type out the entire name of the component)
6--Press enter to add the component(s) you would like, and then tab to the “Affects Version” field.
7--Again, you can use the provided text field to begin typing in the affects version(s), for example, 22.0, pressing enter after each entry you would like to add (note: For trunk/master, type in the most recent version, in this case “23.0” which should be listed as “tentative”
8--Next, you’ll want to press tab several times to skip past the “Assignee” and “Environment” fields until you come to the “Main Content Area” for entering a “Description”
9--Again, it may be easier to cut and paste the “Description” from text that you’ve already prepared in a MS Word document.
10--Next, you will want to press tab several times until you reach the “Main Content Area” for the “Test Plan” field.
11--Cut and paste the “Test Plan” information into the provided text field.
12—From here, if you press tab, your cursor will land on the “browse” button for the “Attachment” option. If you wish to add a video or other attachment to your ticket, press enter and use the file picker to browse a list of available drives to locate the file you want to attach and press enter.
13--Next, press tab a couple of times to skip past the “Security Level” fields to the “Labels” field.
14--Start typing in any labels you would like to add to the ticket, being sure to Press enter after each label you add (note: as you start to type the name of an existing label, the field should auto-complete. If the word you’ve entered doesn’t already exist as a label, the label will be created automatically)
15--Tab past the “Conversion Script,” “Create Another Issue,” and “Cancel” options until you reach the “Create” button and press enter to finish.
16--You will get a Success message indicating that your ticket has been created with its unique SAK number.
17--Sometimes Jira will automatically assign someone based on particular components that are selected/added to the ticket, so you may need to go back into the SAK ticket and change the “Assignee” field to “Unassigned” if this happens.
18--Also, you will notice that the “Activity” section (for adding comments) is not available during the Jira creation process, so if you wish to add notes to your ticket, you can do this once it is created.
What Else?
While the above instructions cover most of what you will need to know for creating tickets in Jira using the JAWS screen reader, there were still some parts of the Jira creation modal that I found problematic and/or unable to use with my assistive technology.
For example, I wasn’t able to figure out how to get the “mention” button to work, which is used for tagging people on specific Jira tickets.
Also, throughout my testing, I continued to experience weird behavior with the labels field where the auto-complete feature wasn’t allowing me to select/activate the correct label.
Similarly, I found that when referencing a specific SAK-ticket when adding a comment, Jira would automatically create a link to the ticket in the comment which would result in my screen reader losing focus, so I would have to go back in to the recently saved comment and edit the text to replace any of the information that got cut off.
Now, if I want to reference a specific issue in a new comment, I will start by typing in the numeric portion of the ticket, and then when I have finished entering my entire note, I will go back and add the “SAK” prefix in front of the numbers.
It's not ideal, but it is a temporary work around that you can use.
In future installments of this multi-part blog series we may come back to tackle some of these unresolved issues, assuming that we are able to figure out how some of these tasks can be done using the JAWS screen reader. And of course we will continue to cover other features of the Jira ticketing system, possibly even engaging other blind/low-vision Jira users to describe their own experiences. Who knows, maybe the folks at Atlassian will even want to get involved, since they too have a vested interest in improving the accessibility of their products.