Screening questions page

[brindasasi]

✨ Feature

Screening questions should be shown for user answers

🕵️ Details

Add any additional details that could assist with the development of the new feature.

🎨 Design File

https://www.figma.com/file/BXYVsu1fo9LS2IySJDUINY/Applicants---Job-application?node-id=636-59839&t=JufuhV0iNsTnIOxc-0

📸 Screenshot

🙋‍♀️ Proposed Implementation

(optional) Do you have a proposed implementation?

🌎 Localization

EN	FR	Description
Answer key questions about your fit in this role.	Répondez aux questions clés sur votre adéquation à ce rôle.	Application step for screening questions, page subtitle
A few related questions	Quelques questions sur le sujet	Application step for screening questions, introduction title
In the final step of the application, we’d like to ask you a handful of opportunity-specific questions that help us understand your unique fit.	Dans la dernière étape de la candidature, nous aimerions vous poser quelques questions relatives à l’occasion qui nous aideront à comprendre votre profil unique.	Application step for screening questions, introduction description, paragraph one
Your answers will be assessed as a part of your application, so be sure to give each question the time and thought required for an answer that really represents you and your experience.	Vos réponses seront évaluées dans le cadre de votre candidature, alors assurez-vous de donner à chaque question le temps et la réflexion nécessaires pour une réponse qui vous représente vraiment, vous et votre expérience.	Application step for screening questions, introduction description, paragraph two
I’m ready!	Je suis prêt!	An action button to proceed
Screening questions	Question de sélection	Application step for screening questions, title
Don’t forget to take a break if you need to! Using the “Save and quit for now” button, you can record your progress and return to questions you might be stuck on later.	N’oubliez pas de faire une pause si vous en avez besoin! À l’aide du bouton « Enregistrer et quitter pour l’instant », vous pouvez enregistrer les renseignements que vous avez fournis et revenir aux questions sur lesquelles vous pourriez être bloqué plus tard.	Application step for screening questions, description
Let’s review my application	Passez en revue ma candidature	Action button to proceed to reviewing the application

✅ Acceptance Criteria

A set of assumptions which, when tested, verify that the feature was properly implemented.

• [ ] This page exists at the proper route (behind feature flag
• [ ] On this page, page subtitle and breadcrumbs appear correctly
• [ ] The inner contents of the page (so not the hero and stepper layout) have a storybook story
• [ ] Save button should save the answers in the DB and take the user back to the dashboard
• [ ] Let’s review my application should also save the answers in the DB

Out of Scope

• Taking the user to review page if it is not built yet

🛑 Blockers

Blocked by #6021

[github-actions[bot]]

Status: Ready to merge :heavy_check_mark:

Issues blocking this PR:

• 6021 :heavy_check_mark:

  ---

  This comment was automatically written by the Blocking Issues bot, and this PR will be monitored for further progress.

[vd1992]

Assuming this was an accidental removal of estimate when moving to Product Backlog, restoring the estimate of 3

[esizer]

Should the label for the textarea be the question rather than "Your answer to question {number}"? We will need to associate the question to the input for AT's anyway and the best way to do that is with a label.

[petertgiles]

Should the label for the textarea be the question rather than "Your answer to question {number}"? We will need to associate the question to the input for AT's anyway and the best way to do that is with a label.

I commented on this in my review. Unfortunately it doesn't look good for multiline questions - of which I suspect will be most of them.

[esizer]

I commented on this in my review. Unfortunately it doesn't look good for multiline questions - of which I suspect will be most of them.

This is going to be a very large issue since AT users typically navigate forms by tabbing through each input individually and hear the label read out to them. So what they will hear is something like:

• Textarea, Answer to question 1
• Textarea, Answer to question 2

With no concept of what the actual question is. So they would then need to go back up to hear the question be read and make an assumption that what they just heard was question 1 with no certainty unless they go back up and hear the heading being read. That means, in order to reliably answer a question the user would need to do:

• tab
• AT Key + up
• AT Key + up
• tab

Hearing the text in the opposite order it was meant to be read. Which would get old, very quick 😢

[JoshBeveridge]

Is it not reasonable to wrap the textarea and question inside of a fieldset and use the legend to describe the question?

Edit: for clarity, it would seem weird to me for the question to be read as the input label... the logical flow in my head should be "question 1: How did you...? textarea: your answer to question 1"

[esizer]

Is it not reasonable to wrap the textarea and question inside of a fieldset and use the legend to describe the question?

No, since the legend is not read out on all AT. 😢 Also, it is required to make the labels self-explanatory and "Answer to question 1" is not self-explanatory without knowing what the question is, especially with common navigation technique of listing form inputs to quickly navigate a form.

When listing form inputs a user would just hear:

• Answer to question 1
• Answer to question 2

With no knowledge of what the actual questions are.

Fieldsets are meant for grouping multiple similar inputs and typically not used for single inputs.

[JoshBeveridge]

ATs not reading out legends seems like an AT problem to me, not an incorrect use of the HTML 🤔

Another option is to use a more descriptive labelled-by... But at any rate, this is a pretty common pattern used out in the wild, where the question isn't the label directly. Making the question the label seems like a bad option all around, both because it's not demanding an action and because the length would exceed a reasonable label format.

The link you sent has an instance of this happening right in their examples:

[esizer]

Making the question the label seems like a bad option all around, both because it's not demanding an action and because the length would exceed a reasonable label format.

I would argue that asking a question, associating it with an input and making it required is demanding an action (response to the question). Though, I agree it is very ugly and we should avoid it if possible 😅

The link you sent has an instance of this happening right in their examples:

Yes, that is why I specified "... typically not used for single inputs". It can be done, but since the legend is not guaranteed to be read out to ATs, it is not the best pattern available and it should be treated as supplementary information, not key information.

Another option is to use a more descriptive labelled-by

I think this may be a good solution, labelled-by supports multiple IDs and we are already doing this with the aria-describedby 👍 . We will just need to update our inputs to accept additional values here and test it. I believe the resulting HTML should look similar to the following:

<h2>Question 1</h2>
<p id="question-1">What is your name?</p>
<label id="question-1-label" for="question-1-answer">Answer to question 1</label>
<textarea id="question-1-answer" label="Answer to question 1" aria-labelledby="question-1 question-1-label">Answer</textarea>

[JoshBeveridge]

Hmm, I do still take issue with:

Yes, that is why I specified "... typically not used for single inputs". It can be done, but since the legend is not guaranteed to be read out to ATs, it is not the best pattern available and it should be treated as supplementary information, not key information.

If the WCAG website has an example of exactly this behaviour in the context of using the legend element (i.e. using the legend to ask a question and the input's label as a direct value), I'm inclined to suggest we're okay to use it. If we were to decide not to, it basically removes the purpose of the legend element entirely, and that impacts not only this element, but all fieldsets, including checkbox groups, radio groups, and the new design for our dates. Each input inside that fieldset would no longer have the context of the larger legend to define what the day, month, and year apply to.

If we're trying to support all ATs (a goal I don't necessarily think is reasonable), we wouldn't be using ARIA either, because of its inconsistent implementation. In this case, I lean towards the HTML standard over anything else.