Created new studioBanner for form validation#5214
Conversation
|
Thanks @yeshwanth235! High-level it is aligned with expectations. We will assign someone for a detailed review soon. Meanwhile, would you be able to update to align with this acceptance criteria?
It should be a straightforward update - let us know if you had any questions. And for accessibility, I forgot to mention it in the issue - to make error information accessible to screen readers, could you use useKLiveRegion to send a polite (recommended by our a11y lead) message to the live region when the error banner text is displayed? The message should be translated and the same as error banner text. |
|
Added the useKliveRegion @MisRob One doubt regarding test cases. Instead of using @vue/test-utils. Are you suggesting to use @testing-library/vue for writing test case? |
|
Yes @yeshwanth235 |
|
updated the test cases @MisRob |
|
Thanks @yeshwanth235. My good colleague @AllanOXDi will review your pull request :) |
There was a problem hiding this comment.
Thanks @yeshwanth235 for the great work on this! 🙌 Overall, everything looks good A few notes and suggestions - I am not sure why the error is persistent but not showing me the required field
| }, | ||
| }, | ||
| watch: { | ||
| errorText(newText) { |
There was a problem hiding this comment.
This block only runs when the errorText prop changes. It does NOT run if
the error prop changes from false to true while the text stays the same. Th banner may appears with error: false and errorText: and error becomes True, but errorText doesn't change. I think we should also watch the error prop or, even better, watch a computed property that combines both error and errorText to decide when to announce
There was a problem hiding this comment.
If we were to announce every error count update, then yes, this would make much sense.
However, I'd like to suggest not using watcher to not overwhelm screen reader users whose experience is different from those that are sighted. Sighted users perceive more kinds of information at once. Screen reader users get information in a linear way, one by one, and if there's too much of it, it can get difficult.
For now, instead of using watcher, let's only announce banner error text after user clicks submit button. That will be the most reasonable start. Later when we have a11y QA in Studio, we can further adjust if needed (there will likely be more work in this form anyway that's not in scope of this particular task).
There was a problem hiding this comment.
Sure, will update it misRob
There was a problem hiding this comment.
It seems that announcing got lost completely in the last version @yeshwanth235. Were there any issues with implementing what's suggested?
| expect(screen.getByText(sampleInfoMessage)).toBeInTheDocument(); | ||
| }); | ||
|
|
||
| test('error true with errorText', () => { |
There was a problem hiding this comment.
None blocking: it may be good to add a test for when errorText is empty or error is false to ensure the banner still renders correctly without triggering sendPoliteMessage.
| mockSendPoliteMessage.mockClear(); | ||
| }); | ||
|
|
||
| test('smoke test - with default props', () => { |
There was a problem hiding this comment.
renaming this to something like renders banner with error text to describe behavior more explicitly.
Screen.Recording.2025-08-07.at.15.58.59.mov |
|
Will check it, and will push the changes. |
I check this issue. It is happening in main branch as well. Can you please help to create an issue. @AllanOXDi |
|
Hi @yeshwanth235 and @AllanOXDi - I wanted to note that after it's re-reviewed, let's wait for merging until I let you know. This is due to pre-release preparations, and will take only a couple of days. Yes @yeshwanth235, you don't need to fix something that was present on |
|
@AllanOXDi @yeshwanth235 I was just notified, we can merge PRs now. Allan, do you have any other feedback? |
| <template> | ||
|
|
||
| <div | ||
| class="banner notranslate" |
There was a problem hiding this comment.
Since div contains text. Hence kept the class.
There was a problem hiding this comment.
notranslate is only for some user-generated texts. To prevent Google Translate from translating it.
So here can be removed.
It's a bit nuanced. Generally when working on Studio, you can remember that for anything that's application text, we don't want to prevent translation.
There was a problem hiding this comment.
One of my colleagues recently summed it up nicely. Hopefully it helps to understand.
Studio's UI isn't translated into as many languages as Kolibri, but being an online service, we've supported using in-browser Google Translate as an option for those unsupported languages. The notranslate class then tries to align that behavior like it was a UI language option-- only translating Studio's UI and not user-generated text.
|
Let me re review it |
|
|
||
| const banner = screen.getByTestId('studio-banner'); | ||
| expect(banner).toBeInTheDocument(); | ||
| expect(banner).toHaveClass('banner', 'notranslate'); |
There was a problem hiding this comment.
There's no need to test for presence of classes - it doesn't really say that much about resulting user experience, and also ties tests to internal implementation.
|
Thanks for review @MisRob Updated the PR. Please help to review @AllanOXDi and @MisRob |
MisRob
left a comment
There was a problem hiding this comment.
Thanks @yeshwanth235, two last notes from me. Unless @AllanOXDi has some feedback, I believe we can then merge.
| } | ||
|
|
||
| .studio-banner { | ||
| margin-top: 8px !important; |
There was a problem hiding this comment.
Will check and update it
| const slotContent = this.$slots.default; | ||
| const textContent = slotContent[0].text; | ||
| if (textContent && this.error) { | ||
| this.sendPoliteMessage(textContent); |
There was a problem hiding this comment.
Almost there :) Screen reader now properly announces the error message when I click "Send request" for the first time, while not announcing each dynamic change to error count as I requested 👍
However when I fix few errors, but not all of them, and click the button again, it doesn't announce. This is because the same banner is displayed, and mounted is not executed again. Maybe we could simply sendPoliteMessage in Send request click handler, outside StudioBanner component? Since StudioBanner itself doesn't really have enough context to distinguish between what's dynamic error count updates and what's the error message when the form is clicked again.
There was a problem hiding this comment.
Made changes @MisRob. Thanks for the suggestion.
Now sendPoliteMessage will be called in onValidationFailed. Which is triggered by form validation. So from now on when ever the submit is click. If there are any errors sendPoliteMessage will be sent.
MisRob
left a comment
There was a problem hiding this comment.
Thanks @yeshwanth235 @AllanOXDi.
Nice work. Screen reader now reports in a balanced manner 👍

Summary
Created a new studioBanner for form validation.
Replaced Banner component with new studioBanner
Screenshots:




References
5082
Reviewer guidance
Check storage request form validation.
If there are any errors new banner should be shown.
On change of any field. Should update error count in banner